strongSwan ESP-in-UDP: kiam ne estas NAT por detekti
NAT-detektado trovas adresan tradukon, ne fajroŝirman politikon. Reteja konekto sen NAT povas tamen bezoni eksplicitan elekton de ESP-in-UDP.
NAT-detektado respondas unu demandon: ĉu la adresoj aŭ pordoj ŝanĝiĝis dumvoje? Ĝi ne respondas, ĉu fajroŝirmilo permesas IP-protokolon 50. Retejaj pordegoj tute sen traduko ankoraŭ povas stari malantaŭ politiko, kiu forĵetas native ESP, kaj tiu postulo devas esti agordita anstataŭ malkovrita. La mekanismo estas ESP-in-UDP, kaj ĝi estas decido, ne rezerva solvo, kiu aperas per si mem.
Detektado estas aritmetiko sur adresoj, ne fajroŝirma sondado
IKEv2 portas NAT-detektajn utilŝarĝojn kun haketoj de la fontaj kaj celaj adresoj kaj pordoj. Ĉiu flanko komparas tion, kion ĝi ricevis, kun tio, kion ĝi vidas loke, kaj malkongruo diras al ĝi, ke io tradukis la paketon. Nenio en tiu interŝanĝo testas, ĉu enkursigilo en la mezo plusendas protokolon 50.
Indas diri la praktikan sekvon klare. Tunelo, kiu funkciis kun native ESP, ne mem malkovros novan restriktan fajroŝirmilon, kaj ĝia sekva provo malsukcesos en la datena stadio dum IKE daŭre sukcesas. Vi vidos establitajn IKE-sekurecajn asociojn kaj neniun protektitan trafikon, kio aspektas kiel enkursiga fuŝo ĝis vi kaptos per drato.
Enkapsuligo do estas eco de la konekto, kiun vi agordas, ne rezulto, kiun la partneroj intertraktas el la konduto de la reto.
Kiel encap ŝanĝas la interŝanĝon
En moderna strongSwan-agordo administrata per swanctl.conf, la agordo encap = yes ĉe la konekto influas la NAT-detektan interŝanĝon tiel, ke ambaŭ partneroj uzas UDP-enkapsuligon por ESP. La protektitaj paketoj tiam vojaĝas ene de UDP, kutime ĉe pordo 4500, kaj ambaŭ finpunktoj devas interkonsenti pri tiu aranĝo.
connections {
site {
encap = yes
# existing approved peer, authentication and child settings
}
}
Tiu fragmento apartenas ene de reala konekta difino kaj ne estas kompleta reteja profilo. Konservu la partnerajn adresojn, aŭtentikigon kaj child-trafikajn selektilojn, kiujn vi jam uzas; la sola aldonita ŝlosilo ŝanĝas, kiel la protektitaj datumoj estas volvataj, ne kion ĝi protektas.
La gvidilo de strongSwan pri NAT-traversal priskribas ĉi tiun konduton, inkluzive la interagon kun porta flosado kiam MOBIKE estas uzata.
Uzu la agordon, kiu apartenas al via backend
strongSwan havas du agordajn backend-ojn, kaj la ŝlosilo diferencas inter ili. swanctl.conf-konekto prenas encap, dum malnova ipsec.conf-konekto forceencaps prenas. Meti la ŝlosilvorton de unu backend en la alian produktas agordon, kiu ŝarĝiĝas sen plendo kaj ŝanĝas nenion, kio estas pli malbona ol eraro.
Kontrolu, kiu demono efektive funkcias, antaŭ ol redakti ion ajn. En multaj distribuaĵoj ambaŭ dosieroj ekzistas, ĉar unu estas restaĵo de pli frua migrado, kaj la aktiva estas tiu, kiun lanĉas la serva unuo. Legu tiun unuon anstataŭ diveni el dosieraj tempomarkoj. Kvin-sekunda kontrolo ĉi tie ŝparas horojn da testado de agordo, kiun nenio ŝarĝis.
Apliku la ŝanĝon per la posedanto de la konekto kaj restarigu la asocion dum regata fenestro. Jam instalita child konservas sian nunan enkapsuligon ĝis ĝi estos anstataŭigita, do dosiera redakto sola ne pruvas, ke la nova aranĝo estas uzata.
Kontrolu la volvitajn datumojn, ne nur la pordon
Kaptu ĉe la pordego dum protektita trafiko fluas, poste komparu tion kun la propra vidmaniero de strongSwan:
$ sudo tcpdump -ni eth0 'udp port 4500' -c 20
$ sudo swanctl --list-sas --ike site
$ sudo ip xfrm state list
Native ESP aperas kiel IP-protokolo 50 kaj tute ne similas al UDP. Volvita ESP aperas kiel UDP-datagramoj ĉe 4500, kies utilŝarĝo ne estas IKE. IKE-trafiko ĉe tiu sama pordo ne estas pruvo de enkapsuligo, ĉar MOBIKE povas movi IKE tien dum la datena vojo restas native, do legu la utilŝarĝon, ne la pordan numeron.
Memoru ankaŭ la voj-MTU. La volvaĵo aldonas superkoston, kaj vojo, kiu portis native ESP, eble bezonos ĝustigojn kiam la paketoj kreskos. Bezonata ICMP-traktado jam devus esti parto de la dezajno; enkapsuligo ne forigas tiun dependecon.
Akceptu la ŝanĝon, kiam freŝa aplikada trafiko ene de la tunelo videblas en la kapto kiel volvita ESP ĉe ambaŭ finoj, kaj kiam la interna servo kaj ĝia reena vojo ankoraŭ funkcias. Io ajn malpli estas agordo, kiu aspektas ĝusta en dosiero.