Slik budsjetterer du adresseplass for en VPN med flere lokasjoner

Hvor stort VPN-subnettet bør være, har ikke noe svar før du navngir hvilke adresser du teller. I ett design er de adressene de to endepunktene på en nummerert tunnellenke, i et annet er de kontorets LAN bak en policybasert tunnel, og i et tredje er de den reserverte infrastrukturen til en administrert gateway. Tre objekter, tre budsjetter, og de fleste dimensjoneringsfeil kommer av å fylle én kolonne med en annen kolonnes tall.

Fire roller, fire forskjellige spørsmål

Den ytre transporten er adressen en peer kobler til, så størrelsen følger din offentlige adressering eller leverandørens, aldri antallet enheter bak den. Indre tunnellenker finnes bare i design som nummererer et virtuelt grensesnitt, og der følger antallet topologiens naboskap. Beskyttede LAN-prefikser følger de virkelige nettene og deres vekstplan. Leverandørreservert infrastruktur følger det den administrerte tjenesten dokumenterer.

Bare den tredje av disse har noen forbindelse med hvor mange bærbare kontoret inneholder. Nettopp den forvekslingen forklarer de fleste diskusjonene.

Skriv de fire rollene som separate kolonner før du åpner en kalkulator. Hver får sin egen tildeling, eier og vekstforutsetning, og ingen av dem arver en annens størrelse. Når et design ikke har noen nummerert indre lenke, er den kolonnen tom i stedet for liten, og en tom kolonne er et faktum som er verdt å notere for neste gjennomgang.

Å telle blokker: hva et /30 egentlig koster

En punkt-til-punkt-lenke trenger to adresser og bruker en blokk hvis størrelse avhenger av plattformen. Et /30 rommer fire adresser, hvorav to vanligvis er brukbare, så tolv lenker bruker førtiåtte adresser i planen mens de tilbyr tjuefire endepunkter. Et /31 rommer to adresser og begge er brukbare, noe som halverer regnestykket, men bare der begge ender godtar det.

RFC 3021 definerer modellen med to adresser, og støtte er en egenskap ved endepunktene og tjenesten snarere enn ved gode intensjoner. En leverandør-API kan pålegge sitt eget maskekrav på et indre tunnelvalg, og en generell RFC opphever ikke en dokumentert begrensning. Kontroller hva plattformen din oppgir før du oppsummerer budsjettet, fordi forskjellen mellom førtiåtte og tjuefire adresser avgjør om planen passer i det reserverte området. Regn det ut i stedet for å stole på det sent på en lang dag.

ipcalc -n 10.44.12.0/30
ipcalc -n 10.44.12.4/31

Multipliser først når topologien er fastlagt. Tolv separate lenker og ett multipunkt-overlegg med tolv deltakere gir svært forskjellige totaler ut fra samme antall lokasjoner.

Den administrerte gatewayens subnett er ikke en klientpool

En administrert tjeneste reserverer ofte et subnett for sin egen gateway-infrastruktur, og det subnettet forbrukes av tjenesten i stedet for å bli gitt til klienter. Det har en dokumentert størrelse, noen ganger et dokumentert navn, og ingen forbindelse med hvor mange brukere som kobler til. Å behandle det som adressepoolen for eksterne maskiner gir et design som tømmer seg selv den første travle morgenen.

Les leverandørens krav som en fast kostnad, slik du ville behandlet en rackenhet. Det er ikke en del av budsjettet for det beskyttede prefikset.

Den samme lesningen gjelder for navn. Et subnett hvis dokumenterte formål er gateway-infrastruktur, er infrastruktur etter sedvane i den tjenesten, og å gi det nytt navn for å passe til ditt eget skjema ødelegger utrullingen i stedet for å forbedre diagrammet. Behold leverandørens navn og størrelser, og bruk ditt eget nummereringsskjema på delene du kontrollerer.

Dokumenter planen slik at den overlever den andre lokasjonen

En plan som lever i hodet til én ingeniør, feiler ved den første overlappingen mellom et kontorprefiks og en hjemmeruters standardområde. Publiser tildelingene med eierne deres, og angi hvilken ende av hver lenke som tildeler hvilken adresse. Ruter eller selektorer må fortsatt annonseres, fordi nummerering av en indre lenke ikke offentliggjør et LAN i seg selv.

Noter vekstforutsetningen bak hver blokk, fordi det er den delen ingen senere leser kan rekonstruere ut fra adressene alene.

Test så planen mot de vanskelige tilfellene: en lokasjon som kommer med et prefiks du allerede bruker, en lenke der den fjerne enden administreres av noen andre, og en region der leverandørkravet avviker fra det første du dokumenterte. Hvis noe av dette tvinger en ny utforming, var det du hadde et diagram og ikke en policy. En plan som overlever dem, er kort nok til å ligge i repositoriet ved siden av tunnelkonfigurasjonen, og det er nettopp der den neste personen vil lete etter den.