Miért veszít egy OpenVPN-útvonal a strongSwan XFRM-szabályzattal szemben

A csomagok követhetnek egy OpenVPN-útvonalat és mégis egy IPsec-szabályzat elkaphatja őket, és ez a kombináció minden szögből útvonalválasztási hibának látszik, kivéve a megfelelőt. A Linux felold egy útvonalat, majd egy külön biztonsági szabályzat-adatbázist kérdez le, így egy konkrétabb célútvonal nem szorít ki egy illeszkedő XFRM-szabályzatot. A látható tünet az a forgalom, amely elhagyja a gazdagépet és soha nem érkezik meg, miközben mindkét alagút egészségesnek jelenti magát. Három lehetőség oldja meg, és hogy melyiket választja, attól függ, melyik a két útvonal közül hivatott azt a prefixet vinni.

Két döntés, nem egy

Az útvonalválasztás egy szűk kérdésre válaszol: melyik következő ugrás és forrás-cím vigye ezt a csomagot. A biztonsági szabályzat-adatbázis egy másikra válaszol: igényel-e ez a csomag IPsec-védelmet, és mely szelektorok alatt. Mindkettő ugyanarra a csomagra fut, és az első teljesítése semmit sem mond a másodikról. Ezért egy metrika módosítása vagy egy statikus útvonal hozzáadása érintetlenül hagyhatja a tünetet.

A széles IPsec-szelektor a szokásos ok. Egy 172.16.0.0/12-t védő szabályzat lefedi a 172.20.8.0/24-et is, ahová a rendszergazda esetleg az OpenVPN-alagúton keresztül kíván eljutni. A szándék csak az útválasztási táblában létezik, és a szabályzat-adatbázis soha nem szerzett tudomást róla.

Tekintse ezt két konfigurált védelmi útvonal közötti konfliktusnak, nem két metrika versenyének. A javítás ahhoz a komponenshez tartozik, amelyet rossz hatókörrel konfiguráltak.

Olvassa el az útvonalat, amelyet a kernel valóban választ

Kezdje azzal a kereséssel, amelyet a kernel végez, beleértve a forrás-címet és minden olyan szabályzati szabályt, amely másik táblába terelheti. A fő táblában lévő útvonalat soha nem is nézhetik meg, ha egy korábbi szabály másik táblát választ, és a leghosszabb prefix egyezése csak azon a táblán belül érvényes, amelyet egy szabály választ.

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

Az utolsó parancs a fontos, mert kiírja a választott útvonalat együtt a forrás-címmel, amelyet a kernel használna. Hasonlítsa össze ezt a kimenetet a szelektorral, amelyre az IPsec-szabályzat illeszkedik. Amikor az útvonal az OpenVPN-interfészre mutat, és a szabályzat továbbra is ugyanarra a párra illeszkedik, találgatás nélkül reprodukálta a konfliktust.

Tartsa a dumpokat nem kapcsolódó címektől mentesen, mielőtt jegybe kerülnek. Egy éles gazdagép útválasztási táblája belső topológiát hordoz, és csak a kérdésre válaszoló sorokat érdemes beilleszteni.

Olvassa el a szabályzatot, amely szintén érvényes

A szabályzatlistázás megmutatja az irányt, a szelektorokat és azt a sablont, amely eldönti, mi történik egy illeszkedő csomaggal. Először a kimenő irányt olvassa, majd a bejövő oldalt a visszatérő forgalomhoz, mert az egyirányú kivétel olyan kapcsolatot eredményez, amely elindul és soha nem fejeződik be.

ip -s xfrm policy
swanctl --list-sas

Hasonlítsa össze a listában lévő szelektorokat a kapcsolat által megtárgyalt prefixekkel. A strongSwan útvonaltelepítésének kikapcsolása nem távolítja el ezeket a szabályzatokat, és egy metrika módosítása nem változtatja meg, hogy egy szabályzat mely forrás-cél párt védi. Ezt a két áltjavítást érdemes korán kizárni, mert az emberek ezeket próbálják először.

Ha a lista nem tartalmaz szabályzatot a várt prefixhez, a probléma máshol van, és az útválasztási tábla valószínűleg igazat mond. Ha szélesebb szabályzatot tartalmaz, amely lefedi a prefixet, megtalálta az elfogást.

Három lehetőség, amikor mindkét útvonal jogszerű

Az IPsec-szelektor szűkítése a legtisztább lehetőség, amikor a széles prefix kényelem volt, nem követelmény. A távoli forgalom szelektorának csökkentése azokra az alhálózatokra, amelyek valóban IPsec mögé tartoznak, egyszerre megszünteti a konfliktust minden gazdagépnél, és kulcs-újratárgyalásba kerül, nem új komponensbe.

Az átengedő kivétel a sebészi lehetőség, amikor a széles szelektornak maradnia kell. A strongSwan támogat egy külön kapcsolatot, amelynek gyermeke pass módot használ, ami azt mondja a kernelnek, hogy az illeszkedő forgalmat nem szabad IPsec-kel feldolgozni. A loopback távoli cím megakadályozza, hogy ezt a kapcsolatot bejövő partnerekhez válasszák, és a szelektoroknak a valódi engedélyezett párt kell leírniuk, nem mindent.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

A strongSwan-konfigurációs példák dokumentálják ezt a szabályzattípust és a loopback-partner konvenciót. A harmadik lehetőség egy útvonalalapú tervezés XFRM-interfészekkel, amely a szabályzatot egy nevesített interfészen át irányított forgalomhoz köti globális szelektor helyett. Ez migráció, nem finomhangolás, és a forgalomnak továbbra is meg kell felelnie a megtárgyalt szelektoroknak.

Bizonyítsa a kivételt a többi gyengítése nélkül

A módosítás betöltése után tesztelje a kivételt és egy közönséges célt, amelynek védeni kell maradnia. Ellenőrizze mindkét irányt, majd ejtse el az OpenVPN-alagutat, és erősítse meg, mi történik a kivételes forgalommal. Egy kivétel, amely csendben nyíltan küldi azt a prefixet, amikor az alagút le van állva, olyan szabályzati döntés, amelyet szándékosan kell meghoznia, nem incidens közben felfedeznie.

Jegyezze fel, melyik prefix melyik útvonalat használja és miért. Különben a következő mérnök, aki széles szelektort lát, újra megnyitja ugyanazt a vizsgálatot, és a válasz egy commit-üzenetben ül, amelyet senki nem olvas.