Så här packar NAT-traversering in ESP i UDP

Två klienter bakom samma router talar med en enda IPsec-gateway, och den ena tappar ständigt anslutningen medan den andra håller sig kvar. Inbyggd ESP är IP-protokoll 50 utan portar, så en översättare har inget att fästa en mappning på när flera klienter delar en adress. NAT-traversering stänger igen den luckan genom att packa in ESP i UDP på 4500, och den headern förklarar de flesta av symptomen som följer. Den pekar också ut enheten som måste ändras.

Varför dataplanet flyttar till port 4500

Under konfigurationen jämför IKEv2 de adresser och portar som varje sida tror sig använda, genom att utbyta hashar i sina NAT-detekteringsaviseringar. När hasharna inte stämmer sitter en översättare någonstans på vägen, och båda parterna flyttar den skyddade trafiken till UDP-inkapsling. Därför ser en session som mötte en översättare annorlunda ut än en som inte gjorde det.

Inpackningen är ett kuvert, inte en protokolländring: ESP behåller sin header, sin integritetskontroll och sin kryptering, och UDP levererar bara de portar som översättaren behöver. Port 500 bär IKE-utbytet; 4500 bär de inkapslade data efter detekteringen, och ofta även de senare IKE-meddelandena. Ingen av portarna gör flödet till en TCP-anslutning, ett antagande som vilseleder de flesta som läser en avlyssning.

Kontrollera de två stegen i ordning

Bevisa först kontrollutbytet, därefter datavägen, och håll de två åtskilda i dina anteckningar. En avlyssning som visar trafik på 500 och aldrig på 4500 betyder vanligtvis att datavägen filtreras, så rättelsen hör hemma i brandväggsregeln och inte i klienten.

Bevaka båda portarna med tcpdump -ni any 'udp port 500 or udp port 4500', och läs översättningstabellen på routern medan en session är aktiv. Tabellen visar källporten som gatewayen faktiskt kommer att se, och en avlyssning på laptopen skiljer sig med avsikt: laptopen tror 500 medan gatewayen ser 4500 med en översatt källport, och båda har rätt. Samma flöde, före och efter översättningen:

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

Symtom som inpackningen förklarar, och två som den inte gör

En router som tillåter kontrollutbytet och blockerar de inkapslade data ger rapporten att tunneln är uppe men att ingenting går igenom. Mappningstabeller löper ut, så en inaktiv session behöver keepalive-trafik som parterna skickar med avsikt, och de paketen är inte hälsokontroller. När flera klienter bakom en gateway misslyckas samtidigt, undersök den gatewayens översättning och alla gamla passthrough-funktioner. Inpackningen förklarar inte ett program som misslyckas hos varje klient efter att tunneln rests, eller en certifikatvarning på en blockeringssida; båda ligger ovanför detta lager.

Läs mappningstabellen för två klienter samtidigt: om båda visar samma översatta port skiljer enheten dem inte så som gatewayen kräver. Ett passthrough-läge som ger inbyggd ESP till bara en värd motsvarar inte att betjäna flera översatta klienter, även om leverantörer beskriver båda som IPsec-vänliga. Dubbelt NAT lägger till ett mappningslager och ytterligare en utgångspunkt, men det bryter inte utgående anslutningar automatiskt.

Keepalive-trafik förtjänar en egen rad i driftmanualen, eftersom det är den som håller svarsvägen öppen genom tysta perioder. Aktivera den där leverantören dokumenterar den, och kontrollera den först när en session dör efter några minuters tystnad i stället för vid första användningen.

Byt ägare till mappningen och testa sedan igen

Följ de NAT-traverseringsinställningar som stöds på båda parterna i stället för att gissa en port. Att redigera den lokala källporten på en klient kan inte ändra tjänsten som lyssnar i andra änden, och det bryter vanligtvis den mappning som redan byggts. Om klienten sitter bakom en enhet som du inte kontrollerar tillhör ändringen dess ägare.

Upprepa båda stegkontrollerna efter varje ändring och bekräfta att ett datapaket passerar, inte bara att statusskärmen blev grön. Håll tuplarna, utdata från mappningstabellen och regeländringen i en enda anteckning, så att nästa person inte börjar om från kontrollutbytet. strongSwans anteckningar om NAT-traversering täcker inkapslings- och keepalive-inställningarna bakom båda stegen.