Контейнер VPN АнтиЗапрета для установки на собственный сервер

и да, в логах постоянно предупреждение об отсутствии в конфиге
auth-nocache

так задумано?

Это фиктивное предупреждение, в конфигурационном файле не используется аутентификация по логину и паролю. Добавьте auth-nocache в ваш файл, если вас это предупреждение смущает.

уже)
но спасибо за пояснение для чайников :handshake:

и ещё, чтобы я уже окончательно отстал))
я раньше юзал скрипт автонастройки https://github.com/angristan/openvpn-install
у вас в контейнере используется необходимое/достаточное шифрование (не для параноиков вопрос, а интереса ради)? )))

Шифрование трафика надёжное. Для TCP используется AES-128, для UDP — Blowfish-64. Последний считается уязвимым, если у злоумышленника есть возможность захвата большого количества трафика, но OpenVPN меняет ключ каждые несколько десятков мегабайт, чтобы предотвратить подобную атаку.

Я не рекомендую использовать UDP-конфигурацию. Она устаревшая и оставлена для совместимости с клиентами, которые много лет не перекачивали конфигурацию с сайта. Актуальная конфигурация — TCP.
Поменяйте настройки шифра и отключите comp-lzo у себя, если хотите использовать UDP.

Она устаревшая и оставлена для совместимости с клиентами, которые много лет не перекачивали конфигурацию с сайта

ну дык это ж контейнер для личного сервера; полагаю, тут такие условности ни к чему

Поменяйте настройки шифра и отключите comp-lzo у себя, если хотите использовать UDP

Не знаю, правильно ли я сделал, но я в конфиге контейнера
/etc/openvpn/server/antizapret.conf
добавил
cipher AES-128-GCM
убрал
comp-lzo
изменил
ncp-ciphers AES-128-GCM

в конфиге antizapret-client-udp.ovpn
добавил
auth-nocache
cipher AES-128-GCM
убрал
comp-lzo

Здравствуйте! Скачал, запустил контейнер - работает.
Хочу использовать adguard dns, чтобы видеть меньше рекламы
роутер зухель (speedtester без usb=без opkg) корректно работает только в случае указания 192.168.104.1 в качестве единственного dns
в /root/dnsmap/proxy.py
указал p.add_argument("–upstream","-u",default=“94.140.15.15:53”,
в resolv.conf тоже
Всё равно остаётся очучение, что используется google dns
1)как точно это проверить?
2)как и где ещё вписать adguard dns?

Возможно поможет вам, а также другим, у кого проблемы с наличием интернета внутри контейнера. Также потратил какое-то время, пока не нашел решение.

Проблема заключается в использовании ufw в качестве фаервола в Ubuntu. Подробно описано здесь:

Читал по диагонали, но похоже, что ufw по-умолчанию не пробрасывает порты внутрь контейнера.
У меня такое было актуально на Ubuntu 20.04

Самое простое решение - прописать правила для сетевого интерфейса контейнера - lxdbr0:

sudo ufw allow in on lxdbr0
sudo ufw route allow in on lxdbr0

Ну и само собой, порт для подключения клиентов должен быть открыт:
sudo ufw allow 1194
У меня после этого всё заработало.

