IKEv2 uzas UDP 500 kaj 4500: kiu el ili portas la datumojn?

La unua interŝanĝo kaj la vojo, kiu portas datumojn, ne estas la sama fluo. Kontrolu ambaŭ pordojn kaj memoru, ke denaska ESP estas protokola numero, ne pordo.

Malfermi UDP 500 en la fajromuro ebligas al la tunelo intertrakti, kaj poste la konekto ĉesas pasigi trafikon. La pordolisto estis nekompleta, ne malĝusta. IKEv2 komenciĝas sur unu soketo kaj, en multaj realaj deplojoj, daŭras sur alia, dum la utilaĵo eble tute ne estas pordo. Legi la etapojn laŭ ordo klarigas, kiu regulo mankas.

Du pordoj, du taskoj

IKEv2 komenciĝas per ŝlosila interŝanĝo sur UDP 500, kie la partneroj aŭtentikiĝas kaj starigas sekurecan asocion por la tunelo. La datumvojo, kiu sekvas, estas aparta afero: ĝi povas esti denaska ESP, kiu estas IP-protokola numero anstataŭ pordo, aŭ trafiko enkapsuligita en UDP sur 4500. Teni ilin apartaj en fajromura revizio estas la diferenco inter tunelo, kiu intertraktas, kaj tunelo, kiu funkcias. Unu soketo portas regadon kaj la alia portas la utilaĵon.

Tial regulo permesanta nur 500 produktas la plej konfuzan simptomon en la tuta protokolofamilio: la intertraktado sukcesas kaj nenio utila sekvas. La stato montras partneron, la protokolo montras starigitan IKE SA, kaj la aplikaĵo ankoraŭ tempolimas. La mankanta permeso apartenas al alia fluo ol tiu, kiu ĵus sukcesis.

Kial 4500 entute ekzistas

Multaj NAT-aparatoj ne povas plusendi alian protokolon ol TCP aŭ UDP, kaj iuj reskribas adresojn tiel, ke rompiĝas la integreca kontrolo de ESP. Enkapsuligi ESP en UDP solvas ambaŭ problemojn, kontraŭ kosto de plia kaplinio kaj dua pordo por permesi. Tiu enkapsuligo estas la kialo, ke la dua pordo entute ekzistas.

Post kiam NAT estas detektita, IKE mem ankaŭ transiras al 4500, por ke la tuta trafiko dividu unu vojon tra la tradukilo. Markilo de kvar bajtoj, kiu ne estas ESP, distingas regadmesaĝojn de datumoj sur tiu soketo. La transiro estas protokola decido, ne prefero de administranto.

Kie ŝanĝiĝas la fonta pordo

Tradukilo povas reskribi la fontan pordon de la kliento, do la tuple vidata ĉe la servilo ne kongruas kun la tuple ĉe la kliento. Rigardu ambaŭ flankojn de ĉiu NAT-salto antaŭ ol konkludi, ke regulo estas ignorata. Solvado de problemoj nur ĉe la kliento povas doni regulon, kiu aspektas ĝusta kaj tamen malsukcesas.

MOBIKE-kapablaj realigoj povas ankaŭ transiri al 4500 sen detektita NAT, kaj iuj deplojoj intence devigas tiun vojon. Vidi do 4500 estas pruvo de decido, ne pruvo de hejma enkursigilo.

Kontrolu ambaŭ fluojn ĉe ĉiu limo

Iru tra la tri limoj: la klienta reto, ajna intera fajromuro kaj la servilo. Ĉiu bezonas la fluojn, kiujn la deplojo dokumentas, ne la fluojn el artikolo pri alia kazo.

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

La ESP-linio en fajromura listo estas protokola kongruo, do pordoregulo neniam kovras ĝin. Se la operatoro uzas propran pordon, sekvu la dokumentitan agordon ĉe ambaŭ finoj, ĉar kliento ne povas krei aŭskultanton ĉe la servilo elektante konatan numeron.

Notu, kie la intertraktado haltis kaj ĉu infana sekureca asocio estis instalita, ĉar tiu paro apartigas blokitan vojon de aŭtentikiga aŭ politika eraro. Poste ripetu la teston kun ŝaltita servila kontrolado, ĉar atingeblo ne estas aŭtentikigo. Tiu lasta paŝo apartigas permesitan pordon de fidinda partnero.

Rilataj artikoloj