Кстати, намедни дебажил отсутствия маршрутизации на опенврт. Выяснил, что опенврт не смог прописать маршруты, что передает опенвпн сервак, в итоге дописал в клиентский конфиг эти строки, все сработало.
route 10.224.0.0 255.254.0.0
dhcp-option DNS 192.168.104.1
ufw allow 1194/tcp
ufw allow 1194/udp
Открывайте порты в впс’е, а не в контейнере антизапрета
Добрый день, как побороли? Я уже и согласно рекомендациям сделал в скрипте
sudo ufw allow in on lxdbr0
sudo ufw route allow in on lxdbr0 и 1194, перед командой machinectl enable antizapret-vpn. Не отрабатывают скрипты финальной настройки т.к. нет инета внутри контейнера. А фаерволл совсем выключать не хочется (
Большим жирным шрифтом. Если у вас интерфейс не lxdbr0, необходимо подправить команды.
Если у вас есть какие-то дополнительные запрещающие правила, необходимо также разобраться с тем, что они запрещают.
У меня не сработало. Новая машина Ubuntu 20.04 на Vultr по инструкции в ридми.
Last login: Sat Jun 18 16:26:27 2022 from 92.255.102.90
root@vultr:~# systemctl disable --now ufw
Synchronizing state of ufw.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable ufw
root@vultr:~# machinectl stop antizapret-vpn
root@vultr:~# machinectl start antizapret-vpn
root@vultr:~# sleep 20
root@vultr:~# machinectl copy-from antizapret-vpn /root/easy-rsa-ipsec/CLIENT_KEY/antizapret-client-tcp.ovpn /root/antizapret-client-tcp.ovpn
Failed to copy: No such file or directory
Как это вообще дебажить? Логин в контейнер требует пароль.
Когда-то ставил себе антизапрет на CentOS 7,
нашёл в своих заметках, может, кому ещё пригодится (на полную правильность всего не претендую, я не профессиональный линуксоид)
yum -y update
reboot
yum -y install epel-release
yum -y update
yum -y install yum-plugin-copr
yum -y copr enable ngompa/snapcore-el7
yum -y install snapd
systemctl enable --now snapd.socket
yum -y install http://download.zfsonlinux.org/epel/zfs-release.el7_4.noarch.rpm
yum -y install yum-utils
yum-config-manager --disable zfs
yum-config-manager --enable zfs-kmod
yum -y install zfs
grubby --args="user_namespace.enable=1" --update-kernel="$(grubby --default-kernel)"
grubby --args="namespace.unpriv_enable=1" --update-kernel="$(grubby --default-kernel)"
sh -c 'echo "user.max_user_namespaces=3883" > /etc/sysctl.d/99-userns.conf'
reboot
snap search lxd
snap install lxd
ln -s /var/lib/snapd/snap /snap
snap list
snap services
usermod -a -G lxd root
newgrp lxd
id
lxc list
lxd init
nano /etc/systemd/system/snap.lxd.daemon.service
[Service]
Environment=LXD_INSECURE_TLS=true
systemctl restart snap.lxd.daemon.service
lxc image import https://antizapret.prostovpn.org/container-images/az-vpn --alias antizapret-vpn-img
lxc init antizapret-vpn-img antizapret-vpn
lxc config device add antizapret-vpn proxy_1194 proxy listen=tcp:[::]:1194 connect=tcp:127.0.0.1:1194
lxc config device add antizapret-vpn proxy_1194_udp proxy listen=udp:[::]:1194 connect=udp:127.0.0.1:1194
lxc start antizapret-vpn
sleep 10
lxc file pull antizapret-vpn/root/easy-rsa-ipsec/CLIENT_KEY/antizapret-client-tcp.ovpn antizapret-client-tcp.ovpn
kscp -P 22 -pw <password> root@<ip_addr>:./antizapret-client-tcp.ovpn antizapret-client-tcp.ovpn
Только что попробовал, взяв скрипт и добавив в самое его начало правила ufw — сработало. Обратите внимание, что по ссылке правила для LXD, а для systemd-machined необходимо изменить название интерфейса на “ve-antizapr+”. Вот полный текст скрипта (но у меня, почему-то, он не выполнился до конца, пришлось запускать вручную):
Спойлер
#!/bin/bash
ufw allow in on ve-antizapr+
ufw route allow in on ve-antizapr+
export DEBIAN_FRONTEND=noninteractive
export APT_LISTCHANGES_FRONTEND=none
apt update
apt -y install systemd-container dirmngr
mkdir -p /root/.gnupg/
gpg --no-default-keyring --keyring /etc/systemd/import-pubring.gpg --keyserver hkps://keyserver.ubuntu.com --receive-keys 0xEF2E2223D08B38D4B51FFB9E7135A006B28E1285
machinectl pull-tar https://antizapret.prostovpn.org/container-images/az-vpn/rootfs.tar.xz antizapret-vpn
mkdir -p /etc/systemd/nspawn/
echo -e "[Network]\nVirtualEthernet=yes\nPort=tcp:1194:1194\nPort=udp:1194:1194" > /etc/systemd/nspawn/antizapret-vpn.nspawn
systemctl enable --now systemd-networkd.service
machinectl enable antizapret-vpn
machinectl start antizapret-vpn
sleep 20
machinectl copy-from antizapret-vpn /root/easy-rsa-ipsec/CLIENT_KEY/antizapret-client-tcp.ovpn /root/antizapret-client-tcp.ovpn
machinectl shell antizapret-vpn для доступа внутрь контейнера.
Спасибо, уже прошло дальше, файл .ovpn появился, правда пришлось заново переустановить машину. Но VPN не подключается, таймаут. Подключается с выключенным файерволом:
systemctl disable --now ufw
Пробовал порт разрешать, но не помогло:
ufw allow 1194
Хорошо было бы обновить в итоге инструкцию в ридми для Vultr, а то она не рабочая получается.
Всем привет!
Не нашел готового докер контейнера, а по инструкции отсюда Bitbucket внутри контейнеров для LXD и systemd-machined небыло интернета.
Разбираться не стал и конвертнул образ LXD в docker. Через него все завелось!
Закинул на гитхаб:
Имхо старт получился проще, чем в LXD или systemd-machined. Если бы еще нативный Dockerfile сделать, а не конвертить, было бы шикарно…
@ValdikSS буду признателен за фидбэк! Если все ок, то мб можно перенести мой код в основной репо или добавить инструкцию в readme?
Docker предназначен для контейнеров приложений (application container): в контейнере, как правило, запускается единственная программа как init 1, образ не может самостоятельно обновляться (его необходимо коммитить), и т.п.
LXD и machined — системные контейнеры (system container) — предназначены для контейнеризации всей системы, по принципу виртуальной машины.
Я удивлён, что у вас в принципе запускается systemd (/usr/sbin/init) внутри — все эти годы Docker не поддерживал systemd. Docker — неподходящий инструмент для целей контейнеризации антизапрета.
Всем доброго времени!
Установил контейнер, но столкнулся с проблемой - при подключении к VPS с ОС Ubuntu 20.04, на котором поднят контейнер, страницы не открываются. Браузер весело посылает в тухес с сообщением “ERR_NAME_NOT_RESOLVED”.
В самом контейнере интернет есть.
Connected to machine antizapret-vpn. Press ^] three times within 1s to exit session.
root@antizapret-vpn:~# ping ya.ru
PING ya.ru (87.250.250.242): 56 data bytes
64 bytes from 87.250.250.242: icmp_seq=0 ttl=241 time=68.027 ms
64 bytes from 87.250.250.242: icmp_seq=1 ttl=241 time=68.049 ms
64 bytes from 87.250.250.242: icmp_seq=2 ttl=241 time=68.065 ms
64 bytes from 87.250.250.242: icmp_seq=3 ttl=241 time=67.992 ms
64 bytes from 87.250.250.242: icmp_seq=4 ttl=241 time=67.960 ms
64 bytes from 87.250.250.242: icmp_seq=5 ttl=241 time=67.998 ms
64 bytes from 87.250.250.242: icmp_seq=6 ttl=241 time=68.017 ms
^C— ya.ru ping statistics —
7 packets transmitted, 7 packets received, 0% packet loss
round-trip min/avg/max/stddev = 67.960/68.015/68.065/0.033 ms
root@antizapret-vpn:~# nslookup ya.ru
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: ya.ru
Address: 87.250.250.242
Name: ya.ru
Address: 2a02:6b8::2:242
root@antizapret-vpn:~#
Подскажите, куда ковырнуть?
UFW отключен и не используется. Пробовал включать, в порядке бреда пробрасывать порт 1194 - то же самое. Голову сломал
Убедитесь, что DNS knot-resolver’а внутри контейнера работает:
dig ya.ru @127.0.0.1
systemctl status kresd@1
Привет!
Во-первых, всегда хотел сказать спасибо за антизапрет. Пользуюсь уже долгое время, никаких проблем не возникало.
Во-вторых, я потестил Docker-контейнер от xtrime, и он прекрасно работает, но я не совсем понял что под самостоятельным обновлением образа ты имел в виду. Мол, нужно будет поддерживать Docker-образ и обновлять его после новых коммитов в репо на Bitbucket или что-то другое?
В контейнере настроены автоматические обновления безопасности компонентов ОС, что позволяет не беспокоиться об актуальности софта без его пересборки. С Docker такое не получится, его концепция подразумевает «заморозку» образа, что несёт прямо противоположный эффект.
можно подробней пояснить про безопасность?
мне не совсем понятно, для чего в самом lxd-контейнере нужны эти обновления безопасности?
по сути – если обновляются только сами нужные для работы функционала списки,
проброшен только нужный порт,
к чему обновлять сам контейнер, не достаточно ли обновлять по безопасности только сам хост-сервер?
Добрый день, работало перу дней стабильно и без нареканий, вчера заметил что вечером не коннектится. Начал копать, выяснил что doall.sh ругается на закончившееся свободное место.
Безопасность контейнеров приложений
Основной целью атаки и потенциальным местом наличия уязвимостей является софт внутри контейнера, ведь именно c ПО внутри контейнера ведётся взаимодействие пользователя, оно содержит и обрабатывает ваши данные, и именно к этому ПО злоумышленник имеет прямой сетевой доступ. Его защита и обновление является первостепенной задачей обеспечения безопасности.
Системы контейнеризации обеспечивают изоляцию одного контейнера от другого и от хост-системы, но каких-либо дополнительных методов защиты ПО внутри контейнера не предоставляют. В этом плане работа ПО внутри контейнера не отличаются от его работы просто в хост-системе, без контейнеризации.
Если злоумышленнику удалось взломать ПО и получить доступ внутрь контейнера, он может применять атаки к хост-системе (на ПО контейнеризации и к ядру системы), чтобы повысить привилегии и выйти из контейнера, поэтому также важно обновлять и ПО хост-системы.
Системные контейнеры, вроде АнтиЗапрета, содержат полноценную операционную систему и пакеты, установленные из официальных репозиториев дистрибутива. В VPN-контейнере есть только два нештатных компонента: DNS-ремаппер и скрипт обновления списка заблокированных сайтов. Всё остальное ПО внутри контейнера стандартное, что позволяет настроить автоматические обновления безопасности дистрибутива, переложив ответственность за это на мейнтейнеров дистрибутива — людей, которые лучше всего в этом разбираются. Причем в Debian, на котором построен контейнер, автообновления реализованы гибко и надёжно — можно настроить обновления пакетов только в случае исправлений безопасности, а не всех подряд.
Контейнеры приложений, в отличие от системных, подразумевают миниатюрную файловую систему из минимально необходимых компонентов для запуска ПО, а также заморозку образа в состоянии на момент сборки. Это удобно на этапе разработки, для ПО вне репозитория или для устаревшего, которому нужны определённые версии библиотек, но перекладывает ответственность за поддержание сторонних компонентов внутри контейнера в актуальном состоянии и на создателя этого контейнера (компоненты необходимо обновлять, а контейнер пересобирать), и на пользователей (контейнер необходимо обновлять), чего я стремлюсь избегать — лучше доверить эту работу более компетентным и ответственным мейнтейнерам дистрибутива.
Как сказал системный администратор Amarao:
Docker — это отличная возможность переложить проблемы поддержания актуальных версий системных библиотек (того же самого openssl) с поставщиков ОС и системных администраторов на никого. После того, как проблемы безопасности окружения переложены на никого, скорость внедрения и эксплуатации заметно возрастает, ведь производительность никого ограничена только супремумом пофигизма, а он, в свою очередь, верхней границы не имеет
Сделал как вы сказали, но все равно пинги не идут
Отвечу сам на свой вопрос. 10Gb SSD не хватает на хост и контейнер. Может зря обновил ОС. Каталог cuda (в /usr/local/cuda/lib64) весит под 2.8 Gb, думаю, надо ли он? Тесновато под систему, работает пару дней, потом сама себя логами перегружает и все. Нет места. Делать апгред пакета за 3.5 уе до 5, в котором 25 гиг на SSD? Или можно почистить ручками ненужное?
10 хватает. Помимо антизапрета стоит еще один vpn-сервер на самом хосте, 2 месяца уже спокойно всё работает
UPD: полная конфигурация: 1 ядро, 1гб RAM, 10гб SSD, Debian 11, контейнер systemd, в общем всё занимает почти 4гб
