WireGuard-handtrykket verkar, men kontorunder-nettet svarar ikkje

Handtrykket fullførast, wg show rapporterer nyleg overføring, og tunneladressa til tenaren svarar på ein ping. Ein vert på LAN-et til tenaren gjer det ikkje. Tre vilkår må gjelde samstundes: klienten må rute LAN-prefikset inn i tunnelen, tenaren må videresende pakkane, og svaret treng ein veg tilbake. Når eitt av dei tre manglar, er symptomet identisk.

AllowedIPs er både ei tilgangsliste og ei rutetabell

På klienten avgjer lista AllowedIPs både kva som kan sendast til den peeren, og kva ruter WireGuard installerer. Ei peer-oppføring som berre listar tunneladressa til tenaren, installerar éi vertsrute, så LAN-destinasjonar kjem aldri inn i tunnelen. Å leggje til LAN-prefikset er det første som må stadfestast, og det er òg endringa som oftast manglar etter ein kopiert konfigurasjon. Ein peer utvida til ei standardrute er eit anna design, og det flyttar òg internettrafikken til klienten.

Hald vertsruta og LAN-prefikset som separate oppføringar. Viss kontoret har to subnett, høyrer båe til i lista, og det manglande andre prefikset gjev ein feil som ser selektiv ut snarare 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 omsetjing høyrer heime på tenaren

Tenaren treng IP-videresending slått på, ei videresendingsregel som tek imot trafikk frå tunnelen, og ei omsetjingsregel mot LAN-grensesnittet sitt. Det er omsetjinga som får designet til å verke utan å røre kvar vert på kontornettet. Svara går då tilbake til tenaren i staden for til ei adresse LAN-et aldri har høyrt om. Utan ho treng kvar vert ei rute til tunnel-subnettet og ei brannmurregel som tillèt ho, noko som sjeldan er akseptabelt på eit nettverk nokon andre styrer.

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

Reglar som blir lagde til manuelt, forsvinn ved omstart, så bind dei til grensesnittet med hook-kommandoane i tenarkonfigurasjonen. Eit regelsett som overlever grensesnittet sitt, er korleis ein maskin endar med å omsetje trafikk for ein tunnel som ikkje finst lenger.

Då LAN-et flytta, og regelen ikkje gjorde det

Utskifting av ein ruter som omnummererer kontor-subnettet, er den klassiske versjonen av denne feilen. Tunnelen held seg oppe, handtrykket held seg friskt, og ingenting bak tenaren svarar, fordi omsetjingsregelen framleis nemner den gamle adressa. Installasjonsskript legg ofte LAN-adressa til tenaren inn i ein POSTROUTING-regel, og etter ei omnummerering finst ikkje den adressa på noko grensesnitt. Pakkane blir då skrivne om til ein destinasjon som ikkje kan svare.

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

Samanlikn dei to utdataa. Eit omsetjingsmål som ikkje visest i grensesnittlista, er feilen, og å rette han er ei endring på éi line når du først har sett han. Regelen kan liggje i ein generert unit i staden for i WireGuard-konfigurasjonen, så last den uniten på nytt etter redigering og stadfest at neste oppstart ikkje skriv over endringa di.

To nettstader bak NAT treng ein stad å møtast

Når ingen av sidene tek imot innkomande tilkoplingar, er det praktiske svaret ein liten vert med ei offentleg adresse og to WireGuard-grensesnitt. Kvar nettstad koplar seg utover, den midtre verten listar LAN-et til kvar peer i sitt eige AllowedIPs, og videresending ber pakkar mellom dei to tunnelane. Ingenting i brannmuren til nokon av nettstadene må endrast, og difor spreier dette designet seg lett.

Ruting mellom nettstadene held på dei opphavlege kjeldadressene og held dermed logging per vert meiningsfull. Omsetjing på den midtre verten er enklare når dei to LAN-a overlappar, men på kostnad av å miste kjeldidentiteten i loggane. Avgjer kva eigenskap som tel før du vel.

Skil laga med fire kontrollar

Køyr éin kontroll per lag i staden for å endre tre ting og håpe. Den første viser alderen på handtrykket og teljarar for kvar peer. Den andre viser om klienten faktisk rutar den destinasjonen inn i tunnelen. Den tredje og fjerde fortel om førespurnaden kom fram, og om ein policy sleppte han etter ankomst.

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

Ein førespurnad som kjem fram og ikkje gjev svar, peikar på svarvegen eller på LAN-verten. Ein førespurnad som aldri kjem fram, peikar på AllowedIPs eller på ruta til klienten. Desse to utfalla treng ulike rettingar, og opptaket er det som skil dei.