IPsec v IPsec: které adresy musí nést vnější tunel

Dejte vnějšímu tunelu adresy vnitřních bran, ne podsítě aplikací. Pak dokažte forwarding, překlad a MTU na každé vrstvě, než to nazvete vnořeným.

Vnořený IPsec se snáze promýšlí, když obě vrstvy končí na různých strojích. Čtyři brány, dva tunely a jediná otázka, která rozhoduje, zda návrh funguje: co vnější tunel skutečně vidí, když vnitřní skončí s packetem? Odpovězte na ni a selektory, trasy i pořadí řešení problémů vyplynou. Zmýlíte-li se, strávíte den laděním tunelu, který je technicky aktivní.

Model čtyř bran

Vnější brány A a B staví první tunel mezi oběma lokalitami. Za A stojí vnitřní brána C s tranzitní adresou 10.60.0.2; za B stojí vnitřní brána D s tranzitní adresou 10.70.0.2. Aplikační sítě žijí za C a D a každá adresa v příkladu se záměrně nepřekrývá.

application net -> C -> A == outer IPsec == B -> D -> application net
                       \---------- inner IPsec ----------/

C transit: 10.60.0.2      D transit: 10.70.0.2
A and B:    underlay addresses only

Rozdělení vrstev na čtyři hostitele znamená, že každý stroj vynucuje jednu hranici. Jeden hostitel provozující obě vrstvy musí sladit dvě sady politik, dvě routovací tabulky a dva režimy selhání na jednom stroji, což je možné a mnohem obtížnější pozorovat.

Každá vrstva odstraňuje jen svou vlastní ochranu

C šifruje aplikační packet pro D. Výsledek je adresován z C do D a to je to, co dorazí k A. Vše níže závisí na tomto přepsání.

A jej znovu zašifruje pro B. B dešifruje vnější vrstvu, vidí packet z C do D a přeposílá ho stále zašifrovaný. D odstraní vnitřní ochranu a doručí aplikační packet.

A a B tedy vidí vnitřní koncové body a jejich metadata, ale nejsou stranami, které dešifrují aplikační payload. To je skutečná vlastnost návrhu, nikoli tvrzení, že C, D nebo aplikační hostitelé jsou důvěryhodní.

Vnější selektory pojmenovávají vnitřní brány

Zde většina těchto staveb selhává. U vnějšího tunelu založeného na politikách musí selektory, které vyjednáváte, obsahovat adresy, se kterými A a B skutečně pracují: 10.60.0.2/32 a 10.70.0.2/32, ve správném lokálním a vzdáleném pořadí.

Umístit konečné aplikační podsítě do vnějších selektorů nefunguje, protože než packet dorazí k A, vnitřní zapouzdření už přepsalo to, co A musí chránit. Vnější politika by pak ničemu neodpovídala a tunel by se zvedl, aniž by přenášel data.

Nezužujte vnější povolení na UDP 500. Vnitřní spojení má vlastní datovou cestu, která používá ESP nebo UDP zapouzdření podle toho, co vyjednalo, a vnější politika musí tento protokol povolit.

Výsledek ověřte pomocí swanctl --list-sas na každé bráně a potvrďte, že child bezpečnostní asociace hlásí adresy, které jste zamýšleli, ne ty, které jste předpokládali. Pokud seznam ukazuje aplikační podsítě, vnější politika byla napsána pro špatnou vrstvu. Opravte selektory dřív, než začnete ladit routing, protože routing bude vypadat správně a čítače se nehnou.

Forwarding a past rekurze

Selektory nenahrazují routing. A a B musí přeposílat provoz mezi C a D v obou směrech, což znamená zapnutý IP forwarding, trasy ukazující na tunel a zpětnou cestu, která na druhé straně existuje.

Pokud vnější tunel používá rozhraní XFRM, trasy vybírají rozhraní, zatímco vyjednané politiky stále omezují, co přenáší. Rozhraní nerozšiřuje chráněné; jen mění, jak kernel packet zachytí.

Pastí je rekurze. Trasa A k vnějšímu koncovému bodu B musí následovat underlay, ne tunel, který A staví, jinak se zapouzdření pokusí cestovat uvnitř sebe a spojení se nikdy nedokončí.

Prohlédněte překlad, než přidáte vrstvy

Podívejte se na jakýkoli source NAT na A a B, než cokoli jiného vyladíte. Pravidlo, které přepíše adresu C před aplikací politiky IPsec, může rozbít dohodnuté selektory a může také změnit, co D na druhé straně obdrží.

Široké maskování není bezpečnější tím, že má dvě vrstvy. Skrývá, kterou adresu vzdálená strana vidí, a to je přesně informace, kterou potřebujete, když je tunel aktivní a aplikace nefunguje.

Pokud je pravidlo NAT skutečně nutné, zapište, se kterou adresou si každá strana myslí, že mluví. Ten jeden řádek vyřeší většinu sporů o to, zda je na vině tunel, nebo překlad. Také řekne dalšímu inženýrovi, kam se podívat, až bude pravidlo za rok odstraněno. Ping nic z toho neudělá.

Dokažte fail-closed a zkontrolujte MTU

Zmizení trasy samo o sobě není politika fail-closed. Jiná tabulka, default trasa nebo pravidlo politiky mohou tiše poskytnout záložní cestu a jediný způsob, jak to zjistit, je shodit vnější tunel a pozorovat, co aplikační provoz dělá. Udělejte to záměrně, v okně, místo abyste to objevili náhodou.

Otestujte tři stavy: vnější tunel dole, vnitřní tunel dole a obnovu poté, co se oba vrátí. Použijte čítače politik na každé bráně, protože dvě navázané IKE relace dokazují jen to, že vyjednávání řídicí roviny uspělo.

Naplánujte rozpočet pro obě zapouzdření. Fungující IKE je výsledek malých packetů a plnohodnotné aplikační packety mohou stále selhat, jakmile se přidají dvě hlavičky; testujte se známou velikostí payloadu na skutečné cestě, místo abyste předpokládali, že čísla sedí. Aritmetika je snadná, cesta ne.

Související články