L2TP/IPsec gjennom NAT: hva som faktisk bryter og hvorfor

Påstanden om at NAT bryter L2TP/IPsec er halvt sann og derfor ubrukelig. Adresseoversetting er normalt, NAT-traversal finnes nettopp for å overleve den, og millioner av klienter kobler til hver dag bak en ruter. Det som bryter, er et bestemt stadium av en bestemt utveksling: IKE får aldri svar, den innkapslede tunnelen forkastes av en policy som bare tillater én protokoll, eller mappingen utløper mens tunnelen er inaktiv. Når du vet hvilket stadium du er i, er rettelsen vanligvis én regel eller en keepalive, ikke et nytt VPN-design.

Myten er det gale spørsmålet

Det nyttige spørsmålet er ikke «bryter NAT dette», men «hvilken del av utvekslingen oversettes, og hva gjør enheten som oversetter med den». L2TP/IPsec er en lagdelt protokoll: IKE forhandler, ESP beskytter, og L2TP bærer PPP inne i den beskyttelsen. Adresseoversetting virker ulikt på hvert lag, og feilsignaturene kan skilles hvis du ser på forhandlingsstadiet i stedet for feildialogen.

En ruter som surfer på nettet uten problemer beviser bare at TCP med kildeportoversetting virker. Den sier ingenting om UDP 500, UDP 4500 eller protokoll 50, og det er nettopp disse tre tingene denne utrullingen avhenger av.

Stadium 1: IKE må i det hele tatt få et svar

Den første utvekslingen går til svareren på UDP 500. Kommer det ikke noe svar tilbake, betyr alt annet ingenting: den forhåndsdelt nøkkelen, forslaget og legitimasjonen forblir ulest. Følg med på forespørselen og svaret i stedet for å gjette ut fra klientens tidsavbrudd:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

En forespørsel uten svar betyr vanligvis at en brannmur eller operatøren lenger opp kaster pakken, ikke at serveren avviste den. Et svar med en varselnyttelast som nevner et forslag eller et sertifikatproblem betyr at pakkene kom frem og at forhandlingen feilet på innhold, som er en helt annen reparasjon.

Når begge parter sitter bak oversetting, trenger initiativtakeren bare å nå svareren, så de fleste utrullinger på klientsiden virker fra stadium 1. Hosting på serversiden er der inngangsproblemet starter, og det er grunnen til at de to situasjonene aldri bør diskuteres som én.

Stadium 2: innkapsling endrer hva brannmuren ser

ESP er en IP-protokoll, ikke en TCP- eller UDP-port, og vanlig portadresseoversetting har ikke noe portfelt å skrive om. Derfor flytter NAT-traversal den beskyttede nyttelasten inn i UDP 4500: innkapslingen gir enheten som oversetter noe den vet hvordan den skal oversette. Når det skjer, vil en brannmurregel som bare er skrevet for UDP 500, tillate forhandlingen og forkaste tunnelen, noe som gir det forvirrende resultatet der loggen viser en vellykket fase 1 og ingen trafikk.

Selve IKE-utvekslingen kan også flyttes til UDP 4500 etter at en NAT er oppdaget, noe som overrasker folk som har tillatt 500 og ingenting annet. Tillat begge portene i begge retninger på veien, og husk at en stateful brannmur bare holder flyten så lenge den ser trafikk.

Protokoll 50 er fortsatt viktig på veier uten oversetting, og på veier der en mellomliggende boks er konfigurert til å tillate den. Hvis du diagnostiserer ved eliminering, slå av hypotesen i stedet for å legge til regler i bunter: tillat 500, 4500 og ESP, bekreft at tunnelen kommer opp, og fjern deretter det som viste seg unødvendig. En regel ingen kan forklare, er en regel ingen fjerner når den blir årsaken til neste avbrudd. Skriv innsnevringen i endringsloggen sammen med stadiet den rettet, slik at neste ingeniør starter fra bevisene dine i stedet for fra den samme tommelfingerregelen.

Stadium 3: mappingen utløper og tunnelen dør

En enhet som oversetter, holder tilstand for flytene den videresender, og den tilstanden har en levetid. En L2TP/IPsec-tunnel bærer lite trafikk når ingen bruker den, så en inaktiv tunnel kan overleve mappingen sin og slutte å motta returtrafikk. Klienten forblir overbevist om at den er tilkoblet, serveren ser ingenting, og det første symptomet er vanligvis en applikasjonstidsavbrudd og ikke en VPN-feil.

Deteksjon av død peer og NAT-keepalives finnes for dette, og begge ender må være villige til å sende dem. Hvis serveren din er bak oversetting, er kravet på Windows-siden en dokumentert registerinnstilling som får serveren til å anta UDP-innkapsling for sine egne utgående pakker; uten den sender svareren ESP som enheten som oversetter ikke kan mappe tilbake. Det er et serverkonfigurasjonsproblem, ikke et klientproblem.

En endring av WAN-adressen gir samme utfall fra en annen retning: mappingen bygges opp igjen rundt en ny adresse, og den gamle sikkerhetsassosiasjonen peker nå på en tuppel som ikke finnes lenger. Gjenoppkoblingsatferd hører til klientimplementasjonen, og derfor virker «koble til på nytt etter at ruteren starter på nytt» på én klient og krever en manuell bryter på en annen.

Hosting bak carrier-grade NAT er et annet problem

Hvis du vil hoste en L2TP/IPsec-server hjemme og nå den utenfra, er kravet uoppfordret inngående tilgjengelighet, og det er ikke det NAT-traversal gir. En carrier-grade NAT foran ruteren din betyr at det ikke finnes noen port du kan videresende som gjør deg tilgjengelig, fordi den offentlige adressen er delt og mappingen bare er utgående.

Ingen IPsec pass-through-avkrysningsboks endrer det, og ingen klientkonfigurasjon kompenserer for det. De støttede svarene er en adresse som faktisk er tilgjengelig, et hostet endepunkt eller en arkitektur der hver deltaker oppretter en utgående tilkobling. UDP-innkapslingsspesifikasjonen løser oversettingsproblemet for flyter som finnes; den skaper ikke en inngående vei der operatøren ikke tilbyr en.

Sammenlign derfor nettverk i stedet for å gjette. Ta med samme enhet og profil til et annet tillatt nettverk og se hvilket stadium som feiler der. Virker det andre steder, ligger forskjellen i veien, og det snevrer søket inn til de tre stadiene ovenfor i stedet for hele konfigurasjonen.