IPsec s více podsítěmi ztrácí zpětný provoz? Spočítejte reqid

Provoz opustí jedno místo a už se nikdy nevrátí, obě brány hlásí dokončené vyjednávání a jediným vodítkem je hromada odchozích paketů bez odpovědí. Na linuxovém koncovém bodě nebývá příčinou síla šifrování, MTU ani směrovací tabulka. Je to zrnitost položek politiky a číslo, které spojuje každou politiku s bezpečnostní asociací. Postup níže čte tyto dvě databáze, než se čehokoli jiného dotkne.

Rozdělte symptom, než cokoli změníte

Jednosměrná závada s dokončeným vyjednáváním IKE zužuje problém na datovou cestu. Buď politika pro odchozí provoz odpovídala a odpověď byla zahozena, nebo odpověď nikdy nedorazila, protože druhá strana neměla čím ji poslat. Z pohledu aplikace vypadají oba případy stejně a databáze xfrm je rozliší.

Nezačínejte MTU. Špatné MTU působí zasekávání a příznaky fragmentace, ne čisté rozdělení směru s rostoucími odchozími čítači.

Přečtěte databázi politik a databázi stavů

V Linuxu o šifrování rozhodují položky politiky, takže odpovídající politika, ne trasa, dostane paket do tunelu. Spusťte ip xfrm policy a uvidíte selektory, směr, prioritu a šablonu každé položky, a ip xfrm state pro zobrazení zavedených asociací s jejich reqid. Politika a asociace jsou spojeny tímto reqid.

Podívejte se na všechny tři směry. Odchozí a příchozí pokrývají provoz k tomuto hostiteli a od něj; směr předávání je důležitý, když hostitel směruje za jiné. Chybějící nebo odlišná položka v jednom směru vysvětluje jednosměrný výsledek bez jakékoli kryptografické závady.

Klasická asymetrie: jeden reqid pro několik podsítí

Častá závada pochází od protějšku, který nainstaluje politiky pro všechny vyjednané podsítě pod jediným reqid, což se děje s generate_policy require u racoonu. Provoz pak odchází přes asociaci zavedenou naposledy, zatímco druhá strana drží samostatnou asociaci pro každou podsíť. Odpovědi přicházejí na asociaci, jejíž reqid neoznačuje politiku, která by je měla přijmout, a jádro je po dešifrování zahodí.

Oprava je změna konfigurace, ne pravidlo firewallu: generate_policy unique; dá každé politice vlastní reqid, takže asociace protějšku na politiku mají odpovídající partnery. Použijte to, znovu vyjednejte a spočítejte různé reqid pro očekávané podsítě, než prohlásíte úspěch.

Pokud dvě podsítě stále sdílejí reqid, zatímco druhá strana očekává dvě, našli jste asymetrii. Zapište mapování, protože je důkazem, že je další změna opravila nebo zachovala.

Selektory pocházejí z vyjednávání, ne z vaší konfigurace

Chráněné rozsahy jsou to, na čem se oba konce dohodly, ne to, o co jedna strana požádala. Klient nabízející pár hostitelů proti širokému vzdálenému rozsahu dostane zúženou verzi brány a nemůže ji rozšířit. Čtěte nainstalované selektory, ne ty ve svém místním souboru.

Když je cílem opak, tedy udržet jeden cíl mimo tunel, přidejte politiku obejití s nižším číslem priority, aby porazila automaticky nainstalovanou položku. Politika bez šablony povoluje otevřený text, což z ní dělá záměrnou výjimku pro záznam změny, ne krok ladění.

Ověřujte v tomto pořadí a vězte, jak se vrátit zpět

Vypište politiky pro každou podsíť v obou směrech, včetně směru předávání, pokud hostitel směruje. Spočítejte různé reqid a potvrďte jeden na politiku na straně, která ho očekává. Porovnejte nainstalované selektory s vyjednanými. Po obnově klíče znovu přečtěte čítače asociace, protože asociace, kterou jste zkontrolovali, už může být pryč. Trasy zkontrolujte nakonec, protože chybějící trasa ke vzdálené podsíti dává podobný jednosměrný příznak s čistými čítači politiky.

Než změníte protějšek, uložte aktuální výstup obou příkazů xfrm. Pokud nové nastavení neobnoví zpětný směr, obnovení tohoto výstupu je rychlejší návrat než znovuvytvoření tunelu z paměti a udržuje poctivé srovnání.