IKEv2-k UDP 500 eta 4500 erabiltzen ditu: zeinek eramaten ditu datuak?

Suhormagailuan UDP 500 irekitzeak tunelari negoziatzen uzten dio, eta gero konexioak trafikoa pasatzeari uzten dio. Portuen zerrenda osatugabea zen, ez okerra. IKEv2 socket batean hasten da eta inplementazio erreal askotan beste batean jarraitzen du, karga erabilgarria portu bat ere ez izan daitekeen bitartean. Etapak hurrenez hurren irakurtzeak azaltzen du zein arau falta den.

Bi portu, bi zeregin

IKEv2 gako-truke batekin hasten da UDP 500ean, non pareek autentifikatu eta tunelerako segurtasun-elkarte bat ezartzen duten. Jarraitzen duen datu-bidea kontu bereizia da: ESP natiboa izan daiteke, hau da, IP protokolo-zenbaki bat eta ez portu bat, edo UDP barruan kapsulatutako trafikoa 4500ean. Suhormagailuaren berrikuspenean horiek bereiztea negoziatzen duen tunelaren eta funtzionatzen duen tunelaren arteko aldea da. Socket batek kontrola darama eta besteak karga erabilgarria.

Horregatik, 500 soilik baimentzen duen arau batek protokolo-familia osoko sintomarik nahasgarriena sortzen du: negoziazioak arrakasta du eta ez da ezer erabilgarririk etortzen. Egoerak pare bat erakusten du, erregistroak ezarritako IKE SA bat erakusten du, eta aplikazioak oraindik denbora-muga gainditzen du. Falta den baimena orain dela gutxi arrakasta izan zuen fluxuaz bestelako fluxu bati dagokio.

Zergatik dago 4500 batere

NAT gailu askok ezin dute TCP edo UDP ez den protokolorik birbidali, eta batzuek helbideak ESPren osotasun-egiaztapena hausten duten moduan berridazten dituzte. ESP UDPren barruan kapsulatzeak bi arazoak konpontzen ditu, goiburu gehigarri baten eta baimendu beharreko bigarren portu baten truke. Kapsulazio hori da bigarren portua batere existitzeko arrazoia.

NAT detektatu ondoren, IKE bera ere 4500era pasatzen da, trafiko guztiak itzultzailetik bide bakarra parteka dezan. ESP ez den lau byteko markatzaile batek kontrol-mezuak datuetatik bereizten ditu socket horretan. Aldaketa protokoloaren erabakia da, ez administratzailearen hobespena.

Non aldatzen den iturburuko portua

Itzultzaileak bezeroaren iturburuko portua berridatz dezake, beraz zerbitzarian ikusten den tuplak ez du bezeroaren tuplarekin bat egiten. Begiratu NAT jauzi bakoitzaren bi aldeak arau bat alde batera uzten ari dela ondorioztatu aurretik. Bezeroan soilik arazoak bilatzeak zuzena dirudien eta hala ere huts egiten duen araua eman dezake.

MOBIKE onartzen duten inplementazioek NAT detektatu gabe ere 4500era pasa daitezke, eta zenbait inplementaziok bide hori nahita behartzen dute. Beraz, 4500 ikustea erabaki baten froga da, ez etxeko router baten froga.

Egiaztatu bi fluxuak muga bakoitzean

Igo hiru mugak: bezeroaren sarea, tarteko suhormagailua eta zerbitzaria. Bakoitzak inplementazioak dokumentatzen dituen fluxuak behar ditu, beste kasu bati buruzko artikulu bateko fluxuak ez.

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

Suhormagailuen zerrendako ESP lerroa protokolo-kointzidentzia da, beraz portu-arau batek ez du inoiz estaltzen. Operadoreak portu pertsonalizatua erabiltzen badu, jarraitu mutur bietan dokumentatutako konfigurazioa, zeren bezeroak ezin baitio zerbitzarian entzule bat sortu zenbaki ezagun bat aukeratuz.

Erregistratu non gelditu zen negoziazioa eta seme-segurtasun-elkartea instalatu zen ala ez, bikote horrek bide blokeatua autentifikazio- edo politika-errore batetik bereizten baitu. Ondoren errepikatu proba zerbitzariaren egiaztapena gaituta, irisgarritasuna ez baita autentifikazioa. Azken urrats horrek baimendutako portua konfiantzazko pare batetik bereizten du.