L2TP/IPsec gjennom NAT: kva som faktisk bryt og kvifor

Påstanden om at NAT bryt L2TP/IPsec er halvt sann og derfor ubrukeleg. Adresseomsetjing er normalt, NAT-traversal finst nettopp for å overleve henne, og millionar av klientar koplar til kvar dag bak ein ruter. Det som bryt, er eit bestemt stadium av ei bestemt utveksling: IKE får aldri svar, den innkapsla tunnelen blir kasta av ein policy som berre tillèt éin protokoll, eller mappinga går ut medan tunnelen er inaktiv. Når du veit kva stadium du er i, er rettinga vanlegvis éin regel eller ein keepalive, ikkje eit nytt VPN-design.

Myten er det gale spørsmålet

Det nyttige spørsmålet er ikkje «bryt NAT dette», men «kva del av utvekslinga blir omsett, og kva gjer eininga som omset med han». L2TP/IPsec er ein lagdelt protokoll: IKE forhandlar, ESP vernar, og L2TP ber PPP inne i den vernen. Adresseomsetjing verkar ulikt på kvart lag, og feilsignatura kan skiljast om du ser på forhandlingsstadiet i staden for feildialogen.

Ein ruter som surfar på nettet utan problem beviser berre at TCP med kjeldeportomsetjing verkar. Han seier ingenting om UDP 500, UDP 4500 eller protokoll 50, og det er nettopp desse tre tinga denne utrullinga er avhengig av.

Stadium 1: IKE må i det heile få eit svar

Den første utvekslinga går til svararen på UDP 500. Kjem det ikkje noko svar tilbake, betyr alt anna ingenting: den førehandsdelte nøkkelen, forslaget og legitimasjonen blir verande ulesne. Følg med på førespurnaden og svaret i staden for å gjette ut frå tidsavbrotet til klienten:

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

Ein førespurnad utan svar betyr vanlegvis at ein brannmur eller operatøren lenger oppe kastar pakken, ikkje at serveren avviste han. Eit svar med ei varselnyttelast som nemner eit forslag eller eit sertifikatproblem betyr at pakkane kom fram og at forhandlinga feila på innhald, som er ei heilt anna reparasjon.

Når begge partar sit bak omsetjing, treng initiativtakaren berre å nå svararen, så dei fleste utrullingane på klientsida verkar frå stadium 1. Hosting på serversida er der inngangsproblemet startar, og det er grunnen til at dei to situasjonane aldri bør diskuterast som éin.

Stadium 2: innkapsling endrar kva brannmuren ser

ESP er ein IP-protokoll, ikkje ein TCP- eller UDP-port, og vanleg portadresseomsetjing har ikkje noko portfelt å skrive om. Derfor flyttar NAT-traversal den verna nyttelasta inn i UDP 4500: innkapslinga gjev eininga som omset noko ho veit korleis ho skal omsetje. Når det skjer, vil ein brannmurregel som berre er skriven for UDP 500, tillate forhandlinga og kaste tunnelen, noko som gjev det forvirrande resultatet der loggen viser ein vellukka fase 1 og ingen trafikk.

Sjølve IKE-utvekslinga kan også flyttast til UDP 4500 etter at ein NAT er oppdaga, noko som overraskar folk som har tillate 500 og ingenting anna. Tillat begge portane i begge retningar på vegen, og hugs at ein stateful brannmur berre held flyten så lenge han ser trafikk.

Protokoll 50 er framleis viktig på vegar utan omsetjing, og på vegar der ein mellomliggjande boks er konfigurert til å tillate han. Viss du diagnostiserer ved eliminering, slå av hypotesen i staden for å leggje til reglar i buntar: tillat 500, 4500 og ESP, stadfest at tunnelen kjem opp, og fjern så det som viste seg unødvendig. Ein regel ingen kan forklare, er ein regel ingen fjernar når han blir årsaka til neste avbrot. Skriv innsnevringa i endringsloggen saman med stadiet ho retta, slik at neste ingeniør startar frå prova dine i staden for frå den same tommelfingerregelen.

Stadium 3: mappinga går ut og tunnelen døyr

Ei eining som omset, held tilstand for flyta ho videresender, og den tilstanden har ei levetid. Ein L2TP/IPsec-tunnel ber lite trafikk når ingen brukar han, så ein inaktiv tunnel kan overleve mappinga si og slutte å ta imot returtrafikk. Klienten blir verande overtydd om at han er tilkopla, serveren ser ingenting, og det første symptomet er vanlegvis eit applikasjonstidsavbrot og ikkje ein VPN-feil.

Oppdaging av død peer og NAT-keepalive finst for dette, og begge endar må vere viljuge til å sende dei. Viss serveren din er bak omsetjing, er kravet på Windows-sida ei dokumentert registerinnstilling som får serveren til å anta UDP-innkapsling for sine eigne utgåande pakkar; utan ho sender svararen ESP som eininga som omset ikkje kan mappe tilbake. Det er eit serverkonfigurasjonsproblem, ikkje eit klientproblem.

Ei endring av WAN-adressa gjev same utfallet frå ei anna retning: mappinga blir bygd opp att rundt ei ny adresse, og den gamle tryggleiksassosiasjonen peikar no på ein tuppel som ikkje finst lenger. Gjenoppkoplingsåtferd høyrer til klientimplementasjonen, og derfor verkar «kople til på nytt etter at ruteren startar på nytt» på éin klient og krev ein manuell brytar på ein annan.

Hosting bak carrier-grade NAT er eit anna problem

Viss du vil hoste ein L2TP/IPsec-server heime og nå han utanfrå, er kravet uoppfordra inngåande tilgjenge, og det er ikkje det NAT-traversal gjev. Ein carrier-grade NAT framfor ruteren din betyr at det ikkje finst nokon port du kan videresende som gjer deg tilgjengeleg, fordi den offentlege adressa er delt og mappinga berre er utgåande.

Ingen IPsec pass-through-avkrysningsboks endrar det, og ingen klientkonfigurasjon kompenserer for det. Dei støtta svara er ei adresse som faktisk er tilgjengeleg, eit hosta endepunkt eller ein arkitektur der kvar deltakar opprettar ei utgåande tilkopling. UDP-innkapslingsspesifikasjonen løyser omsetjingsproblemet for flyter som finst; ho skapar ikkje ein inngåande veg der operatøren ikkje tilbyr ein.

Samanlikn derfor nettverk i staden for å gjette. Ta med same eining og profil til eit anna tillate nettverk og sjå kva stadium som feilar der. Verkar det andre stader, ligg skilnaden i vegen, og det snevrar søket inn til dei tre stadia ovanfor i staden for heile konfigurasjonen.