PRIVATE INFRASTRUKTUR / KEINE IDENTITÄT ERFORDERLICHLesen Sie die Datenschutzgrundsätze
Die KoalaVPS-Feldnotizen

Ein privater Tunnel mit klarem Zweck.

WireGuard kann Ihre Geräte mit einem Server oder einem privaten Netzwerk verbinden. Der Nutzen hängt von korrektem Routing, DNS und Endpunktsicherheit ab.

Definieren Sie die Route

Entscheiden Sie, ob der Tunnel nur privaten Dienstverkehr oder den gesamten Internetverkehr führt. Konfigurieren Sie zulässige Routen bewusst und berücksichtigen Sie sowohl IPv4 als auch IPv6. Ein Split-Tunnel- und ein Full-Tunnel-Setup haben unterschiedliche Überlegungen zu Leaks und Erreichbarkeit.

Ein Schlüssel pro Gerät

Generieren Sie private Schlüssel nach Möglichkeit auf dem Gerät und veröffentlichen Sie sie niemals. Verwenden Sie getrennte Peer-Identitäten, damit ein verlorenes Gerät widerrufen werden kann, ohne jeden Client zu ersetzen. Speichern Sie die Serverkonfiguration mit geschützten Berechtigungen.

Weiterleitung und DNS konfigurieren

Legen Sie Weiterleitungs- und Firewall-Regeln bewusst fest. Prüfen Sie Namensauflösung, MTU und den Rückweg. Testen Sie die effektive öffentliche Adresse und das DNS-Verhalten vom Client aus, statt anzunehmen, dass ein erfolgreicher Handshake bedeutet, dass der gesamte Datenverkehr die vorgesehene Route nutzt.

Den Vertrauenswechsel verstehen

Ein selbst gehostetes VPN kann Datenverkehr im lokalen Netzwerk schützen, aber der VPS und Upstream sehen weiterhin Metadaten und unverschlüsselten Datenverkehr. Es macht eine Browsersitzung nicht anonym und hebt die Richtlinien der von Ihnen genutzten Dienste nicht auf.

Verwenden Sie einen expliziten Listener und prüfen Sie den Handshake

UDP 51820 ist eine gängige WireGuard-Konfigurationswahl, keine verpflichtende oder garantierte Host-Richtlinie. Öffnen Sie nur den gewählten UDP-Port und halten Sie die Administration separat eingeschränkt. Der Befehl wg show kann Informationen zu Peer-Handshake und Transfer melden, ohne dass Sie private Schlüssel veröffentlichen müssen.

  • Einen aktuellen Handshake überprüfen
  • Testen Sie den vorgesehenen privaten Dienst
  • Testen Sie Internet- und DNS-Routen nur, wenn ein vollständiger Tunnel beabsichtigt ist
wg show

Verwenden Sie Keepalives nur, wenn das Netzwerk sie benötigt

Ein Peer hinter NAT benötigt möglicherweise regelmäßigen Keepalive-Verkehr, um eine Zuordnung für eingehende Pakete aufrechtzuerhalten. Die passende Einstellung hängt vom Netzwerk ab. Halten Sie die Konfiguration bewusst; kopieren Sie kein Full-Tunnel-Rezept, wenn das Ziel nur der Zugriff auf eine private Anwendung ist.

Wählen Sie Split-Tunnelling oder ein Full-Tunnel-Design

Beginnen Sie mit dem tatsächlichen Ziel. Ein Split-Tunnel kann nur ein privates Subnetz oder einen administrativen Dienst übertragen; ein Full-Tunnel benötigt zusätzlich Internet-Weiterleitung, Egress-Regeln und einen DNS-Plan. Wählen Sie sich nicht überschneidende Tunnel-Adressen und entscheiden Sie, wie IPv6 behandelt wird. UDP51820 ist ein üblicher Port, kein erforderlicher. Bestätigen Sie die Richtlinie des gewählten Hosts und halten Sie den Konsolen-/Administratorzugang verfügbar, während Sie Routen oder Firewall-Regeln ändern.

  • Geben Sie jedem Gerät ein eindeutiges Schlüsselpaar und eine eng begrenzte Peer-Identität.
  • Bewahren Sie private Schlüssel auf den dafür vorgesehenen Geräten auf und nicht in öffentlichen Dateien oder QR-Freigaben.
  • Behandeln Sie öffentliche Endpunkte und das Roaming von Clients als Teil des Netzwerkdesigns.

Richten Sie einen kleinen Tunnel ein, bevor Sie Internet-Routing hinzufügen

Folgen Sie der unterstützten Betriebssysteminstallation und erzeugen Sie Schlüssel mit restriktiven Dateiberechtigungen. Konfigurieren Sie die Server-Schnittstelle, einen Peer und den gewählten UDP-Listener. Ein serverseitiger Peer sollte normalerweise eine eigene Tunneladresse in AllowedIPs haben statt eines überlappenden Catch-All, das mehreren Clients zugewiesen ist. Beginnen Sie mit dem Zugriff auf die Tunneladresse und fügen Sie dann genehmigte Weiterleitungs- und Zielrouten hinzu. Ein erfolgreicher Handshake beweist Peer-Kontakt, nicht dass DNS oder der Internet-Egress korrekt ist.

# Inspection examples; these do not reveal a private key:
wg show
ip address show dev wg0
ip route get 10.44.0.1

Testen Sie den erwarteten Pfad und einen verbotenen Pfad

Verifizieren Sie vom Client aus einen aktuellen Handshake und einen zulässigen privaten Dienst. Versuchen Sie ein Ziel, das abgelehnt werden sollte. Bei einem vollständigen Tunnel prüfen Sie von diesem Client aus die effektive öffentliche Route, den DNS-Resolver und das IPv6-Verhalten; Split-Tunnel-Datenverkehr sollte den vorgesehenen lokalen Pfad beibehalten. Wiederholen Sie dies nach einem Netzwerkwechsel des Clients. Verwenden Sie ein NAT-Keepalive nur, wenn das Netzwerk des Peers es benötigt, und halten Sie das Intervall im Einklang mit dem dokumentierten Design.

  • Kein Handshake: Prüfen Sie Endpunkt DNS, UDP-Erreichbarkeit, Schlüssel und Peer-Zuordnung.
  • Handshake, aber kein Dienst: Prüfen Sie AllowedIPs, Firewall, Weiterleitung und die Rückroute.
  • Manche Seiten stocken: Untersuchen Sie die Pfad-MTU, bevor Sie einen zufälligen dauerhaften Wert anwenden.

Machen Sie Widerruf und Neustartverhalten wiederholbar

Entfernen Sie den Peer-Schlüssel eines verlorenen Geräts und bestätigen Sie, dass es den vorgesehenen Zugriff nicht mehr herstellen kann. Bewahren Sie verschlüsselte Konfigurationssicherungen und ein Verzeichnis auf, das angibt, welcher öffentliche Schlüssel zu welchem Gerät gehört. Testen Sie, ob die Schnittstelle und die erforderlichen Routing-Regeln nach einem normalen Neustart zurückkehren. Ein VPN verlagert das Vertrauen auf den VPS und dessen Upstream; es beseitigt weder Anwendungskennungen noch Konto-Cookies noch die Notwendigkeit von HTTPS zum endgültigen Ziel.

KONFIGURIEREN SIE IHRE INFRASTRUKTUR

Übernehmen Sie die Kontrolle.
Bereitstellen zu Ihren Bedingungen.

Kein Identitätspapierkram. Vollständiger Administratorzugriff. Krypto-native Abrechnung.