Неофициальный docker-контейнер АнтиЗапрета

antizapret.prostovpn.org АнтиЗапрет на собственном сервере (self-hosted)
303

проблема в том, что перестал работать adguard. Не могу зайти в web-интерфейс, запустил docker compose logs adguardhome для просмотра информации, но там вроде бы всё хорошо, за исключением сообщения о буфере, может быть критичным?

adguardhome  | 2024/08/28 13:55:46.447379 [info] AdGuard Home is available at the following addresses:
adguardhome  | 2024/08/28 13:55:46.447600 [info] go to http://127.0.0.1:80
adguardhome  | 2024/08/28 13:55:46.447607 [info] go to http://[::1]:80
adguardhome  | 2024/08/28 13:55:46.447610 [info] go to http://172.18.0.2:80
adguardhome  | 2024/08/28 13:55:46.448025 [info] clients: processing addresses
adguardhome  | 2024/08/28 13:55:46.473063 [info] go to https://MY_SERVER_HOST:443
adguardhome  | 2024/08/28 13:55:47.739503 [info] dnsproxy: starting dns proxy server
adguardhome  | 2024/08/28 13:55:47.739745 [info] dnsproxy: creating udp server socket 0.0.0.0:53
adguardhome  | 2024/08/28 13:55:47.740135 [info] dnsproxy: listening to udp://[::]:53
adguardhome  | 2024/08/28 13:55:47.740301 [info] dnsproxy: creating tcp server socket 0.0.0.0:53
adguardhome  | 2024/08/28 13:55:47.740502 [info] dnsproxy: listening to tcp://[::]:53
adguardhome  | 2024/08/28 13:55:47.740906 [info] dnsproxy: creating tls server socket 0.0.0.0:853
adguardhome  | 2024/08/28 13:55:47.741116 [info] dnsproxy: listening to tls://[::]:853
adguardhome  | 2024/08/28 13:55:47.741287 [info] creating listener quic://0.0.0.0:853
adguardhome  | 2024/08/28 13:55:47.744694 failed to sufficiently increase receive buffer size (was: 208 kiB, wanted: 7168 kiB, got: 416 kiB). See https://github.com/quic-go/quic-go/wiki/UDP-Buffer-Sizes for details.
adguardhome  | 2024/08/28 13:55:47.745921 [info] listening quic://[::]:853
adguardhome  | 2024/08/28 13:55:47.753887 [info] dnsproxy: entering udp listener loop on [::]:53
adguardhome  | 2024/08/28 13:55:47.754304 [info] dnsproxy: entering tcp listener loop on [::]:53
adguardhome  | 2024/08/28 13:55:47.754858 [info] dnsproxy: entering tls listener loop on [::]:853
adguardhome  | 2024/08/28 13:55:47.755144 [info] Entering the DNS-over-QUIC listener loop on [::]:853

на всякий скидываю файл docker для adguard

services:
  antizapret-vpn:
    extends:
      file: docker-compose.yml
      service: antizapret-vpn
    environment:
      - DNS=adguardhome
      - ADGUARD=1
    depends_on:
      - adguardhome
  adguardhome:
    image: adguard/adguardhome
    container_name: adguardhome
    hostname: adguardhome
    restart: unless-stopped
    ports:
      # - 53:53/tcp
      # - 53:53/udp
      # - 80:80/tcp
      # - 443:443/tcp
      # - 784:784/udp
      # - 853:853/tcp
      - 3000:3000/tcp
#    dns:
#      - 1.1.1.1
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - ./.adguard/confdir:/opt/adguardhome/conf
      - ./.adguard/workdir:/opt/adguardhome/work
304

Кинетик при подключении к VPN (по крайней мере, OpenVPN) не игнорирует адреса, полученные от провайдера (даже доисторическая прошивка Padavan это умела, а вот KeeneticOS не умеет).

Поэтому, если просто поднять туннель, кинетик будет использовать как адреса от провайдера, так и адрес DNS АнтиЗапрета. Соответственно, обход блокировок будет работать по принципу “работает в зависимости от того, кто первым успел ответить”.

Если же отключить получение адресов от провайдера вообще, то при падении туннеля (например, если сервер умрет или Роскомнадзор начнёт резать протокол) некому будет резолвить вообще.

Отсюда необходимость в принципе прописывать сторонние DNS и создавать роуты.

