Plan privé-VPN-adresbereiken voordat sites botsen

Twee sites die beide 192.168.1.0/24 gebruiken, kunnen elk het internet bereiken en toch elkaar niet bereiken. De gateway meldt geen fout; hij installeert één route voor dat prefix en stuurt elk pakket naar de peer die het als eerste opeiste. Niets in de handshake, de cijferlijst of de interface-metriek zegt welke peer ongelijk heeft. Adresplanning is het deel van het ontwerp dat dit beslecht voordat iemand verbindt.

Inventariseer elke ruimte die bereikbaar moet zijn

Schrijf de bereiken op die gerouteerd moeten worden, niet alleen die u configureert. Dat betekent site-LAN’s, VPN-clientpools, cloud-subnetten, beheer- en out-of-band-netwerken, laboratoriumsegmenten en de netwerken waarvan gebruikers thuis gewoonlijk verbinden. Een consumentenrouter die als 192.168.1.0/24 wordt geleverd, is niet hypothetisch, en hetzelfde prefix duikt op in hotels en congrescentra. De inventaris is een tabel van prefix, eigenaar en doel, en het is het enige artefact dat voorkomt dat hetzelfde bereik twee keer wordt uitgegeven.

Voeg de prefixen toe die u het komende jaar verwacht, want een plan dat alleen vandaag dekt, faalt bij de eerste nieuwe site. Markeer in elke rij wie hem kan wijzigen, niet alleen wie hem bezit.

Het is het hergebruik dat dit moeilijk maakt: de privéruimte is eindig en elke organisatie beschouwt 10.0.0.0/8 als de hare. Een plan kan niet beloven dat geen toekomstige gast-LAN op een van uw prefixen landt, dus het ontwerp moet zeggen wat er gebeurt als dat wel zo is. Twee regels doen het meeste werk. Zet clientpools in één aaneengesloten blok dat u kunt samenvatten, en wijs nooit een bereik toe dat een ander team al routeert. Al het overige is een registratie die iemand actueel houdt.

Waarom een overlap de routingtabel verslaat

Een route is een prefix plus een volgende hop, en doorsturen kiest het langste overeenkomende prefix. Wanneer twee peers allebei 192.168.1.0/24 opeisen, houdt de tabel één vermelding daarvoor, dus verkeer van beide sites vertrekt door dezelfde tunnel. De tweede site is niet verkeerd geconfigureerd; hij is onbereikbaar omdat de eerste voor dezelfde adressen antwoordt. Geen enkele metriek kan ze scheiden, want de match gebeurt voordat metrieken worden geraadpleegd.

De storing is asymmetrisch en gemakkelijk verkeerd te lezen. Hosts op site A bereiken de gateway en sommige diensten, terwijl die van site B nergens op antwoorden, en het log toont een gezonde tunnel in beide richtingen. Dat patroon is een adresconflict en geen authenticatie- of firewallfout, en het bevestigen ervan vereist één tabeldump vergeleken met de inventaris.

Dimensioneer de clientpool en de sitebereiken bewust

Een VPN-clientpool is een bereik waaruit de gateway één adres per keer uitgeeft, dus de grootte begrenst de gelijktijdigheid. Een /24 bevat 254 bruikbare adressen, wat royaal is voor een klein team en krap voor een vestiging die containers draait; een /22 kost niets extra binnen de privéruimte en haalt de discussie weg. Houd de pool aaneengesloten en vrij van elk site-LAN, zodat de samenvattingsroute naar clients nooit een site opslokt. Reserveer het bereik ook terwijl de pool leeg is, want een onbeschreven bereik is degene die de volgende engineer toewijst.

Sites krijgen bereiken die zijn gedimensioneerd op verwachte hosts plus groei, uitgelijnd op een grens die netjes samenvat. Bewuste gaten tussen toewijzingen kosten niets en kopen ruimte om later te aggregeren.

Controleer dan de richting die mensen vergeten: de terugweg. Elke siterouter heeft een route naar de clientpool nodig, en de concentrator heeft een route nodig naar elk site-prefix dat hij bedient. Een nette prefixtabel zonder weg terug naar de pool is nog steeds een gebroken ontwerp, en het symptoom is een eenrichtingsverbinding die nergens op antwoordt. Houd beide richtingen in dezelfde tabel en herzie die telkens wanneer een site wordt toegevoegd.

Vertaling en hernummering lossen verschillende problemen op

Als er al een overlap bestaat, zijn er twee eerlijke opties en één oneerlijke. Hernummering verwijdert het conflict permanent en kost een onderhoudsvenster plus elk hardgecodeerd adres dat u vergeten bent. Adresvertaling mapt het privébereik van één kant naar een ander bereik aan de tunnelrand, wat beide sites ongemoeid laat maar state toevoegt, protocollen breekt die adressen insluiten en logs moeilijker leesbaar maakt. De oneerlijke optie is een hostroute naar één server, die één test doorstaat en al het overige faalt.

Kies op beheersbaarheid en levensduur. Een site die u bezit en kunt plannen, hoort op het hernummeringspad; een partnernetwerk dat u niet kunt aanraken en voor één toepassing wordt gebruikt, is kandidaat voor vertaling met een gedocumenteerde mapping. Schrijf die mapping op, want vertaling die alleen in een configuratiebestand bestaat, verdwijnt op het moment dat het bestand wordt vervangen.

Test vanaf de verre kant voordat u uitrolt

Test vanaf een netwerk dat de gateway niet host, want het eigen LAN van de gateway verbergt de meeste routeringsfouten. Verbind een client achter een gewone thuisrouter en bereik vervolgens een dienst op elke site en één binnen de clientpool. Test ook de omgekeerde richting, van een sitehost naar de client, want terugwegen falen onafhankelijk. Een test die alleen de gateway pingt, bewijst dat de tunnel omhoog is en niets meer.

Houd bereiken, eigenaren en vertaalmappings in één gedeeld register dat de volgende site leest voordat er iets wordt toegewezen. Herzie het wanneer een site wordt toegevoegd, en behandel een ongedocumenteerd bereik als een defect en niet als een verrassing.

Het register is het resultaat. Een plan dat in het geheugen van drie mensen leeft, faalt de eerste keer dat een van hen met vakantie is, en een overlap die in productie wordt gevonden, kost meer dan de tabel zou hebben gekost.