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