L2TP/IPsec genom NAT: vad som faktiskt går sönder och varför

Påståendet att NAT bryter L2TP/IPsec är halvt sant och därför oanvändbart. Adressöversättning är normalt, NAT-traversal finns just för att överleva den, och miljontals klienter ansluter varje dag bakom en router. Det som går sönder är ett visst steg i ett visst utbyte: IKE får aldrig något svar, den inkapslade tunneln kastas av en policy som bara tillåter ett protokoll, eller mappningen löper ut medan tunneln är inaktiv. När du vet vilket steg du är i är åtgärden oftast en enda regel eller en keepalive, inte en ny VPN-design.

Myten är fel fråga

Den användbara frågan är inte ”bryter NAT detta” utan ”vilken del av utbytet översätts, och vad gör enheten som översätter med den”. L2TP/IPsec är ett skiktat protokoll: IKE förhandlar, ESP skyddar, och L2TP bär PPP inne i det skyddet. Adressöversättning påverkar varje lager olika, och felsignaturerna går att skilja om du tittar på förhandlingssteget i stället för feldialogen.

En router som surfar utan problem bevisar bara att TCP med källportsöversättning fungerar. Den säger ingenting om UDP 500, UDP 4500 eller protokoll 50, och det är just dessa tre saker som den här driftsättningen är beroende av.

Steg 1: IKE måste överhuvudtaget få ett svar

Det första utbytet går till svararen på UDP 500. Kommer inget svar tillbaka spelar allt annat ingen roll: den fördelade nyckeln, förslaget och inloggningsuppgifterna förblir olästa. Följ begäran och svaret i stället för att gissa utifrån klientens tidsgräns:

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

En begäran utan svar betyder oftast att en brandvägg eller operatören längre upp kastar paketet, inte att servern avvisade det. Ett svar med en aviseringsnyttolast som namnger ett förslag eller ett certifikatproblem betyder att paketen kom fram och att förhandlingen misslyckades på innehållet, vilket är en helt annan reparation.

När båda sidor sitter bakom översättning behöver initiativtagaren bara nå svararen, så de flesta driftsättningar på klientsidan fungerar från steg 1. Hosting på serversidan är där ingångsproblemet börjar, och det är därför de två situationerna aldrig bör diskuteras som en.

Steg 2: inkapslingen ändrar vad brandväggen ser

ESP är ett IP-protokoll, inte en TCP- eller UDP-port, och vanlig portadressöversättning har inget portfält att skriva om. Därför flyttar NAT-traversal den skyddade nyttolasten in i UDP 4500: inkapslingen ger enheten som översätter något den vet hur den ska översätta. När det väl händer kommer en brandväggsregel som bara är skriven för UDP 500 att tillåta förhandlingen och kasta tunneln, vilket ger det förvirrande resultatet där loggen visar en lyckad fas 1 och ingen trafik.

Själva IKE-utbytet kan också flyttas till UDP 4500 efter att ett NAT upptäckts, vilket överraskar dem som tillåtit 500 och inget annat. Tillåt båda portarna i båda riktningarna på vägen, och kom ihåg att en stateful brandvägg bara håller flödet så länge den ser trafik.

Protokoll 50 är fortfarande viktigt på vägar utan översättning, och på vägar där en mellanliggande box är konfigurerad att tillåta det. Om du diagnostiserar genom uteslutning, stäng av hypotesen i stället för att lägga till regler i klump: tillåt 500, 4500 och ESP, bekräfta att tunneln kommer upp och ta sedan bort det som visade sig onödigt. En regel som ingen kan förklara är en regel som ingen tar bort när den blir orsaken till nästa avbrott. Skriv in snävningen i ändringsloggen tillsammans med steget den rättade, så att nästa ingenjör börjar från dina bevis och inte från samma tumregel.

Steg 3: mappningen löper ut och tunneln dör

En enhet som översätter håller tillstånd för de flöden den vidarebefordrar, och det tillståndet har en livstid. En L2TP/IPsec-tunnel bär lite trafik när ingen använder den, så en inaktiv tunnel kan överleva sin mappning och sluta ta emot returtrafik. Klienten förblir övertygad om att den är ansluten, servern ser ingenting, och det första symptomet är oftast en applikationstimeout och inte ett VPN-fel.

Detektion av död peer och NAT-keepalives finns för detta, och båda ändarna måste vara villiga att skicka dem. Om din server står bakom översättning är kravet på Windows-sidan en dokumenterad registerinställning som får servern att anta UDP-inkapsling för sina egna utgående paket; utan den skickar svararen ESP som enheten som översätter inte kan mappa tillbaka. Det är ett serverkonfigurationsproblem, inte ett klientproblem.

En ändring av WAN-adressen ger samma utfall från ett annat håll: mappningen byggs upp igen kring en ny adress, och den gamla säkerhetsassociationen pekar nu på en tupel som inte längre finns. Återanslutningsbeteendet hör till klientimplementeringen, och därför fungerar ”anslut igen efter omstart av routern” på en klient och kräver en manuell brytare på en annan.

Hosting bakom carrier-grade NAT är ett annat problem

Om du vill hosta en L2TP/IPsec-server hemma och nå den utifrån är kravet oombedd inkommande nåbarhet, och det är inte vad NAT-traversal erbjuder. En carrier-grade NAT framför din router innebär att det inte finns någon port du kan vidarebefordra som gör dig nåbar, eftersom den publika adressen delas och mappningen bara är utgående.

Ingen IPsec pass-through-ruta ändrar det, och ingen klientkonfiguration kompenserar för det. De svar som stöds är en adress som faktiskt är nåbar, en hostad slutpunkt eller en arkitektur där varje deltagare gör en utgående anslutning. UDP-inkapslingsspecifikationen löser översättningsproblemet för flöden som finns; den skapar inte en inkommande väg där operatören inte erbjuder någon.

Jämför därför nätverk i stället för att gissa. Ta med samma enhet och profil till ett annat tillåtet nätverk och se vilket steg som misslyckas där. Fungerar det någon annanstans ligger skillnaden i vägen, och det snävar in sökningen till de tre stegen ovan i stället för hela konfigurationen.