OpenVPN ക്ലയന്റ് ഒരു വിലാസത്തിൽ ഡയൽ ചെയ്യുന്നു, സർവർ മറ്റൊരു വിലാസത്തിൽ നിന്ന് ഉത്തരം നൽകുന്നു, ടണൽ ഒരിക്കലും ഉയരുന്നില്ല. സർവർ ലോഗ് പാക്കറ്റ് വരുന്നത് കാണിക്കുന്നു, ക്യാപ്ചർ ഉത്തരം പോകുന്നത് കാണിക്കുന്നു, അതിനാൽ തകരാർ ക്ലയന്റിന്റെ മേൽ ആരോപിക്കപ്പെടുന്നു. പല ഇന്റർഫേസുകളുള്ള ഹോസ്റ്റിലോ ഒരു ഇന്റർഫേസിൽ പല വിലാസങ്ങളുള്ളപ്പോഴോ, ഏത് വിലാസമാണ് ഉപയോഗിക്കുന്നത് എന്നതിൽ ഇരുവശവും യോജിക്കുന്നില്ല. ഉത്തരം IP പാളിയിൽ സാധുവാണ്, എന്നിട്ടും ബന്ധപ്പെട്ട വിലാസമല്ല ഉറവിടമായുള്ള ഡാറ്റാഗ്രാം പല ക്ലയന്റുകളും ഉപേക്ഷിക്കുന്നു.

ഉറവിടം മാറുമ്പോൾ ക്ലയന്റ് എന്ത് കാണുന്നു

നിർദ്ദിഷ്ട പ്രാദേശിക വിലാസത്തോട് ബന്ധിക്കാത്ത UDP സോക്കറ്റിന് സ്ഥിരമായ ഉറവിടമില്ല, അതിനാൽ കെർണൽ അയയ്ക്കുമ്പോൾ ഒന്ന് തിരഞ്ഞെടുക്കുന്നു. ആ തിരഞ്ഞെടുപ്പ് ക്ലയന്റിന്റെ വിലാസത്തിലേക്കുള്ള റൂട്ട് തിരയലിൽ നിന്ന് വരുന്നു, ഉറവിടം തിരയൽ തിരഞ്ഞെടുക്കുന്ന ഇന്റർഫേസിന്റെ വിലാസമാകുന്നു. ഒരു ഇന്റർഫേസുള്ള യന്ത്രത്തിൽ തിരഞ്ഞെടുപ്പ് അദൃശ്യമാണ്; മാനേജ്മെന്റ് വിലാസം, പൊതു വിലാസം, അതേ നെറ്റ്വർക്ക് കാർഡിലെ ദ്വിതീയ വിലാസം എന്നിവയുള്ള ഹോസ്റ്റിൽ അത് റൂട്ടിംഗ് മെട്രിക്കുകളെയും നയത്തെയും ആശ്രയിച്ചിരിക്കുന്നു. നയാധിഷ്ഠിത റൂട്ടിംഗ് പൊരുത്തക്കേട് കുറയ്ക്കുന്നതിനു പകരം കൂട്ടുന്നു, കാരണം ഒരു നിയമത്തിന് ക്ലയന്റ് ഒരിക്കലും എത്താത്ത മേൽഭാഗ ലിങ്ക് തിരഞ്ഞെടുക്കാനാകും. ഒരു ദാതാവിൽ നിന്ന് പഠിച്ച സ്ഥിരസ്ഥിത റൂട്ടും മറ്റൊന്നിലേക്ക് ചൂണ്ടുന്ന ഉറവിട നിയമവും അത് സൃഷ്ടിക്കാൻ മതി.

മറുപടികൾ ഫിൽട്ടർ ചെയ്യുന്ന ക്ലയന്റുകളും കൃത്യമായ നാലെണ്ണവും ഉറവിടവും പ്രതീക്ഷിക്കുന്ന കണക്ഷൻ ട്രാക്കിംഗും ഉപയോഗപ്രദമായ സന്ദേശമില്ലാതെ മറുപടി ഉപേക്ഷിക്കും. തുടർന്ന് ടണൽ ഒന്നും വന്നിട്ടില്ലാത്തതുപോലെ സമയം കഴിഞ്ഞ് അവസാനിക്കുന്നു, അതുകൊണ്ടാണ് ഇത് ക്ലയന്റ് ഭാഗത്തെ ഫയർവാൾ പ്രശ്നമായി തെറ്റായി കരുതുന്നത്. സർവറിൽ മാത്രം എടുത്ത ക്യാപ്ചർ പിശക് വിശദീകരിക്കുന്നതിനു പകരം സ്ഥിരീകരിക്കുന്നു, കാരണം മറുപടി യഥാർത്ഥത്തിൽ പോകുന്നു. മറ്റെന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് മറുപടിയുടെ ഉറവിടം ക്ലയന്റ് ഡയൽ ചെയ്ത വിലാസവുമായി താരതമ്യം ചെയ്യുക.

