Не использовать слишком простые пароли, не выполнять команды из интернетов без понимания что они делают (особенно под root или через sudo), собственно не работать под root, не открывать сомнительные файлы, не запускать исполняемые файлы неясного происхождения (да, и .exe тоже - они могут выполниться через wine или mono и оказаться вирусосодержащим продуктом, который пошифрует файлы на Linux так же хорошо, как и на винде).
Соершенно бессмысленно покупать "платную лицензию" на 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).
Интересная ситуция... Возможно домен у них просто отобрали (судя по всему, они там торговали справками).