Hoe u adresruimte begroot voor een VPN met meerdere locaties

Hoe groot het VPN-subnet moet zijn, heeft geen antwoord tot u benoemt welke adressen u telt. In het ene ontwerp zijn dat de twee uiteinden van een genummerde tunnelverbinding, in een ander het kantoor-LAN achter een beleidsgebaseerde tunnel, en in een derde de gereserveerde infrastructuur van een beheerde gateway. Drie objecten, drie budgetten, en de meeste dimensioneringsfouten komen doordat één kolom met het getal van een andere kolom wordt gevuld.

Vier rollen, vier verschillende vragen

Het buitenste transport is het adres waarop een peer verbindt, dus de omvang volgt uw openbare adressering of die van de provider, nooit het aantal apparaten erachter. Interne tunnelverbindingen bestaan alleen in ontwerpen die een virtuele interface nummeren, en daar volgt het aantal de buren van de topologie. Prefixen van beschermde LAN’s volgen de echte netwerken en hun groeiplan. Door de provider gereserveerde infrastructuur volgt wat de beheerde dienst documenteert.

Alleen de derde daarvan heeft iets te maken met hoeveel laptops het kantoor bevat. Juist die ene verwarring verklaart de meeste discussies.

Schrijf de vier rollen als aparte kolommen voordat u een rekenmachine opent. Elk krijgt zijn eigen toewijzing, eigenaar en groeiaanname, en geen enkele erft de omvang van een andere. Als een ontwerp geen genummerde interne verbinding heeft, is die kolom leeg in plaats van klein, en een lege kolom is een feit dat het waard is vast te leggen voor de volgende beoordelaar.

Blokken tellen: wat een /30 echt kost

Een punt-tot-punt-verbinding heeft twee adressen nodig en verbruikt een blok waarvan de grootte van het platform afhangt. Een /30 bevat vier adressen, waarvan er twee meestal bruikbaar zijn, dus twaalf verbindingen verbruiken achtenveertig adressen in het plan terwijl ze vierentwintig eindpunten bieden. Een /31 bevat twee adressen en beide zijn bruikbaar, wat de rekensom halveert, maar alleen waar beide uiteinden dat accepteren.

RFC 3021 definieert het model met twee adressen, en ondersteuning is een eigenschap van de eindpunten en de dienst, niet van goede bedoelingen. Een provider-API kan zijn eigen maskeis op een interne tunneloptie opleggen, en een algemene RFC heft een gedocumenteerde beperking niet op. Controleer wat uw platform aangeeft voordat u het budget samenvat, want het verschil tussen achtenveertig en vierentwintig adressen bepaalt of het plan in het gereserveerde bereik past. Reken het door in plaats van erop te vertrouwen aan het eind van een lange dag.

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

Vermenigvuldig pas nadat de topologie vaststaat. Twaalf afzonderlijke verbindingen en één multipoint-overlay met twaalf deelnemers leveren heel verschillende totalen op bij hetzelfde aantal locaties.

Het subnet van de beheerde gateway is geen clientpool

Een beheerde dienst reserveert vaak een subnet voor zijn eigen gateway-infrastructuur, en dat subnet wordt door de dienst verbruikt in plaats van aan clients gegeven. Het heeft een gedocumenteerde grootte, soms een gedocumenteerde naam, en geen enkele relatie met hoeveel gebruikers verbinden. Het behandelen als de adrespool voor externe machines levert een ontwerp op dat zich op de eerste drukke ochtend uitput.

Lees de eis van de provider als een vaste kostenpost, zoals u een rackeenheid zou behandelen. Het maakt geen deel uit van het budget van het beschermde prefix.

Dezelfde lezing geldt voor namen. Een subnet waarvan het gedocumenteerde doel gateway-infrastructuur is, is in die dienst infrastructureel volgens conventie, en het hernoemen om het bij uw eigen schema te laten passen breekt de uitrol in plaats van het diagram te verbeteren. Houd de namen en groottes van de provider aan, en besteed uw eigen nummeringsschema aan de delen die u beheert.

Documenteer het plan zodat het de tweede locatie overleeft

Een plan dat in het hoofd van één ingenieur leeft, faalt bij de eerste overlap tussen een kantoorprefix en het standaardbereik van een thuisrouter. Publiceer de toewijzingen met hun eigenaren, en geef aan welk uiteinde van elke verbinding welk adres toewijst. Routes of selectors moeten nog steeds worden aangekondigd, want het nummeren van een interne verbinding publiceert op zichzelf geen LAN.

Leg de groeiaanname achter elk blok vast, want dat is het deel dat geen enkele latere lezer uit de adressen alleen kan reconstrueren.

Test het plan daarna tegen de lastige gevallen: een locatie die binnenkomt met een prefix dat u al gebruikt, een verbinding waarvan het verre uiteinde door iemand anders wordt beheerd, en een regio waarvan de providereis afwijkt van de eerste die u documenteerde. Als een daarvan een herontwerp afdwingt, dan had u een diagram en geen beleid. Een plan dat ze overleeft, is kort genoeg om in de repository naast de tunnelconfiguratie te staan, en precies daar zal de volgende persoon het zoeken.