На данный момент, чтобы Knot Resolver принимал ответы от AdGuard Home необходимо так же прописать отключение проверок DNSSEC: trust_anchors.remove('.')
Без этого, dig google.com @127.0.0.1 внутри контейнера возвращает SERVFAIL, соответственно работать не будет.
(лог запроса в моем случае:

[plan] plan 'google.com.' type 'A' uid [58041.00]
[iter]   'google.com.' type 'A' new uid was assigned .01, parent uid .00
[cach]   => skipping exact RR: rank 030 (min. 030), new TTL -9724
[cach]   => no NSEC* cached for zone: google.com.
[cach]   => skipping zone: google.com., NSEC, hash 0;new TTL -123456789, ret -2
[plan]   plan '.' type 'DNSKEY' uid [58041.02]
[iter]     '.' type 'DNSKEY' new uid was assigned .03, parent uid .01
[cach]     => satisfied by exact RRset: rank 060, new TTL 159019
[iter]     <= rcode: NOERROR
[vldr]     <= parent: updating DNSKEY
[vldr]     <= answer valid, OK
[iter]   'google.com.' type 'A' new uid was assigned .04, parent uid .00
[plan]   plan 'com.' type 'DS' uid [58041.05]
[iter]     'com.' type 'DS' new uid was assigned .06, parent uid .04
[cach]     => satisfied by exact RRset: rank 060, new TTL 72803
[iter]     <= rcode: NOERROR
[vldr]     <= DS: OK
[vldr]     <= parent: updating DS
[vldr]     <= answer valid, OK
[iter]   'google.com.' type 'A' new uid was assigned .07, parent uid .00
[plan]   plan 'com.' type 'DNSKEY' uid [58041.08]
[iter]     'com.' type 'DNSKEY' new uid was assigned .09, parent uid .07
[cach]     => satisfied by exact RRset: rank 060, new TTL 72803
[iter]     <= rcode: NOERROR
[vldr]     <= parent: updating DNSKEY
[vldr]     <= answer valid, OK
[iter]   'google.com.' type 'A' new uid was assigned .10, parent uid .00
[nsre] score 21 for 185.93.109.76#00053;         cached RTT: -1
[resl]   => id: '13851' querying: '185.93.109.76#00053' score: 21 zone cut: 'com.' qname: 'gOOgLE.COm.' qtype: 'A' proto: 'udp'
[resl]   => id: '13851' querying: '185.93.109.76#00053' score: 21 zone cut: 'com.' qname: 'gOOgLE.COm.' qtype: 'A' proto: 'udp'
[iter]   <= ignoring mismatching response from 185.93.109.76#00053
[vldr]   <= bogus proof of DS non-existence
[iter]   'google.com.' type 'A' new uid was assigned .11, parent uid .00
[resl]   => no valid NS left
[resl]   finished: 8, queries: 3, mempool: 32800 B

)

Приветствую. Может кто объяснить как дать доступ клиенту antizapret-vpn на localhost машины где развернут lxd контейнер, т.е. чтобы клиент vpn смог выйти за рамки lxd контейнера. На localhost развернут небольшой хостинг, работает только в локальной сети, чтобы не городить второй vpn, хотелось чтобы на него можно было ходить через развернутый antizapret-vpn из внешней сети.

Добавьте в /root/antizapret/config/include-ips-custom.txt ваш IP-адрес, по одному на строку, затем запустите /root/antizapret/doall.sh и дождитесь его завершения.

Сделал, но пинг из под vpn все равно не проходит, из самого контейнера пинг идет. Попробовал добавить в server.conf push “route 10.0.0.0 255.255.255.0” Локальный ip сервера 10.0.0.218. В итоге ответ пинга

From 192.168.104.1 icmp_seq=1 Destination Port Unreachable

Я вас дезинформировал.
Измените /root/antizapret/doall.sh, добавив после ./update.sh ваш IP-адрес, обязательно с CIDR. Вот так:

./update.sh
echo '10.0.0.218/32' >> temp/list.csv
./parse.sh
./process.sh

Затем запустите doall.sh, с правильной локалью:
LANG=C.UTF-8 /root/antizapret/doall.sh

Больше ничего делать не нужно. Изменять конфигурационный файл openvpn тоже не нужно.

Спасибо, все заработало.

Возникла еще одна необходимость, нужно получить доступ с сервера, где развернут antizapret в lxd, до клиента vpn на определенный порт, на клиенте разрешил доступ, в итоге из контейнера получилось достучатся, за пределами контейнера, с хост машины, не получилось. Попробовал в ручную задать “sudo ip route add 192.168.104.0/22 via 10.83.198.1 dev lxdbr0” Пинг проходит до 192.168.104.1, до клиента 192.168.104.2 нет. думаю надо iptables ковырять.
Заранее спасибо, возможно решение на поверхности, но моих познаний пока не хватает.

Вернулся к выше сказанному еще раз, нужно было достучатся на определенный порт клиента. С хост машины. Получилось только так **lxc config device add antizapret-vpn proxy_1880 proxy listen=tcp:[::]:1880 connect=tcp:192.168.104.2:1880** Возможно это костыль, но другого на ум не чего не пришло.

