Was ein VPS zulassen muss, bevor er dein VPN hosten kann

Die Instanz startet, Paketinstallationen gelingen, und der Dienst meldet sogar einen laufenden Zustand, doch nichts verbindet sich. Dieses Muster ist auf virtuellen privaten Servern verbreitet, denn ein Gast, der bequem ins Internet kommt, kann trotzdem unfähig sein, die Schnittstelle zu erzeugen, die dein Protokoll verlangt. Fünf Prüfungen trennen einen Host, der einen Tunnel bedienen kann, von einem, der nur bereit aussieht, und die erste fehlschlagende Prüfung erklärt meist alles danach. Jede ist billig auszuführen und endet in einer Entscheidung statt in einer Notiz.

Bestätige die Schnittstelle, die das Protokoll braucht

OpenVPN über TUN braucht das Zeichengerät und das Kernelmodul dahinter; WireGuard braucht eigene Kernel-Unterstützung oder eine Userspace-Implementierung mit passenden Erwartungen. Verwaltete Container teilen sich womöglich einen Host-Kernel, der das Gerät nie freigibt, und manche Plattformen verbieten das Anlegen von Tunnelschnittstellen grundsätzlich, unabhängig davon, was installiert ist.

Prüfe die Fähigkeit, statt eine Support-Seite zu lesen, denn Marketingbezeichnungen ändern sich schneller als die zugrunde liegenden Grenzen. Eine Funktionsliste für einen Tarif beschreibt vielleicht nicht den Kernel, auf dem der Gast tatsächlich läuft. Zwei kurze Befehle beantworten die Frage für die gängigen Protokolle, und beide räumen hinter sich auf. Die Befehle unten erzeugen nichts Dauerhaftes und werden sofort entfernt.

sudo ip tuntap add dev tun9 mode tun
sudo ip tuntap del dev tun9 mode tun
sudo ip link add wgtest type wireguard && sudo ip link del wgtest

Eine Ablehnung beim ersten Paar bedeutet, dass TUN nicht verfügbar ist und der Standardmodus von OpenVPN nicht starten kann; eine Ablehnung in der letzten Zeile bedeutet, dass die WireGuard-Kernelschnittstelle fehlt. Die Kernel-Dokumentation zu TUN/TAP beschreibt das Gerät, das die erste Prüfung ausübt. Keiner der beiden Fehler wird durch Neuinstallation des VPN-Pakets behoben.

Denk daran: Der eingehende Weg hat zwei Eigentümer

Netzwerkregeln des Anbieters und die Firewall des Gastes sind getrennte Systeme, und der Verkehr muss beide überstehen. Ein auf dem Gast gebundener Listener bedeutet nichts, wenn die Sicherheitsgruppe des Anbieters den Port verwirft, und eine offene Anbieterregel bewirkt nichts, wenn der Gast das Paket ablehnt. Prüfe den Listener, dann die Gastregeln, dann das Anbieterpanel, in dieser Reihenfolge, und bestätige sowohl das Protokoll als auch die Portnummer. Direkt zum Anbieterpanel zu springen ist der Weg, auf dem Leute einen Bereich öffnen, den sie nicht brauchten.

UDP ist das übliche Opfer: Viele Plattformen erlauben TCP standardmäßig und behandeln UDP-Regeln als separaten Eintrag. Steht die Instanz hinter dem NAT des Anbieters statt eine öffentliche Adresse zu halten, wird Portweiterleitung auf Anbieterseite zu einer dritten Konfiguration, die abgestimmt werden muss.

Plane den Rückweg, nicht nur den Ausgang

Volltunnel-Dienst braucht aktivierte Weiterleitung, ein Übersetzungs- oder Routing-Schema für Client-Verkehr und einen Rückweg, der den Client-Pool erreicht. Einen Listener zu öffnen liefert nichts davon. Ein Tunnel, der sich aufbaut, aber keinen nützlichen Verkehr trägt, scheitert meist hier statt bei der Authentifizierung. Behandle einen erfolgreichen Handshake als Beginn der Diagnose, nicht als ihr Ende.

Schreib den Plan als drei konkrete Entscheidungen: welchen Quellbereich Clients erhalten, wie ihr Verkehr ins Internet hinausgeht und wie Antworten zurückfinden. Bestätige dann, dass der Kernel dem Plan zustimmt, bevor du einen Client testest, damit eine stille Abweichung nicht für einen clientseitigen Fehler gehalten wird.

sysctl -n net.ipv4.ip_forward
sudo nft list ruleset | head -n 40
ip -4 route show default

Entscheide die IPv6-Frage ausdrücklich

IPv6 kommt über mehrere Mechanismen, die sich für ein Gateway unterschiedlich verhalten: eine Adresse auf der Instanz, ein geroutetes Präfix oder gar nichts. Nur ein geroutetes Präfix erlaubt dem Server, Clients Adressen auf die übliche Weise zu geben. Anzunehmen, eine funktionierende IPv6-Adresse auf dem Host bedeute ein nutzbares Client-Präfix, ist ein Fehler, der später als halb kaputte Konnektivität auftaucht. Es ist die Art von Fehler, die jeden nur mit IPv4 durchgeführten Test übersteht.

Wenn der Anbieter kein Präfix routet, entscheide, ob der Tunnel nur IPv4 ist und ob Clients das erfahren sollen. Eine dokumentierte Abwesenheit ist sicherer als eine Teilkonfiguration, die IPv6-Ziele für verbundene Nutzer still ins schwarze Loch schickt.

Beweise es von einem externen Client

Lokaler Dienststatus beschreibt einen Prozess auf einem Host. Der nützliche Test ist ein autorisierter Client in einem anderen Netz, der sich mit dem Profil verbindet, das du verteilen willst, dann eine Anwendung erreicht und einen Namen auflöst. Verbinde dich auch einmal neu, denn ein Tunnel, der nur beim ersten Versuch funktioniert, verfehlt die Anforderung, die in der Praxis am meisten zählt.

sudo wg show wg0 latest-handshakes
ip -4 route get 203.0.113.44
sudo journalctl -u wg-quick@wg0 -n 15 --no-pager

Halte die betrieblichen Grundlagen neben dem Test: Platz für Aktualisierungen, begrenzte Logs, administrativen Zugang, der nicht vom Tunnel abhängt, eine Wiederherstellungskonsole und eine Notiz dazu, was mit Client-Profilen passiert, wenn die Instanz neu aufgebaut wird und sich ihre öffentliche Adresse ändert. Ist eine erforderliche Schnittstelle oder ein Weiterleitungsmodell schlicht nicht verfügbar, schafft keine clientseitige Änderung sie herbei, und der ehrliche nächste Schritt ist ein anderer Instanztyp statt mehr Konfiguration.