Proč bezpečnostní politika IPsec není položkou směrovací tabulky

Pošlete ping na 10.20.0.5 tunelem a nic se nevrátí, zatímco směrovací tabulka tvrdí, že ta podsíť je dostupná. Směrování a IPsec odpovídají na různé otázky a jen jedna z nich je o dostupnosti. Dopředné vyhledání vybere cestu, pak databáze bezpečnostní politiky rozhodne, zda tato cesta musí být chráněna, ponechána nebo odmítnuta. Když se obě neshodnou, paket tiše umře, proto je čtěte v tomto pořadí.

Začněte vyhledáním, ne tabulkou

Zeptejte se jádra, co by skutečně udělalo: ip route get 10.20.0.5 vypíše zvolenou trasu, výstupní rozhraní a zdrojovou adresu, kterou by použilo. Prefix, pravidlo politiky, značka nebo preferovaný zdroj mohou tento výsledek změnit, proto je živé vyhledání lepší než čtení tabulky okem.

Testujte cíl uvnitř chráněného rozsahu, ne adresu brány. Dosažení brány na druhé straně dokazuje jen to, že nějaká trasa existuje; nic neříká o podsíti, kterou skutečně potřebujete. Potom potvrďte, že rozhraní vybrané vyhledáním je to, které očekáváte, že tunel použije.

Slaďte selektory na obou stranách

Databáze politiky má vlastní položky a každá uvádí směr, zdroj, cíl a protokol, a potom říká, co se má stát s odpovídajícími pakety. K výpisu použijte ip xfrm policy; příznaky ukazují, zda je akce chránit, obejít nebo zablokovat. Politika, jejíž selektory jsou širší nebo užší než váš testovací tok, se s ním neshodne a paket odchází nechráněný. To je porucha, kterou hledáte, ne chybějící trasa.

Porovnejte skutečné hodnoty: zdroj, cíl, protokol a porty. Pokud vyhledání vyřešilo jednu dvojici adres, zatímco položka politiky pokrývá jinou, oba pohledy popisují jiný provoz. Spusťte obojí znovu se stejným tuplem, než uděláte závěr, jinak upravíte politiku, která nikdy nebyla na cestě.

Shoda politiky není nainstalovaný stav

Odpovídající politika jen říká, že paket musí být chráněn; jádro stále potřebuje bezpečnostní asociaci, aby ochranu provedlo. Vypište je pomocí ip xfrm state, nebo pomocí swanctl --list-sas, když vyjednávání vede strongSwan, a přečtěte selektory a čítače u každé položky.

Když politika odpovídá a žádná asociace nepokrývá stejné selektory, paket se zahodí, místo aby byl odeslán v otevřené podobě. To je to zahození, které hledáte, když tunel běží, ale jedna podsíť selhává. Čítače řeknou zbytek: asociace, která nikdy neroste, nebyla nikdy vybrána, zatímco ta, která roste a přesto skončí zahozením, ukazuje na vzdálenou stranu. Oprava selektorů a obnova klíčů jsou různé opravy, proto se rozhodněte, kterou potřebujete, než se dotknete konfigurace.

Co tunel založený na trase stále vyžaduje

Rozhraní XFRM dělá z tunelu zařízení, do kterého lze směrovat, což je opravdu užitečné. Neodstraňuje však politiku a stav, které rozhodují, co se stane, když tam paket dorazí. Trasa přispívá dalším skokem a ničím víc.

Pokud zařízení existuje a trasa do něj ukazuje, ale žádná asociace neodpovídá vnitřním selektorům, paket se zahodí a žádné množství úprav tras nevytvoří klíče ani selektory. Zkontrolujte rozhraní se stejnými zdrojem a cílem, které jste směrovali, a potom to porovnejte se seznamem stavů.

Než cokoli upravíte, vyjasněte vlastnictví

Firewall hostitele přidává třetí rozhodnutí, o kterém žádná z obou databází neví. Správná trasa plus odpovídající politika plus nainstalovaná asociace mohou stále skončit zahozeným paketem a aplikace hlásí jen vypršení časového limitu. Potvrďte, že firewall povoluje chráněný provoz, než obviníte IPsec. Zachytávání na tunelovém zařízení a na fyzickém rozhraní ukáže, na které straně šifrování paket zmizel.

Vlastnictví konfigurace rozhoduje, zda vaše oprava přežije restart. Jedna komponenta může instalovat stav, zatímco jiná spravuje trasy, a ruční úprava druhé se přepíše při příštím spuštění tunelu. Změňte konfiguraci vlastníka a potom oba pohledy znovu přečtěte; RFC 4301 udržuje obě databáze oddělené, když musíte to rozdělení někomu jinému vysvětlit.