Ster of volledig net: welke VPN-topologie past bij uw locaties
Twee werkende tunnels zijn nog geen topologie. Vergelijk transittijd, gedrag bij storing en de kosten van een wijziging voordat u een hub, een volledig net of een hub met enkele directe links kiest.
Twee filialen praten de hele dag met elkaar, en de tunnel tussen hen maakt een omweg via een datacenter in een andere regio. Elk verzoek betaalt die omweg twee keer, en niemand merkt het tot de bestandssynchronisatie verkeerd begint te voelen. Daar begint de topologievraag echt: niet met welk diagram er veerkrachtiger uitziet, maar met welk verkeerspatroon u betaalt. Beide ontwerpen werken, en ze falen op verschillende manieren tegen verschillende kosten.
Tel eerst de peerverhoudingen
Bij N locaties heeft een volledig net N keer N min één, gedeeld door twee, tunnels nodig; een hub heeft er N nodig. Bij vijf locaties is dat tien tegen vijf, wat nog beheersbaar klinkt. Bij vijftien is het 105 tegen vijftien, en het verschil is geen rekenwerk meer maar personeel.
Elk van die verhoudingen draagt toestand die u moet beheren. Bij IPsec betekent dat een security association, een identiteit, een sleutel of certificaat, dead-peer detection en minstens één route per remote prefix. Bij WireGuard betekent het een publieke sleutel en een AllowedIPs-blok per peer; per peer goedkoper, maar zonder enige discovery: een nieuwe locatie is hoe dan ook een configuratiewijziging op elke bestaande.
Laat de verkeersmix beslissen, niet de tekening
Als filiaalverkeer vooral verzoeken aan een centraal ERP- of bestandscluster is, is een hub geen compromis maar de juiste vorm: het verkeer wilde daar al heen, en één beleidspunt is makkelijker te auditen dan een net van paarsgewijze regels. Een volledig net verdient zijn complexiteit wanneer filialen onderling gegevens uitwisselen: replicatie tussen twee kantoren, spraak tussen locaties, een CAD-share die een dozijn ingenieurs de hele dag opent.
De ongemakkelijke gevallen zitten ertussenin, en dat is de meerderheid. Meet voordat u discussieert in plaats van te gissen uit een organigram.
| Signal | Points to a hub | Points to a mesh |
|---|---|---|
| Branch-to-branch traffic | Occasional, small | Dominant, all day |
| Site count | Growing, past ten | Small and stable |
| Change rate | Frequent adds and moves | Rare |
| Failure tolerance | A second hub is affordable | Every site must survive alone |
Lees de tabel als beslechter, niet als regel. Drie van de vier rijen één kant op beslecht meestal het ontwerp, en een splitsing betekent een hybride, wat de meeste volwassen netwerken uiteindelijk toch draaien.
Een hub moet worden verteld dat hij moet doorsturen
Twee werkende spoke-naar-hub-tunnels maken nog geen toegang tussen spokes. De hub heeft IP-forwarding nodig, een route naar elk spokennetwerk, een firewallregel die het transport toestaat en een uitgewerkt retourpad; elke spoke heeft een route naar de prefixen van de andere locatie nodig. Op een Linux-hub is dat net.ipv4.ip_forward=1 plus een FORWARD-keten die het paar niet stil laat vallen, en bij beleidsgebaseerde IPsec zijn het traffic selectors die het remote spokennet op beide uiteinden vermelden. strongSwan notities over doorsturen dekken de kernel- en firewallkant wanneer dat de laag is die u mist. Een goedkope test is verkeer van de ene spoke naar een dienst op de andere sturen terwijl u de tellers van de hub bekijkt; een regel die nooit oploopt betekent dat de volgorde fout is, niet de route.
Centraal beleid is ook het nuttige deel. Filialen kunnen gedeelde diensten bereiken zonder elkaar te bereiken, en die toegangsmatrix is het waard om expliciet op te schrijven. Ontbrekende routes zijn een slechte vervanging voor een regel die iemand kan lezen.
Let op de halfaffemaakte versie: spoke A routeert via de hub naar spoke B, de hub routeert beide kanten op, en de firewall van de hub staat nieuwe verbindingen van A toe maar niet van B. De eerste richting test prima en de tweede blijft hangen, wat op een routeringsfout lijkt en het niet is.
Ontwerp eerst de storing, dan het normale pad
Een enkele hub is een gedeelde afhankelijkheid en een transportknelpunt, en redundantie is waar hubontwerpen meestal misgaan. Twee hubs betekenen dat elke spoke twee tunnels houdt, en het retourpad moet overeenkomen met het uitgaande; als dat niet zo is, laat een stateful firewall de antwoorden vallen en is het symptoom een verbinding die opent en dan sterft. Grotere implementaties lossen dat op met een routeringsprotocol over de tunnels in plaats van statische prefixen, wat meer machinerie is maar het gissen wegneemt. Wat u ook kiest, schrijf het retourpad naast het uitgaande, want de retourhelft is degene die niemand test.
Een volledig net spreidt dat risico: de link van één locatie die uitvalt isoleert de andere niet. Het vermenigvuldigt ook de plaatsen waar padselectie u kan verrassen, en applicatiesessies overleven een padwissel nog steeds niet zonder hulp.
Geen van beide ontwerpen houdt zelf een TCP-sessie in leven tijdens een failover. Als de applicatie niet opnieuw kan verbinden, is topologie niet uw probleem.
Kies op wijzigingskosten en verifieer dan de routes
Begin met de hub, want dat is goedkoper om fout te doen, en voeg directe tunnels toe voor de paren wier verkeer dat rechtvaardigt. Die hybride is geen mislukte beslissing; het is het ontwerp waarop de meeste organisaties binnen een jaar uitkomen. Wat telt is dat elke directe link een genoemde reden en een eigenaar heeft.
Verifieer dan de twee tekeningen in plaats van één. Voor het normale pad: traceroute van elke locatie naar elk dienstprefix en bevestig dat de hops met het diagram kloppen. Voor het storingspad: sluit één tunnel en herhaal het, want een route die alleen werkt zolang alles aan staat is niet ontworpen, alleen geconfigureerd.
Bewaar beide tekeningen bij de toegangsmatrix en herzie ze wanneer een locatie wordt toegevoegd; de kosten die u beheert zijn de kosten van de volgende wijziging, niet de elegantie van het huidige plaatje.