Исходный порт клиента против слушателя сервера в потоке VPN
Сравните два номера портов в одном туннеле: фиксированный слушатель сервера и кратковременный источник клиента, а также как между ними находится трансляция маршрутизатора.
В одном и том же разговоре появляются два номера, и ни один из них не ошибочен. Журнал сервера показывает слушателя, который предлагает службу, ноутбук показывает сокет, отправивший дейтаграмму, а маршрутизатор между ними может переписать второй номер на выходе. Сравнивать концы разговора полезнее, чем сами цифры. Сравнение ниже держит отдельно слушателя, клиентский сокет и транслированный источник, потому что они отвечают на разные вопросы.
Два номера, описывающие противоположные концы
Настроенный порт сервера — это адресат, к которому обращается клиент. Он зафиксирован политикой, присутствует в профиле и должен быть открыт на стороне сервера. Исходный порт клиента выбирается локально, обычно из эфемерного диапазона, и существует, чтобы ответу было куда прийти. Он может меняться при каждом переподключении, и ничто в архитектуре не зависит от его стабильности.
Маршрутизатор между ними может переписать этот источник в собственное сопоставление 'NAT'. Поэтому номер, наблюдаемый на сервере, часто никак не связан с тем, который выбрал ноутбук.
Где номер источника меняется на выходе
Возьмите вымышленный пример с IPv4: клиент за транслирующим маршрутизатором, сервер с одним слушателем 'UDP' и одна дейтаграмма, пересекающая оба. Таблица называет каждый конец и то, что с ним происходит, вместо повторного проигрывания пакета в трёх точках наблюдения.
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
Адресат постоянен в каждой строке, и меняется только идентичность источника. Требования UDP NAT различают внутренний адрес и порт и внешнее сопоставление, и это в точности разница между второй и третьей строками. Маршрутизатор может сохранить исходный порт клиента или выбрать другой; сохранение — не то, что приложение должно предполагать.
Прочитайте три конца на самих узлах
Списки ниже получены с трёх разных машин и вместе показывают весь разговор. Запустите первый на сервере, второй на клиенте, а третий там, где существует сопоставление. Одна строка журнала никогда не показывает все три.
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194Первый список доказывает, что сервер привязан к порту службы, и показывает, какой процесс им владеет. Второй показывает локальный сокет клиента и адресат, к которому он обратился. Третий показывает сопоставление, созданное маршрутизатором, и это единственное место, где появляется транслированный источник. Прочитайте их в этом порядке, и два номера перестанут выглядеть противоречивыми.
Что меняет переподключение, а что нет
Некоторые маршрутизаторы сохраняют исходный порт клиента, когда он свободен, а другие каждый раз выделяют другой. Оба поведения нормальны, и приложение, требующее первого, сломается на втором. Изменение сопоставления после переподключения или смены сети не является неисправностью сервера: клиент открывает новый сокет, маршрутизатор выделяет то, что имеет, а сервер видит новый источник на том же слушателе. Неисправностью было бы ожидать, что сервер примет трафик, адресованный произвольному порту клиента.
Клиенты OpenVPN из сообщества получают это поведение через nobind, что позволяет операционной системе выбрать локальный порт; удалённый порт по-прежнему берётся из профиля. Явная привязка — осознанный выбор, а не требование протокола. Сервер продолжает предлагать один конец, пока клиенты выбирают собственные локальные идентичности.
Помечайте уровни отдельно в записи
Внутри туннеля идёт второй разговор со своими портами. Запрос HTTPS, переносимый туннелем, имеет адресатом TCP 443, тогда как внешнее зашифрованное соединение использует UDP 1194, поэтому смена внешнего исходного порта ничего не меняет во внутренней службе.
Даже на внешнем уровне протокол важен. UDP 1194 и TCP 1194 — разные концы, и слушатель 'TCP' никогда не получит дейтаграмму UDP только потому, что номер совпадает. Документируя развёртывание, помечайте слушателя сервера, клиентский сокет и транслированный источник как три разные вещи и добавляйте транспорт к каждому.
Затем пусть политика следует ролям. Сервер открывает предусмотренный транспорт на своём слушателе и по-прежнему аутентифицирует партнёра; межсетевой экран клиента пропускает ответы на собственный исходящий обмен, не публикуя входящую службу. Фильтру без состояний нужен явно записанный обратный путь, и это практическая причина, по которой различение важно за пределами аккуратных схем.