En WireGuard-tunnel hemifrån behöver en returväg från LAN-et

Handskakningen är den lätta delen. Bestäm arbetsfördelningen mellan router och gateway, håll laptopens källa intakt och ge LAN-et en returväg.

Åtkomst hemifrån är en enda privat tjänst, inte en andra internetutgång. WireGuard terminerar på en Linux-burk bakom routern, routern behåller sitt nuvarande jobb och laptopen skickar bara hemprefixet genom tunneln. Vilken enhet som vidarebefordrar och vilken som terminerar är det beslut som varje senare regel följer av. Tar du den uppdelningen fel kommer du felsöka NAT som du aldrig tänkt lägga till.

Bestäm vem som vidarebefordrar och vem som terminerar

Routern äger den publika ingången: den tar emot UDP-paketet och skickar det vidare till Linux-värden. Den värden äger WireGuard-lyssnaren och beslutet att vidarebefordra in i LAN-et. I praktiken skickar mappningen UDP 51820 till 192.168.50.10, och applikationens egen port förblir stängd. Att hålla rollerna åtskilda håller brandväggen kort.

Skriv adressplanen innan du skapar gränssnittet. Router 192.168.50.1, gateway 192.168.50.10, tjänst 192.168.50.20, tunnel 10.77.0.0/24 med gateway .1 och laptop .2. Tunnelns intervall får inte överlappa ett nätverk som laptopen redan når, annars blir destinationerna tvetydiga. Carrier-grade NAT eller en router högre upp kan blockera inkommande åtkomst, och ingen lokal portvidarebefordran reparerar det.

Byt nycklar och dimensionera sedan AllowedIPs

Skapa ett separat nyckelpar per ändpunkt och flytta bara publika nycklar genom en verifierad kanal. Gatewayens peer-post tillåter bara laptopens tunnelkälla, eftersom hemma-LAN-et ligger bakom gatewayen och inte bakom laptopen. Att sätta LAN-et i den posten beskriver en topologi du inte har byggt.

[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/32

AllowedIPs är hemprefixet plus gatewayens tunneladress, aldrig 0.0.0.0/0, så vanligt surfande behåller sin lokala väg. Håll en konfigurationseägare och koppla aldrig samma gränssnitt till en andra nätverkshanterare.

Returvägen är den del folk hoppar över

Den här designen behåller laptopens 10.77.0.2-källa i stället för att maskera den som gatewayen, så hemmaenheterna måste veta hur de svarar den. Lägg till en statisk väg på hemmaroutern för 10.77.0.0/24 med 192.168.50.10 som nästa hopp, och läs vad wg-quick härleder från AllowedIPs i sin referens. Utan den vägen finns en slutförd handskakning vid sidan av applikationssvar som aldrig kommer fram.

Klarar routern inte att bära den vägen, välj en dokumenterad returdesign. Att tyst lägga till NAT ändrar i stället den källmodell du just skrev ner.

Tillåt en tjänst, inte subnätet

Slå på IPv4-vidarebefordran på gatewayen och håll tre brandväggsuppgifter åtskilda: släpp in WireGuard-lyssnaren, vidarebefordra laptopens källa bara till 192.168.50.20 och låt resten av hemmanätverket vara stängt för den peeren. Integrera reglerna i brandväggshanteraren som redan används i stället för att tömma den. En väg för hela hemprefixet är inte tillstånd att använda varje enhet inuti.

Applikationens egen autentisering och värdenens brandvägg är en egen port. Namnge tjänsten som regeluppsättningen tillåter, så att nästa granskare kan kontrollera den mot den avsedda uppgiften.

Testa utifrån och dra sedan tillbaka rent

Ta upp profilerna via deras ägare, bekräfta handskakningen och öva sedan den avsedda applikationen från ett godkänt externt nätverk och kontrollera svaret. Försök med en hemmetjänst som måste förbli nekad, för en tillåtande regel är osynlig tills något använder den. Använd för HTTPS namnet på certifikatet och låt valideringen köra; att skriva den rå adressen och klicka igenom varningen bevisar ingenting om vägen. PersistentKeepalive är valfritt: det hjälper en NAT-bunden peer efter ledig tid, men det är inte en saknad väg eller en behörighetsrättning.

En dynamisk publik adress kräver DNS-uppdateringar, och laptopen måste lösa sin ändpunkt igen efter en ändring; nya DNS-poster flyttar inte en konfigurerad ändpunkt. Dra tillbaka laptopen genom att ta bort dess peer från den sparade och aktiva konfigurationen; att bara radera laptopprofilen återkallar inte gatewayens auktorisering.

Relaterade artiklar