strongSwan ESP-in-UDP: amikor nincs felderítendő NAT

A NAT-felderítés egy kérdésre válaszol: változtak-e útközben a címek vagy a portok? Arra nem válaszol, hogy egy tűzfal engedélyezi-e az IP 50-es protokollt. Fordítás nélküli helyszín-átjárók is állhatnak olyan szabályzat mögött, amely eldobja a native ESP-t, és ezt a követelményt konfigurálni kell, nem felderíteni. A mechanizmus az ESP-in-UDP, és ez döntés, nem magától megjelenő tartalék megoldás.

A felderítés címeken végzett aritmetika, nem tűzfalpróba

Az IKEv2 NAT-felderítő hasznos terheket szállít, amelyek a forrás- és célcímek, valamint -portok hash-eit tartalmazzák. Mindkét fél összeveti a kapottat azzal, amit helyben lát, és az eltérés azt mondja neki, hogy valami lefordította a csomagot. Ebben az eszmecserében semmi sem vizsgálja, hogy egy közbenső útválasztó továbbítja-e az 50-es protokollt.

Érdemes nyíltan kimondani a gyakorlati következményt. Egy native ESP-vel működő alagút nem fedezi fel magától az új, korlátozó tűzfalat, és a következő kísérlete az adatszakaszban elbukik, miközben az IKE továbbra is sikeres. Látni fog létrehozott IKE-biztonsági társításokat és semmilyen védett forgalmat, ami útválasztási hibának látszik addig, amíg a vezetéken el nem kapja.

A beágyazás tehát a konfigurált kapcsolat tulajdonsága, nem olyan eredmény, amelyről a felek a hálózat viselkedése alapján tárgyalnak.

Hogyan változtatja meg az encap az eszmecserét

Egy modern strongSwan-telepítésben, amelyet swanctl.conf kezel, a kapcsolat encap = yes beállítása hat a NAT-felderítő eszmecserére, hogy mindkét fél UDP-beágyazást használjon az ESP-hez. A védett csomagok ezután UDP-n belül, jellemzően a 4500-as porton utaznak, és mindkét végpontnak egyet kell értenie ebben az elrendezésben.

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

Ez a töredék valódi kapcsolatdefinícióba tartozik, és nem teljes helyszínprofil. Tartsa meg a társ-címeket, a hitelesítést és a child-forgalom szelektorokat, amelyeket már futtat; az egyetlen hozzáadott kulcs azt változtatja meg, hogyan csomagolják a védett adatokat, nem azt, hogy mit védenek.

A strongSwan NAT-traversal útmutatója leírja ezt a viselkedést, beleértve a port lebegésével való kölcsönhatást, amikor MOBIKE-et használnak.

Azt a beállítást használja, amely az Ön backendjéhez tartozik

A strongSwan-nak két konfigurációs backendje van, és a kulcs különbözik közöttük. swanctl.conf-kapcsolat encap-t vesz fel, míg egy régebbi ipsec.conf-kapcsolat forceencaps-t vesz fel. Az egyik backend kulcsszavát a másikba tenni olyan konfigurációt eredményez, amely panasz nélkül betöltődik és semmit sem változtat, ami rosszabb egy hibánál.

Nézze meg, melyik démon fut valójában, mielőtt bármit szerkeszt. Sok disztribúcióban mindkét fájl létezik, mert az egyik egy korábbi migráció maradványa, és az aktív az, amelyiket a szolgáltatásegység indít. Olvassa azt az egységet, ahelyett hogy a fájlok időbélyegeiből találgatna. Egy öt másodperces ellenőrzés itt órákat takarít meg egy olyan beállítás teszteléséből, amelyet semmi sem töltött be.

Alkalmazza a változtatást a kapcsolat tulajdonosán keresztül, és állítsa helyre a társítást egy ellenőrzött ablakban. A már telepített child megtartja jelenlegi beágyazását, amíg le nem cserélik, így a fájl szerkesztése önmagában nem bizonyítja, hogy az új elrendezés használatban van.

A becsomagolt adatokat ellenőrizze, ne csak a portot

Rögzítsen az átjárón, miközben védett forgalom folyik, majd hasonlítsa össze a strongSwan saját nézetével:

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

A native ESP IP 50-es protokollként jelenik meg, és egyáltalán nem hasonlít az UDP-re. A becsomagolt ESP 4500-on UDP-datagramokként jelenik meg, amelyek hasznos terhe nem IKE. Az IKE-forgalom ugyanazon a porton nem bizonyíték a beágyazásra, mert a MOBIKE odaviheti az IKE-et, miközben az adatút native marad, ezért a hasznos terhet olvassa, ne a portszámot.

Tartsa szem előtt az útvonal MTU-ját is. A burkolat többletterhelést ad, és egy native ESP-t szállító útvonalnak beállításokra lehet szüksége, ahogy a csomagok nőnek. A szükséges ICMP-kezelésnek már a tervezés része kell legyen; a beágyazás nem szünteti meg ezt a függőséget.

Akkor fogadja el a változtatást, ha az alagúton belüli friss alkalmazásforgalom a rögzítésben mindkét végén becsomagolt ESP-ként látható, és ha a belső szolgáltatás és visszatérési útvonala továbbra is működik. Ennél kevesebb olyan konfiguráció, amely egy fájlban helyesnek látszik.