Proč trasa OpenVPN podléhá politice XFRM v strongSwan

Pakety mohou sledovat trasu OpenVPN a přesto být zachyceny politikou IPsec, a tato kombinace vypadá jako chyba směrování ze všech úhlů kromě toho správného. Linux vyřeší trasu a poté se obrátí na samostatnou databázi bezpečnostních politik, takže konkrétnější trasa k cíli nevytlačí odpovídající politiku XFRM. Viditelným příznakem je provoz, který opustí hostitele a nikdy nedorazí, zatímco oba tunely se hlásí jako zdravé. Řeší to tři možnosti a kterou zvolíte, závisí na tom, která ze dvou cest má tento prefix nést.

Dvě rozhodnutí, ne jedno

Výběr trasy odpovídá na úzkou otázku: který další skok a zdrojová adresa mají tento paket nést. Databáze bezpečnostních politik odpovídá na jinou: vyžaduje tento paket ochranu IPsec a pod kterými selektory. Obě probíhají pro stejný paket a splnění prvního neříká o druhém nic. Proto změna metriky nebo přidání statické trasy může příznak nechat nedotčený.

Široký selektor IPsec je obvyklou příčinou. Politika chránící 172.16.0.0/12 pokrývá i 172.20.8.0/24, kam správce možná chce dosáhnout tunelem OpenVPN. Záměr existuje jen ve směrovací tabulce a databáze politik se o něm nikdy nedozvěděla.

Berte to jako konflikt mezi dvěma nakonfigurovanými cestami ochrany, nikoli jako souboj dvou metrik. Oprava patří do komponenty, která byla nakonfigurována s nesprávným rozsahem.

Přečtěte si trasu, kterou jádro skutečně volí

Začněte vyhledáním, které jádro provádí, včetně zdrojové adresy a každého pravidla politiky, které by ji mohlo odklonit do jiné tabulky. Trasa v hlavní tabulce nemusí být nikdy zvážena, pokud dřívější pravidlo vybere jinou tabulku, a shoda nejdelšího prefixu platí jen v tabulce, kterou pravidlo zvolí.

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

Poslední příkaz je ten, na kterém záleží, protože vypisuje zvolenou trasu spolu se zdrojovou adresou, kterou by jádro použilo. Porovnejte tento výstup se selektorem, kterému odpovídá politika IPsec. Když trasa ukazuje na rozhraní OpenVPN a politika stále odpovídá stejnému páru, reprodukovali jste konflikt bez hádání.

Udržujte výpisy bez nesouvisejících adres, než se dostanou do tiketu. Směrovací tabulka z produkčního hostitele nese interní topologii a vložit se vyplatí jen řádky, které odpovídají na otázku.

Přečtěte si politiku, která platí také

Výpis politik ukazuje směr, selektory a šablonu, která rozhoduje, co se stane s odpovídajícím paketem. Čtěte nejprve odchozí směr, poté vstupní stranu pro zpětný provoz, protože jednosměrná výjimka vytváří spojení, které začne a nikdy se nedokončí.

ip -s xfrm policy
swanctl --list-sas

Porovnejte selektory ve výpisu s prefixy, které spojení vyjednalo. Vypnutí instalace tras v strongSwan tyto politiky neodstraní a změna metriky nemění, který pár zdroje a cíle politika chrání. Tyto dvě nepravé opravy se vyplatí vyloučit brzy, protože je lidé zkoušejí jako první.

Pokud výpis neobsahuje politiku pro očekávaný prefix, problém je jinde a směrovací tabulka pravděpodobně říká pravdu. Pokud obsahuje širší politiku, která prefix pokrývá, našli jste zachycení.

Tři možnosti, když jsou obě cesty oprávněné

Zúžení selektoru IPsec je nejčistší možnost, když byl široký prefix pohodlím, nikoli požadavkem. Zmenšení selektoru vzdáleného provozu na podsítě, které skutečně patří za IPsec, odstraní konflikt pro každého hostitele najednou a stojí obnovu klíčů, ne novou komponentu.

Výjimka průchodu je chirurgická možnost, když široký selektor musí zůstat. strongSwan podporuje samostatné spojení, jehož potomek používá režim pass, což jádru říká, že odpovídající provoz nesmí být zpracován přes IPsec. Vzdálená adresa loopback brání tomu, aby bylo toto spojení vybráno pro příchozí partnery, a selektory musí popisovat skutečný povolený pár, ne vše.

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
            }
        }
    }
}

Příklady konfigurace strongSwan dokumentují tento typ politiky a konvenci loopback partnera. Třetí možností je design založený na směrování s rozhraními XFRM, který váže politiku na provoz směrovaný přes pojmenované rozhraní místo na globální selektor. Je to migrace, ne úprava, a provoz musí stále splňovat vyjednané selektory.

Dokažte výjimku, aniž byste oslabili zbytek

Po načtení změny otestujte výjimku a běžný cíl, který musí zůstat chráněný. Zkontrolujte oba směry, poté shodte tunel OpenVPN a potvrďte, co se stane s vyjmutým provozem. Výjimka, která při vypnutém tunelu tiše posílá tento prefix v otevřené podobě, je rozhodnutí o politice, které byste měli učinit záměrně, ne objevit během incidentu.

Zaznamenejte, který prefix používá kterou cestu a proč. Jinak další inženýr, který uvidí široký selektor, znovu otevře stejné vyšetřování a odpověď bude v commit zprávě, kterou nikdo nečte.