NAT-tuvastus vastab ühele küsimusele: kas aadressid või pordid muutusid teel? See ei vasta, kas tulemüür lubab IP-protokolli 50. Saidilüüsid, kus tõlkimist üldse pole, võivad siiski seista poliitika taga, mis viskab native ESP kõrvale, ja see nõue tuleb konfigureerida, mitte avastada. Mehhanism on ESP-in-UDP ja see on otsus, mitte varuvariant, mis ise tekib.

Tuvastus on aritmeetika aadressidel, mitte tulemüüri sond

IKEv2 kannab NAT-tuvastuse kasulikke koormusi koos lähte- ja sihtaadresside ning -portide räsidega. Kumbki pool võrdleb saadut sellega, mida ta kohapeal näeb, ja lahknevus ütleb talle, et miski tõlkis paketi. Miski selles vahetuses ei testi, kas keskel olev ruuter edastab protokolli 50.

Praktiline tagajärg tasub otse välja öelda. Tunnel, mis töötas native ESP-ga, ei avasta ise uut piiravat tulemüüri ja selle järgmine katse ebaõnnestub andmeetapis, samal ajal kui IKE jätkab õnnestumist. Näete loodud IKE turbeseoseid ja mingit kaitstud liiklust, mis näeb välja nagu marsruutimisviga, kuni kaablil püüate.

Kapseldamine on seega ühenduse omadus, mille te konfigureerite, mitte tulemus, mille pooled võrgu käitumisest läbi räägivad.

Kuidas encap vahetust muudab

Kaasaegses strongSwan-i juurutuses, mida hallatakse swanctl.conf kaudu, mõjutab ühendusel säte encap = yes NAT-tuvastuse vahetust nii, et mõlemad pooled kasutavad ESP jaoks UDP-kapseldamist. Kaitstud paketid liiguvad seejärel UDP sees, tavaliselt pordil 4500, ja mõlemad otspunktid peavad selle korraldusega nõustuma.

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

See fragment kuulub päris ühenduse definitsiooni sisse ega ole täielik saidiprofiil. Jätke alles partneri aadressid, autentimine ja child-liikluse selektorid, mida te juba kasutate; ainus lisatud võti muudab seda, kuidas kaitstud andmeid mähitakse, mitte mida see kaitseb.

strongSwan-i NAT-traversali juhend kirjeldab seda käitumist, sealhulgas koostoimet pordi hõljumisega, kui MOBIKE on kasutusel.

Kasutage sätet, mis kuulub teie backendile

strongSwan-il on kaks konfiguratsiooni-backendit ja võti erineb nende vahel. swanctl.conf ühendus võtab encap, samas kui vanem ipsec.conf ühendus võtab forceencaps. Ühe backendi märksõna teise panemine loob konfiguratsiooni, mis laaditakse ilma kaebuseta ja ei muuda midagi, mis on hullem kui viga.

Kontrollige, milline deemon tegelikult töötab, enne kui midagi muudate. Paljudes distributsioonides on mõlemad failid olemas, sest üks on varasema migratsiooni jäänuk, ja aktiivne on see, mille teenuseüksus käivitab. Lugege seda üksust, selle asemel et faili ajatemplite põhjal oletada. Viiesekundiline kontroll siin hoiab ära tunnid sätte testimist, mida miski ei laadinud.

Rakendage muudatus ühenduse omaniku kaudu ja taastage seos kontrollitud aknas. Juba paigaldatud child säilitab oma praeguse kapseldamise, kuni see asendatakse, seega ainult faili muutmine ei tõesta, et uus korraldus on kasutusel.

Kontrollige mähitud andmeid, mitte ainult porti

Püüdke lüüsil, kui kaitstud liiklus voolab, ja võrrelge seda seejärel strongSwan-i enda vaatega:

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

Native ESP ilmub IP-protokollina 50 ega sarnane üldse UDP-le. Mähitud ESP ilmub UDP-datagrammidena pordil 4500, mille kasulik koormus ei ole IKE. IKE-liiklus samal pordil ei ole kapseldamise tõestus, sest MOBIKE võib IKE sinna liigutada, samal ajal kui andmetee jääb native'iks, seega lugege kasulikku koormust, mitte pordi numbrit.

Pidage silmas ka tee MTU-d. Ümbris lisab üldkulutusi ja tee, mis kandis native ESP-d, võib vajada kohandusi, kui paketid kasvavad. Nõutav ICMP-käsitlus peaks juba projekti osa olema; kapseldamine ei kõrvalda seda sõltuvust.

Nõustuge muudatusega, kui tunnelis olev värske rakendusliiklus on püüdis nähtav mähitud ESP-na mõlemas otsas, ja kui sisemine teenus ja selle tagasitee ikka töötavad. Kõik vähem on konfiguratsioon, mis failis õige välja näeb.

Seotud artiklid