IKEv2 använder UDP 500 och 4500: vilken bär datat?

Det första utbytet och vägen som bär datat är inte samma flöde. Kontrollera båda portarna och kom ihåg att inbyggd ESP är ett protokollnummer, inte en port.

Att öppna UDP 500 i brandväggen låter tunneln förhandla, och därefter slutar anslutningen att föra vidare trafik. Portlistan var ofullständig, inte fel. IKEv2 börjar på en socket och fortsätter i många verkliga installationer på en annan, medan nyttolasten inte alls behöver vara en port. Att läsa faserna i ordning förklarar vilken regel som saknas.

Två portar, två uppgifter

IKEv2 börjar med ett nyckelutbyte på UDP 500, där parterna autentiserar sig och upprättar en säkerhetsassociation för tunneln. Datavägen som följer är en separat sak: den kan vara inbyggd ESP, som är ett IP-protokollnummer och inte en port, eller trafik inkapslad i UDP på 4500. Att hålla isär dessa i en brandväggsgranskning är skillnaden mellan en tunnel som förhandlar och en tunnel som fungerar. Den ena socketen bär styrning, den andra nyttolast.

Därför ger en regel som bara tillåter 500 det mest förvirrande symptomet i hela protokollfamiljen: förhandlingen lyckas och inget användbart följer. Statusen visar en peer, loggen visar en etablerad IKE SA, och applikationen får ändå timeout. Den saknade tillåtelsen hör till ett annat flöde än det som just lyckades.

Varför 4500 alls finns

Många NAT-enheter kan inte vidarebefordra andra protokoll än TCP eller UDP, och en del skriver om adresser på sätt som bryter ESP:s integritetskontroll. Att kapsla in ESP i UDP löser båda problemen, till priset av en extra rubrik och en andra port som måste tillåtas. Den inkapslingen är anledningen till att den andra porten alls finns.

När NAT upptäcks flyttar IKE självt också till 4500 så att all trafik delar en väg genom översättaren. En markör på fyra byte som inte är ESP skiljer styrmeddelanden från data på den socketen. Det bytet är ett protokollbeslut, inte en administratörens preferens.

Var källporten ändras

En översättare kan skriva om klientens källport, så tupeln som syns på servern stämmer inte med tupeln på klienten. Titta på båda sidor av varje NAT-hopp innan du drar slutsatsen att en regel ignoreras. Felsökning bara på klienten kan ge en regel som ser korrekt ut och ändå misslyckas.

MOBIKE-kompatibla implementationer kan också flytta till 4500 utan upptäckt NAT, och en del installationer tvingar den vägen med avsikt. Att se 4500 är därför bevis på ett beslut, inte bevis på en hemmarouter.

Kontrollera båda flödena vid varje gräns

Gå igenom de tre gränserna: klientnätet, eventuell mellanliggande brandvägg och servern. Var och en behöver de flöden som installationen dokumenterar, inte flödena från en artikel om ett annat fall.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

ESP-raden i en brandväggslista är en protokollmatchning, så en portregel täcker den aldrig. Om operatören använder en anpassad port, följ den dokumenterade konfigurationen i båda ändar, eftersom en klient inte kan skapa en lyssnare på servern genom att välja ett välkänt nummer.

Anteckna var förhandlingen stannade och om en underordnad säkerhetsassociation installerades, eftersom det paret skiljer en blockerad väg från ett autentiserings- eller policyfel. Upprepa sedan testet med serververifiering aktiverad, eftersom nåbarhet inte är autentisering. Det sista steget skiljer en tillåten port från en betrodd peer.

Relaterade artiklar