Вдобавок, приходится создавать отдельный профиль DNS для клиентов, потому, что без него возникают проблемы в некоторых случаях, когда провайдер использует PPPoE (в случае, когда подключение к провайдеру по IPoE, можно ограничиться добавлением DNS в системный профиль, не создавая профиль для клиентов).

Но это всё относится к OpenVPN. Поскольку инструкцция писалась под “официальный” АнтиЗапрет, она не тестировалась с WG и другими протоколами.

305

Да, отлично. В этом и была причина, благодарю!

306

Спасибо за отличное обьяснение! Просто люди начинают эти роуты использовать и в asus, что бы решить пробему которой там, кажется, нет :slight_smile:

307

В ipsec.env есть переменная VPN_IPSEC_PSK, откуда её брать или как сгенерировать?

308

Это любая строка на ваш выбор. В клиенте это называется общий ключ.

309

А тут?

Screenshot_12
Screenshot_121627×245 16.1 KB

310

Спасибо огромное за разъяснение этого момента! Значит не зря я эти роуты добавлял, потому что у Keenetic с WG в этом плане такая же история, как и с OVPN

311

@xtrime осталось для полного фарша добавить поддержку XRay (XTLS Realty) и вообще не страшно будет, даже если WG\OVPN прихлопнут, то такой прокси уже просто так не потушить :slight_smile:

312


932×190 18.9 KB

Они так предлагают. Т.е. в локальной пишите свою сеть, а в удаленной как раз то что надо проксировать: 10.0.0.0 - 255.0.0.0 (/8)

313

А там есть tunnel split? Я кажется только в openconnect видел. Но плохо разбираюсь во всех этих современных штуках.

314

Может быть это ответит на ваш вопрос: Introduction - sing-box

315

Не получается подключить пишет нет соединения. А с wireguard на смартфоне вроде бы работает, но на Keenetic по инструкции выше не работает.

316

Достаточно добавить OpenConnect, который маскируется под HTTPS, имеет кучу клиентов под все платформы и поддерживается даже в Keenetic (на данный момент - в бета-версиях).

317

Спасибо, почитал про OpenConnect и действительно, это то что нужно
Завернуть под HTTPS и там хоть об блокируйся, потому что по сути придётся весь HTTPS на 443 блокировать

318

Знакомый devops подсказал, что wg на 443 порту не блочат :slight_smile:
Запушил фикс На мегафоне он начал работать: ASC для WireGuard (AmneziaWG) · Issue #54 · xtrime-ru/antizapret-vpn-docker · GitHub

Обновляйтесь через git pull, пересоздавайте контейнер и скачивайте обновленный конфиг. Ну или руками поправить порт в старом конфиге.

PS

  • Мам, давай сделаем OpenConnect?
  • У нас есть OpenConnect дома!
    OpenConnect дома:
    image-29-e1670231093526-427x372
319

Спасибо!
Только единственное:
Переменная WG_PORT в docker-compose.wireguard.yml говорит именно WG внутри контейнера юзать 443, как основной порт подключения, а значит в компоузе проброс должен быть таким:

ports:
- “443:443/udp”

Либо оставлять WG порт внутри контейнера дефолтный (не трогать переменную WG_PORT, дефолтный порт 51820), а маппить в самом компоузе на хостовый порт 443, тогда текущий маппинг будет верный:

ports:
- “443:51820/udp”

320

Спасибо, проверю и поправлю сейчас. Второй вариант точно не правильный, так как переменная так же отвечает за генерацию клиентских конфигов. И там должен быть 443.

321

сломалось. не принимает трафик

322

Sep 8 11:20:30 ovpn-client3[20654]: Data Channel: cipher ‘AES-128-GCM’, peer-id: 2
Sep 8 11:20:30 ovpn-client3[20654]: Timers: ping 2, ping-restart 10
Sep 8 11:20:30 ovpn-client3[20654]: Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
Sep 8 11:20:32 ovpn-client3[20654]: Initialization Sequence Completed
Sep 8 11:20:41 ovpn-client3[20654]: [antizapret-server] Inactivity timeout (–ping-restart), restarting
Sep 8 11:20:41 ovpn-client3[20654]: SIGUSR1[soft,ping-restart] received, process restarting
Sep 8 11:20:41 ovpn-client3[20654]: Restart pause, 1 second(s)

И так постоянно.