Симетричен 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, когато го описвате. Използването на точните термини струва едно изречение и пречи на следващия читател да повтори същата грешна диагноза, а това е целият смисъл да се напише бележката.