Režim trap v strongSwan: proč IPsec tunel čeká na provoz

Nečinný IPsec tunel na vyžádání neukáže CHILD SA, dokud paket neodpovídá jeho zásadě trap. Přečtěte si stav, zkontrolujte spouštěč a vězte, kdy se hodí start.

Ve výstupu stavu se neobjeví CHILD SA, tunel vypadá mrtvý, a pak ho ping do vzdálené podsítě zvedne. V nastavení IPsec na vyžádání je tento sled záměr, ne závada. Zásada trap nainstaluje selektor a čeká, a první paket, který jí odpovídá, spustí IKE a vyjednávání CHILD SA.

Část zmatku je ve slovníku: „up“ se používá pro dva různé stavy. Konfigurace je načtená a zásada jádra existuje, ale datová asociace ne. Monitor, který počítá jen aktivní SA, bude hlásit zdravé místo jako nedostupné, dokud tam nikdo neposílá provoz.

Nečinný tunel na vyžádání nemá CHILD SA, který by ukázal

Záznam trap sám o sobě nic neautentizuje. Žádá jádro, aby drželo zásadu pro vybraný provoz a aby zvedlo acquisition, když paket tuto zásadu potřebuje. Démon acquisition přijme, spáruje ho s definicí child a odtud vyjednává. Do té doby není k zobrazení ani IKE SA, a proto mohou být oba seznamy prázdné zároveň.

Právě toto pořadí dělá logy čitelné. Nejprve přijde acquisition, pak IKE_SA_INIT a IKE_AUTH, pak CHILD SA. Končí-li log hned po acquisition, spouštěč fungoval. Vyjednávání selhalo a další otázka je o přihlašovacích údajích, návrzích nebo dostupnosti, ne o trap.

S jádrem Linux jako backendem můžete zásadu vidět dřív, než existuje jakýkoli SA. Spusťte ip xfrm policy a hledejte selektor se směrem out a šablonou ukazující na spojení. Tento záznam je stav na vyžádání a jeho přítomnost je první věc k potvrzení.

start_action rozhoduje, zda vůbec něco bude čekat

Každý child v swanctl.conf nese start_action. start se spustí při načtení konfigurace, trap nainstaluje zásadu a čeká a none nechává spuštění na něčem jiném. Jen trap vytváří chování „ping a ono se zvedne“ popsané výše.

children {
    office-lan {
        local_ts = 192.168.50.0/24
        remote_ts = 192.168.70.0/24
        start_action = trap
    }
}

Dva selektory provozu určují, co se počítá jako zajímavé, a paket z hostitele mimo tyto prefixy trap nespustí; směruje se jako obvykle. Rozšíření selektorů, aby byl spouštěč dychtivější, rozšiřuje i rozsah, který tunel tvrdí, že chrání, takže je odvozujte z provozu, který skutečně chcete šifrovat.

Referenční příručka swanctl.conf uvádí přijímané hodnoty spolu se samostatnými akcemi close a DPD, které řídí, co se stane, jakmile SA existuje.

Zjistěte, zda se spouštěč vůbec aktivoval

Začněte s swanctl --list-conns a potvrďte, že child je načtený s akcí, kterou jste zamýšleli. Pak pošlete jeden paket z hostitele uvnitř local_ts na adresu uvnitř remote_ts a sledujte swanctl --list-sas. Pokud se výstup nezmění, žádný acquisition se k démonovi nedostal.

Dva obvyklé důvody tichého trap: paket prošel source-NAT dřív, než se dostal k zásadě, a už neodpovídá local_ts, nebo se spojení nikdy nenačetlo kvůli syntaktické chybě či chybě údajů. Spusťte znovu swanctl --load-all a přečtěte si jeho výstup, než sáhnete na selektory. Spojení, které se nenačetlo, neinstaluje žádnou zásadu, takže provoz nemá co spustit.

Směr také rozhoduje: trap nainstalovaný pro odchozí provoz se nespustí příchozím paketem. Pokud má tunel zvednout vzdálená strana, potřebuje vlastní trap, nebo tato strana potřebuje start.

Čekání na první paket není vždy správná výměna

Interaktivní relace pocítí náklady na nastavení. První požadavek platí za výměnu IKE a vyjednávání CHILD a klient s krátkým termínem to může vzdát dřív, než SA existuje. Proaktivní start toto zpoždění prvního paketu odstraní. Ale drží tunel zvednutý pro provoz, který možná nikdy nepřijde.

Tři fakta rozhodují: jak často se cesta používá, zda má první požadavek těsný termín a zda je peer při startu dostupný. Občasný dávkový provoz a peer, který může být při startu offline, obojí upřednostňují trap. Klient citlivý na latenci a peer, který je vždy dostupný, upřednostňují start. Mohou-li obě strany iniciovat, dohodněte se, kdo spouštěč vlastní, ať nemáte duplicitní vyjednávání.

Nainstalovaná zásada také není zárukou proti úniku. Pokud je požadavek fail-closed, firewall musí zahazovat provoz bez SA a toto pravidlo žije mimo definici child.

Zapište tři řádky, které ukončí příští hádku

Zapište selektory, akci při startu a výstup příkazu, který ukazuje zásadu přítomnou bez SA. Tyto tři řádky oddělují „na vyžádání a nečinný“ od „nenačítá se“, až někdo příště nahlásí tunel jako nedostupný. Zachytit je trvá minutu. Bez nich stejné vyšetřování začíná od nuly.

Testujte z hostitele, který je skutečně uvnitř selektoru. Ping ze samotného routeru často jde jinou cestou a nic nedokazuje o zásadě chránící podsíť za ním.

Související články