Ang AllowedIPs ay listahan ng routing, hindi tuntunin ng firewall

Karamihan sa mga tao ay binabasa ang AllowedIPs bilang listahan ng pahintulot, ang set ng mga address na maaaring kumonekta sa isang peer, halos parang tuntunin ng firewall na isinulat para sa isang tunnel. Hindi ganoon. Ang field ay isang talahanayan ng routing na gumagana sa dalawang direksyon: pumipili ito ng peer para sa papalabas na packet at nagpapatunay ng pinagmulan ng papasok. Ang pagbasa nito bilang listahan ng access ay gumagawa ng mga configuration na nagruruta ng trapikong walang humiling.

Isang field, dalawang mambabasa: pagpili ng palabas at pagsuri ng pinagmulan

Sa kliyente, ang mga prefix ang nagpapasya kung aling destinasyon ang pupunta sa peer na iyon at alin ang mananatili sa ordinaryong network. Kaya ang entry para sa 0.0.0.0/0 ay humuhuli sa bawat destinasyong IPv4, at iyon ang dahilan kung bakit ang pag-import ng full-tunnel profile ay nagpapadala ng ordinaryong pagba-browse sa malayong makina. Ang makitid na entry ay kabaligtaran: niruruta lamang ang mga network na inilista mo at iniiwan ang lahat ng iba kung nasaan ito. Ang seksyon tungkol sa crypto key routing sa dokumentasyon ng WireGuard ay nagsasaad ng dalawang gawain sa isang lugar: pagpili ng palabas na peer at pagpapatunay ng papasok na pinagmulan.

Sa server, inilalarawan ng parehong field kung aling source address ang maaaring gamitin ng bawat peer. Ito ay cryptographic na pagsusuri at hindi filter ng packet: ang packet na ang panloob na pinagmulan ay hindi tumutugma sa listahan ng peer ay itinatapon sa loob ng WireGuard bago pa ito makita ng anumang firewall ng host. Ang dalawang gawain ay nagbabahagi ng isang listahan, at iyon mismo ang dahilan kung bakit ang listahang kinopya mula sa ibang lugar ay mali ang kilos sa lugar na hindi mo isinaalang-alang.

Ang block ng kliyente ang lugar kung saan nagsisimula ang karamihan ng kalituhang ito. Pinangalanan ng hatian na tunnel ang malalayong network, at ang buong tunnel ay ang parehong field na may default na prefix:

[Peer]
# split tunnel: only these networks
AllowedIPs = 10.77.0.0/24, 192.168.30.0/24

[Peer]
# full tunnel: everything, both families
AllowedIPs = 0.0.0.0/0, ::/0

Ang dalawang anyo ay kumpleto sa sarili nito, at sila ay alternatibo hindi hakbang. Ang una ay nagpapadala lamang ng dalawang network na iyon sa tunnel; ang pangalawa ay nagpapadala ng bawat destinasyon, at ang entry na ::/0 ay nagdaragdag ng IPv6 sa default na IPv4. Alinman ang piliin mo, ang mga prefix na iyon ang buong desisyon sa routing para sa peer na iyon kapag nagsimulang mag-install ng ruta ang wg-quick.

Kailangan ng hub ng ibang listahan

Inililista ng hub ang tunnel address ng bawat kliyente bilang prefix ng host, kasama ang anumang network na tunay na nasa likod ng kliyenteng iyon. Ang pagkopya ng malawak na listahan ng kliyente sa bawat peer ng hub ay nagsasabi sa hub na maraming peer ang maaaring gumamit ng parehong address bilang pinagmulan, at iyon ay hindi plano ng address. Ang field na Endpoint ay kabilang sa ganap na ibang layer: pinangalanan nito ang panlabas na address at port ng peer, hindi kailanman destinasyon sa loob ng tunnel.

[Peer]
# laptop: tunnel address 10.77.0.2, office LAN behind it
AllowedIPs = 10.77.0.2/32, 192.168.30.0/24

Ang prefix ng host ay nagdadala ng tunnel address at ang prefix ng network ay nagdadala ng nasa likod ng kliyente, at kailangan ang dalawa. Kung walang prefix ng host hindi maibabalik ng hub ang sariling trapiko ng kliyente, at kung walang prefix ng network nananatiling hindi maabot ang LAN sa likod nito; ang peer na walang anuman sa likod ay tumatanggap lamang ng prefix ng host.

Ang paglaktaw sa pag-install ng ruta ay nag-iiwan ng puwang

Ang wg-quick, ang katulong na nag-aangat ng interface mula sa configuration file, ay nag-i-install ng interface address at ruta bilang bahagi ng gawaing iyon. Ang pagtatakda ng Table = off ay nagsasabi sa katulong na laktawan ang gawain sa ruta, na hindi nag-i-install ng kapalit at hindi ginagawang maabot ang pribadong network. Kapag ang awtomatikong ruta ay gumagawa na ng gawain, ang pagpangalan sa mga prefix na kailangan mo ang mas malinaw na configuration. Ang pag-off ng pamamahala ng ruta at pag-iwan sa kapalit na hindi nakasulat ay hindi disenyo, ito ay pagpapabaya.

Ang batayang tool na wg ay kakaiba ang kilos: kinokonfigura ang interface at hindi kailanman hinahawakan ang ruta, kaya ang setup na direktang itinayo rito ay nangangailangan ng sariling mga utos ng ruta. Ang mga tagubiling isinulat para sa isang tool ay maaaring magmukhang mali kapag sinusunod sa isa pa. Ang matagumpay na ping ay mahinang ebidensya rin, dahil sinasalang nito ang isang landas hindi ang bawat landas ng application na kailangan mo.

Ang DNS at IPv6 ay pinagpapasyahan nang hiwalay

Suriin ang address ng DNS server na inaanunsyo ng tunnel at tiyakin na may ruta patungo sa address na iyon sa pamamagitan ng mga prefix na pinili mo. Ang setting ng resolver ay hindi ginagawang maabot ang resolver, at ang pagpapakipot ng tunnel ay maaaring tahimik na mag-alis ng rutang dating papunta roon. Suriin din ang IPv6 nang mag-isa, dahil ang tamang paghahati ng IPv4 ay walang sinasabi tungkol sa default na ruta ng IPv6 na patuloy na nakaturo sa pisikal na link. Tatlong hiwalay na desisyon ang maaaring magbago nang sabay kapag inedit mo ang isang block ng peer.

Pagkatapos ay buksan ang isang pribadong resource at isang ordinaryong website mula sa kilalang panimulang configuration. Kung tumugon ang resource at ang pagba-browse ay lumalabas pa rin sa lokal na koneksyon, ginagawa ng hatian ang hiniling mo. Kung masisira ang pagba-browse sa parehong sandali, kinuha ng tunnel ang default na ruta at ang listahan ng prefix ang lugar na dapat tingnan.