L2TP/IPsec gennem NAT: hvad der reelt brækker, og hvorfor

Påstanden om, at NAT brækker L2TP/IPsec, er halvt sand og derfor ubrugelig. Adresseoversættelse er normalt, NAT-traversal findes netop for at overleve den, og millioner af klienter forbinder hver dag bag en router. Det, der brækker, er et bestemt stadie af en bestemt udveksling: IKE får aldrig et svar, den indkapslede tunnel droppes af en politik, der kun tillader én protokol, eller mappingen udløber, mens tunnelen er inaktiv. Når du ved, hvilket stadie du er i, er rettelsen normalt en enkelt regel eller et keepalive i stedet for et nyt VPN-design.

Myten er det forkerte spørgsmål

Det brugbare spørgsmål er ikke »brækker NAT det her«, men »hvilken del af udvekslingen oversættes, og hvad gør enheden, der oversætter, ved det«. L2TP/IPsec er en lagdelt protokol: IKE forhandler, ESP beskytter, og L2TP bærer PPP inde i den beskyttelse. Adresseoversættelse påvirker hvert lag forskelligt, og fejlsignaturerne kan skelnes, hvis du ser på forhandlingsstadiet i stedet for fejldialogen.

En router, der kan browse web uden problemer, beviser kun, at TCP med kildeportoversættelse virker. Den siger intet om UDP 500, UDP 4500 eller protokol 50, og det er netop de tre ting, denne udrulning afhænger af.

Stadie 1: IKE skal overhovedet have et svar

Den første udveksling går til responderenden på UDP 500. Kommer der intet svar tilbage, betyder alt andet intet: den foruddelte nøgle, forslaget og legitimationsoplysningerne forbliver ulæste. Hold øje med anmodningen og svaret i stedet for at gætte ud fra klientens timeout:

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

En anmodning uden svar betyder normalt, at en firewall eller operatøren længere oppe kaster pakken væk, ikke at serveren afviste den. Et svar med en notifikationsnyttelast, der nævner et forslag eller et certifikatproblem, betyder, at pakkerne nåede frem, og at forhandlingen fejlede på indhold, hvilket er en helt anden reparation.

Når begge parter sidder bag oversættelse, skal initiativtageren kun nå responderenden, så de fleste udrulninger på klientsiden virker fra stadie 1. Hosting på serversiden er der, hvor indgangsproblemet starter, og det er grunden til, at de to situationer aldrig bør drøftes som én.

Stadie 2: indkapsling ændrer, hvad firewallem ser

ESP er en IP-protokol, ikke en TCP- eller UDP-port, og almindelig portadresseoversættelse har ikke noget portfelt at omskrive i. Derfor flytter NAT-traversal den beskyttede nyttelast ind i UDP 4500: indkapslingen giver den oversættende enhed noget, den ved, hvordan den skal oversætte. Når det sker, vil en firewallregel, der kun er skrevet til UDP 500, tillade forhandlingen og droppe tunnelen, hvilket giver det forvirrende resultat, hvor loggen viser en vellykket fase 1 og ingen trafik.

Selve IKE-udvekslingen kan også flytte til UDP 4500, efter at en NAT er registreret, hvilket overrasker folk, der har tilladt 500 og intet andet. Tillad begge porte i begge retninger på vejen, og husk, at en stateful firewall kun kan holde flowet, så længe den ser trafik.

Protokol 50 betyder stadig noget på veje uden oversættelse, og på veje hvor en mellemboks er konfigureret til at tillade den. Hvis du diagnosticerer ved at udelukke, så slå hypotesen fra i stedet for at tilføje regler i bunker: tillad 500, 4500 og ESP, bekræft at tunnelen kommer op, og fjern så det, der viste sig unødvendigt. En regel, ingen kan forklare, er en regel, ingen fjerner, når den bliver årsagen til den næste afbrydelse. Skriv indsnævringen i ændringsloggen sammen med det stadie, den rettede, så den næste ingeniør starter fra dine beviser i stedet for fra den samme tommelfingerregel.

Stadie 3: mappingen udløber, og tunnelen dør

En oversættende enhed holder tilstand for de flows, den videresender, og den tilstand har en levetid. En L2TP/IPsec-tunnel bærer lidt trafik, når ingen bruger den, så en inaktiv tunnel kan overleve sin mapping og holde op med at modtage returtrafik. Klienten forbliver overbevist om, at den er forbundet, serveren ser intet, og det første symptom er normalt en applikationstimeout i stedet for en VPN-fejl.

Detektion af død peer og NAT-keepalives findes til dette, og begge ender skal være villige til at sende dem. Hvis din server er bag oversættelse, er kravet på Windows-siden en dokumenteret registreringsindstilling, der får serveren til at antage UDP-indkapsling for sine egne udgående pakker; uden den sender responderenden ESP, som den oversættende enhed ikke kan mappe tilbage. Det er et serverkonfigurationsproblem, ikke et klientproblem.

En ændring af WAN-adressen giver samme udfald fra en anden retning: mappingen genopbygges omkring en ny adresse, og den gamle sikkerhedsassociation peger nu på en tuple, der ikke findes længere. Genopkoblingsadfærd hører til klientimplementeringen, og derfor virker »genopkobl efter routeren genstarter« på én klient og kræver en manuel kontakt på en anden.

Hosting bag carrier-grade NAT er et andet problem

Hvis du vil hoste en L2TP/IPsec-server derhjemme og nå den udefra, er kravet uopfordret indgående tilgængelighed, og det er ikke det, NAT-traversal giver. En carrier-grade NAT foran din router betyder, at der ikke er nogen port, du kan videresende, som gør dig tilgængelig, fordi den offentlige adresse er delt, og mappingen kun er udgående.

Ingen IPsec pass-through-afkrydsningsboks ændrer det, og ingen mængde klientkonfiguration kompenserer for det. De understøttede svar er en adresse, der faktisk er tilgængelig, et hostet endepunkt eller en arkitektur, hvor hver deltager opretter en udgående forbindelse. UDP-indkapslingsspecifikationen løser oversættelsesproblemet for flows, der findes; den skaber ikke en indgående vej, hvor operatøren ikke tilbyder en.

Sammenlign derfor netværk i stedet for at gætte. Tag samme enhed og profil med til et andet tilladt netværk, og se, hvilket stadie der fejler der. Virker det andre steder, ligger forskellen i vejen, og det indsnævrer søgningen til de tre stadier ovenfor i stedet for hele konfigurationen.