Ein WireGuard-Tunnel nach Hause braucht eine Rückroute aus dem LAN
Der Handshake ist der leichte Teil. Legen Sie die Arbeitsteilung zwischen Router und Gateway fest, lassen Sie die Quelle des Laptops unangetastet und geben Sie dem LAN eine Rückroute.
Der Heimzugriff ist ein einzelner privater Dienst, kein zweiter Internetausgang. WireGuard endet auf einer Linux-Kiste hinter dem Router, der Router behält seine bisherige Aufgabe, und der Laptop schickt nur das Heimpräfix durch den Tunnel. Welches Gerät weiterleitet und welches terminiert, ist die Entscheidung, aus der jede spätere Regel folgt. Geht diese Aufteilung schief, debuggen Sie NAT, das Sie nie einführen wollten.
Entscheiden Sie, wer weiterleitet und wer terminiert
Der Router besitzt den öffentlichen Einstieg: Er nimmt das UDP-Paket an und reicht es an den Linux-Host weiter. Dieser Host besitzt den WireGuard-Listener und die Weiterleitungsentscheidung ins LAN. In der Praxis schickt das Mapping UDP 51820 an 192.168.50.10, und der eigene Port der Anwendung bleibt geschlossen. Getrennte Rollen halten die Firewall kurz.
Schreiben Sie den Adressplan, bevor Sie das Interface anlegen. Router 192.168.50.1, Gateway 192.168.50.10, Dienst 192.168.50.20, Tunnel 10.77.0.0/24 mit Gateway .1 und Laptop .2. Der Tunnelbereich darf sich nicht mit einem Netz überschneiden, das der Laptop bereits erreicht, sonst werden Ziele mehrdeutig. Carrier-Grade-NAT oder ein vorgeschalteter Router kann eingehenden Zugriff blockieren, und keine lokale Portweiterleitung repariert das.
Tauschen Sie Schlüssel, dann dimensionieren Sie die AllowedIPs
Erzeugen Sie ein eigenes Schlüsselpaar pro Endpunkt und bewegen Sie nur öffentliche Schlüssel über einen verifizierten Kanal. Der Peer-Eintrag des Gateways erlaubt allein die Tunnelquelle des Laptops, weil das Heim-LAN hinter dem Gateway und nicht hinter dem Laptop liegt. Das LAN in diesen Eintrag zu schreiben, beschreibt eine Topologie, die Sie nicht gebaut haben.
[Interface]
Address = 10.77.0.2/32
PrivateKey = LAPTOP_PRIVATE_KEY_BASE64
[Peer]
PublicKey = HOME_PUBLIC_KEY_BASE64
Endpoint = home-vpn.example.com:51820
AllowedIPs = 192.168.50.0/24, 10.77.0.1/32AllowedIPs ist das Heimpräfix plus die Tunneladresse des Gateways, nie 0.0.0.0/0, damit gewöhnliches Surfen seinen lokalen Weg behält. Halten Sie einen Konfigurationseigentümer, und hängen Sie dasselbe Interface nie an einen zweiten Netzwerkmanager.
Die Rückroute ist der Teil, den Leute auslassen
Dieses Design behält die Quelle 10.77.0.2 des Laptops, statt sie als Gateway zu maskieren, also müssen Heimgeräte wissen, wie sie antworten. Fügen Sie am Heimrouter eine statische Route für 10.77.0.0/24 mit 192.168.50.10 als nächstem Hop hinzu, und lesen Sie, was wg-quick in seiner Referenz aus AllowedIPs ableitet. Ohne diese Route existiert ein abgeschlossener Handshake neben Anwendungsantworten, die nie ankommen.
Kann der Router diese Route nicht tragen, wählen Sie ein dokumentiertes Rückdesign. Still NAT hinzuzufügen ändert stattdessen das Quellmodell, das Sie gerade aufgeschrieben haben.
Erlauben Sie einen Dienst, nicht das Subnetz
Aktivieren Sie IPv4-Weiterleitung am Gateway und halten Sie drei Firewall-Aufgaben getrennt: den WireGuard-Listener zulassen, die Laptop-Quelle nur an 192.168.50.20 weiterleiten und den Rest des Heimnetzes für diesen Peer geschlossen lassen. Binden Sie die Regeln in den bereits genutzten Firewall-Manager ein, statt ihn zu leeren. Eine Route für das ganze Heimpräfix ist keine Erlaubnis, jedes Gerät darin zu nutzen.
Die eigene Authentifizierung der Anwendung und die Host-Firewall sind ein separates Tor. Benennen Sie den Dienst, den das Regelset erlaubt, damit der nächste Prüfer ihn gegen die beabsichtigte Aufgabe prüfen kann.
Testen Sie von außen und ziehen Sie dann sauber zurück
Bringen Sie die Profile über ihren Eigentümer hoch, bestätigen Sie den Handshake, und üben Sie dann die beabsichtigte Anwendung aus einem freigegebenen externen Netz und prüfen Sie die Antwort. Versuchen Sie einen Heimprozess, der verweigert bleiben muss, denn eine großzügige Regel ist unsichtbar, bis etwas sie nutzt. Nutzen Sie für HTTPS den Namen im Zertifikat und lassen Sie die Validierung laufen; die Rohadresse zu tippen und durch die Warnung zu klicken beweist nichts über den Pfad. PersistentKeepalive ist optional: Es hilft einem NAT-gebundenen Peer nach Leerlauf, aber es ist keine fehlende Route und keine Berechtigungskorrektur.
Eine dynamische öffentliche Adresse braucht DNS-Aktualisierungen, und der Laptop muss seinen Endpunkt nach einer Änderung neu auflösen; neue DNS-Einträge verschieben keinen konfigurierten Endpunkt. Ziehen Sie den Laptop zurück, indem Sie seinen Peer aus der gespeicherten und der aktiven Konfiguration entfernen; nur das Laptop-Profil zu löschen widerruft die Autorisierung des Gateways nicht.