Hoe NAT-traversal de ESP in UDP verpakt

Twee clients achter dezelfde router praten met één IPsec-gateway, en de ene valt steeds weg terwijl de andere verbonden blijft. Native ESP is IP-protocol 50 zonder poorten, dus een vertaler heeft niets om een mapping aan op te hangen wanneer meerdere clients één adres delen. NAT-traversal dicht die kloof door ESP op 4500 in UDP te verpakken, en die header verklaart de meeste van de volgende symptomen. Hij wijst ook op het apparaat dat moet worden gewijzigd.

Waarom het dataplane naar poort 4500 verschuift

Tijdens de installatie vergelijkt IKEv2 de adressen en poorten die elke kant denkt te gebruiken, door hashes uit te wisselen in zijn NAT-detectiemeldingen. Als de hashes niet overeenkomen, zit er ergens op het pad een vertaler, en beide peers schakelen het beschermde verkeer over naar UDP-inkapseling. Daarom ziet een sessie die een vertaler tegenkwam er anders uit dan een die dat niet deed.

De verpakking is een envelop, geen protocolwijziging: ESP behoudt zijn header, integriteitscontrole en versleuteling, en UDP levert alleen de poorten die de vertaler nodig heeft. Poort 500 draagt de IKE-uitwisseling; 4500 draagt de ingekapselde gegevens na de detectie, en vaak ook de latere IKE-berichten. Geen van beide poorten maakt de stroom een TCP-verbinding, een aanname die de meeste mensen bij het lezen van een capture op het verkeerde been zet.

Controleer de twee fasen in volgorde

Bewijs eerst de controle-uitwisseling, dan het datapad, en houd de twee gescheiden in je notities. Een capture die verkeer op 500 laat zien en nooit op 4500 betekent meestal dat het datapad wordt gefilterd, dus de oplossing hoort in de firewallregel en niet in de client.

Bekijk beide poorten met tcpdump -ni any 'udp port 500 or udp port 4500', en lees de vertaaltabel op de router terwijl een sessie actief is. Die tabel toont de bronpoort die de gateway werkelijk zal zien, en een capture op de laptop wijkt daar bewust van af: de laptop gelooft 500 terwijl de gateway 4500 ziet met een vertaalde bronpoort, en beide hebben gelijk. Dezelfde stroom, voor en na de vertaling:

client 192.0.2.10:500 -> router 203.0.113.7:62000 -> gateway 198.51.100.9:4500

Symptomen die de verpakking verklaart, en twee die het niet doet

Een router die de controle-uitwisseling toestaat en de ingekapselde gegevens blokkeert levert het rapport op dat de tunnel staat maar er niets doorgaat. Mappingtabellen verlopen, dus een inactieve sessie heeft keepalive-verkeer nodig dat de peers met opzet sturen, en die pakketten zijn geen gezondheidscontroles. Als meerdere clients achter één gateway samen falen, onderzoek dan de vertaling van die gateway en elke oude passthrough-functie. De verpakking verklaart niet een toepassing die bij elke client faalt nadat de tunnel staat, of een certificaatwaarschuwing op een blokkeerpagina; beide liggen boven deze laag.

Lees de mappingtabel voor twee clients tegelijk: als beide dezelfde vertaalde poort tonen, scheidt het apparaat ze niet zoals de gateway vereist. Een passthrough-modus die native ESP aan slechts één host geeft, is niet gelijk aan het bedienen van meerdere vertaalde clients, hoewel leveranciers beide als IPsec-vriendelijk beschrijven. Dubbel NAT voegt een mappinglaag en nog een verlooppunt toe, maar het verbreekt uitgaande verbindingen niet automatisch.

Keepalive-verkeer verdient zijn eigen regel in het beheerhandboek, want het is wat het antwoordpad tijdens stille perioden openhoudt. Schakel het in waar de leverancier het documenteert, en controleer het eerst wanneer een sessie na minuten stilte sterft en niet bij het eerste gebruik.

Wijzig de eigenaar van de mapping en test opnieuw

Volg de ondersteunde NAT-traversal-instellingen op beide peers in plaats van een poort te raden. Het lokale bronpoort op één client aanpassen kan de dienst aan de andere kant niet wijzigen, en het breekt meestal de al opgebouwde mapping. Als de client achter een apparaat zit dat je niet beheert, hoort de wijziging bij de eigenaar daarvan.

Herhaal na elke wijziging beide fasecontroles en bevestig dat een datapakket erdoorheen gaat, niet alleen dat het statusschema groen is geworden. Houd de tuples, de uitvoer van de mappingtabel en de regelwijziging in één notitie, zodat de volgende persoon niet opnieuw bij de controle-uitwisseling begint. De strongSwan-notities over NAT-traversal behandelen de inkapselings- en keepalive-instellingen achter beide fasen.