Gumagana ang handshake ng WireGuard, ngunit hindi sumasagot ang subnet ng opisina

Nakumpleto ang handshake, wg show nag-uulat ng kamakailang paglilipat, at sumasagot sa ping ang address ng tunnel ng server. Ang host sa LAN ng server ay hindi. Tatlong kundisyon ang dapat totoo nang sabay: dapat i-route ng kliyente ang prefix ng LAN papasok sa tunnel, dapat ipasa ng server ang mga packet, at kailangan ng tugon ng landas pabalik. Kapag kulang ang isa sa tatlo, magkapareho ang sintomas.

Ang AllowedIPs ay listahan ng access at talahanayan ng routing nang sabay

Sa kliyente, ang listahan AllowedIPs ang nagtatakda kung ano ang maaaring ipadala sa peer na iyon at kung aling mga ruta ang ini-install ng WireGuard. Ang entry ng peer na naglilista lamang ng address ng tunnel ng server ay nag-i-install ng isang host route, kaya hindi kailanman pumapasok sa tunnel ang mga destinasyon sa LAN. Ang pagdaragdag ng prefix ng LAN ang unang dapat suriin, at ito rin ang pagbabagong madalas nawawala pagkatapos ng kinopyang configuration. Ang peer na pinalawak sa default route ay ibang disenyo, at ililipat din nito ang trapiko sa internet ng kliyente.

Panatilihing magkahiwalay na entry ang host route at ang prefix ng LAN. Kung may dalawang subnet ang opisina, pareho silang kabilang sa listahan, at ang nawawalang pangalawang prefix ay gumagawa ng pagkasira na mukhang pili kaysa buo.

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

Ang pagpapasa at pagsasalin ay para sa server

Kailangan ng server ng naka-enable na pagpapasa ng IP, isang tuntunin sa pagpapasa na tumatanggap ng trapikong galing sa tunnel, at isang tuntunin sa pagsasalin patungo sa interface ng LAN nito. Ang pagsasalin ang dahilan kung bakit gumagana ang disenyo nang hindi hinahawakan ang bawat host sa network ng opisina. Bumabalik noon ang mga tugon sa server sa halip na sa isang address na hindi pa narinig ng LAN. Kung wala ito, kailangan ng bawat host ng ruta patungo sa subnet ng tunnel at tuntunin sa firewall na nagpapahintulot nito, na bihirang katanggap-tanggap sa network na pinamamahalaan ng iba.

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

Ang mga tuntuning idinagdag nang manwal ay nawawala sa reboot, kaya itali ang mga ito sa interface gamit ang mga utos na hook sa configuration ng server. Ang set ng tuntuning mas matagal kaysa sa interface nito ang paraan kung paano nauuwi ang isang makina sa pagsasalin ng trapiko para sa tunnel na wala na.

Noong lumipat ang LAN at hindi ang tuntunin

Ang pagpapalit ng router na muling nagnumero sa subnet ng opisina ang klasikong bersyon ng pagkasirang ito. Nananatiling aktibo ang tunnel, nananatiling sariwa ang handshake, at walang sumasagot sa likod ng server, dahil tinutukoy pa rin ng tuntunin sa pagsasalin ang lumang address. Madalas na isinasama ng mga installer script ang address ng LAN ng server sa isang tuntunin sa POSTROUTING, at pagkatapos ng muling pagnumero ay wala ang address na iyon sa anumang interface. Isinusulat muli noon ang mga packet patungo sa destinasyong hindi makasasagot.

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

Ihambing ang dalawang output. Ang target ng pagsasalin na hindi lumalabas sa listahan ng interface ang bug, at ang pag-aayos nito ay isang linyang pagbabago kapag nakita mo na. Maaaring nasa isang nabuong unit ang tuntunin at hindi sa configuration ng WireGuard, kaya i-reload ang unit na iyon pagkatapos mag-edit at tiyakin na hindi muling isusulat ng susunod na boot ang pagbabago mo.

Kailangan ng dalawang site sa likod ng NAT ng lugar na pagtatagpuan

Kapag wala sa dalawang panig ang tumatanggap ng mga koneksyong papasok, ang praktikal na sagot ay isang maliit na host na may pampublikong address at dalawang interface ng WireGuard. Kumokonekta palabas ang bawat site, inililista ng gitnang host ang LAN ng bawat peer sa sarili nitong AllowedIPs, at dinadala ng pagpapasa ang mga packet sa pagitan ng dalawang tunnel. Wala sa firewall ng alinmang site ang kailangang magbago, kaya madaling kumalat ang disenyong ito.

Ang routing sa pagitan ng mga site ay nagpapanatili ng orihinal na source address at sa gayon ay nagpapanatili ng makabuluhang pag-log kada host. Ang pagsasalin sa gitnang host ay mas simple kapag nagsasapawan ang dalawang LAN, ngunit kapalit ng pagkawala ng pagkakakilanlan ng pinagmulan sa mga log. Magpasya kung aling katangian ang mahalaga bago pumili.

Paghiwalayin ang mga layer gamit ang apat na pagsusuri

Gumawa ng isang pagsusuri kada layer sa halip na magbago ng tatlong bagay at umasa. Ipinapakita ng una ang edad ng handshake at mga counter para sa bawat peer. Ipinapakita ng pangalawa kung talagang ini-route ng kliyente ang destinasyong iyon papasok sa tunnel. Sinasabi ng pangatlo at pang-apat kung nakarating ang kahilingan at kung may patakarang nagtapon nito pagkatapos makarating.

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

Ang kahilingang nakarating at walang tugon ay tumuturo sa landas ng tugon o sa host sa LAN. Ang kahilingang hindi kailanman nakarating ay tumuturo sa AllowedIPs o sa ruta ng kliyente. Kailangan ng dalawang resultang ito ng magkaibang pagwawasto, at ang pagkuha ang nagtatangi sa kanila.