L2TP/IPsec deur NAT: wat werklik breek en waarom
NAT-deurgang skuif ESP in UDP in, en die kaart, die vuurmuur en die netwerkoperateur faal elkeen anders. Identifiseer die stadium voordat jy die kliënt blameer.
Die bewering dat NAT L2TP/IPsec breek, is half waar en daarom nutteloos. Adresvertaling is normaal, NAT-deurgang bestaan juis om dit te oorleef, en miljoene kliënte verbind elke dag van agter ’n router. Wat breek, is ’n spesifieke stadium van ’n spesifieke uitruiling: IKE kry nooit ’n antwoord nie, die ingekapselde tonnel word deur ’n beleid laat val wat net een protokol toelaat, of die vertalingskaart verval terwyl die tonnel ledig is. Sodra jy weet in watter stadium jy is, is die oplossing gewoonlik ’n enkele reël of ’n keepalive eerder as ’n nuwe VPN-ontwerp.
Die mite is die verkeerde vraag
Die nuttige vraag is nie “breek NAT dit nie”, maar “watter deel van die uitruiling word vertaal, en wat doen die toestel wat die vertaling doen daarmee”. L2TP/IPsec is ’n gelaagde protokol: IKE onderhandel, ESP beskerm, en L2TP dra PPP binne daardie beskerming. Adresvertaling werk anders op elke laag, en die foutpatrone kan onderskei word as jy na die onderhandelingstadium kyk eerder as na die foutdialoog.
’n Router wat suksesvol webwerwe blaai, bewys net dat TCP met bronpoortvertaling werk. Dit sê niks oor UDP 500, UDP 4500 of protokol 50 nie, en dit is die drie dinge waarvan hierdie ontplooiing afhanklik is.
Stadium 1: IKE moet enigsins ’n antwoord kry
Die eerste uitruiling gaan na die respondente op UDP 500. As geen antwoord terugkom nie, maak niks anders saak nie: die vooraf gedeelde sleutel, die voorstel en die geloofsbriewe word almal ongelees gelaat. Let op die versoek en die antwoord eerder as om uit die kliënt se tydsverloop af te lei:
sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas
’n Versoek sonder antwoord beteken gewoonlik dat ’n vuurmuur of die opstroom-operateur die pakkie laat val, nie dat die bediener dit verwerp het nie. ’n Antwoord met ’n kennisgewing-lading wat ’n voorstel of ’n sertifikaatprobleem noem, beteken die pakkies het aangekom en die onderhandeling het op inhoud misluk, wat ’n heeltemal ander herstelling is.
Wanneer beide eweknieë agter vertaling sit, hoef die inisieerder net die respondente te bereik, so die meeste kliëntkant-ontplooiings werk vanaf stadium 1. Bedienerkant-gasheerskap is waar die inkomende probleem begin, en dit is die rede waarom die twee situasies nooit as een bespreek moet word nie.
Stadium 2: inkapseling verander wat die vuurmuur sien
ESP is ’n IP-protokol, nie ’n TCP- of UDP-poort nie, en gewone poortadresvertaling het geen poortveld om daarin te herskryf nie. Dit is waarom NAT-deurgang die beskermde vrag in UDP 4500 skuif: die inkapseling gee die vertalende toestel iets wat dit weet hoe om te vertaal. Sodra dit gebeur, sal ’n vuurmuurreël wat net vir UDP 500 geskryf is die onderhandeling toelaat en die tonnel laat val, wat die verwarrende resultaat lewer waar die log ’n suksesvolle fase 1 en geen verkeer toon nie.
Die IKE-uitruiling self kan ook na UDP 4500 skuif nadat ’n NAT bespeur is, wat mense verras wat 500 en niks anders toegelaat het nie. Laat albei poorte in albei rigtings op die pad toe, en onthou dat ’n toestandvolle vuurmuur die vloei dalk net hou solank dit verkeer sien.
Protokol 50 maak steeds saak op paaie sonder vertaling, en op paaie waar ’n middelkassie geconfigureer is om dit toe te laat. As jy deur eliminering diagnoseer, deaktiveer die hipotese eerder as om reëls in bulk by te voeg: laat 500, 4500 en ESP toe, bevestig die tonnel kom op, verwyder dan wat onnodig geblyk het. ’n Reël wat niemand kan verduidelik nie, is ’n reël wat niemand sal verwyder wanneer dit die oorsaak van die volgende onderbreking word. Skryf die vernouing in die veranderingsrekord saam met die stadium wat dit reggemaak het, sodat die volgende ingenieur van jou bewyse begin eerder as van dieselfde reël-van-duim.
Stadium 3: die kaart verval en die tonnel sterf
’n Vertalende toestel hou toestand vir die vloei wat dit aanstuur, en daardie toestand het ’n leeftyd. ’n L2TP/IPsec-tonnel dra min verkeer wanneer niemand dit gebruik nie, so ’n ledige tonnel kan sy kaart oorleef en ophou om terugkeerverkeer te ontvang. Die kliënt bly oortuig dat hy verbind is, die bediener sien niks, en die eerste simptoom is gewoonlik ’n toepassing-tydsverloop eerder as ’n VPN-fout.
Dooie-eweknie-bespeuring en NAT-keepalives bestaan hiervoor, en albei kante moet bereid wees om dit te stuur. As jou bediener agter vertaling is, is die Windows-vereiste ’n gedokumenteerde registerinstelling wat die bediener laat aanneem dat UDP-inkapseling vir sy eie uitgaande pakkies geld; sonder dit stuur die respondente ESP wat die vertalende toestel nie kan terugkaart nie. Dit is ’n bedienerkonfigurasie-kwessie, nie ’n kliënt een nie.
’n WAN-adresverandering lewer dieselfde uitkoms uit ’n ander rigting: die kaart word rondom ’n nuwe adres herbou, en die ou sekuriteitsassosiasie wys nou na ’n tuple wat nie meer bestaan nie. Herverbindingsgedrag hoort by die kliëntimplementering, en dit is waarom “herverbind nadat die router herbegin” op een kliënt werk en op ’n ander ’n handmatige skakelaar nodig het.
Gasheerskap agter operateur-graad NAT is ’n ander probleem
As jy ’n L2TP/IPsec-bediener by die huis wil gasheer en dit van buite wil bereik, is die vereiste ongevraagde inkomende bereikbaarheid, en dit is nie wat NAT-deurgang bied nie. ’n Operateur-graad NAT voor jou router beteken daar is geen poort wat jy kan aanstuur wat jou bereikbaar sal maak nie, want die publieke adres word gedeel en die kaart is slegs uitgaande.
Geen IPsec-deurlaat-merkie verander dit nie, en geen hoeveelheid kliëntkonfigurasie vergoed daarvoor nie. Die ondersteunde antwoorde is ’n adres wat werklik bereikbaar is, ’n gehoste eindpunt, of ’n argitektuur waar elke deelnemer ’n uitgaande verbinding maak. Die UDP-inkapselingspesifikasie los die vertalingsprobleem op vir vloei wat bestaan; dit skep nie ’n inkomende pad waar die operateur nie een bied nie.
Vergelyk dus netwerke eerder as om te raai. Neem dieselfde toestel en profiel na ’n ander toegelate netwerk en kyk watter stadium daar faal. As dit elders werk, is die verskil in die pad, en dit vernou die soektog na die drie stadiums hierbo in plaas van die hele konfigurasie.