mDNS sa ibabaw ng WireGuard: tatlong tarangkahan bago tumugon ang peer
Kailangan ng Avahi ng karapat-dapat na interface, ruta patungo sa grupo at peer na nagmamay-ari ng destinasyon. Tatlong tarangkahan, tatlong hiwalay na pagsusuri at walang pamamahagi.
Ang pagtatakda ng multicast flag sa isang WireGuard device ay ginagawang karapat-dapat ang interface para sa discovery software, at iyon lang ang ginagawa ng flag. Hindi nito sinasabi sa protocol kung saan dapat pumunta ang group packet, at sa device na may ilang peer ay walang isang malinaw na sagot. Tatlong hiwalay na tarangkahan ang nakatayo sa pagitan ng tumatakbong daemon at ng natuklasang serbisyo.
Subukan sila nang sunod-sunod, dahil ang pagpasa sa isa ay walang sinasabi tungkol sa susunod.
Unang tarangkahan: ang flag at ang patakaran ng daemon
Ang Linux WireGuard device ay ginagawa bilang point-to-point link na walang ARP, at hindi ito nagdadala ng multicast flag bilang default. Ang pagdaragdag ng flag ay lokal na pagbabago ng interface, na ginagawa ng kahit anong namamahala sa device. Ang Avahi ay may sariling pananaw sa mundo sa ibabaw nito, at ang default na patakaran nito ay ganap na nilalaktawan ang point-to-point interfaces. Kaya dalawang independiyenteng pagsubok ng pagiging karapat-dapat ang nalalapat bago gumalaw ang isang packet.
Kaya kailangan ng daemon ng malinaw na desisyon, hindi lamang tumatakbong proseso. Kasama sa mga dokumentadong kontrol nito ang allow-interfaces, deny-interfaces at allow-point-to-point, at ang huli ang setting na napapabayaan ng mga tao.
Ang mga pagsusuri sa ibaba ay nag-uulat ng mga flag ng link, ang multicast route at kung ang configuration ng daemon ay na-parse man:
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkAng daemon na matagumpay na nagsimula ay hindi laging nagbukas ng mga socket sa interface na mahalaga sa iyo. Basahin ang epektibong configuration nito sa halip na ipagpalagay na ang status ng serbisyo ay katumbas ng saklaw.
Ikalawang tarangkahan: ang ruta patungo sa grupo
Ang ikalawang tarangkahan ay ordinaryong routing. Ang packet na naka-address sa 224.0.0.251 ay sumusunod sa forwarding table tulad ng iba pa, at kung ipapadala ito ng table palabas sa pisikal na LAN interface, walang configuration ng WireGuard ang makakapagbago niyon. Ayusin muna ang ruta at ang natitirang imbestigasyon ay maiikli. Tingnan kung ano ang iniuulat ng kernel para sa group address bago hawakan ang anumang peer key.
| Observation | Gate it belongs to | What it does not prove |
|---|---|---|
Multicast flag present on wg0 | Interface eligibility | The daemon will use the interface |
Route to the group via wg0 | Forwarding | Any peer will receive it |
| Destination inside a peer's allowed list | Peer selection | That peer's network will answer |
Kung walang partikular na ruta, bumabalik ang kernel sa sariling multicast handling ng link, kaya mukhang tama ang default sa flat na LAN at mali sa sandaling ang parehong group traffic ay dapat lumabas sa tunnel. Tahimik ang pagkabigo mula sa panig ng nagpapadala: ang query ay pumupunta sa kung saan, at ang sagot ay hindi kailanman dumarating.
Ikatlong tarangkahan: pumipili ang WireGuard ng isang peer bawat packet
Pinipili ng WireGuard ang outgoing peer sa pamamagitan ng paghahanap ng destinasyon sa mga set ng pinapayagang address, at ginagawa ng Linux transmit path ang paghahanap na iyon isang beses bawat packet. Isang resulta lang, at ang packet ay naka-encrypt para sa peer na iyon. Ang parehong group prefix na lumilitaw sa pinapayagang listahan ng ilang peer ay hindi lumilikha ng membership o replication; lumilikha ito ng malabong paghahanap na nauuwi sa isa sa kanila.
Sa dedikadong link na may dalawang endpoint ito ang eksaktong gusto mo, dahil may isang sinadyang tatanggap para sa sadyang dinadalang group traffic. Sa interface na may limang peer ito ay limitasyon, hindi feature, at ang pagwawasto ay sa disenyo at hindi sa configuration ng alinmang peer.
Ang disenyong may pamamahagi ay nangangailangan ng malinaw na relay, hiwalay na link o ganap na ibang mekanismo ng pagtuklas. Ang paglathala ng recipe ng dalawang endpoint bilang solusyon ng maraming kliyente dahil kayang i-ping ng bawat kliyente ang gateway ay kung paano ito nade-deploy nang mali.
Ang papasok na direksyon ay sinisuri nang iba: ang pinagmulan ng natanggap na packet ay dapat nasa loob ng pinapayagang listahan ng authenticated peer. Ang pagdaragdag ng multicast destination doon ay hindi pinapalitan ang tunay na pagmamay-ari ng pinagmulan ng nagpadala.
Ang pagsasalamin ay hangganan, hindi tulay
Ang reflector ng Avahi ay muling gumagawa ng mDNS messages sa pagitan ng mga interface na pinipili nito, sa application layer. Ito ay hangganan ng pagtuklas sa pagitan ng mga network, hindi Ethernet bridge at hindi pangkalahatang multicast router. Dalawang reflector na konektado sa parehong mga network ay masayang lilikha ng loop ng mga paulit-ulit na anunsyo.
Ang pagsasalamin ay naghahatid din ng mga pangalan ng serbisyo at kanilang metadata sa ibang network, na desisyon sa privacy kung paanong desisyon din ito sa routing. Limitahan ang mga napiling interface, at gumamit ng service filters kung saan sinusuportahan ng naka-install na bersyon, upang tanging ang mga anunsyong kailangan ng awtorisadong user ang tumawid sa hangganan.
Ang pagtuklas at paggamit ay nananatiling magkahiwalay na resulta. Maaaring makita ng kliyente ang anunsyo para sa serbisyong ang inanunsyong address ay hindi maabot mula sa kinaroroonan ng kliyente, o ang port ay tinatanggihan ng patakaran sa access nito. Kumpirmahin ang koneksyon sa serbisyo pagkatapos lumitaw ang anunsyo, at kung sinusuportahan ng aplikasyon ang stable na DNS name o malinaw na server address, piliin iyon kaysa palawakin ang link-local na pagtuklas. Ang paglalarawan ng cryptokey routing ay sumasaklaw sa pagpiling peer batay sa destinasyon na pinagbabatayan ng lahat ng ito.