Симметричный NAT и VPN: измеряйте отображение, а не ярлык

Тема поддержки заканчивается вердиктом «симметричный NAT, VPN здесь работать не будет», после чего клиент трижды без причины переустанавливают. Ярлык вредит, потому что отвечает на вопрос, которого никто не задавал. Клиент, который подключается наружу к фиксированному серверу, создаёт отображение в момент отправки первого пакета, и ответ разрешается обратно по правилам, которые реализует почти любая сеть. То, что отображение, зависящее от конечной точки, действительно усложняет, — это два партнёра, которые пытаются достичь друг друга одновременно, и это другая проверка.

За одним ярлыком скрываются два вопроса

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

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

Смешение двух вопросов даёт классический неверный диагноз: функция между партнёрами не работает, кто-то запускает тест типа NAT, видит худшую категорию и делает вывод, что и обычный туннель работать не может. Туннель никогда не был тем, что сломалось.

Отображение и фильтрация — разные свойства

Терминология RFC точнее названий, которые используют поставщики, и её стоит переносить в тикет, потому что она прекращает споры. Отображение — это то, как выделяется внешний порт. Фильтрация — это то, какие входящие пакеты пропускаются. Сеть может быть строгой в одном и либеральной в другом, и именно эта комбинация — то, что должен пережить протокол между партнёрами.

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

У фильтрации есть свои три случая и своё название для каждого. Написать в тикете «симметричный NAT», когда имеется в виду «фильтрация, зависящая от адреса и порта», отправляет следующего человека в неверную главу руководства. Оба ведут себя по-разному при проверке, так что ошибка не академическая.

Измеряйте отображение, а не называйте его

Выделенный порт можно наблюдать напрямую со стороны сервера любой службы UDP, которой вы управляете. Начните захват на публичном хосте, отправьте с клиента и прочитайте порт источника, с которым пришёл пакет:

sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820

Строка конечной точки — самая полезная из трёх, потому что WireGuard записывает последний адрес и порт, полученные от каждого партнёра. Сравните этот порт с тем, который клиент считает используемым. Они будут различаться всякий раз, когда происходит какое-либо преобразование, и важный вопрос — остаётся ли значение стабильным.

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

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

Выберите исправление, соответствующее сбою

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

Если сбойная функция — обычный туннель, поведение отображения не ваша проблема, и ничего из перечисленного не применяется. Проверьте, что клиент действительно отправляет, что сервер видит пакет и что ответ возвращается. Эта последовательность — три наблюдения, и она не требует знать что-либо о категории NAT маршрутизатора.

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

Записывайте архитектуру, а не вердикт

Полезная заметка говорит, какой протокол, в каком направлении начинается сеанс, есть ли на пути ретранслятор и что наблюдалось на проводе. «симметричный NAT, не работает» непригодно, потому что оно одновременно неверно про туннель и ничего не сообщает о пути партнёра.

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

Наконец, держите под рукой терминологию RFC 4787, когда будете это записывать. Использование точных терминов стоит одного предложения и не даёт следующему читателю повторить тот же неверный диагноз, и в этом весь смысл написания заметки.