multihome ഓപ്ഷൻ യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

ഈ നിർദ്ദേശം കോൺഫിഗറേഷൻ ഫയലിൽ multihome ആയും കമാൻഡ് ലൈനിൽ --multihome ആയും എഴുതുന്നു, അത് ക്ലയന്റിന്റെ പാക്കറ്റ് എത്തിയ വിലാസത്തിൽ നിന്ന് UDP സർവർ മറുപടി നൽകാൻ നിർബന്ധിക്കുന്നു. സ്വീകരിക്കുമ്പോൾ കെർണൽ യഥാർത്ഥ ലക്ഷ്യ വിലാസം അനുബന്ധ ഡാറ്റയായി നൽകുന്നു, OpenVPN ആ മൂല്യം മറുപടിയുടെ ഉറവിടമായി ഉപയോഗിക്കുന്നു. അങ്ങനെ വൈൽഡ്കാർഡ് വിലാസത്തിൽ കേൾക്കുന്ന സർവർ, IPv4 ന് local 0.0.0.0 അല്ലെങ്കിൽ അതിന്റെ IPv6 തുല്യം, ഓരോ ക്ലയന്റും പ്രത്യേക ശ്രോതാവിനെ എത്തിയതുപോലെ പെരുമാറുന്നു. പൊതു വിലാസത്തിലൂടെ വന്ന ക്ലയന്റുകൾക്ക് പൊതു വിലാസത്തിൽ നിന്ന് മറുപടി ലഭിക്കുന്നു, ആന്തരിക വിലാസത്തിലുള്ള ക്ലയന്റുകൾക്ക് ആ വിലാസത്തിൽ നിന്ന് ലഭിക്കുന്നു. പാക്കറ്റ് പാതയിൽ മറ്റൊന്നും ചലിക്കുന്നില്ല: റൂട്ട്, ഫിൽട്ടർ നിയമങ്ങൾ, ടണൽ കോൺഫിഗറേഷൻ എന്നിവ ഉണ്ടായിരുന്നതുപോലെ തന്നെ തുടരുന്നു.

ഈ അവസാന സ്വഭാവമാണ് ഓപ്ഷൻ മറ്റു കാര്യങ്ങളിൽ പ്രവർത്തിക്കുന്ന സർവറിലേക്ക് ചേർക്കാൻ സുരക്ഷിതമാക്കുന്നത്, ഒരു വിലാസത്തിന് മാത്രം അനുമതി നൽകുന്ന ഫിൽട്ടർ അതിന് ശരിയാക്കാൻ കഴിയാത്തതിന്റെ കാരണവുമത്. പാക്കറ്റ് ഇപ്പോഴും അത് പോകുന്ന പാതയിൽ സ്വീകരിക്കേണ്ടതുണ്ട്, അതിനാൽ ഉറവിട തിരുത്ത് മറുപടിയുടെ ഉത്ഭവം മാറ്റുന്നു, അത്രമാത്രം. ഇത് UDP-ക്ക് മാത്രമാണ്: TCP ശ്രോതാവിന് ഇതേ രൂപത്തിൽ ഈ പ്രശ്നമില്ല, കാരണം കണക്ഷൻ മറുപടിയുടെ ഉറവിട വിലാസത്താലല്ല, നാലെണ്ണത്താൽ തിരിച്ചറിയുന്നു.

സ്ഥിര പ്രാദേശിക വിലാസം എപ്പോഴാണ് തെറ്റായ സ്ഥിരസ്ഥിതി

