Hairpin-NAT: hvorfor VPN-endepunktet svigter indefra

En VPN-server, der svarer fra et mobilnetværk og svigter fra sofaen, er normalt ikke et certifikatproblem. Klienten inde i LAN'et beder routeren om at oversætte en pakke, hvis destination er routerens egen offentlige adresse, hvilket betyder, at pakken skal forlade netværket og komme direkte tilbage ind. Den manøvre kaldes hairpinning, og mange routere implementerer den enten slet ikke eller kun, når en afkrydsningsboks er aktiveret. Det er den beståede test udefra, der gør det forvirrende, fordi den beviser, at lytteren og videresendelsesreglen er i orden.

Pakken går ud og kommer ind igen

Følg pakken. Klienten slår det offentlige navn op, forbinder til den offentlige adresse, og routerens destinations-NAT omskriver destinationen til den interne server. Svaret fra serveren er adresseret til klientens LAN-adresse, så det går tilbage gennem routerens LAN-interface uden nogensinde at passere den NAT-regel, der ville have tilbageoversat kilden.

Nu modtager klienten en pakke fra en adresse, som den aldrig har sendt noget til, og kasserer den. Den asymmetri er hele fejlen.

RFC 4787 beskriver den adfærd, en NAT forventes at have i dette tilfælde, og den korte version er, at den i praksis er valgfri, selv hvor den er specificeret i teorien. Nogle routere kalder indstillingen NAT loopback, andre kalder den hairpin NAT eller NAT reflection, og nogle viser slet intet. En router, der mangler den, er ikke fejlkonfigureret; den gør det sædvanlige, og rettelsen hører til et andet sted. Konkludér ikke ud fra en mislykket lokal test, at den offentlige videresendelsesregel er forkert.

Kontrol 1: test de to veje hver for sig

Udefra LAN'et forbinder du med den samme profil, som en rigtig bruger ville bruge, og bekræfter, at sessionen etableres. Indefra forbinder du til den offentlige adresse med den samme profil og noterer den præcise fejl og tidspunktet.

En præcis lokal test beholder værtsnavnet og tilsidesætter kun adressen: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ sender anmodningen til den offentlige adresse, mens den stadig præsenterer det korrekte servernavn. Det adskiller et navneopløsningsproblem fra et oversættelsesproblem, som er lette at forveksle, når det samme navn virker fra en café. Bemærk, om klienten fejler ved TCP-forbindelsen eller senere ved TLS, fordi det første peger på oversættelse og det andet på identitet.

Kontrol 2: læs, hvad serveren ser

Den mest nyttige observation er serverens syn. Kør en optagelse på VPN-værten filtreret på klientens LAN-adresse og på routerens LAN-adresse, og gentag så det lokale forsøg. Hvis intet ankommer, overlevede pakken ikke oversættelsen.

Hvis en forbindelse ankommer fra routerens LAN-adresse i stedet for klientens, sker der hairpinning, og kilden blev omskrevet. Det er en fungerende konfiguration, ikke en fejl.

Kontrol 3: ret det uden at røre den ydre vej

Der findes tre understøttede former, i stigende rækkefølge efter omfang. Den snævreste er delt DNS: udgiv en intern post, så det samme servernavn opløses til den interne adresse for klienter på LAN'et, hvilket helt undgår den offentlige vej. Den næste er at aktivere routerens dokumenterede loopback- eller reflection-indstilling, hvis den har en, og kun anvende den på denne tjeneste. Den bredeste er en source-NAT-regel på routeren, der omskriver LAN-trafik til serveren, så svaret vender tilbage gennem routeren; på en Linux-router er det en MASQUERADE regel i POSTROUTING , der matcher serverens adresse og port. Alle tre holder den eksterne vej urørt, og det er den egenskab, der skal bevares.

Du skal ikke udvide urelateret portvideresendelse for at få den lokale vej til at ligne den eksterne, og du skal ikke flytte tjenesten til en anden port for at omgå problemet. Begge ændringer ændrer, hvad omverdenen kan nå, for at rette noget, som kun den indre verden ser.

Delt DNS har én fælde, der er værd at nævne. At erstatte et værtsnavn med en vilkårlig IP ændrer, hvad klienten validerer, så den interne post skal stadig matche certifikatets navn.

Kontrol 4: verificér begge veje bagefter

Gentag det eksterne forsøg udefra LAN'et, gentag det interne forsøg med den samme profil, og bekræft, at serverloggen viser to forskellige vellykkede sessioner i stedet for én succes og én tavshed. Kontrollér derefter, at andre klienter stadig når lytteren, og at ruterne til private ressourcer er uændrede.

Hold registreringen kort: hvilken adresse hver klient brugte, hvad serveren så, og hvilken af de tre rettelser der blev anvendt. Hairpinning-kravene i RFC 4787 er referencen for, hvad en NAT forventes at gøre her, og de forklarer, hvorfor en router uden funktionen opfører sig normalt. En lokal fejl, som omverdenen ikke kan genskabe, er et oversættelsesspørgsmål, indtil det modsatte er bevist, så test det som sådant.