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 овде и објаснуваат зошто рутер без оваа функција се однесува нормално. Локален неуспех што надворешниот свет не може да го репродуцира е прашање на превод додека не се докаже спротивното, затоа тестирајте го како такво.