ഓപ്ഷനിലേക്ക് പോകുന്നതിന് മുമ്പ്, സർവർ ഒരു നിർദ്ദിഷ്ട പ്രാദേശിക വിലാസം ബന്ധിക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുക, കാരണം ബന്ധിത ശ്രോതാവ് എപ്പോഴും ആ വിലാസത്തിൽ നിന്ന് മറുപടി നൽകുന്നു. ഇത് ഒരു ഇന്റർഫേസുള്ള വിന്യാസത്തിന് ശരിയാണ്, ക്ലയന്റുകൾ നിയമാനുസൃതമായി ഒന്നിലധികം വിലാസങ്ങൾ ഉപയോഗിക്കുന്ന നിമിഷം തെറ്റാകുന്നു. ബന്ധനം ഉദ്ദേശപൂർവമായിരുന്നെങ്കിൽ, അധിക വിലാസങ്ങളിൽ സർവർ ട്രാഫിക് സ്വീകരിക്കണോ എന്ന് തീരുമാനിക്കുക. ബന്ധനം നീക്കുന്നത് എക്സ്പോഷർ വർദ്ധിപ്പിക്കുന്നു, അതിനാൽ അനുവദിച്ച ഇന്റർഫേസുകളും ഉറവിട നെറ്റ്വർക്കുകളും സേവനവും ഫിൽട്ടറും നടപ്പാക്കണം, ബന്ധന വിലാസം മാത്രമല്ല.

OpenVPN റഫറൻസ് ഓപ്ഷനെ UDP സർവറുകളിൽ പരിമിതപ്പെടുത്തുന്നു, പാക്കറ്റ് പാതയിലെ അധിക പ്രോസസ്സിംഗ് സൂചിപ്പിക്കുന്നു, ഏത് പ്ലാറ്റ്ഫോമുകൾ അത് പിന്തുണയ്ക്കുന്നു എന്ന് രേഖപ്പെടുത്തുന്നു. അതിന്റെ അടിസ്ഥാനത്തിൽ ആസൂത്രണം ചെയ്യുന്നതിന് മുമ്പ് ഇൻസ്റ്റാൾ ചെയ്ത പതിപ്പിൽ അത് സ്ഥിരീകരിക്കുക. പിന്തുണയില്ലാത്തിടത്ത്, നിർദ്ദിഷ്ട വിലാസം ബന്ധിക്കുന്നതോ തിരിച്ചുവരവ് റൂട്ട് ശരിയാക്കുന്നതോ ആണ് ബദൽ, രണ്ടും ഒറ്റനോട്ടത്തിൽ തോന്നുന്നതിലും ഇടുങ്ങിയ മാറ്റങ്ങളാണ്. വൈൽഡ്കാർഡിൽ കേൾക്കുന്നതിന് മറുപടികൾക്കപ്പുറവും പ്രത്യാഘാതങ്ങളുണ്ട്: എല്ലാ വിലാസങ്ങളിലുമുള്ള സർവർ ഹോസ്റ്റ് ബന്ധിപ്പിച്ചിരിക്കുന്ന ഓരോ നെറ്റ്വർക്കിൽ നിന്നും എത്താവുന്നതാണ്, അത് ആരും ഉദ്ദേശിച്ച എക്സ്പോഷർ ആയിരിക്കണമെന്നില്ല.

മറുപടിയുടെ ഉറവിടം പുറത്തുനിന്ന് തെളിയിക്കുക

സർവറിന് പുറത്തുനിന്ന് പരിശോധിക്കുക, എന്തെങ്കിലും ക്യാപ്ചർ ചെയ്യുന്നതിന് മുമ്പ് ക്ലയന്റ് ഉപയോഗിച്ച കൃത്യമായ വിലാസവും ഗതാഗതവും രേഖപ്പെടുത്തുക. താഴെയുള്ള മൂന്ന് പരിശോധനകൾ മൂന്ന് വ്യത്യസ്ത ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നു, ക്രമം പ്രധാനമാണ്.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

