Så budgeterar du adressutrymme för ett VPN med flera platser

Hur stort VPN-undernätet bör vara har inget svar förrän du namnger vilka adresser du räknar. I en design är det de två ändpunkterna på en numrerad tunnellänk, i en annan kontorets LAN bakom en policybaserad tunnel, och i en tredje den reserverade infrastrukturen för en hanterad gateway. Tre objekt, tre budgetar, och de flesta dimensioneringsfel kommer av att fylla en kolumn med en annan kolumns tal.

Fyra roller, fyra olika frågor

Den yttre transporten är adressen en peer ansluter till, så storleken följer din offentliga adressering eller leverantörens, aldrig antalet enheter bakom den. Interna tunnellänkar finns bara i designer som numrerar ett virtuellt gränssnitt, och där följer antalet topologins grannskap. Skyddade LAN-prefix följer de verkliga näten och deras tillväxtplan. Leverantörsreserverad infrastruktur följer det den hanterade tjänsten dokumenterar.

Bara den tredje av dessa har någon koppling till hur många bärbara datorer kontoret innehåller. Just den sammanblandningen förklarar de flesta diskussionerna.

Skriv de fyra rollerna som separata kolumner innan du öppnar en miniräknare. Var och en får sin egen tilldelning, ägare och tillväxtantagande, och ingen ärver en annans storlek. När en design inte har någon numrerad intern länk är den kolumnen tom i stället för liten, och en tom kolumn är ett faktum som är värt att notera för nästa granskare.

Att räkna block: vad ett /30 egentligen kostar

En punkt-till-punkt-länk behöver två adresser och förbrukar ett block vars storlek beror på plattformen. Ett /30 rymmer fyra adresser, varav två vanligtvis är användbara, så tolv länkar förbrukar fyrtioåtta adresser i planen medan de erbjuder tjugofyra ändpunkter. Ett /31 rymmer två adresser och båda är användbara, vilket halverar räkningen, men bara där båda ändar accepterar det.

RFC 3021 definierar modellen med två adresser, och stöd är en egenskap hos ändpunkterna och tjänsten snarare än hos goda avsikter. Ett leverantörs-API kan ålägga sitt eget maskkrav på ett internt tunnelalternativ, och en allmän RFC upphäver inte en dokumenterad begränsning. Kontrollera vad din plattform anger innan du sammanfattar budgeten, eftersom skillnaden mellan fyrtioåtta och tjugofyra adresser avgör om planen får plats i det reserverade intervallet. Räkna ut det istället för att lita på det sent en lång dag.

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

Multiplicera först när topologin är fastställd. Tolv separata länkar och ett multipunktsöverlägg med tolv deltagare ger mycket olika summor utifrån samma antal platser.

Den hanterade gatewayens undernät är inte en klientpool

En hanterad tjänst reserverar ofta ett undernät för sin egen gateway-infrastruktur, och det undernätet förbrukas av tjänsten i stället för att ges till klienter. Det har en dokumenterad storlek, ibland ett dokumenterat namn, och ingen koppling till hur många användare som ansluter. Att behandla det som adresspool för fjärrmaskiner ger en design som tömmer sig själv första stressiga morgonen.

Läs leverantörens krav som en fast kostnad, så som du skulle behandla en rackenhet. Det ingår inte i budgeten för det skyddade prefixet.

Samma läsning gäller för namn. Ett undernät vars dokumenterade syfte är gateway-infrastruktur är infrastruktur enligt konvention i den tjänsten, och att byta namn på det för att passa ditt eget schema bryter driftsättningen i stället för att förbättra diagrammet. Behåll leverantörens namn och storlekar, och använd ditt eget numreringsschema på de delar du styr.

Dokumentera planen så att den överlever den andra platsen

En plan som lever i huvudet på en enda ingenjör misslyckas vid den första överlappningen mellan ett kontorsprefix och en hemrouters standardintervall. Publicera tilldelningarna med deras ägare, och ange vilken ände av varje länk som tilldelar vilken adress. Rutter eller selektorer måste fortfarande annonseras, eftersom numrering av en intern länk inte publicerar ett LAN i sig.

Anteckna tillväxtantagandet bakom varje block, eftersom det är den delen som ingen senare läsare kan rekonstruera enbart från adresserna.

Testa sedan planen mot de besvärliga fallen: en plats som kommer med ett prefix du redan använder, en länk vars bortre ände hanteras av någon annan, och en region vars leverantörskrav skiljer sig från det första du dokumenterade. Om något av detta tvingar fram en ny design var det du hade ett diagram och inte en policy. En plan som överlever dem är kort nog att ligga i repositoriet bredvid tunnelkonfigurationen, och det är precis där nästa person kommer att leta efter den.