Co zaznamenávat u VPN mezi lokalitami: selektory a rozsah

Šest měsíců po zprovoznění tunelu přestane nová podsíť odpovídat politice a jediný dokument na sdíleném disku říká kancelářská VPN. To je selhání, kterému záznam selektorů brání, a je konkrétní: sada adres se změnila, ale papíry ne. Napsat záznam správně znamená vědět, kterou z několika sad adres popisujete, a zaznamenat tu, kterou protistrana skutečně vynucuje, ne tu, kterou jste nakonfigurovali.

Nakonfigurované není vyjednané

V tunelu IPsec založeném na politice navrhuje každá strana selektory provozu: rozsahy zdroje a cíle pro podřízenou asociaci. Odpovídající strana smí tento návrh zúžit , takže nainstalovaná asociace může pokrývat méně, než uvádí konfigurace. Záznam, který konfiguraci kopíruje, proto popisuje záměr, ne aktuální rozsah ochrany. Obě se tiše rozejdou a nic na stránce stavu tunelu na to neupozorní.

Uchovejte oba sloupce, s datem, kdy jste je pozorovali. Nakonfigurovaný selektor je to, co jste zamýšleli; vyjednaný je to, co jádro právě vynucuje. Když se liší, tento rozdíl vysvětluje překvapivé selhání mnohem častěji než chyba směrování.

Jedna asociace také nepředstavuje každou nakonfigurovanou dvojici. Tunel s několika kombinacemi selektorů může skončit s několika podřízenými asociacemi a záznam, který uvádí jednu z nich, je částečný soupis. Vyjmenujte je, místo abyste je shrnuli.

Tunely založené na trasách vybírají jinak

U rozhraní založeného na trase rozhoduje směrovací tabulka, co vstoupí do tunelu, a selektory mohou být záměrně široké. To je legitimní návrh, ne nedbalost, a záznam to tak musí popsat. Zapište trasu, rozhraní, na které ukazuje, a politiku firewallu, která omezuje dostupné služby. Rozsah ochrany je záměrně široký a zužování dělá rozsah služeb.

Kopírování šablony založené na politice na tunel založený na trase vytvoří dokument, který popisuje mechanismus, jenž nasazení nepoužívá. Další inženýr pak hledá selektory, které tam nikdy neměly být, a usoudí, že tunel je špatně nakonfigurovaný, když je jen špatně zdokumentovaný.

Překlad patří do stejné tabulky

Když NAT představí protistraně jiný rozsah, zaznamenejte původní i přeložené prefixy společně. Poznamenejte fázi, ve které je selektory a pravidla přístupu porovnávají, protože pořadí rozhoduje o tom, zda vzdálená strana někdy uvidí adresu, kterou jste zapsali. Tabulka jen s jedním ze dvou rozsahů je horší než žádná tabulka, protože vypadá úplně.

To je detail, který po změně NAT rozbije fungující tunel: selektor stále odpovídá původnímu prefixu, protistrana nyní dostává přeložený a její zpětná trasa ukazuje na adresu, která už neexistuje. Nic nezaznamená chybu ve chvíli, kdy se obě přestanou shodovat.

Soukromý DNS patří na stejné místo. Jméno, které se překládá na adresu nepoužitelnou z příslušné lokality, je chyba v dokumentaci s přiloženým tiketem podpory a bude za ni obviňován tunel.

Připojte požadavek na službu

Chráněný rozsah není seznam oprávnění. Zapište, které služby mají být dostupné z kterého zdroje a kdo vlastní aplikaci za nimi. Tato dvě pole odpovídají na různé otázky a jejich slévání je způsob, jak bezpečnostní revize skončí hádkou o směrování místo o přístup.

Pak jmenujte správce sítě, který pravidlo udržuje. Soupis selektorů bez vlastníka tiše stárne a zastaralé nelze odlišit od chybného, když se tunel ve dvě ráno rozbije. Vlastník je také člověk, který může potvrdit, že změna byla úmyslná.

Přeměňte záznam na testovací plán

Pro každou požadovanou cestu vyberte reprezentativního zdrojového a cílového hostitele a poznamenejte očekávanou trasu, službu a bránu odpovědi. Tím se dokument mění na testovací plán, ne na popis. Přečtěte živou asociaci příkazem níže a porovnejte ji s vyjednaným řádkem, který jste zapsali.

swanctl --list-sas

Kostra o pěti řádcích obvykle stačí, aby záznam zůstal poctivý. Verze níže se vejde do tiketu změny bez zkrácení:

sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops

Ping jen na bránu není přijímací test. Nikdy neprocvičí tranzitní cestu, takže může projít, zatímco každý přeposílaný tok selhává. Testujte z hostitele na jedné straně na službu na druhé a potvrďte, že odpověď přichází tunelem. Pokud projde jen ping, záznam právě našel problém s přeposíláním, kvůli kterému byl napsán. dokumentace strongSwan k přeposílání vysvětluje, jak selektory, trasy a přeposílání spolupůsobí na linuxovém protějšku.