ക്യാപ്ചർ മറുപടിയിലെ ഉറവിട വിലാസം കാണിക്കുന്നു, ലേഖനം മുഴുവൻ ഈ വസ്തുതയിൽ നിൽക്കുന്നു. സോക്കറ്റ് പട്ടിക സർവർ യഥാർത്ഥത്തിൽ എന്ത് ബന്ധിച്ചു എന്ന് കാണിക്കുന്നു, കാരണം വൈൽഡ്കാർഡ് ശ്രോതാവും നിർദ്ദിഷ്ട ശ്രോതാവും കോൺഫിഗറേഷൻ ഫയലിൽ ഒരുപോലെ കാണപ്പെടുന്നു, നെറ്റ്വർക്കിൽ വ്യത്യസ്തമായി പെരുമാറുന്നു. റൂട്ട് തിരയൽ ആ ഫ്ലോയ്ക്ക് കെർണൽ തിരഞ്ഞെടുക്കുന്ന ഉറവിടം കാണിക്കുന്നു, അത് എന്തെങ്കിലും മാറ്റുന്നതിന് മുമ്പ് ക്യാപ്ചർ വിശദീകരിക്കുന്നു. മൂന്നും IPv4, IPv6 എന്നിവയ്ക്ക് വെവ്വേറെ ആവർത്തിക്കുക, അവ വെവ്വേറെ ശ്രോതാക്കളും വെവ്വേറെ തിരയലുകളുമാണ്, ഒരു കുടുംബത്തിനുള്ള വൈൽഡ്കാർഡ് എൻട്രി മറ്റൊന്നിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

റൂട്ടിംഗ്, കണ്ടെത്തൽ, ഫിൽട്ടറിംഗ് വെവ്വേറെ തുടരുന്നു

മറുപടിയുടെ ഉറവിടം സംരക്ഷിക്കുന്നത് പുറത്തേക്കുള്ള റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്നില്ല, ഡൈനാമിക് DNS അപ്ഡേറ്റ് ചെയ്യുന്നില്ല, ഒരു വിലാസ കുടുംബം മറ്റൊന്ന് സ്വീകരിക്കാൻ നിർബന്ധിക്കുന്നുമില്ല. പല മേൽഭാഗ ലിങ്കുകളുള്ള സർവറിൽ ഓരോ ഉറവിടത്തിനും തിരിച്ചുവരവ് പാത ബോധപൂർവം യോജിപ്പിക്കേണ്ടതുണ്ട്, അല്ലെങ്കിൽ മറുപടികൾ ക്ലയന്റിന്റെ ഫിൽട്ടർ ഒരിക്കലും അനുവദിക്കാത്ത ഇന്റർഫേസിലൂടെ പുറത്തുപോകുന്നു. അതുപോലെ, പ്രിഫിക്സ് മാറിയതിന് ശേഷമുള്ള പുതിയ വിലാസം ക്ലയന്റുകളിലെത്തണം കണ്ടെത്തലിലൂടെയും പിന്തുണയുള്ള വീണ്ടും-ബന്ധിപ്പിക്കൽ പ്രവാഹത്തിലൂടെയും, പഴയ റെക്കോർഡിലൂടെയല്ല.

സർവർ ഐഡന്റിറ്റി പരിശോധനകളും സർട്ടിഫിക്കറ്റ് സ്ഥിരീകരണവും ഉള്ളതുപോലെ തന്നെ വിടുക, കാരണം മാറിയ വിലാസം സ്ഥിരീകരിക്കാത്ത പങ്കാളിയെ സ്വീകരിക്കുന്നത് ന്യായീകരിക്കുന്നില്ല. മറുപടി ഇപ്പോൾ ഉദ്ദേശിച്ച ഉറവിടത്തിൽ നിന്ന് പോകുന്നുണ്ടെങ്കിലും ടണൽ ഇപ്പോഴും പരാജയപ്പെടുന്നെങ്കിൽ, ഉറവിട പ്രശ്നം പരിഹരിച്ചതായി കണക്കാക്കി മുന്നോട്ട് പോകുക. അടുത്തതായി കാണുന്ന പിശക് റൂട്ടിംഗ്, ഫിൽട്ടറിംഗ് അല്ലെങ്കിൽ പ്രാമാണീകരണത്തിന്റേതാണ്, ശ്രോതാവ് വീണ്ടും മാറ്റുന്നത് അതിലെത്തില്ല. ക്ലയന്റ് ഡയൽ ചെയ്ത വിലാസത്തിന് സമീപം ടിക്കറ്റിൽ മറുപടിയുടെ ഉറവിടം എഴുതുക, അടുത്ത വ്യക്തിക്ക് അതേ വസ്തുത ഒരു കമാൻഡിൽ പരിശോധിക്കാനാകും.

അനുബന്ധ ലേഖനങ്ങൾ