Соершенно бессмысленно покупать "платную лицензию" на Linux для личного пользования. Она никогда не окупится и почти никаких реальных проблем почти никогда не решит.
corsarmaks, свитчи скорее всего будут работать как будто они в одном vlan, маршрутизатор сбрасывать опаснее.
Если "шифровльщик" реально обслуживает целую сетку, то должно скорее всего работать. Маршрутизатор из сети исключить и поразбираться с ним отдельно на досуге.
Youtube мог забанить выходную точку VPN. Я вчера буквально столкнулся - с хоста в хецнере без авторизации не пускает смотреть видео. При этом с хоста в другом датацентре пустило.
Все приличные CA позволяют заслать им CSR а не генерят ключ.
Но опять же, это всё неважно, потому что в https серверный ключ используется только для генерации сессионного ключа по диффи-хелману. И вот его CA узнать не может.
Тут риск скорее в том, что CA может сгенерить новый серт и начать изображать из себя тот же самый сайт, не являсь им.
Ayudag, это не всегда нужно, но у нас просто ICMP запрещены политикой сетевой безопасности и если пакет в транзитном узле пошлёт ICMP о фрагментации, то мы его не получаем.
Если вот прям все уменьшат MTU до 1450, то интернет перейдёт с 1500 на 1450 и таким как мы надо будет уменьшать MTU ещё сильнее, чтобы обходить проблему.
Что у провайдера не работает 1500 это само по себе уже нетиповая ситуация. Например, там VPN (какой-нить PPPoE) и это в него не пролазит 1500. На хосте MTU по умоланию ставится VPN-клиентом в 1450, а докер создаёт новый сетевой неймспейс с 1500. По идее, там могло бы работать и с фрагментацией, инициированной хостом, но что-то вот не работает, хотя возможно и это можно было бы починить (но работа с постоянной фрагментацией пакетов это всё равно нехорошо для эффективной работы сети).
Ayudag, у нас в конторе раньше ходила шутка, что все проблемы сводятся к трём:
1. Проблемы с дисками.
2. Проблемы с DNS.
3. Неправильный MTU.
Была однажды история, задеплоили новый сервер и забыли ему понизить MTU (мы всегда делаем, чтобы во все ipsec пролазило). И вот идёт трафик по протоколу с маленькими пакетами, всё работает, пока не случается всплеск трафика и пакеты склеиваются, переставая влезать в MTU, что приводит в итоге к потере этих пакетов и реконнекту по таймауту. Поддержка несколько часов пыталась убедить поставщика, что у нас всё хорошо и это у них проблемы :)
Ayudag, вполне нормально разные контейнеры запускать по-разному. Например, один из способов поднять VPN - это запустить его в host-контейнере.
Нужно только понимать, что host-контейнер это как запуск напрямую на хосте без сетевой изоляции. Если это понимать и учитывать - то всё нормально. А то например пусть есть сервис на порту 123 у которого есть ещё порт 456 с админским интерфейсом. Когда мы его запускаем в стандартной bridge-сети - то порт 123 мы явно публикуем, а порт 456 нет и это не вызывает вопросов. Но порт 456 в host-контейнере будет доступен снаружи, так что надо будет об этом позаботиться (выключить админский интерфейс или зарезать к нему внешний доступ явно).
1. Есть инструменты типа sslh которые могут несколько протоколов проксировать с одного порта в разные приложения. По крайней мере sslh умеет openvpn.
2. Можно использовать policy routing и с его помощью принимать трафик в разные реальные порты в зависимости от IP обращающегося. Но это не поможет против РКН, потому что они с любого IP детектят легко определимые протоколы VPN. Вероятно, ради этого и затевался вопрос? Нет, показом "другого сервиса" их не обмануть.
3. Всякие vless/reality/итд тут уже упомянули. Их пока не умеют детектить, а обилие спецнастроек позволяет рассчитывать, что они будут работать ещё долго путём манипуляции этими настройками.
mxelgin, вот там есть пример создания /etc/apt/sources.list.d/docker.list в Dockerfile. Надо по аналогии создать /etc/apt/sources.list. Как вариант, можно просто сделать
sed -i s/deb.debian.org/mirror.yandex.ru/ /etc/apt/sources.list
Ибо вряд ли там будет что-то похожее н deb.debian.org кроме как в хостах.
Ayudag, если это легальный API для приложений - то ограничения CORS к нему никто не будет применять, вместо этого контроль запросов происходит через ключи доступа.
mxelgin, deb.debian.org редиректит на ftp.debian.org. Вообще, можно заменить его на mirror.yandex.ru. Для этого в сборке своего контейнера также поменять /etc/apt/sources.list.
mxelgin, возможно, лучше тогда сразу поставить gitlab и всё организовать в нём. Он может и сборку с деплоем (CI/CD) с использованием Gitlab Runners, и образа для docker прям в нём можно хранить. Jenkins - это прям очень махровый опенсурс со всеми его недостатками: запутанный интерфейс, длинная история разных некритичных и критичных багов, куча проблем с безопасностью (в том числе в прошлом бывали прям жёсткие RCE без авторизции).
У нас Jenkins используется только для задач, которые напрямую с CI/CD не связаны и которые поэтому не привязаны к коммитам в репе приложения. Например, связанные с установкой новых серверов. А сборка приложений и деплой их в прод - это в Gitlab (плюс образа контейнеров складируются в Harbor).
Ayudag, DROP тут это policy, это что делется в случае если другие правила в этой цепочке не подошли. А судя по отсутствию правил, связанных с IP-адресами контейнеров, в цепочке DOCKER, ни одного контейнера не запущено или они не в bridge-сетях.
Можно посмотреть docker network inspect test-app для изучения чё как запущен контейнер. А также docker network inspect bridge - там будет в том числе список контейнеров с адресами.
