Dvě lokality, jedna podsíť: vytvořte pro každou vlastní pohled aliasů

Dvě zákaznické lokality obě používají 192.168.50.0/24 a vzdálený inženýr se musí v každé z nich dostat k tiskárně na stejné adrese. Žádný směrovací trik tuto nejednoznačnost sám nevyřeší. Každá lokalita potřebuje odlišný pohled na adresy a brána musí vybrat lokalitu z tohoto pohledu, než cokoli předá.

Plán má čtyři části: prefixy aliasů, oba směry překladu, politiku překryvu a názvy. Každá se musí shodovat s ostatními.

Zvolte jeden prefix aliasu na lokalitu

Přiřaďte každé lokalitě celý prefix aliasu, který v prostředí nepatří nikomu jinému. Plán pro dvě lokality může namapovat 192.168.50.0/24 lokality A na 172.21.10.0/24 a stejnou LAN lokality B na 172.21.20.0/24. Ověřte kandidáty proti každé zúčastněné síti, včetně cloudových VPC a dalších fondů VPN. Soukromý adresní prostor sdílí každá organizace, takže to, že rozsah spadá do RFC 1918, nic neříká o tom, že je zde volný.

Vzdáleným uživatelům publikujte alias, ne nativní podsíť. Nativní rozsah zůstává místním faktem.

Překládejte v obou směrech

Překládejte v obou směrech. Mapování cíle přepisuje adresu aliasu na nativní adresu v lokalitě, která ji vlastní. Mapování zdroje přepisuje vzdáleného volajícího na alias, který ostatní lokality rozliší.

Statické mapování jedna k jedné je deterministické, a to neznamená, že implementace je bezstavová. Zpětný překlad může záviset na stavu spojení a přepnutí při selhání nebo asymetrické cesty mohou rozbít plán, který to ignoruje. Dokumentace platformy určuje, které z toho platí.

Přesná fáze, ve které se uplatňují politika, selektory a trasy, se liší mezi IPsec založeným na politikách, tunely založenými na trasách a dalšími produkty. Navrhujte pro ten, který provozujete.

Přeneste plán přes překryv

V hubu přiřaďte každý prefix aliasu cestě lokality, která ho vlastní, a povolte jen tranzit, který úloha potřebuje. V síti typu mesh každý relevantní protějšek potřebuje stejný prefix a znalost politiky. Přidání tunelů samo o sobě nejednoznačné adresování neopraví.

Publikování celé podsítě je širší než publikování jedné služby. Pokud je potřeba jen několik strojů nebo portů, držte přístupová pravidla užší než mapování.

Překlad hlaviček nepřepisuje užitečné zatížení aplikace. Přesměrování, vložené adresy v konfiguračních souborech a oprávnění založená na zdroji mohou stále nést nativní adresu. Testujte cestu aplikace, ne jen ping. Fungující odpověď ICMP dokazuje, že mapování existuje, a nic neříká o tom, zda aplikace alias přijímá.

Opravte názvy, které každý volající vidí

Dejte údržbovým názvům odpovědi, které odpovídají pohledu volajícího. Pokud vzdálený inženýr přeloží název hostitele, měl by vrátit adresu aliasu pro danou lokalitu, ne sdílený nativní rozsah.

Před prvním oknem údržby zkontrolujte zobrazení DNS pro každou lokalitu. Název, který se přeloží na nativní podsíť, vrací volajícího zpět do nejednoznačnosti, kterou měl plán odstranit.

Zaznamenejte a ověřte pro každou lokalitu

Přijměte každou lokalitu samostatně od skutečného volajícího a potvrďte, který stroj odpověděl. Zaznamenejte nativní adresu, alias, vlastnící bránu a povolenou službu společně.

Právě tento soupis zachovává rozlišení, když přijde třetí lokalita se stejnou výchozí LAN. Průvodce IPsec NAT založeným na politikách dokumentuje jeden konkrétní model překladu; není to smlouva pro každou platformu.