Stjärna eller fullt nät: vilken VPN-topologi passar dina platser

Två filialkontor pratar med varandra hela dagen, och tunneln mellan dem tar en omväg via ett datacenter i en annan region. Varje begäran betalar för omvägen två gånger, och ingen märker det förrän filsynkroniseringen börjar kännas fel. Det är där topologifrågan verkligen börjar: inte med vilket diagram som ser mer robust ut, utan med vilket trafikmönster du betalar för. Båda designerna fungerar, och de fallerar på olika sätt med olika kostnader.

Räkna peer-relationerna först

Med N platser behöver ett fullt nät N gånger N minus ett, delat med två, tunnlar; ett nav behöver N. Vid fem platser är det tio mot fem, vilket fortfarande låter hanterbart. Vid femton är det 105 mot femton, och skillnaden är inte längre aritmetik utan bemanning.

Varje sådan relation bär tillstånd som du måste äga. I IPsec betyder det en säkerhetsassociation, en identitet, en nyckel eller ett certifikat, detektering av döda peers och minst en rutt per fjärrprefix. I WireGuard betyder det en publik nyckel och ett AllowedIPs-block per peer; billigare per peer men helt utan upptäckt: en ny plats är ändå en konfigurationsändring på varje befintlig.

Låt trafikmixen avgöra, inte ritningen

Om filialtrafiken mest är begäranden till ett centralt ERP eller filkluster är ett nav ingen kompromiss utan rätt form: trafiken ville redan dit, och en enda policypunkt är lättare att granska än ett nät av parvisa regler. Ett fullt nät förtjänar sin komplexitet när filialer utbyter data med varandra: replikering mellan två kontor, tal mellan platser, en CAD-delning som ett dussin ingenjörer öppnar hela dagen.

De obekväma fallen ligger däremellan, och de är majoriteten. Mät innan du argumenterar i stället för att gissa från ett organisationsschema.

Läs tabellen som en avgörare, inte som en regel. Tre av fyra rader i en riktning avgör oftast designen, och en delning betyder hybrid, vilket de flesta mogna nätverk ändå kör.

Ett nav måste få veta att det ska vidarebefordra

Två fungerande spoke-till-nav-tunnlar skapar ingen åtkomst mellan spokes. Navet behöver IP-vidarebefordran aktiverad, en rutt till varje spokenät, en brandväggsregel som tillåter transiten och en uträknad returväg; varje spoke behöver en rutt till den andra platsens prefix. På ett Linux-nav är det net.ipv4.ip_forward=1 plus en FORWARD-kedja som inte tyst tappar paret, och i policybaserad IPsec är det trafikväljare som listar fjärrspokens subnät i båda ändar. strongSwan anteckningarna om vidarebefordran täcker kärn- och brandväggssidan när det är det lagret du saknar. Ett billigt test är att skicka trafik från en spoke till en tjänst på den andra medan du tittar på navets räknare; en regel som aldrig ökar betyder att ordningen är fel, inte rutten.

Central policy är också den användbara delen. Filialer kan tillåtas nå delade tjänster utan att nå varandra, och den åtkomstmatrisen är värd att skriva ned uttryckligen. Saknade rutter är en dålig ersättning för en regel som någon kan läsa.

Se upp för den halvfärdiga versionen: spoke A routar till spoke B via navet, navet routar åt båda hållen, och navets brandvägg tillåter nya anslutningar från A men inte från B. Den första riktningen testar bra och den andra hänger, vilket ser ut som ett routingfel och inte är det.

Designa felet först, sedan den normala vägen

Ett enda nav är ett delat beroende och en transitflaskhals, och redundans är där navdesigner brukar gå fel. Två nav betyder att varje spoke håller två tunnlar, och returvägen måste stämma med den utgående; när den inte gör det släpper en tillståndsfull brandvägg svaren och symptomet är en anslutning som öppnas och sedan dör. Större utrullningar löser det med ett routingprotokoll över tunnlarna i stället för statiska prefix, vilket är mer maskineri men tar bort gissandet. Vad du än väljer, skriv returvägen bredvid den utgående, för returhalvan är den ingen testar.

Ett fullt nät sprider den risken: en plats länk som går ned isolerar inte de andra. Det mångfaldigar också platserna där vägvalet kan överraska dig, och applikationssessioner överlever fortfarande inte ett vägbyte utan hjälp.

Ingen av designerna håller en TCP-session vid liv genom en failover på egen hand. Om applikationen inte kan återansluta är topologi inte ditt problem.

Välj efter ändringskostnad och verifiera sedan rutterna

Börja med navet, eftersom det är det billigare att ha fel om, och lägg till direkta tunnlar för de par vars trafik motiverar dem. Den hybriden är inget misslyckande att besluta; det är designen som de flesta organisationer landar i inom ett år. Det som spelar roll är att varje direkt länk har ett angivet skäl och en ägare.

Verifiera sedan de två ritningarna i stället för en. För den normala vägen, kör traceroute från varje plats till varje tjänsteprefix och bekräfta att hoppen matchar diagrammet. För felvegen, stäng en tunnel och upprepa, för en rutt som bara fungerar medan allt är uppe är inte designad, bara konfigurerad.

Behåll båda ritningarna med åtkomstmatrisen och se över dem när en plats läggs till; kostnaden du hanterar är kostnaden för nästa ändring, inte elegantensen i den nuvarande bilden.