Beplan private VPN-adresreekse voordat terreine bots
Oorvleuelende private reekse breek roetering nog voor enige tonnel. Maak 'n inventaris van die prefikse, skei kliëntpoele van terrein-LAN's en toets van die verre kant af.
Twee terreine wat albei 192.168.1.0/24 gebruik, kan elk die internet bereik en steeds nie mekaar bereik nie. Die poort ontlok geen fout nie; dit installeer een roete vir daardie prefiks en stuur elke pakkie na watter eweknie dit eerste geëis het. Niks in die handdruk, die syferlys of die koppelvlakmaatstaf sê watter eweknie verkeerd is nie. Adresbeplanning is die deel van die ontwerp wat dit besleg voordat enigiemand koppel.
Maak 'n inventaris van elke ruimte wat bereikbaar moet wees
Skryf die reekse neer wat geroteer moet word, nie net dié wat jy konfigureer nie. Dit beteken terrein-LAN's, VPN-kliëntpoele, wolksubnette, bestuurs- en buitebandnetwerke, laboratoriumsegmente, en die netwerke waarvan gebruikers gereeld by die huis koppel. 'n Verbruikersroeter wat as 192.168.1.0/24 verskeep word, is nie hipoteties nie, en dieselfde prefiks kom in hotelle en konferensielokale voor. Die inventaris is 'n tabel van prefiks, eienaar en doel, en dit is die enigste artefak wat verhoed dat dieselfde reeks twee keer uitgegee word.
| 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 |
Voeg die prefikse by wat jy binne die volgende jaar verwag, want 'n plan wat net vandag dek, faal by die eerste nuwe terrein. Merk elke ry met wie dit kan verander, nie net wie dit besit nie.
Hergebruik is wat dit moeilik maak: privaat ruimte is beperk en elke organisasie beskou 10.0.0.0/8 as sy eie. 'n Plan kan nie belowe dat geen toekomstige gas-LAN op een van jou prefikse sal beland nie, so die ontwerp moet sê wat gebeur wanneer dit wel gebeur. Twee reëls doen die meeste werk. Plaas kliëntpoele in een aaneenlopende blok wat jy kan opsom, en ken nooit 'n reeks toe wat 'n ander span reeds roeteer nie. Al die res is 'n rekord wat iemand aktueel hou.
Waarom 'n oorvleueling die roeteertabel verslaan
'n Roete is 'n prefiks plus 'n volgende sprong, en aanstuur kies die langste ooreenstemmende prefiks. Wanneer twee eweknieë albei 192.168.1.0/24 eis, hou die tabel een inskrywing daarvoor, so verkeer vir albei terreine vertrek deur dieselfde tonnel. Die tweede terrein is nie verkeerd opgestel nie; dit is onbereikbaar omdat die eerste een vir dieselfde adresse antwoord. Geen maatstaf kan hulle skei nie, want die passing gebeur voordat maatstawwe geraadpleeg word.
Die fout is asimmetries en maklik om verkeerd te lees. Gashere op terrein A bereik die poort en sommige dienste, terwyl terrein B se gashere niks antwoord nie, en die log toon 'n gesonde tonnel in albei rigtings. Daardie patroon is 'n adresbotsing eerder as 'n verifikasie- of vuurmuurfout, en om dit te bevestig is een tabelafskrif nodig wat teen die inventaris vergelyk word.
Bepaal die grootte van die kliëntpoel en die terreinreekse doelbewus
'n VPN-kliëntpoel is 'n reeks wat die poort een adres op 'n slag uitdeel, so die grootte daarvan beperk gelyktydigheid. 'n /24 hou 254 bruikbare adresse, wat ruim is vir 'n klein span en krap vir 'n tak wat houers bedryf; 'n /22 kos niks ekstra binne privaat ruimte nie en verwyder die argument. Hou die poel aaneenlopend en weg van elke terrein-LAN, sodat die opsomroete na kliënte nooit 'n terrein insluk nie. Reserveer die reeks selfs terwyl die poel leeg is, want 'n ongeskrewe reeks is die een wat die volgende ingenieur sal toeken.
Terreine kry reekse wat vir verwagte gashere plus groei gegrootte is, en op 'n grens belyn wat skoon opsom. Doelbewuste gapings tussen toekennings kos niks en koop ruimte om later te aggregeer.
Kyk dan na die rigting wat mense vergeet: die terugpad. Elke terreinroeter het 'n roete na die kliëntpoel nodig, en die konsentrator het 'n roete na elke terreinprefiks wat dit bedien nodig. 'n Netjiese prefikstabel sonder 'n pad terug na die poel is steeds 'n gebroke ontwerp, en die simptoom is 'n eenrigtingverbinding wat niks antwoord nie. Hou albei rigtings in dieselfde tabel en hersien dit wanneer 'n terrein bygevoeg word.
Vertaaling en hernommering los verskillende probleme op
Wanneer 'n oorvleueling reeds bestaan, is daar twee eerlike opsies en een oneerlike. Hernommering verwyder die botsing permanent en kos 'n onderhoudsvenster plus elke hardgekodeerde adres wat jy vergeet het. Adresvertaling beeld een kant se privaat reeks in 'n ander reeks by die tonnelrand in, wat albei terreine onaangeraak laat maar toestand byvoeg, protokolle wat adresse insluit breek, en logs moeiliker leesbaar maak. Die oneerlike opsie is 'n gasheersroete na 'n enkele bediener, wat een toets slaag en al die res faal.
Kies volgens beheer en lewensduur. 'n Terrein wat jy besit en kan skeduleer, hoort op die hernommeringspad; 'n vennootnetwerk wat jy nie kan aanraak nie, vir een toepassing gebruik, is 'n kandidaat vir vertaling met 'n gedokumenteerde kartering. Skryf daardie kartering neer, want vertaling wat net binne 'n konfigurasielêer bestaan, verdwyn die oomblik wanneer die lêer vervang word.
Toets van die verre kant voordat jy ontplooi
Toets van 'n netwerk wat nie die poort huisves nie, want die poort se eie LAN verberg die meeste roeteringsfoute. Koppel 'n kliënt agter 'n gewone huisroeter en bereik dan 'n diens op elke terrein en een binne die kliëntpoel. Toets ook die omgekeerde rigting, van 'n terreingasheer na die kliënt, want terugpaaie faal onafhanklik. 'n Toets wat net die poort ping, bewys die tonnel is op en niks meer nie.
Hou reekse, eienaars en vertaalkarterings in een gedeelde rekord wat die volgende terrein lees voordat iets toegeken word. Hersien dit wanneer 'n terrein bygevoeg word, en behandel 'n ongedokumenteerde reeks as 'n gebrek eerder as 'n verrassing.
Die rekord is die lewering. 'n Plan wat in drie mense se geheue leef, faal die eerste keer wanneer een van hulle met verlof is, en 'n oorvleueling wat in produksie gevind word, kos meer as wat die tabel sou kos.