Router oder separater Computer als VPN-Server: So wählen Sie

Sowohl ein Router als auch ein kleiner Computer kann ein VPN beenden, und die Entscheidung hängt selten am Durchsatz. Sie hängt daran, wer das Update um zwei Uhr morgens einspielt, was sonst noch stoppt, wenn diese Box neu startet, und ob Sie noch eine Konsole erreichen, wenn ausgerechnet der Tunnel kaputt ist. Beantworten Sie diese drei Fragen für jeden Kandidaten, und die Wahl trifft sich meist von selbst. Das folgende Verfahren macht aus dem Vergleich eine kurze Liste von Dingen, die Sie prüfen können, bevor Sie sich festlegen.

Beginnen Sie mit dem, was weiterlaufen muss, wenn der Tunnel ausfällt

Der Ausfall, für den Sie planen müssen, ist der, bei dem der VPN-Prozess stirbt und Sie trotzdem an den Host müssen. Auf einem Router teilen Tunnel und Internet-Gateway dasselbe Schicksal: Eine schlechte Konfigurationsänderung kann beide ausfallen lassen, und der Weg zurück ist oft ein physischer Reset. Auf einem separaten Computer läuft das Gateway weiter, und der Host bleibt über das LAN erreichbar. Welches dieser Ergebnisse Sie verkraften, entscheidet mehr als jede Funktionsliste.

Schreiben Sie die Antwort als Satz: Wenn der VPN-Host neu startet, was verliert dann der Haushalt oder das Büro? Enthält die Antwort den gesamten Internetzugang, haben Sie eine gemeinsame Fehlerdomäne akzeptiert, und das sollten Sie bewusst sagen, statt es später zu entdecken.

Ein zweiter Dienst auf demselben Gerät ist keine Ersatzkonsole. Er teilt Netzteil, Firmware und Administratorkonto.

Zählen Sie die Wartungsflächen, die jeder Host hinzufügt

Ein Router bringt Herstellerfirmware mit eigenem Release-Rhythmus mit, und die VPN-Funktion ist meist ein Modul in einem viel größeren Image. Ein Computer bringt ein Betriebssystem, einen Paketmanager, einen Kernel und eine Reihe von Diensten mit, die Ihnen jetzt gehören. Beides braucht Patches, und die eigentliche Frage ist, welchen Rhythmus Sie durchhalten, wenn die Neuheit verblasst.

Machen Sie diesen Rhythmus auf einem Linux-Host sichtbar, statt auf ihn zu hoffen. systemctl list-timers zeigt die geplanten Aufträge, und apt list --upgradable zeigt, was wartet. Notieren Sie, welche Updates einen Neustart brauchen, denn ein VPN-Host, der neu startet, ist ein Ausfall, sofern Sie ihn nicht eingeplant haben. Ein Router ohne unbeaufsichtigten Update-Weg braucht stattdessen einen Kalendereintrag, was eine schwächere Kontrolle ist, aber eine ehrliche.

Zählen Sie auch die Konten. Jede zusätzliche Administratoranmeldung auf dem VPN-Host ist ein weiterer Anmeldedatensatz zum Rotieren und ein weiterer Pfad zum Sperren.

Verfolgen Sie den Pfad im privaten Netz, nicht das Etikett auf der Box

Clients ist egal, wo der Server läuft; sie interessiert, ob die geschützten Präfixe erreichbar sind und ob es einen Rückweg gibt. Setzen Sie den Server dorthin, wo das Routing am einfachsten ist, was meist direkt auf das Segment bedeutet, das die Ressourcen hält. Ein Computer hinter dem Router braucht weiterhin eine Portweiterleitung, und die Ressourcen in diesem LAN brauchen weiterhin eine Route zurück in das Tunnel-Subnetz.

Prüfen Sie die Weiterleitung auf dem Host, bevor Sie den Client beschuldigen. sysctl net.ipv4.ip_forward sollte 1 melden, und nft list ruleset oder iptables -S zeigt, ob die Tunnel-Schnittstelle überhaupt weiterleiten darf. Eine fehlende Masquerade-Regel sieht aus Client-Sicht genauso aus wie ein kaputter Tunnel.

Legen Sie auch fest, was der Tunnel nicht erreichen darf. Ein auf dem Router platzierter Server sieht jedes Subnetz, das dieser Router routet, und das ist oft mehr, als die Zugriffsrichtlinie beabsichtigt. Auf einem separaten Host ist dieselbe Isolation eine Firewall-Regel entfernt, und der Schadensradius eines kompromittierten Clients ist kleiner. Die Beschreibung des IPsec-Gateways in RFC 7296 behandelt dies als Routing- und Richtlinienfrage, nicht als Hardwarefrage, und keine der beiden Formen ist per Voreinstellung sicherer, solange die Richtlinie nicht aufgeschrieben ist.

Halten Sie eine Wiederherstellungskonsole bereit, die nicht vom Tunnel abhängt

Die Konsole, mit der Sie das VPN reparieren, darf nicht das VPN selbst sein. Halten Sie eine LAN-Adresse, eine serielle Konsole oder eine Anbieterkonsole bereit, die funktioniert, während der Tunnel liegt, und nutzen Sie sie mindestens einmal, bevor Sie sie brauchen. Ein Out-of-Band-Weg, der nie geübt wurde, ist ein Plan und keine Fähigkeit.

Sichern Sie die Konfiguration an einem Ort, den der Host selbst nicht löschen kann. tar -czf vpn-config-2026-11-03.tar.gz /etc/wireguard /etc/openvpn erfasst die Schlüssel und die Dienstdefinitionen, und die Kopie muss die Maschine verlassen. Nehmen Sie die Firewall-Regeln und das Client-Verzeichnis mit auf, denn Schlüssel ohne Peer-Liste wiederherzustellen ergibt einen Server, dem niemand beitreten kann. Lagern Sie das Archiv dort, wo die Wiederherstellungskonsole es erreicht.

Schreiben Sie den Rückabwicklungsschritt in dieselbe Notiz. Eine Konfigurationsänderung ohne dokumentierte Umkehrung ist eine dauerhafte Änderung, welche Absicht auch immer dahinterstand.

Prüfen Sie die Wahl mit einem Neustart und einem Update

Testen Sie die Anordnung so, wie sie ausfallen wird, nicht so, wie sie an einem guten Tag läuft. Starten Sie den Host neu, spielen Sie ein ausstehendes Update ein und bestätigen Sie, dass der Tunnel ohne manuelle Schritte zurückkommt.

Prüfen Sie nach dem Neustart die drei Dinge, die am häufigsten brechen. systemctl is-active wg-quick@wg0 meldet, ob die Schnittstelle zurückkam, ss -lunp zeigt, ob etwas auf dem Port lauscht, und wg show listet einen Peer mit abgeschlossenem Handshake. Ein Dienst, der aktiv ist, ohne Handshake, bedeutet, dass die Firewall oder die Route falsch ist, nicht der Daemon.

Wiederholen Sie die Prüfung von einem Client in einem anderen Netz als dem, aus dem Sie konfiguriert haben. Übersteht der Tunnel einen Neustart, ein Update und einen Wechsel des Client-Netzes, ist die Hostwahl vorerst geklärt. Wenn nicht, fehlt meist ein dokumentierter Schritt und nicht eine andere Box.