WireGuard-handshake virker, men kontorets undernet svarer ikke

Handshaket fuldføres, wg show rapporterer nylig overførsel, og serverens tunneladresse svarer på en ping. En vært på serverens LAN gør ikke. Tre betingelser skal være opfyldt samtidig: klienten skal rute LAN-præfikset ind i tunnelen, serveren skal videresende pakkerne, og svaret har brug for en vej tilbage. Når en af de tre mangler, er symptomet identisk.

AllowedIPs er både en adgangsliste og en routingtabel

På klienten afgør listen AllowedIPs både, hvad der må sendes til den peer, og hvilke ruter WireGuard installerer. En peer-post, der kun angiver serverens tunneladresse, installerer én værtsrute, så LAN-destinationer kommer aldrig ind i tunnelen. Tilføjelsen af LAN-præfikset er det første, der skal verificeres, og det er også den ændring, der oftest mangler efter en kopieret konfiguration. En peer udvidet til en standardrute er et andet design, og den flytter også klientens internettrafik.

Hold værtsruten og LAN-præfikset som separate poster. Hvis kontoret har to undernet, hører begge i listen, og det manglende andet præfiks giver en fejl, der ser selektiv ud snarere end total.

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

Videresendelse og oversættelse hører på serveren

Serveren skal have IP-videresendelse aktiveret, en videresendelsesregel, der accepterer trafik fra tunnelen, og en oversættelsesregel mod dens LAN-grænseflade. Det er oversættelsen, der får designet til at virke uden at røre hver vært på kontornettet. Svarene vender så tilbage til serveren i stedet for til en adresse, som LAN'et aldrig har hørt om. Uden den skal hver vært have en rute til tunnelundernettet og en firewallregel, der tillader den, hvilket sjældent er acceptabelt på et netværk, som en anden 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, der tilføjes i hånden, forsvinder ved genstart, så bind dem til grænsefladen med hook-kommandoerne i serverkonfigurationen. Et regelsæt, der overlever sin grænseflade, er hvordan en maskine ender med at oversætte trafik for en tunnel, der ikke længere findes.

Da LAN'et flyttede, og reglen ikke gjorde

Udskiftning af en router, der omnummererer kontorets undernet, er den klassiske version af denne fejl. Tunnelen forbliver oppe, handshaket forbliver friskt, og intet bag serveren svarer, fordi oversættelsesreglen stadig nævner den gamle adresse. Installationsscripts bager ofte serverens LAN-adresse ind i en POSTROUTING-regel, og efter en omnummerering findes den adresse ikke på nogen grænseflade. Pakkerne omskrives derefter til en destination, der ikke kan svare.

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

Sammenlign de to output. Et oversættelsesmål, der ikke vises i grænsefladelisten, er fejlen, og at rette den er en ændring på én linje, når du først har set den. Reglen kan ligge i en genereret unit i stedet for i WireGuard-konfigurationen, så genindlæs den unit efter redigering, og bekræft at næste opstart ikke overskriver din ændring.

To lokationer bag NAT har brug for et sted at mødes

Når ingen af siderne accepterer indgående forbindelser, er det praktiske svar en lille vært med en offentlig adresse og to WireGuard-grænseflader. Hver lokation forbinder udad, mellemværten angiver hver peers LAN i sin egen AllowedIPs, og videresendelse bærer pakker mellem de to tunneler. Intet i nogen af lokationernes firewalls skal ændres, og derfor spredes dette design let.

Routing mellem lokationerne bevarer de oprindelige kildeadresser og bevarer dermed meningsfuld logning per vært. Oversættelse på mellemværten er enklere, når de to LAN'er overlapper, men på bekostning af at kildeidentiteten går tabt i logfilerne. Beslut, hvilken egenskab der betyder noget, før du vælger.

Adskil lagene med fire kontroller

Kør én kontrol per lag i stedet for at ændre tre ting og håbe. Den første viser handshakets alder og tællere for hver peer. Den anden viser, om klienten faktisk ruter den destination ind i tunnelen. Den tredje og fjerde fortæller, om anmodningen nåede frem, og om en politik kasserede den efter ankomsten.

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

En anmodning, der når frem og ikke giver svar, peger på svarvejen eller på LAN-værten. En anmodning, der aldrig når frem, peger på AllowedIPs eller på klientens rute. De to udfald kræver forskellige rettelser, og optagelsen er det, der skelner dem.