mDNS WireGuard પર: પીઅર જવાબ આપે તે પહેલાં ત્રણ દરવાજા
Avahi ને એક યોગ્ય ઇન્ટરફેસ, જૂથ તરફનો રૂટ અને લક્ષ્યનો માલિક પીઅર જોઈએ. ત્રણ દરવાજા, ત્રણ અલગ તપાસ અને કોઈ ફેન-આઉટ નહીં.
WireGuard ઉપકરણ પર મલ્ટિકાસ્ટ ફ્લેગ સેટ કરવાથી ઇન્ટરફેસ શોધ સૉફ્ટવેર માટે યોગ્ય બને છે, અને ફ્લેગ આટલું જ કરે છે. તે પ્રોટોકોલને જણાવતું નથી કે જૂથ પેકેટ ક્યાં જવું જોઈએ, અને ઘણા પીઅર ધરાવતા ઉપકરણ પર એક પણ સ્પષ્ટ જવાબ હોતો નથી. ચાલતા ડેમન અને શોધાયેલી સેવા વચ્ચે ત્રણ અલગ દરવાજા ઊભા છે.
તેમને ક્રમમાં ચકાસો, કારણ કે એક પાસ કરવાથી આગલા વિશે કંઈ ખબર પડતી નથી.
પ્રથમ દરવાજો: ફ્લેગ અને ડેમનની નીતિ
લિનક્સ WireGuard ઉપકરણ ARP વગર પોઈન્ટ-ટુ-પોઈન્ટ લિંક તરીકે બને છે, અને ડિફૉલ્ટ રૂપે મલ્ટિકાસ્ટ ફ્લેગ ધરાવતું નથી. ફ્લેગ ઉમેરવો એ સ્થાનિક ઇન્ટરફેસ ફેરફાર છે, જે ઉપકરણનું સંચાલન કરતું જે પણ હોય તે કરે છે. Avahi નું તેની ઉપર પોતાનું વિશ્વદર્શન છે, અને તેની ડિફૉલ્ટ નીતિ પોઈન્ટ-ટુ-પોઈન્ટ ઇન્ટરફેસ સંપૂર્ણપણે છોડી દે છે. તેથી એક પણ પેકેટ ખસે તે પહેલાં બે સ્વતંત્ર યોગ્યતા પરીક્ષણો લાગુ પડે છે.
તેથી ડેમનને સ્પષ્ટ નિર્ણયની જરૂર છે, ફક્ત ચાલતી પ્રક્રિયાની નહીં. તેના દસ્તાવેજીકૃત નિયંત્રણોમાં allow-interfaces, deny-interfaces અને allow-point-to-point નો સમાવેશ થાય છે, અને છેલ્લું એ સેટિંગ છે જે લોકો ચૂકી જાય છે.
નીચેની તપાસ લિંક ફ્લેગ, મલ્ટિકાસ્ટ રૂટ અને ડેમનની રૂપરેખા બિલકુલ પાર્સ થાય છે કે નહીં તે જણાવે છે:
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 |
ચોક્કસ રૂટ વગર, કર્નલ લિંકની પોતાની મલ્ટિકાસ્ટ હેન્ડલિંગ પર પાછું જાય છે, તેથી ડિફૉલ્ટ સપાટ LAN પર સાચું લાગે છે અને જેવું જ જૂથ ટ્રાફિક ટનલ દ્વારા બહાર જવાનું હોય ત્યાં જ ખોટું લાગે છે. નિષ્ફળતા મોકલનારની બાજુથી શાંત છે: ક્વેરી ક્યાંક જાય છે, અને જવાબ ક્યારેય આવતો નથી.
ત્રીજો દરવાજો: WireGuard દરેક પેકેટ માટે એક પીઅર પસંદ કરે છે
WireGuard માન્ય સરનામા સેટમાં લક્ષ્ય શોધીને આઉટગોઇંગ પીઅર પસંદ કરે છે, અને લિનક્સ ટ્રાન્સમિટ પાથ દરેક પેકેટ માટે એક વાર એ શોધ કરે છે. પરિણામ એક જ છે, અને પેકેટ તે પીઅર માટે એન્ક્રિપ્ટ થાય છે. એક જ જૂથ પ્રીફિક્સ ઘણા પીઅરની માન્ય યાદીમાં દેખાવાથી સભ્યપદ કે પ્રતિકૃતિ બનતી નથી; તે એક અસ્પષ્ટ શોધ બનાવે છે જે તેમાંથી એક પર ઉકેલાય છે.
બે-ટર્મિનલની સમર્પિત લિંક પર આ બરાબર તમે ઇચ્છો તે છે, કારણ કે જાણી જોઈને વહન કરાતા જૂથ ટ્રાફિક માટે એક જ ઇચ્છિત પ્રાપ્તકર્તા છે. પાંચ પીઅરવાળી ઇન્ટરફેસ પર તે મર્યાદા છે, લક્ષણ નહીં, અને સુધારો કોઈ એક પીઅરની રૂપરેખામાં નહીં, ડિઝાઇનમાં હોવો જોઈએ.
ફેન-આઉટ ડિઝાઇનને સ્પષ્ટ રિલે, અલગ લિંક અથવા સંપૂર્ણ ભિન્ન શોધ મેકેનિઝમની જરૂર છે. દરેક ક્લાયન્ટ ગેટવેને પિંગ કરી શકે માટે બે-ટર્મિનલની રેસીપીને બહુ-ક્લાયન્ટ ઉકેલ તરીકે પ્રકાશિત કરવી એ જ રીતે આ ખોટી રીતે તૈનાત થાય છે.
આવકની દિશા અલગ રીતે ચકાસાય છે: પ્રાપ્ત પેકેટનું સ્રોત પ્રમાણિત પીઅરની માન્ય યાદીમાં આવવું જોઈએ. ત્યાં મલ્ટિકાસ્ટ લક્ષ્ય ઉમેરવું મોકલનારના વાસ્તવિક સ્રોત-માલિકીનું સ્થાન લેતું નથી.
પ્રતિબિંબ એ સીમા છે, પુલ નહીં
Avahi નો રિફ્લેક્ટર પસંદ કરેલી ઇન્ટરફેસ વચ્ચે mDNS સંદેશા એપ્લિકેશન સ્તરે પુનરુત્પાદિત કરે છે. તે નેટવર્ક વચ્ચેની શોધ સીમા છે, ઇથરનેટ પુલ નહીં અને સામાન્ય મલ્ટિકાસ્ટ રાઉટર નહીં. એક જ નેટવર્ક સાથે જોડાયેલા બે રિફ્લેક્ટર સરળતાથી પુનરાવર્તિત જાહેરાતોનું લૂપ બનાવશે.
પ્રતિબિંબ સેવાના નામ અને તેમના મેટાડેટા બીજા નેટવર્કને પણ સોંપે છે, જે રૂટિંગ નિર્ણય જેટલું જ ગોપનીયતાનું નિર્ણય છે. પસંદ કરેલી ઇન્ટરફેસ મર્યાદિત કરો, અને જ્યાં સ્થાપિત સંસ્કરણ સમર્થન આપે ત્યાં સેવા ફિલ્ટર વાપરો, જેથી ફક્ત અધિકૃત વપરાશકર્તાને જરૂરી જાહેરાતો જ સીમા ઓળંગે.
શોધ અને ઉપયોગ અલગ પરિણામો રહે છે. ક્લાયન્ટ એવી સેવાની જાહેરાત જોઈ શકે છે જેનું જાહેર કરેલું સરનામું ક્લાયન્ટ જ્યાં છે ત્યાંથી પહોંચી શકાય તેવું નથી, અથવા જેનું પોર્ટ તેની ઍક્સેસ નીતિ નકારે છે. જાહેરાત દેખાય પછી સેવા જોડાણની પુષ્ટિ કરો, અને જો એપ્લિકેશન સ્થિર DNS નામ અથવા સ્પષ્ટ સર્વર સરનામું સમર્થન આપે તો લિંક-લોકલ શોધ વિસ્તારવાને બદલે તેને પ્રાધાન્ય આપો. ક્રિપ્ટોકી રૂટિંગનું વર્ણન તે લક્ષ્ય-આધારિત પીઅર પસંદગીને આવરી લે છે જેના પર આ બધું આધાર રાખે છે.