WireGuard-handskud werk, maar die kantoor-subnet antwoord nie

Die handskud voltooi, wg show meld onlangse oordrag, en die bediener se tonneladres antwoord op 'n ping. 'n Gasheer op die bediener se LAN doen nie. Drie voorwaardes moet gelyktydig geld: die kliënt moet die LAN-voorvoegsel in die tonnel roeteer, die bediener moet die pakkette aanstuur, en die antwoord het 'n pad terug nodig. Wanneer een van die drie ontbreek, is die simptoom identies.

AllowedIPs is beide 'n toegangslys en 'n roetetabel

Op die kliënt bepaal die AllowedIPs lys beide wat na daardie eweknie gestuur mag word en watter roetes WireGuard installeer. 'n Eweknie-inskrywing wat net die bediener se tonneladres lys, installeer een gasheervoete, so LAN-bestemmings gaan nooit in die tonnel in nie. Die byvoeging van die LAN-voorvoegsel is die eerste ding om te verifieer, en dit is ook die verandering wat heel waarskynlik ontbreek ná 'n gekopieerde konfigurasie. 'n Eweknie wat na 'n verstekroete verbreed is, is 'n ander ontwerp, en dit sal die kliënt se internetverkeer ook verskuif.

Hou die gasheervoete en die LAN-voorvoegsel as afsonderlike inskrywings. As die kantoor twee subnetwerke het, hoort albei in die lys, en die ontbrekende tweede voorvoegsel lewer 'n fout wat selektief eerder as totaal lyk.

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

Aanstuur en vertaling hoort op die bediener

Die bediener het IP-aanstuur geaktiveer nodig, 'n aanstuurreël wat verkeer wat uit die tonnel kom, aanvaar, en 'n vertaalreël na sy LAN-koppelvlak. Die vertaling is wat die ontwerp laat werk sonder om elke gasheer op die kantoornetwerk aan te raak. Antwoorde keer dan terug na die bediener eerder as na 'n adres waarvan die LAN nog nooit gehoor het nie. Sonder dit het elke gasheer 'n roete vir die tonnel-subnet en 'n vuurmuurreël nodig wat dit toelaat, wat selde aanvaarbaar is op 'n netwerk wat iemand anders bestuur.

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

Reëls wat met die hand bygevoeg is, verdwyn by herbegin, so bind hulle aan die koppelvlak met die haakopdragte in die bedienerkonfigurasie. 'n Reëlstel wat sy koppelvlak oorleef, is hoe 'n masjien uiteindelik verkeer vertaal vir 'n tonnel wat nie meer bestaan nie.

Toe die LAN geskuif het en die reël nie

'n Roeteerdervervanging wat die kantoor-subnet hernommer, is die klassieke weergawe van hierdie fout. Die tonnel bly op, die handskud bly vars, en niks agter die bediener antwoord nie, want die vertaalreël noem steeds die ou adres. Installeerder-skripte bak dikwels die bediener se LAN-adres in 'n POSTROUTING-reël in, en ná 'n hernommering bestaan daardie adres op geen koppelvlak nie. Pakkette word dan herskryf na 'n bestemming wat nie kan antwoord nie.

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

Vergelyk die twee uitsette. 'n Vertaalteiken wat nie in die koppelvlaklys verskyn nie, is die fout, en om dit reg te maak is 'n een-reël-verandering sodra jy dit gesien het. Die reël mag in 'n gegenereerde eenheid eerder as in die WireGuard-konfigurasie woon, so herlaai daardie eenheid ná die wysiging en bevestig dat die volgende opstart nie jou verandering herskryf nie.

Twee terreine agter NAT het 'n plek nodig om te ontmoet

Wanneer nie een kant inkomende verbindings aanvaar nie, is die praktiese antwoord 'n klein gasheer met 'n openbare adres en twee WireGuard-koppelvlakke. Elke terrein verbind uitwaarts, die middelste gasheer lys elke eweknie se LAN in sy eie AllowedIPs, en aanstuur dra pakkette tussen die twee tonnels. Niks aan óf terrein se vuurmuur hoef te verander nie, en daarom versprei hierdie ontwerp maklik.

Roetering tussen die terreine behou die oorspronklike bronadresse en hou dus per-gasheer-logging betekenisvol. Vertaling by die middelste gasheer is eenvoudiger wanneer die twee LAN's oorvleuel, ten koste van die verlies van die bronidentiteit in die logs. Besluit watter eienskap saak maak voordat jy kies.

Skei die lae met vier kontroles

Voer een kontrole per laag uit eerder as om drie dinge te verander en te hoop. Die eerste wys handskud-ouderdom en tellers vir elke eweknie. Die tweede wys of die kliënt daardie bestemming werklik in die tonnel roeteer. Die derde en vierde vertel jou of die versoek aangekom het en of 'n beleid dit ná aankoms laat val het.

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

'n Versoek wat aankom en geen antwoord uitlok nie, dui op die antwoordpad of op die LAN-gasheer. 'n Versoek wat nooit aankom nie, dui op AllowedIPs of op die kliënt se roete. Daardie twee uitkomste het verskillende regstellings nodig, en die opname is wat hulle onderskei.