WireGuard-handskakningen fungerar, men kontorets subnät svarar inte

Handskakningen slutförs, wg show rapporterar nylig överföring, och serverns tunneladress svarar på en ping. En värd på serverns LAN gör det inte. Tre villkor måste gälla samtidigt: klienten måste routa LAN-prefixet in i tunneln, servern måste vidarebefordra paketen, och svaret behöver en väg tillbaka. När en av de tre saknas är symptomet identiskt.

AllowedIPs är både en åtkomstlista och en routingtabell

På klienten avgör listan AllowedIPs både vad som får skickas till den peeren och vilka rutter WireGuard installerar. En peer-post som bara listar serverns tunneladress installerar en enda värdrutt, så LAN-destinationer kommer aldrig in i tunneln. Att lägga till LAN-prefixet är det första som måste verifieras, och det är också den ändring som oftast saknas efter en kopierad konfiguration. En peer som utökats till en standardrutt är en annan design, och den flyttar även klientens internettrafik.

Håll värdrutten och LAN-prefixet som separata poster. Om kontoret har två subnät hör båda till i listan, och det saknade andra prefixet ger ett fel som ser selektivt ut snarare än totalt.

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

Vidarebefordran och översättning hör hemma på servern

Servern behöver IP-vidarebefordran aktiverad, en vidarebefordringsregel som accepterar trafik från tunneln, och en översättningsregel mot dess LAN-gränssnitt. Det är översättningen som får designen att fungera utan att röra varje värd på kontorsnätet. Svaren går då tillbaka till servern i stället för till en adress som LAN:et aldrig hört talas om. Utan den behöver varje värd en rutt till tunnelns subnät och en brandväggsregel som tillåter den, vilket sällan är acceptabelt på ett nätverk som någon annan administrerar.

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 läggs till manuellt försvinner vid omstart, så bind dem till gränssnittet med hook-kommandona i serverkonfigurationen. En regeluppsättning som överlever sitt gränssnitt är hur en maskin till slut översätter trafik för en tunnel som inte längre finns.

När LAN:et flyttade och regeln inte gjorde det

Utbyte av en router som numrerar om kontorets subnät är den klassiska versionen av detta fel. Tunneln förblir uppe, handskakningen förblir färsk, och inget bakom servern svarar, eftersom översättningsregeln fortfarande anger den gamla adressen. Installationsskript bakar ofta in serverns LAN-adress i en POSTROUTING-regel, och efter en omnumrering finns den adressen inte på något gränssnitt. Paketen skrivs då om till en destination som inte kan svara.

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

Jämför de två utdata. Ett översättningsmål som inte visas i gränssnittslistan är felet, och att åtgärda det är en ändring på en rad när du väl har sett det. Regeln kan ligga i en genererad unit i stället för i WireGuard-konfigurationen, så ladda om den uniten efter redigering och bekräfta att nästa start inte skriver över din ändring.

Två platser bakom NAT behöver en mötesplats

När ingen av sidorna accepterar inkommande anslutningar är det praktiska svaret en liten värd med en offentlig adress och två WireGuard-gränssnitt. Varje plats ansluter utåt, den mellersta värden listar varje peers LAN i sitt eget AllowedIPs, och vidarebefordran bär paket mellan de två tunnlarna. Inget i någon av platsernas brandväggar behöver ändras, och därför sprider sig den här designen lätt.

Routning mellan platserna behåller de ursprungliga källadresserna och håller därmed loggning per värd meningsfull. Översättning på den mellersta värden är enklare när de två LAN:en överlappar, men till priset av att källidentiteten försvinner i loggarna. Bestäm vilken egenskap som spelar roll innan du väljer.

Separera lagren med fyra kontroller

Kör en kontroll per lager i stället för att ändra tre saker och hoppas. Den första visar handskakningens ålder och räknare för varje peer. Den andra visar om klienten faktiskt routar den destinationen in i tunneln. Den tredje och fjärde berättar om begäran kom fram och om en policy släppte den efter ankomst.

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

En begäran som kommer fram och inte ger något svar pekar på svarvägen eller på LAN-värden. En begäran som aldrig kommer fram pekar på AllowedIPs eller på klientens rutt. Dessa två utfall kräver olika åtgärder, och fångsten är det som skiljer dem åt.