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

Доброго времени! Спасибо за ответ.

root@antizapret-vpn:~# dig ya.ru @127.0.0.1

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> ya.ru @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21058
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ya.ru.                         IN      A

;; ANSWER SECTION:
ya.ru.                  600     IN      A       87.250.250.242

;; Query time: 299 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jun 22 12:57:28 MSK 2022
;; MSG SIZE  rcvd: 50

root@antizapret-vpn:~#

root@antizapret-vpn:~# systemctl status kresd@1
● kresd@1.service - Knot Resolver daemon
   Loaded: loaded (/lib/systemd/system/kresd@.service; enabled; vendor preset: e
nabled)
  Drop-In: /etc/systemd/system/kresd@.service.d
           └─override.conf
   Active: active (running) since Wed 2022-06-22 12:57:01 MSK; 2min 1
6s ago
     Docs: man:kresd.systemd(7)
           man:kresd(8)
 Main PID: 381 (kresd)
   CGroup: /system.slice/system-kresd.slice/kresd@1.service
           └─381 /usr/sbin/kresd -c /usr/lib/knot-resolver/distro-preconfig.lua
-c /etc/knot-resolver/kresd.conf -n

Jun 22 12:56:59 antizapret-vpn systemd[1]: Starting Knot Resolver daemon...
Jun 22 12:56:59 antizapret-vpn kresd[381]: [system] warning: hard limit for numb
er of file-descriptors is only 4096 but recommended value is 524288
Jun 22 12:57:01 antizapret-vpn systemd[1]: Started Knot Resolver daemon.
root@antizapret-vpn:~#

Судя по ответам - внутри контейнера все работает.
Что еще посмотреть? Влияют ли как то на работоспособность DNS сервера, которые я использую? Использую не провайдерские, а публичные.
бесплатный хостинг фотографий
Ссылку на скриншот из настроек роутера прилагаю.
Спасибо еще раз за Ваш труд

Обновление unattended upgrades запускается в моем контейнере автоматически. Я чекнул docker diff и в списке измененных файлов есть лог. Правда apt ругается:

W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://download.opensuse.org/repositories/home:/CZ-NIC:/knot-resolver-latest/Debian_10  InRelease: The following signatures were invalid: EXPKEYSIG 74062DB36A1F4009 home:CZ-NIC OBS Project <home:CZ-NIC@build.opensuse.org>

apt update && apt upgrade руками выдает туже ошибку. Это точно проблема в докере, а не в самом образе? Если есть какая то команда, что бы прописать эту signature, то я добавлю ее в entrypoint и автообновление все будет работать.

Спасибо за критику! Согласен, что запуск нескольких приложений внутри одного контейнера противоречит docker-way концепции.
Но инструкции из readme у меня не сработали. А докер многим привычнее и запуск гораздо проще. И заработал сразу…
Из проблем которые вижу: если какой то процесс упадет - то докер не перезапустит контейнер. Нужно делать какой нибудь healthcheck. Хотя не уверен, что lxd как то решает эту проблему…
Хотя у меня все работает стабильно уже неделю, так что пока не горит :slight_smile:

Починил apt update и запушил фикс в свой репо. Теперь система обновляется при сборке образа и автоматически при работе контейнера.

ValdikSS, flameshikari, спасибо за фидбек.


Ссори за холивар, но тут не соглашусь. Почему не получится? Образ это просто “основа” для контейнера. А контейнер никак не ограничивает работу с диском. Система в контейнере будет обновляться, и данные из файловой системы контейнера никуда не денутся даже при перезагрузках. Конечно, изменения записываются в отдельный “слой” файловой системы докера, но на практике это почти ни на что не влияет.

Согласен, что концепция докера не приветствует такие вещи, но на практике используется часто…

https://antizapret.prostovpn.org/help.html

‣ VPN АнтиЗапрета подключается, но заблокированные сайты не открываются

Убедитесь, что используете DNS-сервер внутри VPN-соединения, а не сторонний или провайдерский. Проверьте, что не используете DNS over HTTPS в браузере («Защищенный DNS»), Private DNS в Android, Private Relay в iOS.
Требование вызвано особенностями маршрутизации в VPN АнтиЗапрета.