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 പുറത്തുപോകുന്ന സഹകാരിയെ തിരഞ്ഞെടുക്കുന്നു, ലിനക്സ് ട്രാൻസ്മിറ്റ് പാത്ത് ആ തിരയൽ ഓരോ പാക്കറ്റിനും ഒരിക്കൽ നടത്തുന്നു. ഫലം ഒന്നാണ്, പാക്കറ്റ് ആ സഹകാരിക്കായി എൻക്രിപ്റ്റ് ചെയ്യുന്നു. ഒരേ ഗ്രൂപ്പ് പ്രിഫിക്സ് പല സഹകാരികളുടെ അനുവദനീയ പട്ടികകളിൽ പ്രത്യക്ഷപ്പെടുന്നത് അംഗത്വമോ പകർപ്പോ സൃഷ്ടിക്കുന്നില്ല; അത് അവയിലൊന്നിൽ തീരുന്ന ഒരു അവ്യക്ത തിരയൽ സൃഷ്ടിക്കുന്നു.
രണ്ട് അറ്റങ്ങളുള്ള സമർപ്പിത ലിങ്കിൽ ഇത് കൃത്യമായി നിങ്ങൾ ആഗ്രഹിക്കുന്നതാണ്, കാരണം ബോധപൂർവം കൊണ്ടുപോകുന്ന ഗ്രൂപ്പ് ട്രാഫിക്കിന് ഒരു ഉദ്ദിഷ്ട സ്വീകർത്താവുണ്ട്. അഞ്ച് സഹകാരികളുള്ള ഇന്റർഫേസിൽ ഇത് ഒരു പരിമിതിയാണ്, സവിശേഷതയല്ല, പരിഹാരം ഏതെങ്കിലും ഒരു സഹകാരിയുടെ കോൺഫിഗറേഷനിലല്ല, രൂപകൽപ്പനയിലാണ്.
വിതരണ രൂപകൽപ്പനയ്ക്ക് വ്യക്തമായ റിലേ, വേർതിരിഞ്ഞ ലിങ്കുകൾ അല്ലെങ്കിൽ തികച്ചും വ്യത്യസ്തമായ കണ്ടെത്തൽ സംവിധാനം വേണം. ഓരോ ക്ലയന്റിനും ഗേറ്റ്വേയിലേക്ക് പിംഗ് ചെയ്യാനാകുന്നതിനാൽ രണ്ട്-അറ്റ റെസിപ്പി ബഹു-ക്ലയന്റ് പരിഹാരമായി പ്രസിദ്ധീകരിക്കുന്നത് — ഇങ്ങനെയാണ് ഇത് തെറ്റായി വിന്യസിക്കപ്പെടുന്നത്.
ഉള്ളിലേക്കുള്ള ദിശ വ്യത്യസ്തമായി പരിശോധിക്കുന്നു: സ്വീകരിച്ച പാക്കറ്റിന്റെ ഉറവിടം പ്രാമാണീകരിച്ച സഹകാരിയുടെ അനുവദനീയ പട്ടികയ്ക്കുള്ളിൽ വരണം. അവിടെ multicast ലക്ഷ്യസ്ഥാനം ചേർക്കുന്നത് അയക്കുന്നയാളുടെ യഥാർത്ഥ ഉറവിട ഉടമസ്ഥതയ്ക്ക് പകരമാകുന്നില്ല.
പ്രതിഫലനം ഒരു അതിർത്തിയാണ്, പാലമല്ല
Avahi-യുടെ പ്രതിഫലനി തിരഞ്ഞെടുത്ത ഇന്റർഫേസുകൾക്കിടയിൽ mDNS സന്ദേശങ്ങൾ അപ്ലിക്കേഷൻ പാളിയിൽ പുനർനിർമ്മിക്കുന്നു. ഇത് നെറ്റ്വർക്കുകൾക്കിടയിലുള്ള കണ്ടെത്തൽ അതിർത്തിയാണ്, ഈതർനെറ്റ് പാലമല്ല, സാധാരണ multicast റൗട്ടറുമല്ല. ഒരേ നെറ്റ്വർക്കുകളിൽ ബന്ധിപ്പിച്ച രണ്ട് പ്രതിഫലനികൾ ആവർത്തിച്ചുള്ള പ്രഖ്യാപനങ്ങളുടെ ലൂപ്പ് സന്തോഷത്തോടെ സൃഷ്ടിക്കും.
പ്രതിഫലനം സേവന നാമങ്ങളും അവയുടെ മെറ്റാഡാറ്റയും മറ്റൊരു നെറ്റ്വർക്കിന് കൈമാറുന്നു, ഇത് റൂട്ടിംഗ് തീരുമാനമെന്നതുപോലെ സ്വകാര്യതാ തീരുമാനവുമാണ്. തിരഞ്ഞെടുത്ത ഇന്റർഫേസുകൾ പരിമിതപ്പെടുത്തുക, ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പ് പിന്തുണയ്ക്കുന്നിടത്ത് സേവന ഫിൽട്ടറുകൾ ഉപയോഗിക്കുക, അധികാരമുള്ള ഉപയോക്താവിന് ആവശ്യമായ പ്രഖ്യാപനങ്ങൾ മാത്രം അതിർത്തി കടക്കാൻ.
കണ്ടെത്തലും ഉപയോഗവും വേർതിരിഞ്ഞ ഫലങ്ങളായി തുടരുന്നു. ക്ലയന്റ് ഇരിക്കുന്നിടത്തുനിന്ന് പരസ്യപ്പെടുത്തിയ വിലാസം എത്തിച്ചേരാനാകാത്ത സേവനത്തിന്റെയോ അതിന്റെ ആക്സസ് നയം പോർട്ട് നിരസിക്കുന്ന സേവനത്തിന്റെയോ പ്രഖ്യാപനം ഒരു ക്ലയന്റിന് കാണാം. പ്രഖ്യാപനം പ്രത്യക്ഷപ്പെട്ടതിന് ശേഷം സേവന ബന്ധം സ്ഥിരീകരിക്കുക, അപ്ലിക്കേഷൻ സ്ഥിരമായ DNS നാമമോ വ്യക്തമായ സെർവർ വിലാസമോ പിന്തുണയ്ക്കുന്നുവെങ്കിൽ ലിങ്ക്-ലോക്കൽ കണ്ടെത്തൽ വിപുലീകരിക്കുന്നതിന് പകരം അതിന് മുൻഗണന നൽകുക. ക്രിപ്റ്റോകീ റൂട്ടിംഗ് വിവരണം ഇതെല്ലാം ആശ്രയിക്കുന്ന ലക്ഷ്യാധിഷ്ഠിത സഹകാരി തിരഞ്ഞെടുപ്പ് ഉൾക്കൊള്ളുന്നു.