Naplánujte podsítě před VPN mezi lokalitami: přečíslujte, nebo překládejte

Dvě kanceláře používají obě 192.168.1.0/24, protože nikdo neplánoval jinak, a od tunelu se očekává, že to vyřeší. Nemůže: router nemůže zařídit, aby stejná privátní adresa znamenala dvě různá místa. Práce, která tomu brání, probíhá dřív, než se napíše první parametr tunelu.

Zinventarizujte každý rozsah, včetně těch, na které jste zapomněli

Shromážděte LAN, serverové segmenty, fondy klientů vzdáleného přístupu, rozsahy cloudových VPC a všechny kontejnerové či překryvné sítě, ke kterým se hostitelé musí dostat. Fondy klientů jsou ty, na které se zapomíná, a překvapivě často se překrývají s kancelářským rozsahem, protože oba byly vybrány ze stejné výchozí hodnoty. Zahrňte řídicí síť a jakýkoli out-of-band segment.

Zaznamenejte vlastníka, bránu, účel a zda musí být prefix dostupný z druhé lokality. Prefix, který nikdy nemusí projít tunelem, nemusí být jedinečný, a toto vědomí snižuje práci s přečíslováním.

IPv6 řešte zvlášť, protože jeho plán i jeho překryvy jsou nezávislé.

Porovnávejte prefixy, ne známé adresy

Dvě sítě s různými adresami hostitelů se mohou stále překrývat, protože překryv je vlastnost masek, ne čísel, která si lidé pamatují. 10.20.0.0/16 obsahuje 10.20.30.0/24, ať to někdo řekne nahlas, nebo ne. Porovnávejte celé dvojice prefixů a kontrolujte agregáty proti menším sítím uvnitř nich. Proto kontrola patří do tabulky, ne do něčí hlavy.

Stejná kontrola platí pro vlastní fond klientů VPN a pro každý přeložený rozsah, který plánujete zavést, protože přeložený rozsah, který koliduje, je horší než původní překryv.

Tabulka prefixů s maskami stačí; diagram bez masek ne.

Rozhodněte, co skutečně musí procházet

Lokalita může obsahovat třicet podsítí, zatímco jedna servisní síť potřebuje vzdálený přístup. Začněte od tohoto požadavku a inzerujte jen to, co potřebuje, protože menší inzeráty a odpovídající přístupová pravidla se snáz kontrolují a hůř se omylem rozšiřují. Inzerovat každý používaný privátní rozsah je zvyk, který mění tunel v most. Čím užší inzerát, tím menší dopad budoucí chyby.

Privátní DNS musí vracet adresy, na které se zamýšlení klienti dostanou, takže jméno ukazující na neinzerovaný nebo překrývající se rozsah zůstává rozbité, i když vyhledání uspěje.

Přístupový seznam napište před konfigurací tunelu, ne poté, co selže.

Přečíslujte, nebo překládejte, a znáte cenu

Přečíslování jedné sítě je obvykle nejjasnější dlouhodobá náprava a dotýká se rezervací, zařízení, DNS, pravidel firewallu i všeho, co má adresu zapečenou v konfiguraci. Překlad přístupového rozsahu je alternativou, když je přečíslování nepraktické, a stojí identitu zdroje plus třídu protokolů, které vkládají adresy do payloadu. Vyberte jedno a dokončete to, protože napůl přečíslovaná síť je horší než kterákoli z obou možností.

Ať zvolíte cokoli, zdokumentujte původní i prezentovanou adresu, protože každý pozdější rozhovor o řešení problémů je potřebuje.

Obchvat bez zpětné cesty není obchvat.

Použijte matici tras jako akceptační test

Skončete maticí: lokální prefix, vzdálený prefix, povolená služba a návratová brána. Tato tabulka je akceptačním testem, když tunel naskočí, a je také dokumentem, který bude číst následující inženýr. Testujte ze skutečných hostitelů ve vybraných podsítích, ne z bran.

Ping mezi adresami tunelu dokazuje, že tunel existuje, a nic o plánu adres za ním.

Uchovávejte matici s konfigurací tunelu a příští přidání lokality začne z dat, ne z paměti. Jakmile plán existuje, průvodce předáváním strongSwan pokrývá stranu brány.