strongSwan-ból AWS Site-to-Site-ba: miért nem választ semmit a Child SA

Az IKE-alagút állhat, miközben a gyermek-társulás kizárja az alhálózatait. Először hasonlítsa össze az AWS helyi és távoli CIDR-jét a leftsubnet és rightsubnet értékkel.

A konzol up állapotot mutat, a strongSwan felépült IKE-társulást jelent, a csomagok mégsem érkeznek meg. A következő összehasonlítandó dolog nem az előre megosztott kulcs, hanem az a prefixpár, amelyről mindkét fél azt hiszi, hogy az alagút védi. Haladjon végig sorrendben az alábbi ellenőrzéseken, mert az első kettő dönti el, hogy az alagút egyáltalán át tudja-e vinni a forgalmát.

Fordítsa le az AWS neveit a strongSwan kifejezéseire

Az AWS az ügyfél oldaláról írja le a kapcsolatot: az ügyfélátjáró címe és a helyi CIDR az Öné, a távoli CIDR pedig a VPC-hez tartozik. A strongSwan left és right néven nevezi a két véget, a prefixe a leftsubnetben, a VPC prefixe a rightsubnetben van. Egy pár felcserélése olyan alagutat eredményez, amely a rossz forgalmat tárgyalja meg és választja ki.

Töltse le az AWS által a kapcsolathoz generált konfigurációt, és tekintse annak a konkrét kapcsolatnak a referenciájaként, beleértve az alagút címét és a prefixeket. Ha létrehozáskor mindkét CIDR-mezőt üresen hagyja, a szolgáltatás mindkét oldalon a 0.0.0.0/0 alapértéket használja. Egy szűk prefixszel beállított útválasztó aztán soha nem fog egyezni vele, ezért vagy töltse ki a mezőket, vagy szándékosan szélesítse a választót.

Az eltérés itt útválasztási hibának látszik, és nem az.

Rögzítse azt a címet, amelyet az AWS ténylegesen lát

A NAT mögötti útválasztó olyan interfészről indíthat IKE-t, amelyet a túloldal soha nem ismert meg. Az AWS-ben rögzített átjárócímnek annak kell lennie, amelyet az AWS a hálózaton lát, és az útválasztót ugyanahhoz a helyi címhez kell rögzíteni, ahelyett hogy az alapértelmezett útvonalát követné.

conn %default
    local_addrs = 203.0.113.10

A strongSwanban a local_addrs választja ki az IKE forrás-címét, a régebbi OpenSwan-konfigurációk pedig ugyanezt az ötletet left néven írják. Irányítsa a nyilvános címet tartó interfészre, majd magán a NAT-eszközön ellenőrizze, hogy az UDP 500 és 4500 eléri-e azt a gazdagépet, mert egy korábbi útválasztóról maradt szabály csendben eldobja őket. A helyes választópár rossz forráscímmel is elbukik, és a napló az ajánlatot fogja hibáztatni. Ez a félrevezetés az oka annak, hogy a forráscím saját ellenőrzést érdemel.

Erősítse meg a továbbítási szabályt ahelyett, hogy feltételezné, mert az előző útválasztónak megfelelő szabály gyakran megmarad.

Kezelje külön az 1. fázist és a 2. fázist

Az AWS külön listákként mutatja az IKE- és ESP-beállításokat. Egy mindkét fél által elfogadott IKE-készlet semmit sem mond az ESP-ajánlatról, mert a két lista független. Olvassa ki mindkettőt a generált konfigurációból, és hasonlítsa össze őket egyenként.

conn aws
    ike = aes256-sha1-modp1024
    esp = aes256gcm16

A szintaxis nem utazik a megvalósítások között. Az OpenSwanben működő pár, például a phase2alg=aes_gcm az ike=aes256-sha1;modp1024 értékkel, fordításra szorul a strongSwan esp= és ike= formájára, és az algoritmusnevek eltérnek. Mivel a GCM titkosítás közben hitelesít, nincs szüksége külön integritás-transzformra, ellentétben a SHA-val párosított CBC-készlettel. Az egyik daemonból a másikba fordítás nélkül beillesztett 2. fázisú sor olyan elutasítást ad, amely választó-eltérésnek tűnik.

A gyermek-társulást ellenőrizze, ne az alagút jelzőjét

Ha a kapcsolat betöltődik, de nem jön létre gyermek-társulás, akkor vagy az ajánlatot, vagy a választókat utasították el. Ha létrejön a gyermek, és a választói kizárják a prefixeit, a csomagokat még az alagút elérése előtt szűrik. A konzol jelzője csak az IKE szintet fedi le, ezért nem tudja megmondani, melyik történt a kettő közül.

ipsec statusall

Keresse meg a gyermek biztonsági társulást, és olvassa el a mellette kiírt forgalomválasztókat, majd hasonlítsa össze őket a generált konfiguráció prefixeivel.

Teszteljen a helyi prefixen belüli gazdagépről a VPC prefixén belüli gazdagépre, és ellenőrizze a visszautat, valamint az AWS oldalán lévő biztonsági csoportot vagy hálózati ACL-t. A helyes választók nem védik meg a csomagot a későbbi eldobástól.

Amikor a választók egyezése után is elbukik

Erősítse meg, hogy az útvonal mindkét oldalon az alagútra mutat, majd erősítse meg, hogy a NAT-eszköz nem írja át a forgalmat olyan módon, amire a házirend nem számít. A házirend-alapú alagút a csomagok címeit egyezteti, ezért a házirend-döntés után alkalmazott fordítás megváltoztatja az eredményt.

Naplózzon egy bejövő és egy kimenő csomagot mindkét oldalon, mielőtt újabb ajánlatot módosít.

Rögzítse a választókat, az 1. és 2. fázisú ajánlatokat és a forráscímet a jegyben. Ez a négy érték telefonhívás nélkül megmagyarázza a legtöbb site-to-site hibát.

Kapcsolódó cikkek