Planlegg private VPN-adresseområder før nettsteder kolliderer
Overlappende private områder bryter rutingen før noen tunnel. Inventariser prefiksene, dimensjoner klientpooler atskilt fra nettstedenes LAN og test fra den fjerne siden.
To nettsteder som begge bruker 192.168.1.0/24, kan hver for seg nå internett og likevel ikke nå hverandre. Gatewayen rapporterer ingen feil; den installerer én rute for det prefikset og sender hver pakke til den parten som krevde det først. Ingenting i håndtrykket, chifferlisten eller grensesnittmetrikken sier hvilken part som tar feil. Adresseplanlegging er den delen av designet som avgjør dette før noen kobler til.
Inventariser hvert område som må være tilgjengelig
Skriv ned områdene som må rutes, ikke bare dem du konfigurerer. Det betyr nettstedenes LAN, VPN-klientpooler, nettsky-underlag, administrasjons- og out-of-band-nettverk, laboratoriedeler og nettverkene brukerne vanligvis kobler til fra hjemmet. En forbrukerruter som leveres som 192.168.1.0/24, er ikke hypotetisk, og samme prefiks dukker opp på hoteller og konferansesentre. Inventaret er en tabell over prefiks, eier og formål, og det er det eneste artefaktet som hindrer at samme område deles ut to ganger.
| 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 |
Legg til prefiksene du forventer det neste året, fordi en plan som bare dekker i dag, feiler på det første nye nettstedet. Merk hver rad med hvem som kan endre den, ikke bare hvem som eier den.
Det er gjenbruken som gjør dette vanskelig: det private rommet er endelig, og enhver organisasjon betrakter 10.0.0.0/8 som sitt eget. En plan kan ikke love at ingen framtidig gjeste-LAN lander på et av prefiksene dine, så designet må si hva som skjer når det gjør det. To regler gjør mesteparten av jobben. Legg klientpooler i én sammenhengende blokk du kan oppsummere, og tildel aldri et område et annet team allerede ruter. Alt annet er en fortegnelse som noen holder oppdatert.
Hvorfor en overlapping beseirer rutetabellen
En rute er et prefiks pluss et neste hopp, og videresending velger det lengste samsvarende prefikset. Når to parter begge krever samme 192.168.1.0/24, har tabellen én oppføring for det, så trafikk for begge nettstedene går ut gjennom samme tunnel. Det andre nettstedet er ikke feilkonfigurert; det er uoppnåelig fordi det første svarer for de samme adressene. Ingen metrikk kan skille dem, fordi samsvaret skjer før metrikker konsulteres.
Feilen er asymmetrisk og lett å lese feil. Verter på nettsted A når gatewayen og noen tjenester, mens vertene på nettsted B ikke svarer på noe, og loggen viser en sunn tunnel i begge retninger. Det mønsteret er en adressekollisjon og ikke en feil i autentisering eller brannmur, og å bekrefte det krever en tabellutskrift sammenlignet med inventaret.
Dimensjoner klientpoolen og nettstedenes områder med vilje
En VPN-klientpool er et område gatewayen deler ut én adresse om gangen, så størrelsen begrenser samtidigheten. Et /24 rommer 254 brukbare adresser, noe som er rundhåndet for et lite team og trangt for en filial som kjører containere; et /22 koster ingenting ekstra i det private rommet og fjerner diskusjonen. Hold poolen sammenhengende og unna hvert nettsteds LAN, slik at samleruten mot klientene aldri sluker et nettsted. Reserver området selv når poolen er tom, fordi et ubeskrevet område er det neste ingeniør tildeler.
Nettsteder får områder dimensjonert for forventede verter pluss vekst, justert på en grense som oppsummeres rent. Bevisste hull mellom tildelinger koster ingenting og kjøper plass til senere aggregering.
Sjekk så retningen folk glemmer: returveien. Hver nettstedruter trenger en rute til klientpoolen, og konsentratoren trenger en rute til hvert nettstedprefiks den betjener. En ryddig prefikstabell uten vei tilbake til poolen er fortsatt et brutt design, og symptomet er en enveisforbindelse som ikke svarer på noe. Hold begge retninger i samme tabell og gjennomgå den hver gang et nettsted legges til.
Oversettelse og omnummerering løser ulike problemer
Når en overlapping allerede finnes, er det to ærlige alternativer og ett uærlig. Omnummerering fjerner kollisjonen permanent og koster et vedlikehavsvindu pluss hver hardkodet adresse du glemte. Adresseoversettelse mapper den ene sidens private område til et annet område ved tunnelkanten, noe som lar begge nettstedene være urørt, men legger til tilstand, bryter protokoller som bygger inn adresser og gjør loggene vanskeligere å lese. Det uærlige alternativet er en vertsrute til én enkelt server, som består én test og feiler på alt annet.
Velg etter kontroll og levetid. Et nettsted du eier og kan planlegge, hører på omnummereringsveien; et partnernettverk du ikke kan røre, brukt til én applikasjon, er en kandidat for oversettelse med en dokumentert mapping. Skriv den mappingen ned, for oversettelse som bare finnes inne i en konfigurasjonsfil, forsvinner i det øyeblikket filen erstattes.
Test fra den fjerne siden før du ruller ut
Test fra et nettverk som ikke er vert for gatewayen, fordi gatewayens eget LAN skjuler de fleste ruteleifene. Koble en klient bak en vanlig hjemmeruter, og nå deretter en tjeneste på hvert nettsted og én inne i klientpoolen. Test også motsatt retning, fra en nettstedvert til klienten, fordi returveier feiler uavhengig. En test som bare pinger gatewayen, beviser at tunnelen er oppe og ikke noe mer.
Hold områder, eiere og oversettelsesmappings i én delt fortegnelse som det neste nettstedet leser før det tildeler noe. Gjennomgå den når et nettsted legges til, og behandle et udokumentert område som en defekt og ikke som en overraskelse.
Fortegnelsen er leveransen. En plan som lever i tre personers minne, feiler første gang en av dem er på ferie, og en overlapping funnet i produksjon koster mer enn tabellen ville ha kostet.