Одна сессия SSH, одно веб-приложение и один поиск имени могут разделять одно VPN-соединение, не борясь за порты. Клиент строит один шифрованный поток к шлюзу, и каждый разговор приложения идёт внутри него. Снаружи видны только собственный транспорт туннеля и его порт. Внутри каждая служба сохраняет свой порт и по-прежнему требует своего разрешения.

Что несёт внешний поток и что он скрывает

Клиент оборачивает каждый пакет в транспорт туннеля до того, как пакет покинет машину. У этого внешнего потока один порт назначения, зафиксированный при настройке VPN. Внутри обёртки каждый исходный пакет сохраняет адрес и порт той службы, к которой он направлен. Шлюз снимает обёртку и маршрутизирует по внутреннему заголовку, поэтому получатель видит обычного клиента, приходящего из сети.

Поэтому перехват на интерфейсе WAN показывает один разговор, а не три. Внутренние порты появляются только после декапсуляции. Именно поэтому одно открытие брандмауэра может нести SSH, HTTPS и DNS одновременно.

# WAN side: one outer tuple, whatever the inner services are
tcpdump -ni wan0 'udp port 443'
# tunnel side: the inner tuples appear after decapsulation
tcpdump -ni tun0

Документация TUN/TAP описывает передачу, при которой маршрутизируемое устройство TUN передаёт IP-пакеты между ядром и процессом в пространстве пользователя. Именно эта передача делает внутренний заголовок видимым для кода маршрутизации и брандмауэра шлюза. Она также объясняет, почему внешний порт ничего не говорит о том, какие службы разрешены.

Переадресация NAT принадлежит слушателю, а не приложениям

Самостоятельно размещённому шлюзу за NAT IPv4 нужно одно входящее преобразование: публичный адрес и порт сопоставляются слушателю VPN. Никакое правило не требуется для SSH, HTTPS или DNS только потому, что пользователи туннеля до них доходят. Публикация этих портов открыла бы службы, которые туннель уже защищает. Правило переадресации описывает доступность слушателя, а не разрешение для чего-либо внутри.

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

Внутренняя политика — это место, где доступ действительно решается

Шифрование защищает путь; оно не даёт полномочий получателю. Маршруты клиента выбирают, какие префиксы входят в туннель, политика переадресации шлюза решает, могут ли пакеты его покинуть, а брандмауэр и вход на получателе решают, ответит ли служба. DNS — самый ясный случай: перенос запросов не заставляет резолвер принимать их из вашего пула клиентов. Каждый уровень может сказать нет независимо.

Проверяйте каждую службу отдельно через туннель. Успешный поиск ничего не говорит о веб-порте, а успешный веб-запрос ничего не говорит об SSH.

dig @10.40.0.53 app.corp.example
nc -vz 10.40.0.10 8443
ssh -p 2222 [email protected]

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

WireGuard проводит ту же границу

WireGuard называет свой внешний слушатель ListenPort, а внутреннее приложение по-прежнему использует тот порт службы, который ему нужен. AllowedIPs — это набор маршрутизируемых префиксов, а не список разрешённых портов служб. Чтение его как списка разрешённых портов даёт правила, которые не соответствуют тому, что делает туннель. Именование другое; слоистость та же.

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

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

Похожие статьи