В /etc/ferm/ferm.conf, в table filter chain FORWARD, добавить в самый верх:

interface $EXT_INTERFACE saddr ВАШ_IP_АДРЕС outerface vpn+ ACCEPT;

После чего перезагрузить контейнер.
Маршрут также нужен, ваша команда похожа на правильную.

Попробовал добавить. Как понял нужно указать ip клиента (или хост машины), пробовал то и то, но пинг до клиента так и не проходит.

Вам нужно еще и на клиенте добавить маршрут до IP-адреса вашего сервера, чтобы он мог вам ответить. Сейчас пакеты с сервера клиенту доходит, но он отвечает на них через ваш домашний маршрутизатор/шлюз провайдера.

Проще сделать так, как вы изначально сделали. Либо же настройте обычный VPN под ваши нужды и маршрутизируйте фиктивный диапазон и DNS-сервер из контейнера АнтиЗапрета.

Здравствуйте. Спасибо за контейнер. Поднял на бесплатном сервере от Oracle, под управлением Ubuntu 20.04. У меня пара вопросов, если вам не трудно:

  1. Голый сервер вместе с контейнером занимают 83% от выделенного 1 Гб оперативной памяти. Я, честно говоря, рассчитывал на меньшее потребление. Дело в Ubuntu?
  2. Из коробки не работает) Я добавил правила в ufw, разрешив порты, но это тоже не сработало. Помогло фактическое разрешение всего в iptables:
iptables -P INPUT ACCEPT
iptables -P OUTPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -F
iptables --flush

Но данное решение мне не нравится, а квалификации в настройке iptables у меня 0. Может подскажете, какое правило надо добавить? Сейчас настройки (дефолтные) таковы:

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     icmp --  anywhere             anywhere             icmp parameter-problem /* generated for LXD network lxdbr0 */
ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded /* generated for LXD network lxdbr0 */
ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable /* generated for LXD network lxdbr0 */
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain /* generated for LXD network lxdbr0 */
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain /* generated for LXD network lxdbr0 */
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps /* generated for LXD network lxdbr0 */
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     udp  --  anywhere             anywhere             udp spt:ntp
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             /* generated for LXD network lxdbr0 */
ACCEPT     all  --  anywhere             anywhere             /* generated for LXD network lxdbr0 */
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     icmp --  anywhere             anywhere             icmp parameter-problem /* generated for LXD network lxdbr0 */
ACCEPT     icmp --  anywhere             anywhere             icmp time-exceeded /* generated for LXD network lxdbr0 */
ACCEPT     icmp --  anywhere             anywhere             icmp destination-unreachable /* generated for LXD network lxdbr0 */
ACCEPT     tcp  --  anywhere             anywhere             tcp spt:domain /* generated for LXD network lxdbr0 */
ACCEPT     udp  --  anywhere             anywhere             udp spt:domain /* generated for LXD network lxdbr0 */
ACCEPT     udp  --  anywhere             anywhere             udp spt:bootps /* generated for LXD network lxdbr0 */
InstanceServices  all  --  anywhere             link-local/16

Chain InstanceServices (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             169.254.0.2          owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.2.0/24       owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.4.0/24       owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.5.0/24       owner UID match root tcp dpt:iscsi-target /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.0.2          tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     udp  --  anywhere             169.254.169.254      udp dpt:domain /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.169.254      tcp dpt:domain /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.0.3          owner UID match root tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.0.4          tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     tcp  --  anywhere             169.254.169.254      tcp dpt:http /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     udp  --  anywhere             169.254.169.254      udp dpt:bootps /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     udp  --  anywhere             169.254.169.254      udp dpt:tftp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
ACCEPT     udp  --  anywhere             169.254.169.254      udp dpt:ntp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */
REJECT     tcp  --  anywhere             link-local/16        tcp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */ reject-with tcp-reset
REJECT     udp  --  anywhere             link-local/16        udp /* See the Oracle-Provided Images section in the Oracle Cloud Infrastructure documentation for security impact of modifying or removing this rule */ reject-with icmp-port-unreachable

Заранее спасибо за помощь.