IKEv2 naudoja UDP 500 ir 4500: kuris iš jų perneša duomenis?

UDP 500 atidarymas užkardoje leidžia tuneliui derėtis, o po to ryšys nustoja praleisti srautą. Prievadų sąrašas buvo nepilnas, o ne klaidingas. IKEv2 prasideda viename lizde ir daugelyje realių diegimų tęsiasi kitame, o naudingoji apkrova gali būti visai ne prievadas. Etapų skaitymas iš eilės paaiškina, kurios taisyklės trūksta.

Du prievadai, du darbai

IKEv2 prasideda raktų mainais per UDP 500, kur šalys autentifikuojasi ir sukuria saugumo asociaciją tuneliui. Tolesnis duomenų kelias yra atskiras klausimas: tai gali būti vietinis ESP, kuris yra IP protokolo numeris, o ne prievadas, arba srautas, įkapsuliuotas UDP 4500 prievade. Šių dalykų atskyrimas užkardos apžvalgoje yra skirtumas tarp tunelio, kuris derasi, ir tunelio, kuris veikia. Vienas lizdas perneša valdymą, kitas – apkrovą.

Todėl taisyklė, leidžianti tik 500, sukelia labiausiai klaidinančią simptomą visoje protokolų šeimoje: derybos pavyksta, o nieko naudingo neįvyksta. Būsena rodo partnerį, žurnalas rodo nustatytą IKE SA, o programa vis tiek baigia laiką. Trūkstamas leidimas priklauso kitam srautui nei tas, kuris ką tik pavyko.

Kodėl 4500 apskritai egzistuoja

Daugelis NAT įrenginių negali persiųsti kito protokolo nei TCP ar UDP, o kai kurie perrašo adresus taip, kad sugriauna ESP vientisumo patikrą. ESP įkapsuliavimas UDP sprendžia abi problemas, tačiau kainuoja papildomą antraštę ir antrą prievadą, kurį reikia leisti. Būtent šis įkapsuliavimas yra priežastis, kodėl antras prievadas apskritai egzistuoja.

Kai aptinkamas NAT, pats IKE taip pat persikelia į 4500, kad visas srautas dalytųsi vienu keliu per vertėją. Keturių baitų žymeklis, kuris nėra ESP, tame lizde atskiria valdymo pranešimus nuo duomenų. Šis perėjimas yra protokolo sprendimas, o ne administratoriaus pasirinkimas.

Kur keičiasi šaltinio prievadas

Vertėjas gali perrašyti kliento šaltinio prievadą, todėl serverio matoma pora nesutampa su kliento pora. Prieš darydami išvadą, kad taisyklė ignoruojama, pažiūrėkite į abi kiekvieno NAT šuolio puses. Trikčių šalinimas tik kliente gali duoti taisyklę, kuri atrodo teisinga ir vis tiek nepavyksta.

MOBIKE palaikančios implementacijos taip pat gali pereiti prie 4500 neaptikus NAT, o kai kurie diegimai tą kelią sąmoningai primeta. Todėl 4500 matymas yra sprendimo įrodymas, o ne namų maršrutizatoriaus įrodymas.

Patikrinkite abu srautus kiekvienoje riboje

Pereikite tris ribas: kliento tinklą, bet kokią tarpinę užkardą ir serverį. Kiekvienai reikia srautų, kuriuos dokumentuoja diegimas, o ne srautų iš straipsnio apie kitą atvejį.

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 eilutė užkardos sąraše yra protokolo atitikimas, todėl prievado taisyklė jos niekada neapima. Jei operatorius naudoja pasirinktinį prievadą, laikykitės dokumentuotos konfigūracijos abiejuose galuose, nes klientas negali sukurti klausytojo serveryje pasirinkdamas pažįstamą numerį.

Užfiksuokite, kur derybos sustojo ir ar buvo įdiegta antrinė saugumo asociacija, nes ši pora atskiria užblokuotą kelią nuo autentifikavimo ar politikos klaidos. Tada pakartokite testą įjungę serverio patikrą, nes pasiekiamumas nėra autentifikavimas. Šis paskutinis žingsnis atskiria leidžiamą prievadą nuo patikimo partnerio.