L2TP/IPsec door NAT: wat er echt breekt en waarom

De bewering dat NAT L2TP/IPsec breekt, is half waar en daarom nutteloos. Adresvertaling is normaal, NAT-traversal bestaat juist om die te overleven, en miljoenen clients verbinden dagelijks van achter een router. Wat breekt, is een specifieke fase van een specifieke uitwisseling: IKE krijgt nooit antwoord, de ingekapselde tunnel wordt weggegooid door een beleid dat maar één protocol toestaat, of de vertaalmapping verloopt terwijl de tunnel inactief is. Zodra u weet in welke fase u zit, is de oplossing meestal één regel of een keepalive, niet een nieuw VPN-ontwerp.

De mythe is de verkeerde vraag

De bruikbare vraag is niet „breekt NAT dit”, maar „welk deel van de uitwisseling wordt vertaald, en wat doet het apparaat dat vertaalt ermee”. L2TP/IPsec is een gelaagd protocol: IKE onderhandelt, ESP beschermt, en L2TP draagt PPP binnen die bescherming. Adresvertaling werkt op elke laag anders, en de faalpatronen zijn te onderscheiden als u naar de onderhandelingsfase kijkt in plaats van naar de foutdialoog.

Een router die met succes op het web browst, bewijst alleen dat TCP met bronpoortvertaling werkt. Hij zegt niets over UDP 500, UDP 4500 of protocol 50, en dat zijn precies de drie dingen waarvan deze uitrol afhangt.

Fase 1: IKE moet überhaupt een antwoord krijgen

De eerste uitwisseling gaat naar de responder op UDP 500. Komt er geen antwoord terug, dan maakt al het andere niet uit: de vooraf gedeelde sleutel, het voorstel en de inloggegevens blijven ongelezen. Let op het verzoek en het antwoord in plaats van te gokken op basis van de time-out van de client:

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

Een verzoek zonder antwoord betekent meestal dat een firewall of de provider verderop het pakket weggooit, niet dat de server het heeft geweigerd. Een antwoord met een notificatielading die een voorstel of een certificaatprobleem noemt, betekent dat de pakketten zijn aangekomen en dat de onderhandeling op inhoud is mislukt, wat een heel andere reparatie is.

Als beide kanten achter vertaling zitten, hoeft de initiator alleen de responder te bereiken, dus de meeste uitrollen aan de clientkant werken vanaf fase 1. Hosting aan de serverkant is waar het inkomende probleem begint, en daarom moeten de twee situaties nooit als één worden besproken.

Fase 2: inkapseling verandert wat de firewall ziet

ESP is een IP-protocol, geen TCP- of UDP-poort, en gewone poortadresvertaling heeft geen poortveld om te herschrijven. Daarom verplaatst NAT-traversal de beschermde lading naar UDP 4500: de inkapseling geeft het vertalende apparaat iets dat het weet te vertalen. Zodra dat gebeurt, zal een firewallregel die alleen voor UDP 500 is geschreven, de onderhandeling toestaan en de tunnel laten vallen, wat het verwarrende resultaat oplevert waarbij de log een geslaagde fase 1 en geen verkeer toont.

De IKE-uitwisseling zelf kan na detectie van NAT ook naar UDP 4500 gaan, wat mensen verrast die 500 en niets anders hebben toegestaan. Sta beide poorten in beide richtingen toe op het pad, en onthoud dat een stateful firewall de stroom alleen vasthoudt zolang hij verkeer ziet.

Protocol 50 blijft belangrijk op paden zonder vertaling, en op paden waar een tussenliggende box is geconfigureerd om het toe te staan. Als u diagnosticeert door eliminatie, schakel dan de hypothese uit in plaats van regels in bulk toe te voegen: sta 500, 4500 en ESP toe, bevestig dat de tunnel omhoog komt, en verwijder dan wat onnodig bleek. Een regel die niemand kan uitleggen, is een regel die niemand verwijdert wanneer die de oorzaak van de volgende storing wordt. Schrijf de versmalling in het wijzigingslogboek samen met de fase die ervoor zorgde, zodat de volgende engineer bij uw bewijs begint en niet bij dezelfde vuistregel.

Fase 3: de mapping verloopt en de tunnel sterft

Een vertalend apparaat houdt state bij voor de stromen die het doorstuurt, en die state heeft een levensduur. Een L2TP/IPsec-tunnel draagt weinig verkeer wanneer niemand hem gebruikt, dus een inactieve tunnel kan zijn mapping overleven en stoppen met het ontvangen van retourverkeer. De client blijft overtuigd dat hij verbonden is, de server ziet niets, en het eerste symptoom is meestal een time-out van een toepassing en niet een VPN-fout.

Detectie van dode peers en NAT-keepalives bestaan hiervoor, en beide kanten moeten bereid zijn ze te sturen. Als uw server achter vertaling zit, is de eis aan Windows-kant een gedocumenteerde registerinstelling die de server UDP-inkapseling laat aannemen voor zijn eigen uitgaande pakketten; zonder die instelling stuurt de responder ESP dat het vertalende apparaat niet terug kan mappen. Dat is een serverconfiguratieprobleem, geen clientprobleem.

Een wijziging van het WAN-adres levert hetzelfde resultaat op vanuit een andere richting: de mapping wordt opnieuw opgebouwd rond een nieuw adres, en de oude beveiligingsassociatie wijst nu naar een tuple die niet meer bestaat. Herverbindingsgedrag hoort bij de clientimplementatie, en daarom werkt „opnieuw verbinden na een herstart van de router” op de ene client en vraagt het op een andere om een handmatige schakelaar.

Hosting achter carrier-grade NAT is een ander probleem

Als u thuis een L2TP/IPsec-server wilt hosten en die van buitenaf wilt bereiken, is de eis ongevraagde inkomende bereikbaarheid, en dat is niet wat NAT-traversal biedt. Een carrier-grade NAT voor uw router betekent dat er geen poort is die u kunt doorsturen en die u bereikbaar maakt, omdat het openbare adres wordt gedeeld en de mapping alleen uitgaand is.

Geen enkel IPsec pass-through-vakje verandert dat, en geen enkele clientconfiguratie compenseert het. De ondersteunde antwoorden zijn een adres dat echt bereikbaar is, een gehost eindpunt, of een architectuur waarin elke deelnemer een uitgaande verbinding maakt. De UDP-inkapselingsspecificatie lost het vertaalprobleem op voor stromen die bestaan; ze creëert geen inkomend pad waar de provider er geen biedt.

Vergelijk dus netwerken in plaats van te gokken. Neem hetzelfde apparaat en profiel mee naar een ander toegestaan netwerk en kijk welke fase daar faalt. Als het elders werkt, zit het verschil in het pad, en dat versmalt het zoeken tot de drie fasen hierboven in plaats van de hele configuratie.