IKEv2 bruker UDP 500 og 4500: hvilken av dem bærer dataene?

Å åpne UDP 500 i brannmuren lar tunnelen forhandle, og deretter slutter forbindelsen å føre trafikk. Portlisten var ufullstendig, ikke feil. IKEv2 starter på én socket og fortsetter i mange reelle utrullinger på en annen, mens nyttelasten slett ikke trenger å være en port. Å lese fasene i rekkefølge forklarer hvilken regel som mangler.

To porter, to oppgaver

IKEv2 begynner med en nøkkelutveksling på UDP 500, der partene autentiserer seg og etablerer en sikkerhetsassosiasjon for tunnelen. Databanen som følger, er en egen sak: den kan være native ESP, som er et IP-protokollnummer og ikke en port, eller trafikk innkapslet i UDP på 4500. Å holde disse fra hverandre i en brannmurvurdering er forskjellen mellom en tunnel som forhandler og en tunnel som virker. Den ene socketen bærer kontroll, den andre nyttelast.

Derfor gir en regel som bare tillater 500 det mest forvirrende symptomet i hele protokollfamilien: forhandlingen lykkes, og ingenting nyttig følger. Tilstanden viser en peer, loggen viser en etablert IKE SA, og applikasjonen får fortsatt tidsavbrudd. Tillatelsen som mangler, hører til en annen strøm enn den som nettopp lyktes.

Hvorfor 4500 i det hele tatt finnes

Mange NAT-enheter kan ikke videresende andre protokoller enn TCP eller UDP, og noen skriver om adresser på måter som bryter ESPs integritetskontroll. Å kapsle ESP inn i UDP løser begge problemene, mot prisen av en ekstra header og en andre port som må tillates. Den innkapslingen er grunnen til at den andre porten i det hele tatt finnes.

Når NAT oppdages, flytter IKE selv også til 4500 slik at all trafikk deler én bane gjennom oversetteren. En markør på fire byte som ikke er ESP, skiller kontrollmeldinger fra data på den socketen. Byttet er en protokollbeslutning, ikke en administratorens preferanse.

Hvor kildeporten endres

En oversetter kan skrive om klientens kildeport, slik at tuppelen som ses på serveren ikke samsvarer med tuppelen på klienten. Se på begge sider av hvert NAT-hopp før du konkluderer med at en regel ignoreres. Feilsøking bare på klienten kan gi en regel som ser riktig ut og likevel feiler.

MOBIKE-kompatible implementasjoner kan også flytte til 4500 uten at NAT oppdages, og noen utrullinger tvinger den banen med vilje. Å se 4500 er derfor bevis for en beslutning, ikke bevis for en hjemmeruter.

Sjekk begge strømmene ved hver grense

Gå gjennom de tre grensene: klientnettet, eventuell mellomliggende brannmur og serveren. Hver av dem trenger strømmene utrullingen dokumenterer, ikke strømmene fra en artikkel om et annet tilfelle.

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-linjen i en brannmurliste er en protokolltreff, så en portregel dekker den aldri. Hvis operatøren bruker en tilpasset port, følg den dokumenterte konfigurasjonen i begge ender, fordi en klient ikke kan opprette en lytter på serveren ved å velge et kjent nummer.

Noter hvor forhandlingen stoppet og om en underordnet sikkerhetsassosiasjon ble installert, fordi det paret skiller en blokkert bane fra en autentiserings- eller policyfeil. Gjenta deretter testen med serververifisering aktivert, fordi tilgjengelighet ikke er autentisering. Det siste trinnet skiller en tillatt port fra en klarert peer.