WireGuard AllowedIPs: ang rutang hindi kailanman idinagdag ng NetworkManager
Ang wastong WireGuard profile ay maaaring tapusin ang pakikipagkamay at wala pa ring ipadala. Ihambing ang talahanayan ng kernel sa AllowedIPs, pagkatapos ay bigyan ng isang may-ari ang ruta.
Nag-a-update ang counter ng pakikipagkamay, pinapanatili ng interface ang address nito, at ang ping papunta sa kabilang panig ay hindi umaabot kahit saan. Nakakalito ang kombinasyong iyon dahil ang gumaganang pakikipagkamay ay parang patunay na handa na ang tunnel. Hindi: ang tunnel ay maaaring ganap na napagkasunduan at wala pa ring rutang nagdadala ng trapiko papasok dito, at iyon ay dalawang magkaibang gawain na ginagawa ng dalawang magkaibang piraso ng estado. Ang pagwawasto ay nakasalalay nang buo sa kung alin sa dalawa ang kulang, kaya ang unang hakbang ay alamin iyon.
Ginagawa ng wg-quick ang dalawa nang hindi hinihiling. Ang built-in na suporta ng WireGuard sa NetworkManager ay nag-i-install din ng mga ruta ng peer bilang default, na nagpapaliit sa mga pinaghihinalaan sa isang naka-disable na opsyon, ibang routing table, o isang configuration na na-import sa pamamagitan ng ibang bagay.
Kumpirmahin ang tunnel bago habulin ang ruta
wg show ay nagpi-print ng interface, peer, endpoint at edad ng huling pakikipagkamay, at kinukumpirma ng ip addr show na naroroon ang address. Ang kamakailang pakikipagkamay ay nangangahulugang gumagana ang mga susi, ang endpoint at ang UDP path. Ang lahat ng sira ay nasa ibaba ng mga iyon: routing, pag-filter o paglutas ng pangalan.
Pagkatapos ay tanungin ang kernel kung ano ang gagawin nito sa isang tunay na destinasyon sa halip na isang hipotetikal: ip route get 10.42.7.9. Pinangalanan ng sagot ang palabas na interface at ang source address na dadalhin ng packet. Kapag pinangalanan nito ang pisikal na adapter, hindi kailanman pumapasok ang packet sa tunnel, gaano man kaganda ang pakikipagkamay.
Ang AllowedIPs ay isang filter at isang listahan ng ruta
Ang mga prefix sa AllowedIPs ay gumagawa ng dalawang gawain. Pinipili nila kung aling peer ang magdadala ng palabas na destinasyon, at binibigyang-katwiran nila ang source address ng mga papasok na packet, na siyang hangganan ng routing na may crypto key. Sa wg-quick, ginagabayan din nila ang awtomatikong pag-install ng ruta, at ang dagdag na pag-uugaling iyon ang dahilan kung bakit gumagana ang parehong configuration mula sa terminal at hindi mula sa desktop client.
Sa kaso sa likod ng artikulong ito, ang profile ay na-import sa pamamagitan ng third-party na plugin sa halip na sa built-in na suporta, at ang interface ay umangat na walang ruta ng prefix. Ang paglilista ng talahanayan ay agad na nagpapakita nito: ip route show ay naglalaman lamang ng konektadong ruta para sa address ng interface, at wala para sa malayong saklaw.
Itanong kung ang mga ruta ng peer ay naka-enable talaga
Basahin ang setting bago baguhin ang anuman: nmcli -f wireguard.peer-routes,ipv4.route-table connection show work-wg. Kapag ang peer-routes ay nagpapakita ng no, ang sinusuportahang pag-aayos ay nmcli connection modify work-wg wireguard.peer-routes yes, na sinusundan ng muling pagkonekta. Ang pagdaragdag ng static na ruta sa halip ay gumagana hanggang sa susunod na activation at pagkatapos ay tahimik na nawawala. Ang pagkawalang iyon ang palatandaan: ang rutang bumabalik na parang misteryo tuwing umaga ay hindi ini-install ng profile.
Kung ang opsyon ay naka-enable na, tingnan kung ang prefix ay naninirahan sa ibang talahanayan gamit ang ip route show table all | grep 10. Ang ruta sa talahanayang hindi pangunahin ay hindi kulang, hindi lamang ito nakikita ng paghahanap na tumitingin lamang sa pangunahing talahanayan. Ayusin ang policy routing sa halip na magpatong ng duplicate na entry.
Idagdag ang prefix sa koneksyon, hindi sa tumatakbong sistema
Sa editor ng koneksyon, hinahawakan ng pahina ng WireGuard ang peer at ang AllowedIPs nito, at hinahawakan ng pahina ng IPv4 ang mga karagdagang ruta. Ang rutang idinagdag doon ay tumatagal sa muling pagkonekta dahil kabilang ito sa profile. Sa command line, ang katumbas ay ang paglakip ng ruta sa koneksyon sa anyong may walang laman na gateway, pagkatapos ay ibaba at itaas ang koneksyon upang mailapat ang pagbabago.
Piliin ang pinakamakitid na prefix na sumasaklaw sa mga host na kailangan mo. Ang pagkopya ng halimbawang /8 ng provider ay maaaring lumamon ng mga lokal na saklaw na nagkataong nasa loob nito, at ang mga resulta ng pagpalya ay parang sirang tunnel sa halip na masyadong malawak na ruta.
Ang split na tunnel ay pinagpapasyahan ng listahan ng prefix
Walang switch para sa split na tunnel; ang listahan ng prefix ang desisyon. Ang peer na may isang saklaw para sa LAN ng opisina at isa para sa network ng laboratoryo ay nagpapadala ng eksaktong mga destinasyong iyon sa tunnel at hinahayaan ang lahat ng iba. Ang isang host ay nangangailangan ng /32, at ang mga saklaw na nagsasapawan sa dalawang lokasyon ay nangangailangan ng mga prefix ng host hanggang may mag-renumber ng subnet.
Ang pagpiling huwag magpadala ng anuman sa tunnel ay nagdadala ng parehong desisyon sa hangganan nito: ang minimal na listahan ay nagpapanatili ng link na bukas habang ang ordinaryong trapiko ay sumusunod sa dati nitong landas. Isulat ang intensyon, dahil kung hindi ay ituturing ng susunod na mambabasa ang maikling listahan bilang kapabayaan at matulungin itong papahabain.
Isang may-ari para sa talahanayan ng ruta
Ang wg-quick at NetworkManager ay parehong naniniwala na sila ang may-ari ng mga ruta ng interface. Mag-import ng configuration na isinulat para sa wg-quick at pagkatapos ay simulan din ang serbisyo ng wg-quick, at makakakuha ka ng doble o magkasalungat na entry na ang pag-uugali ay nakasalalay sa kung alin ang huling tumakbo. Pumili ng isang may-ari at alisin ang isa: kung pinamamahalaan ng NetworkManager ang koneksyon, i-disable ang unit ng wg-quick para sa interface na iyon, at huwag kailanman magdagdag ng pangalawang profile para sa parehong device.
Kapag ang paghahati ay dapat sumunod sa isang pisikal na adapter sa halip na isang destinasyon, lumipat ka na sa policy routing, at ang policy routing ay nangangailangan din ng isang may-akda. I-verify sa pamamagitan ng pag-uulit ng ip route get, pagkatapos ay pag-abot sa isang host sa loob ng malayong prefix gamit ang isang bagay na nagpi-print ng source address na pinili nito. Suriin nang hiwalay ang IPv6 at DNS kung ang profile ay may alinman sa dalawa.