strongSwan ESP-in-UDP: kur nuk ka NAT për të zbuluar

Zbulimi i NAT gjen përkthimin e adresave, jo politikën e firewall-it. Një lidhje site pa NAT mund të kërkojë gjithsesi një zgjedhje të qartë ESP-in-UDP.

Zbulimi i NAT përgjigjet një pyetjeje: a ndryshuan adresat ose portat gjatë rrugës? Nuk përgjigjet nëse një firewall lejon protokollin IP 50. Portat e site-it pa asnjë përkthim mund të qëndrojnë ende pas një politike që hedh native ESP, dhe kjo kërkesë duhet të konfigurohet, jo të zbulohet. Mekanizmi është ESP-in-UDP, dhe është një vendim, jo një alternativë që shfaqet vetë.

Zbulimi është aritmetikë mbi adresat, jo një sondë firewall-i

IKEv2 mbart ngarkesa të zbulimit të NAT me hash-e të adresave dhe portave burimore e të destinacionit. Secila palë krahason atë që mori me atë që sheh lokalisht, dhe një mospërputhje i thotë se diçka e përktheu paketën. Asgjë në atë shkëmbim nuk teston nëse një router në mes përcjell protokollin 50.

Vlen të thuhet hapur pasoja praktike. Një tunel që punonte me native ESP nuk do të zbulojë vetë një firewall të ri kufizues, dhe përpjekja e tij tjetër dështon në fazën e të dhënave ndërsa IKE vazhdon të ketë sukses. Do të shihni shoqata sigurie IKE të vendosura dhe asnjë trafik të mbrojtur, që duket si defekt rrugëtimi derisa të kapni në kabllo.

Kapsulimi është pra një veti e lidhjes që konfiguroni, jo një rezultat që palët negociojnë nga sjellja e rrjetit.

Si e ndryshon encap shkëmbimin

Në një vendosje moderne strongSwan të administruar përmes swanctl.conf, cilësimi encap = yes në lidhje ndikon në shkëmbimin e zbulimit të NAT, kështu që të dyja palët përdorin kapsulim UDP për ESP. Paketat e mbrojtura më pas udhëtojnë brenda UDP, zakonisht në portën 4500, dhe të dy skajet duhet të bien dakord për këtë rregullim.

connections {
    site {
        encap = yes
        # existing approved peer, authentication and child settings
    }
}

Ai fragment i përket një përkufizimi të vërtetë lidhjeje dhe nuk është profil i plotë site-i. Mbani adresat e palës tjetër, vërtetimin dhe përzgjedhësit e trafikut child që tashmë i ekzekutoni; çelësi i vetëm i shtuar ndryshon si mbështillen të dhënat e mbrojtura, jo çfarë mbrojnë ato.

Udhëzuesi strongSwan për NAT-traversal përshkruan këtë sjellje, përfshirë ndërveprimin me portën lundruese kur përdoret MOBIKE.

Përdorni cilësimin që i përket backend-it tuaj

strongSwan ka dy backend konfigurimi, dhe çelësi ndryshon mes tyre. swanctl.conf lidhje merr encap, ndërsa një ipsec.conf lidhje e vjetër merr forceencaps. Vendosja e fjalës kyçe të një backend-i në tjetrin prodhon një konfigurim që ngarkohet pa ankesë dhe nuk ndryshon asgjë, që është më keq se një gabim.

Kontrolloni cili daemon po ekzekutohet vërtet përpara se të redaktoni çdo gjë. Në shumë shpërndarje ekzistojnë të dy skedarët, sepse njëri është mbetje e një migrimi të mëparshëm, dhe aktivi është ai që nis njësia e shërbimit. Lexoni atë njësi në vend që të hamendësoni nga vulat kohore të skedarëve. Një kontroll pesë sekondash këtu shmang orë të provës së një cilësimi që asgjë nuk e ngarkoi.

Zbatojeni ndryshimin përmes pronarit të lidhjes dhe rivendosni shoqatën brenda një dritareje të kontrolluar. Një child i instaluar tashmë mban kapsulimin e tij aktual derisa të zëvendësohet, kështu që vetëm redaktimi i skedarit nuk vërteton se rregullimi i ri është në përdorim.

Verifikoni të dhënat e mbështjella, jo vetëm portën

Kapni në portë ndërsa rrjedh trafik i mbrojtur, pastaj krahasoni atë me pamjen e vetë strongSwan:

$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list

Native ESP shfaqet si protokoll IP 50 dhe nuk i ngjan aspak UDP. ESP i mbështjellë shfaqet si datagrame UDP në 4500, ngarkesa e të cilave nuk është IKE. Trafiku IKE në të njëjtën portë nuk është provë kapsulimi, sepse MOBIKE mund ta zhvendosë IKE atje ndërsa rruga e të dhënave mbetet native, prandaj lexoni ngarkesën, jo numrin e portës.

Mbani parasysh edhe MTU-në e rrugës. Mbështjellja shton shpenzime shtesë, dhe një rrugë që mbante native ESP mund të ketë nevojë për rregullime kur paketat rriten. Trajtimi i nevojshëm i ICMP duhet të jetë tashmë pjesë e projektimit; kapsulimi nuk e heq atë varësi.

Pranoje ndryshimin kur trafiku i ri i aplikacioneve brenda tunelit shihet në kapje si ESP i mbështjellë në të dy skajet, dhe kur shërbimi i brendshëm dhe rruga e tij e kthimit vazhdojnë të punojnë. Çdo gjë më pak është një konfigurim që duket i saktë në një skedar.

Artikuj të ngjashëm