IKEv2 brukar UDP 500 og 4500: kva for ein ber dataa?

Den første utvekslinga og vegen som ber dataa er ikkje same straum. Sjekk båe portane, og hugs at native ESP er eit protokollnummer, ikkje ein port.

Å opne UDP 500 i brannmuren lèt tunnelen forhandle, og deretter sluttar sambandet å føre trafikk. Portlista var ufullstendig, ikkje feil. IKEv2 byrjar på éin socket og held fram i mange reelle utrullingar på ein annan, medan nyttelasta slett ikkje treng å vere ein port. Å lese fasane i rekkjefølgje forklarar kva regel som manglar.

To portar, to oppgåver

IKEv2 byrjar med ein nøkkelutveksling på UDP 500, der partane autentiserer seg og etablerer ein tryggleiksassosiasjon for tunnelen. Databanen som følgjer, er ei eiga sak: han kan vere native ESP, som er eit IP-protokollnummer og ikkje ein port, eller trafikk innkapsla i UDP på 4500. Å halde desse frå kvarandre i ei brannmurgransking er skilnaden mellom ein tunnel som forhandlar og ein tunnel som verkar. Den eine socketen ber kontroll, den andre nyttelast.

Difor gjev ein regel som berre tillèt 500 det mest forvirrande symptomet i heile protokollfamilien: forhandlinga lukkast, og ingenting nyttig følgjer. Tilstanden viser ein peer, loggen viser ein etablert IKE SA, og applikasjonen får framleis tidsavbrot. Løyvet som manglar, høyrer til ein annan straum enn den som nett lukkast.

Kvifor 4500 i det heile finst

Mange NAT-einingar kan ikkje videresende andre protokollar enn TCP eller UDP, og nokre skriv om adresser på måtar som bryt integratskontrollen til ESP. Å kapsle ESP inn i UDP løyser båe problema, mot prisen av ein ekstra header og ein andre port som må tillètast. Den innkapslinga er grunnen til at den andre porten i det heile finst.

Når NAT vert oppdaga, flyttar IKE sjølv òg til 4500 slik at all trafikk deler éin bane gjennom omsetjaren. Ein markør på fire byte som ikkje er ESP, skil kontrollmeldingar frå data på den socketen. Byttet er ei protokollavgjerd, ikkje ein preferanse hjå administratoren.

Kvar kjeldeporten endrar seg

Ein omsetjar kan skrive om kjeldeporten til klienten, slik at tuppelen som ein ser på tenaren ikkje svarar til tuppelen på klienten. Sjå på båe sider av kvart NAT-hopp før du konkluderer med at ein regel vert ignorert. Feilsøking berre på klienten kan gje ein regel som ser rett ut og likevel feilar.

MOBIKE-kompatible implementasjonar kan òg flytte til 4500 utan at NAT vert oppdaga, og nokre utrullingar tvingar den banen med vilje. Å sjå 4500 er difor prov på ei avgjerd, ikkje prov på ein heimeruter.

Sjekk båe straumane ved kvar grense

Gå gjennom dei tre grensene: klientnettet, eventuell mellomliggjande brannmur og tenaren. Kvar av dei treng straumane utrullinga dokumenterer, ikkje straumane frå ein artikkel om eit anna 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-linja i ei brannmurliste er eit protokolltreff, så ein portregel dekkjer henne aldri. Viss operatøren brukar ein tilpassa port, følg den dokumenterte konfigurasjonen i båe endar, fordi ein klient ikkje kan opprette ein lyttar på tenaren ved å velje eit kjent nummer.

Noter kvar forhandlinga stoppa og om ein underordna tryggleiksassosiasjon vart installert, fordi det paret skil ein blokkert bane frå ein autentiserings- eller policyfeil. Gjenta deretter testen med tenarverifisering slått på, fordi tilgjenge ikkje er autentisering. Det siste trinnet skil ein tillaten port frå ein klarert peer.

Relaterte artiklar