Naplánujte privátní rozsahy adres VPN dřív, než se lokality střetnou
Překrývající se privátní rozsahy rozbíjí směrování ještě před tunelem. Zinventarizujte prefixy, oddělte klientské pooly od lokálních sítí lokalit a testujte z opačné strany.
Dvě lokality, které obě používají 192.168.1.0/24, se každá dostane na internet, a přesto se navzájem nedostanou. Brána neohlásí chybu; nainstaluje jednu trasu pro tento prefix a každý paket pošle tomu protějšku, který si ho nárokoval první. Nic v handshake, seznamu šifer ani metrice rozhraní neříká, který protějšek je špatně. Plánování adres je ta část návrhu, která to vyřeší dřív, než se kdokoli připojí.
Zinventarizujte každý prostor, který musí být dosažitelný
Zapište rozsahy, které je třeba směrovat, ne jen ty, které konfigurujete. To znamená lokální sítě lokalit, klientské pooly VPN, cloudové podsítě, sítě pro správu a out-of-band, laboratorní segmenty a sítě, ze kterých se uživatelé běžně připojují z domova. Spotřebitelský router dodávaný jako 192.168.1.0/24 není hypotetický a stejný prefix se objevuje v hotelích a kongresových centrech. Inventář je tabulka prefixu, vlastníka a účelu a je jediným artefaktem, který zabrání vydat stejný rozsah dvakrát.
| Prefix | Purpose | Owner |
|---|---|---|
| 10.20.0.0/16 | site LANs | network team |
| 10.20.100.0/22 | VPN client pool | remote access |
| 10.20.200.0/24 | management | operations |
Přidejte prefixy, které očekáváte v příštím roce, protože plán, který pokrývá jen dnešek, selže na první nové lokalitě. Označte v každém řádku, kdo ho může změnit, ne jen kdo ho vlastní.
Právě opětovné použití to dělá obtížným: privátní prostor je konečný a každá organizace považuje 10.0.0.0/8 za svůj. Plán nemůže slíbit, že hostovská síť nikdy nespadne na některý z vašich prefixů, takže návrh musí říct, co se stane, když se to stane. Většinu práce udělají dvě pravidla. Dejte klientské pooly do jednoho souvislého bloku, který umíte shrnout, a nikdy nepřidělujte rozsah, který už jiný tým směruje. Všechno ostatní je záznam, který někdo udržuje aktuální.
Proč překryv poráží směrovací tabulku
Trasa je prefix plus další skok a předávání vybírá nejdelší odpovídající prefix. Když dva protějšky nárokují oba 192.168.1.0/24, tabulka pro něj drží jeden záznam, takže provoz obou lokalit odchází stejným tunelem. Druhá lokalita není špatně nakonfigurovaná; je nedostupná, protože první odpovídá za stejné adresy. Žádná metrika je nemůže oddělit, protože shoda nastává dřív, než se metriky berou v úvahu.
Selhání je asymetrické a snadno se špatně čte. Hostitelé v lokalitě A dosáhnou brány a některých služeb, zatímco hostitelé lokality B neodpovídají nic, a log ukazuje zdravý tunel v obou směrech. Tento vzorec je kolize adres, nikoli porucha autentizace nebo firewallu, a potvrzení vyžaduje jeden výpis tabulky porovnaný s inventářem.
Určete velikost klientského poolu i rozsahů lokalit záměrně
Klientský pool VPN je rozsah, který brána vydává po jedné adrese, takže jeho velikost omezuje souběžnost. /24 pojme 254 použitelných adres, což je velkorysé pro malý tým a těsné pro pobočku provozující kontejnery; /22 nic nestojí navíc uvnitř privátního prostoru a odstraní hádku. Držte pool souvislý a mimo každou lokální síť lokality, aby souhrnná trasa ke klientům nikdy nespolkla lokalitu. Rozsah si rezervujte, i když je pool prázdný, protože nezapsaný rozsah je ten, který přidělí příští inženýr.
Lokality dostávají rozsahy dimenzované pro očekávané hostitele plus růst, zarovnané na hranici, která se čistě sumarizuje. Záměrné mezery mezi přiděleními nic nestojí a kupují prostor pro pozdější agregaci.
Pak zkontrolujte směr, na který lidé zapomínají: zpáteční cestu. Každý router lokality potřebuje trasu do klientského poolu a koncentrátor potřebuje trasu ke každému prefixu lokality, kterou obsluhuje. Úhledná tabulka prefixů bez cesty zpět do poolu je pořád rozbitý návrh a symptomem je jednosměrné spojení, které nic neodpovídá. Držte oba směry v jedné tabulce a revidujte ji při každém přidání lokality.
Překlad a přečíslování řeší různé problémy
Když překryv už existuje, jsou dvě poctivé možnosti a jedna nepoctivá. Přečíslování kolizi trvale odstraní a stojí maintenance okno plus každou pevně zadanou adresu, kterou jste zapomněli. Překlad adres mapuje privátní rozsah jedné strany do jiného rozsahu na okraji tunelu, což nechá obě lokality nedotčené, ale přidá stav, rozbije protokoly, které vkládají adresy, a ztíží čtení logů. Nepoctivá možnost je hostitelská trasa k jedinému serveru, která projde jedním testem a selže ve všem ostatním.
Vybírejte podle kontroly a životnosti. Lokalita, kterou vlastníte a můžete naplánovat, patří na cestu přečíslování; partnerská síť, na kterou nemůžete sáhnout, používaná pro jednu aplikaci, je kandidátem na překlad s dokumentovaným mapováním. To mapování zapište, protože překlad, který existuje jen uvnitř konfiguračního souboru, zmizí v okamžiku, kdy je soubor nahrazen.
Testujte z opačné strany, než nasadíte
Testujte ze sítě, která nehostuje bránu, protože vlastní lokální síť brány skrývá většinu chyb směrování. Připojte klienta za běžný domácí router, pak se dostanete ke službě v každé lokalitě a k jedné uvnitř klientského poolu. Otestujte i opačný směr, z hostitele lokality ke klientovi, protože zpáteční cesty selhávají nezávisle. Test, který jen pingne bránu, dokazuje, že tunel běží, a nic víc.
Držte rozsahy, vlastníky a mapování překladu v jednom sdíleném záznamu, který si příští lokalita přečte, než cokoli přidělí. Revidujte ho při přidání lokality a nedokumentovaný rozsah berte jako vadu, ne jako překvapení.
Záznam je výstup. Plán, který žije v paměti tří lidí, selže poprvé, když je jeden z nich na dovolené, a překryv nalezený v produkci stojí víc, než by stála tabulka.