Kombinerad eller separat VPN-gateway: välj efter feldoman
Att räkna enheter lär dig ingenting. Skriv ned vad som faller samtidigt, var policyn tillämpas och hur du når gatewayen när den går sönder.
Två enheter verkar mer motståndskraftiga än en tills du märker att de delar samma grenkontakt, samma hypervisor och samma uppströmslänk. Att räkna lådor svarar på en fråga som ingen ställde; den användbara frågan är vad som faller samtidigt. Skriv ned felavtalet först och låt det sedan välja topologin. Runbooken nedan producerar den posten.
Vad som stannar vid en omstart
För en kombinerad gateway, lista vad som försvinner vid en omstart, en misslyckad uppdatering eller ett hårdvarufel. Om internetåtkomst och privat anslutning stannar tillsammans är det delade avbrottet nu en del av ditt tillgänglighetskrav, oavsett om någon har skrivit ned det. Samma övning gäller för en enda enhet som avslutar flera roller: listan över tjänster den tar ned är den egentliga specifikationen.
För separata gatewayer, lista vad som förblir delat: ström, virtualiseringsvärden, uppströmslänken, identitetsleverantören, hanteringsnätet. Två enheter bakom en enda misslyckad switch är en enda feldoman med två värdnamn. En separering som ignorerar dessa beroenden är ett diagram, inte en design.
Räkna också med underhållsägandet. En annan enhet tillför konfiguration, övervakning, säkerhetskopior och en andra återställningsprocedur, och inget av det är gratis.
Markera var varje regel tillämpas
Följ ett paket från klienten till en privat resurs och tillbaka, och markera varje plats där en policy tillämpas. En andra router lägger till ännu en punkt där rutpreferens, översättning eller anslutningstillstånd kan vara oense med den första. De flesta mystiska fel i en design med två gatewayer bor på den sömmen.
ip route get 10.20.30.40
traceroute -n 10.20.30.40
conntrack -L -p tcp --dport 443Skriv ned var VPN-skyddet slutar och var den inre policyn börjar. Om vägen mellan de två enheterna är tillåtande har den andra lådan inte skapat en gräns; den har bara flyttat platsen där en gräns hade kunnat finnas. På en enda plattform kan separata policyzoner fortfarande vara effektiva, och deras effektivitet bör bedömas utifrån reglerna i stället för avvisas för att hårdvaran delas.
Stanna om du inte kan säga vilken enhet som tillämpar regeln som betyder något. Den luckan är fyndet, inte en detalj att avgöra senare.
Inneslutning är en gräns, inte ett chassi
En separat enhet innehåller en kompromiss bara när vägen genom den är begränsad till vad den andra sidan behöver. Om båda enheterna accepterar all trafik från varandra har en angripare som landar på en samma räckvidd som tidigare. Inneslutningspåståendet tillhör regeluppsättningen, inte inventariet. Läs reglerna, säg vilka flöden som är tillåtna och avgör sedan om separeringen köpte något.
Samma logik gäller för användare. En VPN-användare som litas på på grund av nätverket de kom från litar på plats i stället för identitet, och NIST:s nolltillitsvägledning beskriver alternativet: autentisera och auktorisera varje begäran mot resursen. Den principen gäller vilket chassi som än avslutar tunneln.
Om separeringen finns för att uppfylla en efterlevnadslinje i stället för att ändra ett flöde, säg det i posten. En kontroll som ingen kan förklara är den första som tas bort under press.
Återställ det du faktiskt kan nå
Fråga vilken återställningsväg som överlever när någon av de två rollerna dör. När det enda sättet att nå en trasig VPN-gateway går genom den gatewayen hjälper inte en reservenhet någon annanstans administratören som måste reparera den. En väg utanför bandet, en konsol och en dokumenterad återrullning är de delar som gör designen återställbar.
systemctl status strongswan
nft list ruleset
ip -brief addressDimensionera designen för den fulla arbetsbelastning som stöds i stället för ett isolerat krypteringstal, eftersom filtrering och inspektion förbrukar samma hårdvara. Använd leverantörsdokumentation och dina egna mätningar i stället för att anta att separering är snabbare eller långsammare. Skriv sedan beslutsprotokollet: vilka flöden som är tillåtna, vilka beroenden som delas, vad ett underhållsfönster tar ned, vilka kapacitetsbevis du har och vem som äger varje återställningssteg. Den posten är kort nog att granska och specifik nog att återkomma till.
Runbooken slutar när felavtalet är skrivet, vidarebefordringsvägen har en namngiven tillämpningspunkt per regel, inneslutning beskrivs med flöden i stället för enhetsantal, och återställning fungerar från utsidan av den felade komponenten. Välj den enklare ordningen som uppfyller dessa krav.