Sådan budgetterer du adresseplads til en VPN med flere lokationer

Hvor stort VPN-undernettet skal være, har intet svar, før du navngiver, hvilke adresser du tæller. I ét design er de adresser de to endepunkter på en nummereret tunnelforbindelse, i et andet er de kontorets LAN bag en politikbaseret tunnel, og i et tredje er de en administreret gateways reserverede infrastruktur. Tre objekter, tre budgetter, og de fleste dimensioneringsfejl kommer af at fylde én kolonne med en anden kolonnes tal.

Fire roller, fire forskellige spørgsmål

Den ydre transport er den adresse, en peer forbinder til, så dens størrelse følger din offentlige adressering eller udbyderens, aldrig antallet af enheder bag den. Indvendige tunnelforbindelser findes kun i design, der nummererer en virtuel grænseflade, og der følger antallet topologiens naboskaber. Beskyttede LAN-præfikser følger de rigtige netværk og deres vækstplan. Udbyderreserveret infrastruktur følger det, den administrerede tjeneste dokumenterer.

Kun det tredje af disse har nogen forbindelse til, hvor mange bærbare computere kontoret indeholder. Netop den forveksling forklarer de fleste diskussioner.

Skriv de fire roller som separate kolonner, før du åbner en lommeregner. Hver får sin egen tildeling, ejer og vækstantagelse, og ingen af dem arver en andens størrelse. Når et design ikke har nogen nummereret indvendig forbindelse, er den kolonne tom i stedet for lille, og en tom kolonne er et faktum, der er værd at notere for den næste anmelder.

At tælle blokke: hvad et /30 egentlig koster

En punkt-til-punkt-forbindelse kræver to adresser og bruger en blok, hvis størrelse afhænger af platformen. Et /30 rummer fire adresser, hvoraf to normalt er brugbare, så tolv forbindelser bruger otteogfyrre adresser i planen, mens de tilbyder fireogtyve endepunkter. Et /31 rummer to adresser, og begge er brugbare, hvilket halverer regnestykket, men kun hvor begge ender accepterer det.

RFC 3021 definerer modellen med to adresser, og understøttelse er en egenskab ved endepunkterne og tjenesten snarere end ved gode hensigter. En udbyder-API kan pålægge sit eget mastekrav på en indvendig tunnelmulighed, og en generel RFC tilsidesætter ikke en dokumenteret begrænsning. Kontrollér, hvad din platform angiver, før du opsummerer budgettet, fordi forskellen mellem otteogfyrre og fireogtyve adresser afgør, om planen passer i det reserverede område. Regn det ud i stedet for at stole på det sidst på en lang dag.

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

Gang kun, efter at topologien er fastlagt. Tolv separate forbindelser og et multipunkt-overlay med tolv deltagere giver meget forskellige totaler ud fra det samme antal lokationer.

Den administrerede gateways undernet er ikke en klientpulje

En administreret tjeneste reserverer ofte et undernet til sin egen gateway-infrastruktur, og det undernet forbruges af tjenesten i stedet for at blive givet til klienter. Det har en dokumenteret størrelse, nogle gange et dokumenteret navn og ingen forbindelse til, hvor mange brugere der forbinder. At behandle det som adressepulje til fjernmaskiner giver et design, der udtømmer sig selv den første travle morgen.

Læs udbyderens krav som en fast omkostning, ligesom du ville behandle en rackenhed. Det er ikke en del af budgettet for det beskyttede præfiks.

Den samme læsning gælder for navne. Et undernet, hvis dokumenterede formål er gateway-infrastruktur, er infrastruktur efter sædvane i den tjeneste, og at omdøbe det for at passe til dit eget skema ødelægger udrulningen i stedet for at forbedre diagrammet. Behold udbyderens navne og størrelser, og brug dit eget nummereringsskema på de dele, du styrer.

Dokumentér planen, så den overlever den anden lokation

En plan, der lever i én ingeniørs hoved, fejler ved det første overlap mellem et kontorpræfiks og en hjemmerutters standardområde. Offentliggør tildelingerne med deres ejere, og angiv, hvilken ende af hver forbindelse der tildeler hvilken adresse. Ruter eller selektorer skal stadig annonceres, fordi nummerering af en indvendig forbindelse ikke i sig selv offentliggør et LAN.

Notér vækstantagelsen bag hver blok, fordi det er den del, ingen senere læser kan rekonstruere ud fra adresserne alene.

Test så planen mod de akavede tilfælde: en lokation, der ankommer med et præfiks, du allerede bruger, en forbindelse, hvis fjerne ende nogen andre styrer, og en region, hvis udbyderkrav adskiller sig fra det første, du dokumenterede. Hvis noget af det tvinger et redesign, var det, du havde, et diagram og ikke en politik. En plan, der overlever dem, er kort nok til at ligge i repositoriet ved siden af tunnelkonfigurationen, og det er præcis der, den næste person vil lede efter den.