Planlæg private VPN-adresseområder, før site-netværk støder sammen
Overlappende private områder bryder routing, før der overhovedet er en tunnel. Optæl præfikserne, dimensionér klientpuljer adskilt fra siternes LAN og test fra den fjerne side.
To site-netværk, der begge bruger 192.168.1.0/24, kan hver især nå internettet og alligevel ikke nå hinanden. Gatewayen rapporterer ingen fejl; den installerer én rute til det præfiks og sender hver pakke til den modpart, der krævede det først. Intet i håndtrykket, cipherlisten eller interfacets metric fortæller, hvilken modpart der er forkert. Adresseplanlægning er den del af designet, der afgør det, før nogen opretter forbindelse.
Optæl hvert område, der skal kunne nås
Skriv de områder ned, der skal routes, ikke kun dem du konfigurerer. Det betyder siternes LAN, VPN-klientpuljer, cloud-subnet, administrations- og out-of-band-netværk, laboratorie-segmenter og de netværk, brugerne normalt forbinder fra derhjemme. En forbrugerrouter, der leveres som 192.168.1.0/24, er ikke hypotetisk, og samme præfiks dukker op på hoteller og konferencecentre. Optællingen er en tabel over præfiks, ejer og formål, og den er det eneste artefakt, der forhindrer, at samme område udleveres to gange.
| 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 |
Tilføj de præfikser, du forventer inden for det næste år, for en plan, der kun dækker i dag, fejler ved det første nye site. Markér hver række med, hvem der kan ændre den, ikke kun hvem der ejer den.
Det er genbrugen, der gør det svært: det private rum er begrænset, og enhver organisation betragter 10.0.0.0/8 som sit eget. En plan kan ikke love, at et fremtidigt gæste-LAN ikke lander på et af dine præfikser, så designet skal sige, hvad der sker, når det gør. To regler klarer det meste. Læg klientpuljer i én sammenhængende blok, du kan opsummere, og tildel aldrig et område, et andet team allerede router. Alt andet er en fortegnelse, som nogen holder opdateret.
Hvorfor et overlap besejrer routingtabellen
En rute er et præfiks plus et næste hop, og videresendelse vælger det længste matchende præfiks. Når to modparter begge kræver 192.168.1.0/24, har tabellen én post til det, så trafik for begge sites forlader gennem samme tunnel. Det andet site er ikke fejlkonfigureret; det er uopnåeligt, fordi det første svarer på de samme adresser. Ingen metric kan skille dem, fordi matchningen sker, før metrics konsulteres.
Fejlen er asymmetrisk og let at fejltolke. Værter på site A når gatewayen og nogle tjenester, mens site B's værter ikke svarer på noget, og loggen viser en sund tunnel i begge retninger. Det mønster er en adressekollision og ikke en fejl i autentificering eller firewall, og at bekræfte det kræver et tabeldump sammenlignet med optællingen.
Dimensionér klientpuljen og siternes områder med vilje
En VPN-klientpulje er et område, som gatewayen uddeler én adresse ad gangen, så dens størrelse begrænser samtidigheden. Et /24 rummer 254 brugbare adresser, hvilket er rundhåndet til et lille team og stramt til en filial, der kører containere; et /22 koster intet ekstra i det private rum og fjerner diskussionen. Hold puljen sammenhængende og fri af hvert sites LAN, så den opsummerede rute mod klienter aldrig slår et site sammen med puljen. Reserver området, selv mens puljen er tom, for et ubeskrevet område er det, den næste ingeniør tildeler.
Sites får områder dimensioneret til forventede værter plus vækst og justeret på en grænse, der opsummeres rent. Bevidste huller mellem tildelinger koster intet og køber plads til senere aggregering.
Kontrollér så den retning, folk glemmer: returvejen. Hver site-router har brug for en rute til klientpuljen, og koncentratoren har brug for en rute til hvert sitepræfiks, den betjener. En pæn præfikstabel uden vej tilbage til puljen er stadig et brudt design, og symptomet er en envejsforbindelse, der ikke svarer på noget. Hold begge retninger i samme tabel, og gennemgå den, hver gang et site tilføjes.
Oversættelse og omnummerering løser forskellige problemer
Når et overlap allerede findes, er der to ærlige muligheder og én uærlig. Omnummerering fjerner kollisionen permanent og koster et vedligeholdelsesvindue plus hver hårdt kodet adresse, du har glemt. Adresseoversættelse mapper den ene sides private område ind i et andet område ved tunnelkanten, hvilket lader begge sites urørte, men tilføjer tilstand, bryder protokoller, der indlejrer adresser, og gør loggene sværere at læse. Den uærlige mulighed er en værtsrute til en enkelt server, som består én test og fejler alt andet.
Vælg efter kontrol og levetid. Et site, du ejer og kan planlægge, hører på omnummereringsvejen; et partnernetværk, du ikke kan røre, brugt til én applikation, er en kandidat til oversættelse med en dokumenteret mapping. Skriv den mapping ned, for oversættelse, der kun findes inde i en konfigurationsfil, forsvinder i det øjeblik, filen erstattes.
Test fra den fjerne side, før du udruller
Test fra et netværk, der ikke huser gatewayen, for gatewayens eget LAN skjuler de fleste routingfejl. Forbind en klient bag en almindelig hjemmerouter, og nå derefter en tjeneste på hvert site og en inde i klientpuljen. Test også den modsatte retning, fra en site-vært til klienten, for returveje fejler uafhængigt. En test, der kun pinger gatewayen, beviser, at tunnelen er oppe, og intet mere.
Hold områder, ejere og oversættelsesmappinger i én fælles fortegnelse, som det næste site læser, før det tildeler noget. Gennemgå den, når et site tilføjes, og behandl et udokumenteret område som en fejl frem for en overraskelse.
Fortegnelsen er leverancen. En plan, der lever i tre personers hukommelse, fejler første gang, en af dem er på ferie, og et overlap fundet i produktion koster mere, end tabellen ville have gjort.