Naplánujte privátne rozsahy adries VPN skôr, než sa lokality zrazia
Prekrývajúce sa privátne rozsahy rozbíjajú smerovanie ešte pred tunelom. Zinventarizujte prefixy, oddelene dimenzujte klientske pooly od lokálnych sietí lokalít a testujte z opačnej strany.
Dve lokality, ktoré obe používajú 192.168.1.0/24, sa každá dostane na internet, a napriek tomu sa navzájom nedostanú. Brána neohlási chybu; nainštaluje jednu trasu pre tento prefix a každý paket pošle tomu partnerovi, ktorý si ho nárokoval prvý. Nič v handshake, zozname šifier ani metrike rozhrania nehovorí, ktorý partner je nesprávny. Plánovanie adries je tá časť návrhu, ktorá to vyrieši skôr, než sa ktokoľvek pripojí.
Zinventarizujte každý priestor, ktorý musí byť dostupný
Zapíšte rozsahy, ktoré treba smerovať, nielen tie, ktoré konfigurujete. To znamená lokálne siete lokalít, klientske pooly VPN, cloudové podsiete, siete pre správu a mimo pásma, laboratórne segmenty a siete, z ktorých sa používatelia bežne pripájajú z domu. Spotrebiteľský router dodávaný ako 192.168.1.0/24 nie je hypotetický a rovnaký prefix sa objavuje v hoteloch a kongresových centrách. Inventár je tabuľka prefixu, vlastníka a účelu a je jediným artefaktom, ktorý zabráni vydať rovnaký 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 |
Pridajte prefixy, ktoré očakávate v budúcom roku, pretože plán pokrývajúci len dnešok zlyhá na prvej novej lokalite. Označte v každom riadku, kto ho môže zmeniť, nielen kto ho vlastní.
Práve opätovné použitie to robí ťažkým: privátny priestor je konečný a každá organizácia považuje 10.0.0.0/8 za svoj. Plán nemôže sľúbiť, že hosťovská sieť nikdy nespadne na niektorý z vašich prefixov, takže návrh musí povedať, čo sa stane, keď sa to stane. Väčšinu práce urobia dve pravidlá. Dajte klientske pooly do jedného súvislého bloku, ktorý viete zhrnúť, a nikdy neprideľujte rozsah, ktorý už iný tím smeruje. Všetko ostatné je záznam, ktorý niekto udržiava aktuálny.
Prečo prekryv poráža smerovaciu tabuľku
Trasa je prefix plus ďalší skok a preposielanie vyberá najdlhší zodpovedajúci prefix. Keď dva partnerské uzly nárokujú oba rovnaký 192.168.1.0/24, tabuľka preň drží jeden záznam, takže prevádzka oboch lokalít odchádza tým istým tunelom. Druhá lokalita nie je zle nakonfigurovaná; je nedostupná, pretože prvá odpovedá za rovnaké adresy. Žiadna metrika ich nemôže oddeliť, pretože zhoda nastáva skôr, než sa metriky berú do úvahy.
Zlyhanie je asymetrické a ľahko sa číta nesprávne. Hostitelia v lokalite A dosiahnu bránu a niektoré služby, zatiaľ čo hostitelia lokality B neodpovedajú na nič, a log ukazuje zdravý tunel v oboch smeroch. Tento vzorec je kolízia adries, nie porucha autentifikácie alebo firewallu, a potvrdenie vyžaduje jeden výpis tabuľky porovnaný s inventárom.
Určte veľkosť klientskeho poolu aj rozsahov lokalít zámerne
Klientsky pool VPN je rozsah, z ktorého brána vydáva po jednej adrese, takže jeho veľkosť obmedzuje súbežnosť. /24 pojme 254 použiteľných adries, čo je veľkorysé pre malý tím a tesné pre pobočku prevádzkujúcu kontajnery; /22 nič nestojí navyše v privátnom priestore a odstráni hádku. Držte pool súvislý a mimo každej lokálnej siete lokality, aby súhrnná trasa ku klientom nikdy neprehltla lokalitu. Rozsah si rezervujte, aj keď je pool prázdny, pretože nezapísaný rozsah je ten, ktorý pridelí nasledujúci inžinier.
Lokality dostávajú rozsahy dimenzované pre očakávaných hostiteľov plus rast, zarovnané na hranici, ktorá sa čisto sumarizuje. Zámerné medzery medzi prideleniami nič nestoja a kupujú priestor na neskoršiu agregáciu.
Potom skontrolujte smer, na ktorý ľudia zabúdajú: spiatočnú cestu. Každý router lokality potrebuje trasu do klientskeho poolu a koncentrátor potrebuje trasu ku každému prefixu lokality, ktorú obsluhuje. Upravená tabuľka prefixov bez cesty späť do poolu je stále pokazený návrh a symptomom je jednosmerné spojenie, ktoré na nič neodpovedá. Držte oba smery v jednej tabuľke a revidujte ju pri každom pridaní lokality.
Preklad a prečíslovanie riešia rôzne problémy
Keď prekryv už existuje, sú dve poctivé možnosti a jedna nepoctivá. Prečíslovanie kolíziu natrvalo odstráni a stojí servisné okno plus každú pevne zadanú adresu, na ktorú ste zabudli. Preklad adries mapuje privátny rozsah jednej strany do iného rozsahu na okraji tunela, čo nechá obe lokality nedotknuté, ale pridá stav, rozbije protokoly vkladajúce adresy a sťaží čítanie logov. Nepoctivá možnosť je hostiteľská trasa k jedinému serveru, ktorá prejde jedným testom a zlyhá vo všetkom ostatnom.
Vyberajte podľa kontroly a životnosti. Lokalita, ktorú vlastníte a môžete naplánovať, patrí na cestu prečíslovania; partnerská sieť, na ktorú nemôžete siahnuť a ktorá sa používa pre jednu aplikáciu, je kandidátom na preklad s dokumentovaným mapovaním. To mapovanie zapíšte, pretože preklad existujúci len vnútri konfiguračného súboru zmizne v okamihu, keď je súbor nahradený.
Testujte z opačnej strany pred nasadením
Testujte zo siete, ktorá nehostuje bránu, pretože vlastná lokálna sieť brány skrýva väčšinu chýb smerovania. Pripojte klienta za bežný domáci router, potom dosiahnite službu v každej lokalite a jednu vnútri klientskeho poolu. Otestujte aj opačný smer, z hostiteľa lokality ku klientovi, pretože spiatočné cesty zlyhávajú nezávisle. Test, ktorý iba pingne bránu, dokazuje, že tunel beží, a nič viac.
Držte rozsahy, vlastníkov a mapovania prekladu v jednom spoločnom zázname, ktorý si nasledujúca lokalita prečíta pred akýmkoľvek pridelením. Revidujte ho pri pridaní lokality a nedokumentovaný rozsah berte ako vadu, nie ako prekvapenie.
Záznam je výstup. Plán, ktorý žije v pamäti troch ľudí, zlyhá prvýkrát, keď je jeden z nich na dovolenke, a prekryv nájdený v produkcii stojí viac, než by stála tabuľka.