strongSwan ESP-in-UDP: as der gjin NAT te ûntdekken is

NAT-ûntdekking fynt adresfertaaling, gjin firewallbelied. In sideferbining sûnder NAT kin dochs in eksplisite ESP-in-UDP-kar nedich hawwe.

NAT-ûntdekking beantwurdet ien fraach: binne de adressen of poarten ûnderweis feroare? It beantwurdet net oft in firewall IP-protokol 50 tastean. Sidepoarten sûnder hokker fertaaling dan ek kinne noch efter in belied sitte dat native ESP falle lit, en dy eask moat konfigurearre wurde ynstee fan ûntdutsen. It meganisme is ESP-in-UDP, en it is in beslút, gjin fallback dy't fansels ferskynt.

Ûntdekking is rekkenjen op adressen, gjin firewallprobe

IKEv2 draacht NAT-ûntdekkingsladingen mei hashes fan 'e boarne- en bestimmingsadressen en -poarten. Eltse kant ferliket wat er ûntfong mei wat er lokaal sjocht, en in ferskil fertelt him dat eat it pakket fertaald hat. Neat yn dy útwikseling testet oft in router yn 'e midden protokol 50 trochstjoert.

It praktyske gefolch is de muoite wurdich om rjocht te sizzen. In tunnel dy't mei native ESP wurke, sil net fansels in nij beheinend firewall ûntdekke, en syn folgjende besykjen mislearret yn 'e datafaze wylst IKE trochgiet mei slagjen. Jo sille fêstige IKE-feiligensassosjaasjes sjen en gjin beskerme ferkear, wat as in routeringsflater liket oant jo op 'e tried fange.

Ynkapseling is dus in eigenskip fan 'e ferbining dy't jo konfigurearje, net in útkomst dy't de pearen ûnderhannelje út it gedrach fan it netwurk.

Hoe't encap de útwikseling feroaret

Yn in moderne strongSwan-útriol fan stâl, beheard fia swanctl.conf, beynfloedet de ynstelling encap = yes op 'e ferbining de NAT-ûntdekkingsútwikseling sa dat beide pearen UDP-ynkapseling foar ESP brûke. De beskerme pakketten reizgje dan binnen UDP, gewoanlik op poarte 4500, en beide einen moatte it oer dy regeling iens wêze.

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

Dat fragmint heart binnen in echte ferbiningsdefinysje en is gjin folslein sideprofyl. Hâld de peer-adressen, autentikaasje en child-ferkearsselektors dy't jo al rinne; de iene tafoege kaai feroaret hoe't de beskerme gegevens ynpakt wurde, net wat se beskermje.

De strongSwan-gids oer NAT-traversal beskriuwt dit gedrach, ynklusyf de ynteraksje mei poartefleat as MOBIKE brûkt wurdt.

Brûk de ynstelling dy't by jo backend heart

strongSwan hat twa konfiguraasje-backends, en de kaai ferskilt tusken har. In swanctl.conf-ferbining nimt encap, wylst in âldere ipsec.conf-ferbining forceencaps nimt. It pleatsen fan it kaaiwurd fan ien backend yn 'e oare makket in konfiguraasje dy't sûnder klacht laden wurdt en neat feroaret, wat slimmer is as in flater.

Kontrolearje hokker daemon eins draait foardat jo eat bewurkje. Op in protte distribúsjes besteane beide bestannen omdat ien in oerbliuwsel fan in eardere migraasje is, en de aktive is dy't de tsjinst-ienheid start. Lês dy ienheid ynstee fan te rieden út bestâns tiidstimpels. In kontrôle fan fiif sekonden hjir foarkomt oeren testen fan in ynstelling dy't neat laden hat.

Tapas de feroaring ta fia de eigner fan 'e ferbining en herstelle de assosjaasje yn in beheard finster. In al ynstallearre child hâldt syn hjoeddeistige ynkapseling oant it ferfongen wurdt, dus in bestânsbewurking allinnich bewiist net dat de nije regeling brûkt wurdt.

Ferifiearje de ynpakte gegevens, net allinnich de poarte

Fange op 'e poarte wylst beskerme ferkear streamt, en ferlykje dat dan mei strongSwan syn eigen byld:

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

Native ESP ferskynt as IP-protokol 50 en liket neat op UDP. Ynpakt ESP ferskynt as UDP-datagrammen op 4500 wêrfan de lading gjin IKE is. IKE-ferkear op deselde poarte is gjin bewiis fan ynkapseling, want MOBIKE kin IKE dêrhinne ferpleatse wylst it datapaad native bliuwt, dus lês de lading, net it poartenûmer.

Hâld ek de MTU fan it paad yn gedachten. De wiksel foeget oerhead ta, en in paad dat native ESP droech kin oanpassingen nedich hawwe as de pakketten groeie. Ferplichte ICMP-ôfhanneling soe al part fan it ûntwerp wêze moatte; ynkapseling hellet dy ôfhinklikens net wei.

Akseptearje de feroaring as frisse applikaasjeferkear yn 'e tunnel yn 'e opname as ynpakt ESP oan beide einen sichtber is, en as de binnenste tsjinst en syn weromrûte noch wurkje. Alles minder is in konfiguraasje dy't yn in bestân goed liket.

Relatearre artikelen