IKEv2 brûkt UDP 500 en 4500: hokker fan de twa draacht de gegevens?

UDP 500 iepenje yn 'e firewall lit de tunnel ûnderhannelje, en dêrnei hâldt de ferbining op mei ferkear troch te litten. De poartelist wie ûnfolslein, net ferkeard. IKEv2 begjint op ien socket en giet yn in protte echte ynstallaasjes troch op in oare, wylst de lading hielendal gjin poart wêze hoecht. It lêzen fan de fazen yn folchoarder ferklearret hokker regel mist.

Twa poarten, twa taken

IKEv2 begjint mei in kaai-útwikseling op UDP 500, dêr't de pearen har autentisearje en in befeiligingsassosjaasje foar de tunnel fêstigje. It gegevenspaad dat folget is in aparte kwestje: it kin native ESP wêze, dat in IP-protokolnummer is yn stee fan in poart, of ferkear dat yn UDP ferpakt is op 4500. Dy twa skiede yn in firewaltrochgong is it ferskil tusken in tunnel dy't ûnderhannelt en in tunnel dy't wurket. Ien socket draacht kontrôle en de oare draacht de lading.

Dêrom jout in regel dy't allinnich 500 tastean it meast betiizjende symptoom yn 'e hiele protokolfamylje: de ûnderhanneling slagget en der folget neat nuttich. De steat toant in pear, it loch toant in stifte IKE SA, en de applikaasje rint noch hieltyd op tiid út. De ûntbrekkende tastimming heart by in oare stream as dy't krekt slagge.

Wêrom't 4500 uberhapt bestiet

In protte NAT-apparaten kinne gjin oar protokol as TCP of UDP trochjaan, en guon skriuwe adressen op sa'n wize oer dat de yntegriteitskontrôle fan ESP brekt. ESP yn UDP ferpakke lost beide problemen op, tsjin de priis fan in ekstra kop en in twadde poart dy't tastien wurde moat. Dy ferpakking is de reden dat de twadde poart uberhapt bestiet.

Sadree't NAT ûntdutsen is, ferhúzet IKE sels ek nei 4500 sadat alle ferkear ien paad troch de oersetter dielt. In marker fan fjouwer bytes dy't gjin ESP is, skiedet kontrôleberjochten fan gegevens op dy socket. De oergong is in protokolbeslút, net in foarkar fan de behearder.

Wêr't de boarnepoart feroaret

In oersetter kin de boarnepoart fan 'e klant oerskriuwe, sadat de tuple dy't de tsjinner sjocht net oerienkomt mei de tuple op 'e klant. Sjoch nei beide kanten fan elke NAT-hop foardat jo konkludearje dat in regel negearre wurdt. Problemen sykje allinnich op 'e klant kin in regel opleverje dy't goed liket en dochs mislearret.

MOBIKE-geskikte ymplemintaasjes kinne ek nei 4500 gean sûnder ûntdutsen NAT, en guon ynstallaasjes twinge dat paad opsetlik ôf. 4500 sjen is dus bewiis fan in beslút, net bewiis fan in thúsrouter.

Kontrolearje beide streamen op elke grins

Gean troch de trije grinzen: it klantnetwurk, elke tuskenlizzende firewall en de tsjinner. Elk hat de streamen nedich dy't de ynstallaasje dokumintearret, net de streamen út in stik oer in oar gefal.

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

De ESP-rige yn in firewal-list is in protokoloerienkomst, dus in poartregel dekt dy nea. As de operator in oanpaste poart brûkt, folgje dan de dokumintearre konfiguraasje oan beide kanten, want in klant kin gjin listener op de tsjinner meitsje troch in fertroud nûmer te kiezen.

Skriuw op wêr't de ûnderhanneling stoppe en oft in bernbefeiligingsassosjaasje ynstallearre is, want dat pear skiedt in blokkearre paad fan in autentikaasje- of beliedsflater. Werhelje dan de test mei tsjinnerferifikaasje oan, want berikberens is gjin autentikaasje. Dy lêste stap skiedt in tastiene poart fan in fertroude pear.