Hairpin NAT: защо крайната точка на VPN не работи отвътре

VPN сървър, който отговаря от мобилна мрежа и се проваля от дивана, обикновено не е проблем със сертификата. Клиентът вътре в LAN иска от рутера да преобразува пакет, чиято дестинация е собственият публичен адрес на рутера, което значи, че пакетът трябва да излезе и веднага да се върне. Тази маневра се нарича hairpinning и много рутери или не я реализират, или я включват само при отметка. Именно успешният тест отвън обърква, защото доказва, че слушателят и правилото за препращане са наред.

Пакетът излиза и се връща

Проследете пакета. Клиентът резолвва публичното име, свързва се с публичния адрес и NAT за дестинация на рутера пренаписва дестинацията към вътрешния сървър. Отговорът на сървъра е адресиран до LAN адреса на клиента, затова се връща през LAN интерфейса на рутера, без изобщо да преминава през NAT правилото, което би върнало източника.

Сега клиентът получава пакет от адрес, към който не е изпращал нищо, и го изхвърля. Тази асиметрия е цялата повреда.

RFC 4787 описва поведението, което се очаква от NAT в този случай, и кратката версия е, че на практика то е незадължително, дори където е зададено теоретично. Някои рутери наричат настройката NAT loopback, други — hairpin NAT или NAT reflection, а трети не показват нищо. Рутер без нея не е конфигуриран грешно; той прави обичайното нещо и поправката принадлежи другаде. Не заключавайте от неуспешен локален тест, че публичното правило за препращане е грешно.

Проверка 1: тествайте двата пътя поотделно

Отвън LAN се свържете със същия профил, който би използвал реален потребител, и потвърдете, че сесията се установява. Отвътре се свържете с публичния адрес със същия профил и запишете точната грешка и часа.

Точният локален тест запазва името на хоста и замества само адреса: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ изпраща заявката към публичния адрес, като същевременно представя правилното име на сървъра. Това отделя проблема с резолвването на имена от проблема с преобразуването, които лесно се бъркат, когато същото име работи от кафене. Отбележете дали клиентът се проваля при TCP свързване или по-късно при TLS, защото първото сочи към преобразуването, а второто към идентичността.

Проверка 2: прочетете какво вижда сървърът

Най-полезното наблюдение е гледната точка на сървъра. Стартирайте прихващане на VPN хоста, филтрирано по LAN адреса на клиента и по LAN адреса на рутера, после повторете локалния опит. Ако нищо не пристига, пакетът не е преживял преобразуването.

Ако връзка пристига от LAN адреса на рутера, а не от този на клиента, hairpinning се случва и източникът е пренаписан. Това е работеща конфигурация, не дефект.

Проверка 3: поправете, без да пипате външния път

Съществуват три поддържани форми, в нарастващ ред на радиус на действие. Най-тясната е разделен DNS: публикувайте вътрешен запис, така че същото име на сървър да резолвва към вътрешния адрес за клиентите в LAN, което напълно избягва публичния път. Следващата е включване на документираната опция loopback или reflection на рутера, ако има такава, и прилагането ѝ само към тази услуга. Най-широката е правило source-NAT на рутера, което пренаписва трафика от LAN към сървъра, за да се върне отговорът през рутера; на Linux рутер това е правило MASQUERADE в POSTROUTING със съвпадение по адреса и порта на сървъра. И трите оставят външния път незасегнат и точно това свойство трябва да се запази.

Не разширявайте несвързано препращане на портове, за да заприлича локалният път на външния, и не местете услугата на друг порт, за да заобиколите проблема. И двете промени менят какво може да достигне външният свят, за да поправят нещо, което вижда само вътрешният.

Разделеният DNS има един капан, който си струва да се назове. Замяната на име на хост с произволен IP променя това, което клиентът валидира, затова вътрешният запис трябва да съвпада с името в сертификата.

Проверка 4: проверете двата пътя след това

Повторете външния опит отвън LAN, повторете вътрешния опит със същия профил и потвърдете, че журналът на сървъра показва две отделни успешни сесии, а не един успех и едно мълчание. После проверете, че други клиенти още достигат слушателя и че маршрутите към частни ресурси не са се променили.

Дръжте записа кратък: кой адрес е използвал всеки клиент, какво е видял сървърът и коя от трите поправки е приложена. Изискванията за hairpinning в RFC 4787 са ориентирът за това какво се очаква от NAT тук и обясняват защо рутер без тази функция се държи нормално. Локален провал, който външният свят не може да възпроизведе, е въпрос на преобразуване, докато не се докаже противното, затова го тествайте като такъв.