WireGuard-håndtrykket virker, men kontorets subnett svarer ikke

Håndtrykket fullføres, wg show rapporterer nylig overføring, og serverens tunneladresse svarer på en ping. En vert på serverens LAN gjør det ikke. Tre betingelser må gjelde samtidig: klienten må rute LAN-prefikset inn i tunnelen, serveren må videresende pakkene, og svaret trenger en vei tilbake. Når én av de tre mangler, er symptomet identisk.

AllowedIPs er både en tilgangsliste og en rutetabell

På klienten avgjør listen AllowedIPs både hva som kan sendes til den peeren, og hvilke ruter WireGuard installerer. En peer-oppføring som bare lister serverens tunneladresse, installerer én vertsrute, så LAN-destinasjoner kommer aldri inn i tunnelen. Å legge til LAN-prefikset er det første som må verifiseres, og det er også endringen som oftest mangler etter en kopiert konfigurasjon. En peer utvidet til en standardrute er et annet design, og den flytter også klientens internettrafikk.

Hold vertsruten og LAN-prefikset som separate oppføringer. Hvis kontoret har to subnett, hører begge til i listen, og det manglende andre prefikset gir en feil som ser selektiv ut snarere enn total.

[Peer]
PublicKey = <server public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.66.0.1/32, 192.168.50.0/24

Videresending og oversetting hører hjemme på serveren

Serveren trenger IP-videresending aktivert, en videresendingsregel som godtar trafikk fra tunnelen, og en oversettingsregel mot LAN-grensesnittet sitt. Det er oversettingen som får designet til å virke uten å røre hver vert på kontornettet. Svarene går da tilbake til serveren i stedet for til en adresse LAN-et aldri har hørt om. Uten den trenger hver vert en rute til tunnel-subnettet og en brannmurregel som tillater den, noe som sjelden er akseptabelt på et nettverk noen andre administrerer.

sysctl -w net.ipv4.ip_forward=1
iptables -A FORWARD -i wg0 -j ACCEPT
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Regler som legges til manuelt, forsvinner ved omstart, så bind dem til grensesnittet med hook-kommandoene i serverkonfigurasjonen. Et regelsett som overlever grensesnittet sitt, er hvordan en maskin ender opp med å oversette trafikk for en tunnel som ikke lenger finnes.

Da LAN-et flyttet, og regelen ikke gjorde det

Utskifting av en ruter som omnummererer kontorets subnett, er den klassiske versjonen av denne feilen. Tunnelen holder seg oppe, håndtrykket holder seg ferskt, og ingenting bak serveren svarer, fordi oversettingsregelen fortsatt nevner den gamle adressen. Installasjonsskript legger ofte serverens LAN-adresse inn i en POSTROUTING-regel, og etter en omnummerering finnes ikke den adressen på noe grensesnitt. Pakkene skrives da om til en destinasjon som ikke kan svare.

iptables -t nat -n -L POSTROUTING
ip -br addr show

Sammenlign de to utdataene. Et oversettingsmål som ikke vises i grensesnittlisten, er feilen, og å rette den er en endring på én linje når du først har sett den. Regelen kan ligge i en generert unit i stedet for i WireGuard-konfigurasjonen, så last den uniten på nytt etter redigering og bekreft at neste oppstart ikke skriver over endringen din.

To nettsteder bak NAT trenger et sted å møtes

Når ingen av sidene godtar innkommende tilkoblinger, er det praktiske svaret en liten vert med en offentlig adresse og to WireGuard-grensesnitt. Hvert nettsted kobler seg utover, den midtre verten lister LAN-et til hver peer i sitt eget AllowedIPs, og videresending bærer pakker mellom de to tunnelene. Ingenting i brannmuren til noen av nettstedene må endres, og derfor sprer dette designet seg lett.

Ruting mellom nettstedene beholder de opprinnelige kildeadressene og holder dermed logging per vert meningsfull. Oversetting på den midtre verten er enklere når de to LAN-ene overlapper, men på bekostning av å miste kildeidentiteten i loggene. Bestem hvilken egenskap som betyr noe før du velger.

Skill lagene med fire kontroller

Kjør én kontroll per lag i stedet for å endre tre ting og håpe. Den første viser håndtrykkets alder og tellere for hver peer. Den andre viser om klienten faktisk ruter den destinasjonen inn i tunnelen. Den tredje og fjerde forteller om forespørselen kom frem, og om en policy slapp den etter ankomst.

wg show
ip route get 192.168.50.20
tcpdump -ni wg0 icmp
iptables -vnL FORWARD --line-numbers

En forespørsel som kommer frem og ikke gir svar, peker på svarveien eller på LAN-verten. En forespørsel som aldri kommer frem, peker på AllowedIPs eller på klientens rute. Disse to utfallene trenger ulike rettelser, og opptaket er det som skiller dem.