Router of aparte computer als je VPN-server: hoe je kiest

Zowel een router als een kleine computer kan een VPN beëindigen, en de keuze draait zelden om doorvoer. Ze draait om wie de update om twee uur ’s nachts toepast, wat er nog meer stopt wanneer dat kastje herstart, en of je nog bij een console kunt komen als juist de tunnel stuk is. Beantwoord die drie vragen voor elke kandidaat en de keuze maakt zich meestal zelf. De procedure hieronder maakt van de vergelijking een korte lijst van dingen die je kunt controleren voordat je je vastlegt.

Begin met wat moet blijven draaien als de tunnel uitvalt

Het falen waarop je moet ontwerpen is dat waarbij het VPN-proces sterft en je toch bij de host moet komen. Op een router delen de tunnel en de internetgateway hetzelfde lot: één slechte configuratiewijziging kan beide onderuit halen, en de weg terug is vaak een fysieke reset. Op een aparte computer blijft de gateway werken en is de host nog bereikbaar via het LAN. Welke van die uitkomsten je kunt verdragen, bepaalt meer dan welke functielijst dan ook.

Schrijf het antwoord als een zin: als de VPN-host herstart, wat verliest het huishouden of het kantoor dan? Als het antwoord al het internetverkeer omvat, heb je een gedeeld foutdomein geaccepteerd en moet je dat bewust zeggen in plaats van het later te ontdekken.

Een tweede dienst op hetzelfde apparaat is geen reserveconsole. Die deelt de voeding, de firmware en het beheerdersaccount.

Tel de onderhoudsoppervlakken die elke host toevoegt

Een router brengt firmware van de fabrikant mee met een eigen release-ritme, en de VPN-functie is meestal één module in een veel groter image. Een computer brengt een besturingssysteem, een pakketbeheerder, een kernel en een set diensten mee die nu van jou zijn. Beide hebben patches nodig, en de echte vraag is welk ritme je volhoudt als de nieuwigheid weg is.

Maak op een Linux-host dat ritme zichtbaar in plaats van erop te hopen. systemctl list-timers toont de geplande taken en apt list --upgradable toont wat er wacht. Noteer welke updates een herstart vereisen, want een VPN-host die herstart is een storing tenzij je die hebt gepland. Een router zonder automatische update-route heeft in plaats daarvan een agenda-item nodig, wat een zwakkere controle is maar een eerlijke.

Tel ook de accounts. Elke extra beheerdersaanmelding op de VPN-host is weer een referentie om te rouleren en weer een pad om in te trekken.

Volg het pad van het privénetwerk, niet het label op het kastje

Clients kan het niet schelen waar de server draait; ze kan het schelen of de beschermde prefixen bereikbaar zijn en of er een terugweg is. Zet de server waar het routeren het eenvoudigst is, wat meestal betekent direct op het segment dat de resources bevat. Een computer achter de router heeft nog steeds port forwarding nodig, en de resources op dat LAN hebben nog steeds een route terug naar het tunnelsubnet nodig.

Controleer forwarding op de host voordat je de client de schuld geeft. sysctl net.ipv4.ip_forward hoort 1 te melden, en nft list ruleset of iptables -S toont of de tunnelinterface überhaupt mag doorsturen. Een ontbrekende masquerade-regel ziet er vanaf de clientkant precies uit als een kapotte tunnel.

Bepaal ook wat de tunnel niet mag bereiken. Een server op de router ziet elk subnet dat die router routeert, en dat is vaak meer dan het toegangsbeleid bedoelt. Op een aparte host is dezelfde isolatie één firewallregel verder, en de schadecirkel van een gecompromitteerde client is kleiner. De beschrijving van de IPsec-gateway in RFC 7296 behandelt dit als een routerings- en beleidsvraag, niet als een hardwarevraag, en geen van beide vormen is standaard veiliger tot het beleid is opgeschreven.

Houd een herstelconsole die niet van de tunnel afhangt

De console waarmee je de VPN repareert, kan niet de VPN zelf zijn. Houd een LAN-adres, een seriële console of een providerconsole die werkt terwijl de tunnel plat ligt, en gebruik die minstens één keer voordat je hem nodig hebt. Een out-of-band-pad dat nooit is geoefend, is een plan en geen vermogen.

Maak een back-up van de configuratie op een plek die de host zelf niet kan wissen. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn legt de sleutels en de servicedefinities vast, en de kopie moet de machine verlaten. Neem de firewallregels en de clientinventaris mee, want sleutels herstellen zonder de peer-lijst levert een server op waar niemand bij kan. Bewaar het archief waar de herstelconsole erbij kan.

Schrijf de terugdraaistap in dezelfde notitie. Een configuratiewijziging zonder gedocumenteerde terugdraai is een blijvende wijziging, wat de bedoeling ook was.

Verifieer de keuze met een herstart en een update

Test de opstelling zoals ze zal falen, niet zoals ze op een goede dag werkt. Herstart de host, pas een wachtende update toe, en bevestig dat de tunnel terugkomt zonder handmatige stappen.

Controleer na de herstart de drie dingen die het vaakst breken. systemctl is-active wg-quick@wg0 meldt of de interface terugkwam, ss -lunp toont of er iets op de poort luistert, en wg show noemt een peer met een voltooide handshake. Een dienst die actief is zonder handshake betekent dat de firewall of de route fout is, niet de daemon.

Herhaal de controle vanaf een client op een ander netwerk dan het netwerk van waaruit je hebt geconfigureerd. Als de tunnel een herstart, een update en een wisseling van clientnetwerk overleeft, is de hostkeuze voorlopig beslecht. Zo niet, dan is het ontbrekende stuk meestal een gedocumenteerde stap en niet een ander kastje.