En WireGuard-tunnel derhjemme kræver en returrute fra LAN'et

Adgang hjemmefra er én privat tjeneste, ikke en anden internetudgang. WireGuard terminerer på en Linux-boks bag routeren, routeren beholder sin nuværende opgave, og laptoppen sender kun hjemmepræfikset gennem tunnelen. Hvilken enhed der videresender, og hvilken der terminerer, er den beslutning, som hver senere regel følger af. Tager du den opdeling forkert, skal du fejlfinde NAT, som du aldrig havde tænkt dig at tilføje.

Beslut hvem der videresender, og hvem der terminerer

Routeren ejer den offentlige indgang: den modtager UDP-pakken og sender den videre til Linux-værten. Den vært ejer WireGuard-lytteren og beslutningen om videresendelse ind i LAN'et. I praksis sender mappingen UDP 51820 til 192.168.50.10, og applikationens egen port forbliver lukket. Adskillelse af rollerne holder firewallen kort.

Skriv adresseplanen, før du opretter interfacet. Router 192.168.50.1, gateway 192.168.50.10, tjeneste 192.168.50.20, tunnel 10.77.0.0/24 med gateway .1 og laptop .2. Tunnelområdet må ikke overlappe et netværk, som laptoppen allerede når, ellers bliver destinationerne tvetydige. Carrier-grade NAT eller en router længere oppe kan blokere indgående adgang, og ingen lokal portvideresendelse reparerer det.

Udveksl nøgler, og dimensionér så AllowedIPs

Opret et separat nøglepar pr. endepunkt, og flyt kun offentlige nøgler gennem en verificeret kanal. Gatewayens peer-post tillader kun laptopens tunnelkilde, fordi hjemme-LAN'et ligger bag gatewayen og ikke bag laptoppen. At sætte LAN'et i den post beskriver en topologi, du ikke har bygget.

[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 er hjemmepræfikset plus gatewayens tunneladresse, aldrig 0.0.0.0/0, så almindelig browsing beholder sin lokale vej. Hold én konfigurationsejer, og sæt aldrig det samme interface på en anden netværkshåndtering.

Returruten er den del, folk springer over

Dette design beholder laptopens 10.77.0.2-kilde i stedet for at maskere den som gatewayen, så hjemmets enheder skal vide, hvordan de svarer den. Tilføj en statisk rute på hjemmerouteren for 10.77.0.0/24 med 192.168.50.10 som næste hop, og læs, hvad wg-quick udleder af AllowedIPs i sin reference. Uden den rute findes et fuldført håndtryk sammen med applikationssvar, der aldrig ankommer.

Kan routeren ikke bære den rute, så vælg et dokumenteret returdesign. At tilføje NAT i det stille ændrer i stedet den kildemodel, du netop har skrevet ned.

Tillad én tjeneste, ikke undernettet

Aktivér IPv4-videresendelse på gatewayen, og hold tre firewallopgaver adskilt: optag WireGuard-lytteren, videresend laptopens kilde kun til 192.168.50.20, og lad resten af hjemmenetværket være lukket for den peer. Integrér reglerne i den firewallhåndtering, der allerede bruges, i stedet for at skylle den. En rute for hele hjemmepræfikset er ikke tilladelse til at bruge hver enhed indeni.

Applikationens egen godkendelse og værtens firewall er en separat port. Navngiv den tjeneste, regelsættet tillader, så den næste anmelder kan kontrollere den mod den tilsigtede opgave.

Test udefra, og udfas derefter rent

Start profilerne gennem deres ejer, bekræft håndtrykket, og afprøv derefter den tilsigtede applikation fra et godkendt eksternt netværk, og kontrollér svaret. Forsøg en hjemmetjeneste, der skal forblive afvist, for en tilladende regel er usynlig, indtil noget bruger den. Brug til HTTPS navnet på certifikatet, og lad valideringen køre; at taste den rå adresse og klikke gennem advarslen beviser intet om vejen. PersistentKeepalive er valgfrit: det hjælper en NAT-bundet peer efter ledig tid, men det er ikke en manglende rute eller en tilladelsesrettelse.

En dynamisk offentlig adresse kræver DNS-opdateringer, og laptoppen skal opløse sit endepunkt igen efter en ændring; nye DNS-poster flytter ikke et konfigureret endepunkt. Udfas laptoppen ved at fjerne dens peer fra den gemte og aktive konfiguration; at slette selve laptopprofilen tilbagekalder ikke gatewayens autorisation.