Prefix ng host sa WireGuard: bakit gumagana ang isang address at hindi ang iba

Aktibo ang tunnel, nangyayari ang handshake tuwing dalawang minuto, at eksaktong isang address sa kabilang panig ang sumasagot. Gumagana ang mga ping sa tunnel address ng peer; wala sa likod nito ang gumagana. May nagbabasa ng configuration ng interface, nakakita ng prefix ng host at naghinuha na mali ang mask. Ang pagpapalawak nito sa /24 ay pansamantalang nag-aayos ng ping at pagkatapos ay may masisira. Hindi kailanman ang prefix ang dahilan, at ang nawawalang ruta ay hindi ang rutang kinokontrol ng mask.

Ano ba talaga ang nililikha ng prefix ng interface

Sa Linux, ang pagtatalaga ng address sa isang interface ay lumilikha ng konektadong ruta para sa prefix na iyon. Kung magtatalaga ka ng prefix ng host, ang konektadong ruta ay sumasaklaw sa isang address. Kung magtatalaga ka ng /24, sumasaklaw ito sa 256, at bawat isa sa kanila ay itinuturing nang maabot sa link na iyon.

ip -4 addr show dev wg0
ip -4 route show dev wg0
ip route get 10.80.7.1

Ang prefix ng host ay ganap na normal na pagpipilian para sa point-to-point na tunnel, dahil eksaktong isang peer lang ang nasa kabilang dulo. Ang ikatlong utos ang sumasagot sa tanong ng user: sinasabi nito kung aling interface ang gagamitin ng kernel para sa destinasyong iyon, at wala itong makikitang kapaki-pakinabang kung walang tumutugmang ruta.

Iyan ang buong paliwanag sa sintomas. Sumasagot ang isang address dahil may konektadong ruta para dito, o dahil kasama ito nang nagkataon sa pinapayagang listahan ng peer. Wala nang ruta ang lahat ng iba at itinatapon bago pa man makisali ang WireGuard. Nananatiling malusog ang tunnel sa buong panahon, kaya patuloy na mukhang nakapagpapatahimik ang counter ng handshake.

Ang AllowedIPs ay dalawang tuntunin sa ilalim ng isang pangalan

Ang pinapayagang listahan kada peer ng WireGuard ay gumagawa ng dalawang trabaho nang sabay, at ang syntax ng configuration ay ginagawa silang mukhang isa. Sa papasok, pinapayagan nito kung aling source address ang maaaring iharap ng isang peer. Sa palabas, pumipili ito kung aling peer ipapadala ang isang packet, sa paghahanap ng pinakaspesipikong tugma.

Wala sa dalawang trabahong iyon ang routing. Kailangan pa ring magpasya ng kernel na kabilang ang packet sa interface ng tunnel bago pa man ito tingnan ng WireGuard, at galing ang desisyong iyon sa routing table. Ang entry ng peer na may malawak na pinapayagang listahan ay hindi nag-iinstall ng ruta nang mag-isa.

Kaya ang isang configuration ay maaaring mukhang kumpleto at kumilos nang asimetriko. Nagpapadala ang client sa kabilang panig dahil may ruta, at hindi kailanman dumarating ang mga sagot dahil hindi pinapayagan ng pinapayagang listahan ng kabilang panig ang source ng client, o dahil walang pabalik na landas ang kabilang panig. Dalawang magkaibang desisyon ang parehong direksyon na may magkaibang paraan ng pagpalya. Ang isulat kung alin ang sinusubok mo ay kalahati ng diagnosis.

Saan galing ang ruta

Kung gumagamit ka ng wg-quick, ang mga ruta ay nililikha para sa iyo mula sa pinapayagang listahan ng bawat peer, maliban kung itinakda mo ang Table = off at ikaw mismo ang kumuha ng kontrol. Iyon ang dokumentadong pag-uugali ng tool, at iyon ang dahilan kung bakit gumagana pa rin ang configuration na walang tahasang direktiba ng ruta.

sudo wg show wg0 allowed-ips
ip route show | grep wg0
sudo wg-quick strip wg0

Ihambing ang pinapayagang listahan sa mga rutang tunay na naroroon. Ang peer na pinapayagan ang buong subnet ngunit isang rutang host lang ang nalikha ay nangangahulugang hindi kailanman tumakbo ang helper, o pinamamahalaan mo ang interface nang direkta gamit ang wg at ip, at sa ganoong kaso walang gumagawa ng ruta para sa iyo.

Kapag pinamamahalaan mo ito nang manuwal, ang ruta ay isang linya at tahasan ang hugis nito: ang destinasyon sa pamamagitan ng interface, walang gateway dahil point-to-point ang link. Ang idagdag ito ay hindi paraan ng pag-iwas para sa masamang prefix; ito ang nawawalang kalahati ng isang disenyong piniling mangasiwa mismo ng routing.

Hindi idinadagdag ng mas malawak na prefix ang entry ng peer

Ang nakakaakit na pagwawasto ay baguhin ang address sa /24 upang masaklaw ng konektadong ruta ang LAN ng server. Mukhang gumagana ito, at ang dahilan kung bakit mukhang gumagana ay tumutugma na ngayon ang konektadong ruta, hindi dahil may bagong natutunan ang WireGuard.

Ang ginawa mo rin ay inangkin ang buong saklaw bilang direktang maabot sa link na iyon, kasama ang mga address na pag-aari ng ibang peer o ng LAN na talagang nasa likod ng server. Pumapasok na ngayon sa tunnel ang trapiko patungo sa mga address na iyon, at kung lalabas ito sa kabilang panig ay nakasalalay sa routing at pinapayagang listahan ng server mismo.

Hindi naaapektuhan ang panig ng kriptograpiya sa anumang kaso. Kailangan pa rin ng WireGuard ng entry sa pinapayagang listahan na sumasaklaw sa destinasyon upang pumili ng peer, at kailangan pa rin ng kabilang panig ng entry na sumasaklaw sa iyong source upang tanggapin ito. Hindi kayang ibigay ng mas malawak na prefix ng interface ang alinman sa dalawa.

Kumpirmahin ang dalawang direksyon bago magbago ng kahit ano

Hiwalay na asikasuhin ang dalawang dulo at isulat kung ano ang sinasabi ng bawat isa. Sa client ang ruta at ang entry ng peer; sa server ang mirror na larawan at ang sariling pabalik na landas:

ip route get 192.168.70.20
sudo wg show wg0 allowed-ips
sudo wg show wg0 latest-handshakes
sudo tcpdump -ni wg0 -c 10

Ang capture ang nagtatapos sa mga pagtatalo tungkol sa direksyon. Kung lumalabas ang mga palabas na packet sa interface ng tunnel at walang itinatala ang server, tinatanggihan sila ng malayong dulo, kadalasan dahil nasa labas ng pinapayagang listahan nito ang iyong source. Kung talagang walang lumalabas, kulang ang ruta o nakaturo ito sa ibang lugar.

Pagkatapos ay ayusin ang mas makitid na dulo. Ang entry sa pinapayagang listahan sa panig ng server para sa address ng iyong client at entry sa panig ng client para sa destinasyong subnet ang normal na hugis, at hinahayaan nitong tahimik ang prefix ng interface. Palawakin lang ang prefix kung talagang gusto ng plano ng address ang pinagsasaluhang subnet sa link na iyon, at gawin ito bilang pagbabago ng plano at hindi bilang hakbang sa pag-debug.