Meshnet, Docker и разрешение между ними

Два URL могут выглядеть одинаково в браузере узла и означать для межсетевого экрана совершенно разные вещи. Один указывает на службу, слушающую на самом хосте. Другой указывает на адрес хоста, порт которого опубликован в сеть контейнеров, где шаг трансляции передаёт соединение другому IP. В одноранговой сети, которая управляет доступом к локальной сети разрешением для каждого узла, эта разница и есть весь разбор.

Разрешение касается конечной точки хоста, трансляция касается Docker, а вход касается приложения. Три решения, три места, куда смотреть.

Следите за назначением после публикации

Возьмите хост Linux с Docker, публикующий порт 80 контейнера на порту хоста 8080. Узел подключается к сетевому адресу хоста на 8080, хост принимает соединение, и трансляция назначения переписывает его на адрес моста контейнера, обычно что-то вроде 172.17.0.2 на порту 80.

К тому времени, когда правило проверяет этот поток, интересующее назначение — контейнер, а не хост. Политика, которая рассуждает только о «службе на этой машине», рассуждает о неверном объекте. Запрос приземлился на хосте, но доставляется в другое место.

Именно поэтому документация сети перечисляет контейнеры Docker среди ресурсов, которыми управляет разрешение локальной сети в Linux. Разрешение не является синонимом обычной записи в списке разрешённых VPN, и два этих средства контроля не заменяют друг друга. Одно решает, может ли узел вообще достичь локальных ресурсов; другое решает, какие назначения несёт туннельный маршрут.

Решите, сколько локального доступа даёт разрешение

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

Затем посмотрите, где Docker публикует порт. Публикация на 0.0.0.0 создаёт слушателя на каждом адресе хоста, что может добавить обычную запись LAN рядом с записью сети. Если требование — только сеть, привяжите публикацию к конкретному адресу или интерфейсу, который вы имеете в виду, и рассматривайте более широкую привязку как отдельную находку, а не как удобство.

Держите политику пересылки хоста и собственную аутентификацию приложения достаточно узкими для службы. URL, выглядящий приватным, не является контролем доступа, а контейнер, доверяющий каждому источнику в своей мостовой сети, не защищён тем, что узел сети был одобрен. Аутентификация приложения — третье решение, и единственное, которое знает, кто пользователь. Разрешение на уровне хоста не может дать этого знания.

Проверьте разрешение, а не только URL

С одобренного узла откройте точную службу и убедитесь, что она работает. Затем попробуйте назначение, которое должно остаться запрещённым, и убедитесь, что оно не работает. Проверка только счастливого пути говорит, что разрешение выдано; она не говорит, что граница там, где вы думаете.

Отдельно сравните службу, свойственную самому хосту. Если база данных слушает на хосте, а панель работает в контейнере, они идут разными путями через одно и то же разрешение и могут управляться политикой пересылки хоста неодинаково. Запишите, что есть что, прежде чем писать заметку о разборе.

Не очищайте таблицы Docker или правила клиента сети, чтобы «сбросить» доступ. Оба продукта устанавливают свою интеграцию политик, и её удаление даёт хост, который выглядит работающим, но обходит те средства контроля, которые вас просили оценить. Если правило выглядит неверным, прочитайте его и измените именно это правило. Если вы не можете объяснить, что делает правило, это и есть находка, а не причина его удалять.

Напишите находку в терминах самой системы

Важно то различие, которое продукт действительно обеспечивает, а не то, что в шаблоне разбора: разрешение достичь конечной точки хоста, разрешение достичь маршрутизируемых приватных ресурсов и разрешение пользоваться приложением. Публикация порта оставляет эти три решения ровно там, где они были, и проверяющий, который считает их одним, одобрит неверную область.

Укажите адрес хоста, опубликованный порт, назначение контейнера и разрешение узла в одном предложении. Это предложение может проверить кто-то другой, и именно это делает его находкой, а не мнением.