strongSwan ESP-in-UDP: wanneer daar geen NAT is om op te spoor nie

NAT-opsporing ontdek adresvertaling, nie firewall-beleid nie. 'n Terreinverbinding sonder NAT kan steeds 'n eksplisiete ESP-in-UDP-keuse nodig hê.

NAT-opsporing beantwoord een vraag: het die adresse of poorte onderweg verander? Dit beantwoord nie of 'n firewall IP-protokol 50 toelaat nie. Terrein-gateways sonder enige vertaling kan steeds agter 'n beleid sit wat native ESP laat val, en daardie vereiste moet gekonfigureer word eerder as ontdek. Die meganisme is ESP-in-UDP, en dit is 'n besluit eerder as 'n terugval wat vanself opduik.

Opsporing is rekenkunde op adresse, nie 'n firewall-probe nie

IKEv2 dra NAT-opsporingslading wat hashes van die bron- en bestemmingsadresse en -poorte bevat. Elke kant vergelyk wat hy ontvang het met wat hy plaaslik sien, en 'n verskil sê vir hom dat iets die pakkie vertaal het. Niks in daardie uitruiling toets of 'n router in die middel protokol 50 aanstuur nie.

Die praktiese gevolg is werd om reguit te stel. 'n Tonnel wat met native ESP gewerk het, sal nie self 'n nuut beperkende firewall ontdek nie, en sy volgende poging misluk in die datafase terwyl IKE aanhou slaag. Jy sal gevestigde IKE-veiligheidsassosiasies sien en geen beskermde verkeer nie, wat soos 'n routeringsfout lyk totdat jy op die draad vasvang.

Inkapseling is dus 'n eienskap van die verbinding wat jy konfigureer, nie 'n uitkoms wat die eweknieë uit die netwerk se gedrag beding nie.

Hoe encap die uitruiling verander

In 'n moderne strongSwan-ontplooiing wat deur swanctl.conf bestuur word, beïnvloed die instelling encap = yes op die verbinding die NAT-opsporingsuitruiling sodat beide eweknieë UDP-inkapseling vir ESP gebruik. Die beskermde pakkies reis dan binne UDP, gewoonlik op poort 4500, en beide eindpunte moet oor daardie reëling saamstem.

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

Daardie fragment hoort binne 'n werklike verbindingsdefinisie en is nie 'n volledige terreinprofiel nie. Hou die eweknie-adresse, verifikasie en kind-verkeerskeisers wat jy reeds gebruik; die enkele bygevoegde sleutel verander hoe die beskermde data toegedraai word, nie wat dit beskerm nie.

Die strongSwan-gids vir NAT-deurgang beskryf hierdie gedrag, insluitend die wisselwerking met poortverskuiwing wanneer MOBIKE in gebruik is.

Gebruik die instelling wat by jou backend hoort

strongSwan het twee konfigurasie-backends, en die sleutel verskil tussen hulle. 'n swanctl.conf-verbinding neem encap, terwyl 'n ouerwetse ipsec.conf-verbinding forceencaps neem. Om een backend se sleutelwoord in die ander te gooi, lewer 'n konfigurasie wat sonder klagte laai en niks verander nie, wat erger is as 'n fout.

Kontroleer watter daemon werklik loop voordat jy enigiets wysig. Op baie distribusies bestaan albei lêers omdat een 'n oorblyfsel van 'n vroeëre migrasie is, en die aktiewe een is dié wat die diens-eenheid begin. Lees daardie eenheid eerder as om uit lêertydstempels te raai. 'n Vyf sekondes lange kontrole hier voorkom ure se toetsing van 'n instelling wat niks gelaai het nie.

Pas die verandering toe via die verbindingseienaar en herstel die assosiasie tydens 'n beheerde venster. 'n Reeds geïnstalleerde kind behou sy huidige inkapseling totdat dit vervang word, so 'n lêerwysiging alleen bewys nie dat die nuwe reëling in gebruik is nie.

Verifieer die toegedraaide data, nie net die poort nie

Vang op die gateway vas terwyl beskermde verkeer vloei, en vergelyk dit dan met strongSwan se eie siening:

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

Native ESP verskyn as IP-protokol 50 en lyk niks soos UDP nie. Toegedraaide ESP verskyn as UDP-datagramme op 4500 waarvan die lading nie IKE is nie. IKE-verkeer op daardie selfde poort is nie bewys van inkapseling nie, want MOBIKE kan IKE daarheen skuif terwyl die datapad native bly, so lees die lading eerder as die poortnommer.

Hou pad-MTU ook in gedagte. Die omhulsel voeg oorhoofse koste by, en 'n pad wat native ESP gedra het, kan aanpassings nodig hê sodra die pakkies groei. Vereiste ICMP-hantering behoort reeds deel van die ontwerp te wees; inkapseling verwyder nie daardie afhanklikheid nie.

Aanvaar die verandering wanneer vars toepassingsverkeer binne die tonnel by beide kante as toegedraaide ESP in die opname sigbaar is, en wanneer die binneste diens en sy terugroete steeds werk. Enigiets minder is 'n konfigurasie wat reg lyk in 'n lêer.

Verwante artikels