Heim-VPN-Server gegen Cloud-Server: Welcher erreicht dein NAS?
Der Tunnel steht, aber das Heim-NAS bleibt unerreichbar. Wähle den Endpunkt-Standort nach der Ressource, die du erreichen musst, und prüfe dann die Route.
Der Tunnel steht, der Client zeigt einen grünen Punkt, und ssh 192.168.1.20 hängt weiter, bis er in einen Timeout läuft. Genau das erlebte ich, nachdem ich eine kleine Cloud-Instanz gemietet und WireGuard darauf installiert hatte: Handshake gut, DNS gut, und das NAS auf meinem Schreibtisch so unerreichbar, als stünde es auf dem Mond. Am Tunnel war nichts falsch. Der Endpunkt stand in einem Netz ohne Route zu meinem Haus. Der Endpunkt-Standort entscheidet, welche Netze benachbart sind, also wähle ihn nach der Ressource, die du zuerst erreichen musst, und vergleiche das Hosting danach.
Ein Tunnel erreicht nur Netze, die der Endpunkt routen kann
Ein VPN gibt deinem Client eine Adresse innerhalb der Routing-Domäne des Endpunkts. Wenn der Client ein Paket an 192.168.1.20 schickt, muss der Endpunkt wissen, wohin es geht. Die Tabelle einer Cloud-VM kennt die VPC-Subnetze des Anbieters; von deinem LAN hat sie nie gehört. Verbunden und erreichbar sind zwei verschiedene Fakten, und der meiste Wirrwarr zwischen Heim und Cloud entsteht, weil man das Erste als Beweis für das Zweite nimmt.
Ein Befehl klärt es. Auf dem Endpunkt ip route get 192.168.1.20 nennt entweder ein LAN-Interface oder zeigt auf die Standardroute. Auf einer Heimbox ist die Antwort die LAN-Seite. Auf einer Cloud-Instanz verlässt das Paket Richtung Internet und stirbt. Das Einschalten von net.ipv4.ip_forward=1 und eine MASQUERADE-Regel ändern daran nichts, denn es gibt nichts weiterzuleiten, bis auf der Heimseite etwas einen Link in die Cloud beendet.
Der Heimfall hat eine zweite Hälfte: den Rückweg. Pakete, die das LAN durch die Tunnelbox verlassen, werden NATet, oder das LAN braucht eine statische Route zurück ins Tunnel-Subnetz. Wenn nur eine Richtung funktioniert, prüfe sysctl net.ipv4.conf.all.rp_filter. Strikte Reverse-Path-Filterung verwirft Antworten, die auf einer anderen Schnittstelle ankommen als die Route vorhersagt, und das Symptom sieht genau wie eine Firewall-Regel aus.
Lies das Symptom, bevor du die Konfiguration anfasst
Tunnel baut nicht auf: Schlüssel, Endpunktadresse oder ein blockierter UDP-Port. Tunnel steht, aber LAN-Hosts tot: Platzierung und Routing. Tunnel steht, aber Surfen tot: Weiterleitung, NAT oder DNS. Das sind drei Schichten und drei verschiedene Prüfungen, und eine bereits korrekte Konfiguration neu zu schreiben kostet einen Abend.
| Symptom | First suspect | Check |
|---|---|---|
| Handshake fails, no transfer | Keys, endpoint port, UDP blocked | wg show, then the port from outside |
| Peer pings, LAN host times out | No route to the LAN | ip route get on the endpoint |
| Tunnel up, name resolution fails | DNS options in the peer config | Resolve a name from the client |
| Large transfers reset the connection | MTU | Lower the tunnel MTU and retry |
Eingehende Erreichbarkeit von zu Hause verdient eine eigene Prüfung, denn sie entscheidet, ob Hosting zu Hause überhaupt möglich ist. Vergleiche die WAN-Adresse, die dein Router meldet, mit der Adresse, die ein externer Host sieht. Liegt sie in 100.64.0.0/10 oder widersprechen sich beide, sitzt du hinter Carrier-Grade-NAT und keine Portweiterleitung wird je funktionieren. Die echten Optionen sind ein Relay, eine Cloud-Verbindung, die von zu Hause nach außen wählt, oder den Endpunkt zu verschieben.
Was Hosting zu Hause bringt und was es kostet
Zuhause ist der einzige Standort, der standardmäßig im LAN liegt, und das ist der ganze Grund, dort einen Server hinzustellen. Geräte, die nur im lokalen Segment antworten, wie Drucker und NAS-Adminseiten, die nicht-lokale Subnetze ablehnen, funktionieren ohne zusätzliches Routing. Du betreibst außerdem Maschine, Router und Uplink selbst.
Die Kosten sind physisch. Heim-Upload ist die Obergrenze für alle Clients gleichzeitig, also konkurrieren Videoanruf und Backup um dieselbe Leitung. Strom, Diskverschleiß, Patches, eine dynamische Adresse, die DDNS braucht, ein Router, der UDP nach innen weiterleiten muss, und womöglich doppeltes NAT landen alles bei dir. Was Leute überspringen, ist die Wiederherstellung: Stirbt die Box, während du weg bist, stirbt dein einziger Weg ins Haus mit ihr. Halte ein zweites Gerät mit denselben Schlüsseln bereit oder zumindest einen Plan für physischen Zugang.
Willst du LAN-Zugang ohne die Box zu Hause, baue eine Verbindung, statt es vorzutäuschen. Der Cloud-Endpunkt wird zum Router: ein Tunnel von der Heimseite mit AllowedIPs = 192.168.1.0/24 am Cloud-Peer, plus Weiterleitung und NAT auf der Cloud-Box. strongSwans Weiterleitungs-Anleitung geht die Rückweg-Hälfte dieser Einrichtung durch, und dort scheitern die meisten dieser Versuche. Der Heim-Peer muss jetzt laufen, damit irgendetwas funktioniert, also hast du eine Abhängigkeit gegen eine andere getauscht und solltest das aufschreiben.
Wofür ein Cloud-Endpunkt wirklich da ist
Ein Cloud-Endpunkt ändert deinen öffentlichen Ausgang. Der Verkehr verlässt den Adressbereich des Anbieters, und Websites sehen diese Adresse statt deiner Heimadresse. Das ist der Wert, und deshalb gibt dir ein Cloud-VPN nicht das NAS: Du hast den Ausgang verschoben, nicht das LAN.
Du betreibst weiterhin das Gastsystem, den VPN-Dienst und dessen Zugangsdaten, während der Anbieter den Hypervisor und das physische Netz betreibt, und diese Aufteilung zählt, wenn um 2 Uhr nachts etwas kaputtgeht. Ein öffentlicher Endpunkt wird laufend gescannt, also halte den Verwaltungsport geschlossen, erlaube nur den VPN-Port und patche nach Plan. Sicherheitsgruppen und Anbieter-Firewalls müssen diesen Port zulassen, und manche Clouds verwerfen weitergeleiteten Verkehr, solange du die Quell- und Zielprüfung auf der Instanz nicht anpasst.
Eine kleine Instanz deckt eine Handvoll Clients ab, aber Verschlüsselung ist CPU-Arbeit, und eine Burstable-Instanz, der die Credits ausgehen, verhält sich unter Dauerlast ungleichmäßig. Schau auf den Weg, den du tatsächlich nutzt, statt auf das Datenblatt.
Eine Entscheidung, die du aufschreiben kannst
Die Aufgabe entscheidet über den Standort, nicht das Etikett auf der Box. Brauchst du ein Gerät in deinem Heim-LAN, ist die billigste richtige Antwort ein Endpunkt zu Hause; eine Cloud-Box funktioniert erst, nachdem du den Rückweg gebaut hast. Brauchst du einen anderen öffentlichen Ausgang, ist Cloud die Antwort und die LAN-Frage stellt sich nie. Beides zu wollen ist legitim, bedeutet aber zwei Endpunkte, zwei Schlüsselsätze und zwei dokumentierte Routen.
| What you need | Endpoint location | What else must exist |
|---|---|---|
| Reach a NAS or printer on the home LAN | A box on that LAN | Port forward or relay, DDNS, recovery plan |
| Browse from an exit unrelated to home | Cloud instance | Firewall and egress rules, patching |
| Both, reliably | Two endpoints, or cloud plus a link home | Separate keys, routes, documented failure modes |
Prüfe vom Client aus der Reihe nach: Handshake, Peer-Adresse, ein LAN-Host, dann die Ausgangs-IP. curl -s https://ifconfig.me zeigt, was das Internet sieht, und ip route get 192.168.1.20 zeigt, was der Endpunkt glaubt. Wenn die Ausgangsprüfung besteht und die NAS-Prüfung hängt, hast du deine Antwort zur Platzierung schon; AllowedIPs am Client anzupassen zaubert keine Route. Eine geteilte Zeile wie 10.8.0.0/24, 192.168.1.0/24 hält LAN-Verkehr nur dann im Tunnel, wenn diese Route wirklich existiert.