mDNS WireGuard-ի վրա. երեք դարպաս՝ մինչև զուգընկերը կպատասխանի
Avahi-ին պետք է համապատասխան միջերես, ուղի դեպի խումբ և զուգընկեր, որը տիրապետում է նպատակակետին։ Երեք դարպաս, երեք առանձին ստուգում և ոչ մի տարածում։
WireGuard սարքի վրա multicast դրոշակը դնելը միջերեսը դարձնում է համապատասխան հայտնաբերման ծրագրերի համար, և դրոշակն այսքանն է անում։ Այն պրոտոկոլին չի ասում, թե խմբային փաթեթը որտեղ պետք է գնա, և մի քանի զուգընկեր ունեցող սարքում մեկ ակնհայտ պատասխան չկա։ Աշխատող դեյմոնի և հայտնաբերված ծառայության միջև կանգնած են երեք առանձին դարպասներ։
Ստուգեք դրանք հերթականությամբ, որովհետև մեկը անցնելը ոչինչ չի ասում հաջորդի մասին։
Առաջին դարպասը. դրոշակը և դեյմոնի քաղաքականությունը
Linux-ի WireGuard սարքը ստեղծվում է որպես կետ-կետ կապ առանց ARP-ի, և այն լռելյայն չի կրում multicast դրոշակը։ Դրոշակը ավելացնելը տեղական միջերեսի փոփոխություն է, որը կատարում է սարքը կառավարողը։ Avahi-ն այդ ամենից վեր ունի աշխարհի իր պատկերացումը, և նրա լռելյայն քաղաքականությունը բացարձակապես բաց է թողնում կետ-կետ միջերեսները։ Այսպիսով, երկու անկախ համապատասխանության թեստեր գործում են նախքան նույնիսկ մեկ փաթեթ կշարժվի։
Այսպիսով, դեյմոնին պետք է բացահայտ որոշում, ոչ թե պարզապես աշխատող պրոցես։ Նրա փաստաթղթավորված կառավարիչները ներառում են allow-interfaces, deny-interfaces և allow-point-to-point, և վերջինը այն կարգավորումն է, որը մարդիկ բաց են թողնում։
Ստորև բերված ստուգումները հաղորդում են կապի դրոշակները, multicast ուղին և արդյոք դեյմոնի կոնֆիգուրացիան ընդհանրապես վերլուծվում է։
ip -d link show wg0
ip route get 224.0.0.251
avahi-daemon --checkՀաջողությամբ մեկնարկած դեյմոնը պարտադիր չէ, որ սոքեթներ բացած լինի ձեզ հետաքրքրող միջերեսում։ Կարդացեք նրա արդյունավետ կոնֆիգուրացիան՝ փոխարենը ենթադրելու, որ ծառայության կարգավիճակը հավասար է ծածկույթին։
Երկրորդ դարպասը. ուղին դեպի խումբ
Երկրորդ դարպասը սովորական երթուղավորումն է։ 224.0.0.251 հասցեին ուղղված փաթեթը հետևում է փոխանցման աղյուսակին ինչպես մնացած ամեն ինչ, և եթե աղյուսակն այն ուղարկում է ֆիզիկական LAN միջերեսով դուրս, ապա ոչ մի WireGuard կոնֆիգուրացիա դա չի փոխի։ Նախ ուղղեք ուղին, և հետաքննության մնացած մասը կկրճատվի։ Նայեք, թե միջուկը ինչ է հաղորդում խմբի հասցեի համար, նախքան որևէ զուգընկերի բանալու դիպչելը։
| 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 |
Առանց կոնկրետ ուղու՝ միջուկը վերադառնում է կապի սեփական multicast մշակմանը, ինչի պատճառով լռելյայնը ճիշտ է երևում հարթ LAN-ում և սխալ՝ հենց որ նույն խմբային երթևեկությունը պետք է դուրս գա թունելով։ Անհաջողությունը լուռ է ուղարկողի կողմից, հարցումը ինչ-որ տեղ է գնում, և պատասխանը երբեք չի հասնում։
Երրորդ դարպասը. WireGuard-ը մեկ զուգընկեր է ընտրում յուրաքանչյուր փաթեթի համար
WireGuard-ը ընտրում է ելքային զուգընկերոջը՝ փնտրելով նպատակակետը թույլատրված հասցեների հավաքածուներում, և Linux-ի փոխանցման ուղին այդ որոնումը կատարում է մեկ անգամ յուրաքանչյուր փաթեթի համար։ Արդյունքը մեկն է, և փաթեթը գաղտնագրվում է այդ զուգընկերոջ համար։ Նույն խմբային նախածանցը մի քանի զուգընկերների թույլատրված ցանկերում չի ստեղծում անդամակցություն կամ կրկնօրինակում, այն ստեղծում է երկիմաստ որոնում, որը լուծվում է նրանցից մեկի օգտին։
Երկու ծայրով նվիրված կապի վրա սա հենց այն է, ինչ ուզում եք, որովհետև դիտավորյալ տեղափոխվող խմբային երթևեկության համար կա մեկ նախատեսված ստացող։ Հինգ զուգընկեր ունեցող միջերեսի վրա սա սահմանափակում է, ոչ թե հատկություն, և ուղղումը պատկանում է նախագծին, այլ ոչ թե որևէ մեկ զուգընկերոջ կոնֆիգուրացիային։
Ճյուղավորված նախագծին պետք է բացահայտ ռելե, առանձին կապեր կամ բոլորովին այլ հայտնաբերման մեխանիզմ։ Երկու ծայրով բաղադրատոմսը որպես բազմահաճախորդ լուծում հրապարակելը, քանի որ յուրաքանչյուր հաճախորդ կարող է ping անել դարպասին, հենց այն ձևն է, որով սա սխալ է տեղակայվում։
Ներգնա ուղղությունը ստուգվում է այլ կերպ, ստացված փաթեթի աղբյուրը պետք է ընկնի նույնականացված զուգընկերոջ թույլատրված ցանկի մեջ։ Այնտեղ multicast նպատակակետ ավելացնելը չի փոխարինում ուղարկողի իրական աղբյուրի տիրապետմանը։
Արտացոլումը սահման է, ոչ կամուրջ
Avahi-ի անդրադարձիչը վերարտադրում է mDNS հաղորդագրությունները իր ընտրած միջերեսների միջև՝ հավելվածային մակարդակում։ Դա հայտնաբերման սահման է ցանցերի միջև, ոչ Ethernet կամուրջ և ոչ ընդհանուր multicast երթուղիչ։ Նույն ցանցերին միացված երկու անդրադարձիչներ հեշտությամբ կստեղծեն կրկնվող հայտարարությունների օղակ։
Արտացոլումը նաև ծառայությունների անուններն ու դրանց մետատվյալները հանձնում է մեկ այլ ցանցի, ինչը գաղտնիության որոշում է այնպես, ինչպես երթուղավորման որոշում։ Սահմանափակեք ընտրված միջերեսները և օգտագործեք ծառայության զտիչներ այնտեղ, որտեղ տեղադրված տարբերակը դրանք աջակցում է, որպեսզի սահմանը հատեն միայն լիազորված օգտվողին անհրաժեշտ հայտարարությունները։
Հայտնաբերումը և օգտագործումը մնում են առանձին արդյունքներ։ Հաճախորդը կարող է տեսնել ծառայության հայտարարություն, որի գովազդված հասցեն հասանելի չէ այնտեղից, որտեղ գտնվում է հաճախորդը, կամ որի պորտը մերժում է նրա մուտքի քաղաքականությունը։ Հաստատեք ծառայության միացումը հայտարարությունը հայտնվելուց հետո, և եթե հավելվածն աջակցում է կայուն DNS անվան կամ բացահայտ սերվերի հասցեի, նախընտրեք դա կապի տեղական հայտնաբերման ընդլայնման փոխարեն։ Գաղտնաբանալիով երթուղավորման նկարագրությունը ընդգրկում է նպատակակետի վրա հիմնված զուգընկերոջ ընտրությունը, որից կախված է այս ամենը։