ഗസ്റ്റ് VPN-ഉം ഹോസ്റ്റ് VPN-ഉം: ഏത് റൂട്ടാണ് യഥാർത്ഥത്തിൽ ജയിക്കുന്നത്
രണ്ട് ക്ലയന്റുകൾ, രണ്ട് ഡിഫോൾട്ട് റൂട്ടുകൾ, ഒരു ആശയക്കുഴപ്പമുള്ള ലക്ഷണം. ഗസ്റ്റിന്റെ കണക്ഷൻ രേഖപ്പെടുത്തുക, അതിന്റെ അന്ത്യബിന്ദു പുറത്തേക്ക് പിന്തുടരുക, എന്നിട്ട് ഒരു സമയത്ത് ഒരു വേരിയബിൾ മാറ്റുക.
രണ്ട് ക്ലയന്റുകൾ ഒരേസമയം പ്രവർത്തിക്കുന്നു, ഓരോന്നും ഡിഫോൾട്ട് റൂട്ട് തങ്ങളുടേതാണെന്ന് ഉറച്ചു വിശ്വസിക്കുന്നു, ലക്ഷണം വിചിത്രമായ രീതിയിൽ വരുന്നു: ഗസ്റ്റിന്റെ ഒരു അപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നു, മറ്റൊന്ന് തെറ്റായ സ്ഥലത്തേക്ക് പരിഹരിക്കപ്പെടുന്നു. ഗസ്റ്റിനുള്ളിലെ VPN-ഉം ഹോസ്റ്റിലെ VPN-ഉം ഒരുമിച്ച് നിലനിൽക്കാം, എന്നാൽ പുറത്തെ പാതയും അകത്തെ നയവും ആര് എന്ത് കൊണ്ടുപോകുന്നു എന്നതിൽ യോജിക്കുമ്പോൾ മാത്രം. രണ്ടും ആരംഭിക്കുന്നത് തന്നെ ഒരു ശൃംഖല സൃഷ്ടിക്കുന്നില്ല. ആദ്യം കണക്ഷൻ രേഖപ്പെടുത്തുക, പിന്നീട് ഒരു സമയത്ത് ഒരു കാര്യം മാറ്റുക.
ആദ്യം ഗസ്റ്റിന്റെ കണക്ഷൻ രേഖപ്പെടുത്തുക
ഗസ്റ്റ് തന്റെ VPN സെർവറിൽ എത്തുന്നത് ഹൈപ്പർവൈസർ നൽകിയ പാതയിലൂടെയാണ്: ഹോസ്റ്റിന് പിന്നിലെ NAT, ഭൗതിക സെഗ്മെന്റിലേക്കുള്ള ബ്രിഡ്ജ്, അല്ലെങ്കിൽ മുകളിൽ റൂട്ടിംഗ് ചേർത്ത ഹോസ്റ്റ്-മാത്ര നെറ്റ്വർക്ക്. ഓരോ കണക്ഷനും ഗസ്റ്റിന് എന്ത് കാണാമെന്നും ഹോസ്റ്റിന് അതിന്റെ ട്രാഫിക്കിൽ എന്ത് ചെയ്യാമെന്നും മാറ്റുന്നു. NAT-ന് കീഴിൽ ഗസ്റ്റിന്റെ പാക്കറ്റുകൾ ഹോസ്റ്റിൽ നിന്ന് വരുന്നതായി തോന്നുന്നു, അതിനാൽ ഹോസ്റ്റിന്റെ സ്വന്തം ടണൽ ഗസ്റ്റിന് ഒന്നും അറിയാതെ അവ കൊണ്ടുപോകാം. ബ്രിഡ്ജിന് കീഴിൽ ഗസ്റ്റിന് സെഗ്മെന്റിൽ സ്വന്തം സാന്നിധ്യവും സ്വന്തം ഡിഫോൾട്ട് ഗേറ്റ്വേയും ഉണ്ട്.
ഏതെങ്കിലും കോൺഫിഗറേഷൻ തൊടുന്നതിന് മുമ്പ് കണക്ഷൻ രേഖപ്പെടുത്തുക, ഏത് ക്ലയന്റ് ഏത് അപ്ലിക്കേഷൻ കൊണ്ടുപോകണം എന്നതും സഹിതം. ആ വാക്യമാണ് ഇത്തരം കേസുകളിൽ ഭൂരിഭാഗവും പരിഹരിക്കുന്നത്, കാരണം രണ്ട് ക്ലയന്റുകളും സാധാരണയായി വ്യത്യസ്ത അനുമാനങ്ങളിൽ നിർമ്മിച്ചവയാണ്. ഹോസ്റ്റിന്റെ ടണൽ ഉപയോഗിക്കുമെന്ന് പ്രതീക്ഷിക്കുന്ന ഗസ്റ്റിന് സ്വന്തമായി ഒരു മത്സര ഡിഫോൾട്ട് റൂട്ടും ഉണ്ടാകരുത്.
ഗസ്റ്റിന്റെ അന്ത്യബിന്ദു പുറത്തേക്ക് പിന്തുടരുക
ഗസ്റ്റ് VPN-ന് മറ്റെന്തെങ്കിലും പ്രവർത്തിക്കുന്നതിന് മുമ്പ് സ്വന്തം സെർവറിലേക്ക് ഉപയോഗയോഗ്യമായ ഒരു പാത വേണം. ഹോസ്റ്റിന്റെ ടണൽ ഓണായിരിക്കുകയും ഗസ്റ്റ് NAT-ന് പിന്നിൽ ഇരിക്കുകയും ചെയ്യുമ്പോൾ, ഗസ്റ്റിന്റെ ഹാൻഡ്ഷേക്ക് ഹോസ്റ്റിന്റെ ടണലിലൂടെ പുറത്തുപോകുന്നു, അത് ഒന്നുകിൽ ഡിസൈൻ അല്ലെങ്കിൽ ആരും രേഖപ്പെടുത്താത്ത ഒരു അപകടമാണ്. ഹോസ്റ്റിന്റെ ടണൽ വീഴുകയും ഗസ്റ്റ് അതിനെ ആശ്രയിക്കുകയും ചെയ്താൽ, ഗസ്റ്റിന്റെ ഭാഗത്ത് ഒരു മാറ്റവുമില്ലാതെ ഗസ്റ്റിന് കണക്ടിവിറ്റി നഷ്ടമാകുന്നു. അന്ത്യബിന്ദു പുറത്തേക്ക് പിന്തുടരുന്നത് ആ രണ്ടിൽ ഏതാണ് യഥാർത്ഥത്തിൽ നിങ്ങൾക്കുള്ളതെന്ന് പറയും.
ഏത് സന്ദർഭത്തിലും വിശാലമായ ഒരു റൂട്ട് മറ്റേ ക്ലയന്റ് പ്രതീക്ഷിച്ച ട്രാഫിക് പിടിക്കുന്നു. ഗസ്റ്റിനുള്ളിലെ 0.0.0.0/0 റൂട്ടും പൂർണ്ണ ടണലുള്ള ഹോസ്റ്റ് ക്ലയന്റും രണ്ടും എല്ലാത്തിനും അവകാശം ഉന്നയിക്കുന്നു, ഒടുവിൽ ബാധകമാകുന്നത് ജയിക്കുന്നു. ഗസ്റ്റിന്റെ വെർച്വൽ നെറ്റ്വർക്കുകൾ, പ്രാദേശിക LAN, വിദൂര നെറ്റ്വർക്കുകൾ എന്നിവയ്ക്കിടയിലുള്ള ഓവർലാപ്പ് സ്വകാര്യ പ്രിഫിക്സുകൾക്ക് അതേ ഫലം നൽകുന്നു, പരാജയങ്ങൾ പ്രാമാണീകരണ പ്രശ്നങ്ങൾ പോലെ തോന്നുന്നു; വിലാസ വിവർത്തനത്തിന്റെ സ്വഭാവം കണ്ടെയ്നർ നെറ്റ്വർക്കിംഗിന് വിവരിച്ചതിന് സമാനമാണ്.
മുമ്പും ശേഷവുമുള്ള രേഖ താരതമ്യം ചെയ്യുക
ഹോസ്റ്റിന്റെ ടണൽ ഓഫായിരിക്കുകയോ നിങ്ങളുടെ നയം അനുവദിക്കുന്ന ഏതെങ്കിലും നിയന്ത്രിത അവസ്ഥയിലോ അടിസ്ഥാനരേഖ എടുത്ത് ഗസ്റ്റിന്റെ റൂട്ടും പരിഹാരകവും രേഖപ്പെടുത്തുക. തുടർന്ന് സംയോജിത കോൺഫിഗറേഷൻ പ്രയോഗിച്ച് രണ്ട് രേഖകളും താരതമ്യം ചെയ്യുക, സ്വകാര്യതാ ആവശ്യകതകൾ അക്ഷതമായി നിലനിർത്തി. നേരിട്ടുള്ള അടിസ്ഥാനരേഖ അനുയോജ്യമല്ലെങ്കിൽ, താരതമ്യം ഒഴിവാക്കുന്നതിന് പകരം ആ പരിധി രേഖയിൽ എഴുതുക.
ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12
റൂട്ട് ക്വറി ഒരു നിർദ്ദിഷ്ട ലക്ഷ്യസ്ഥാനം കൊണ്ടുപോകുന്ന ഇന്റർഫേസും സ്രോതസ്സ് വിലാസവും പേരിടുന്നു, ഈ അന്വേഷണത്തിലെ ഏറ്റവും ഉപയോഗപ്രദമായ വരിയാണത്. നിയമങ്ങളുടെ പട്ടിക ചില ലക്ഷ്യസ്ഥാനങ്ങൾ രണ്ടാമത്തെ പട്ടികയിലൂടെ അയയ്ക്കുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. പരിഹാരകത്തിന്റെ ഔട്ട്പുട്ട് DNS ഗസ്റ്റിന്റെ ടണൽ പിന്തുടർന്നോ ഹോസ്റ്റിന്റെ പാതയിൽ തുടർന്നോ എന്ന് കാണിക്കുന്നു. അതേ മൂന്ന് കമാൻഡുകൾ മാറ്റത്തിന് മുമ്പും ശേഷവും പ്രവർത്തിപ്പിക്കുക, വ്യത്യാസം കുറ്റവാളിയെ പേരിടും.
പുനരാരംഭങ്ങൾക്കിടയിലും ഉടമസ്ഥത വ്യക്തമാക്കി നിർത്തുക
ഹോസ്റ്റ് ക്ലയന്റിന്റെ പ്രാദേശിക ആക്സസ് നിയന്ത്രണം വെർച്വൽ NAT-ലേക്കോ ബ്രിഡ്ജിലേക്കോ ഉള്ള ട്രാഫിക് തടയാം, ആ നിയന്ത്രണം പലപ്പോഴും ഗസ്റ്റിന്റെ ക്രെഡൻഷ്യൽ പ്രശ്നമായി തെറ്റിദ്ധരിക്കപ്പെടുന്നു. പരീക്ഷണം കടത്തിവിടാൻ നിയന്ത്രണം നിർജ്ജീവമാക്കുന്നതിന് പകരം ക്ലയന്റിന്റെ രേഖപ്പെടുത്തിയ സ്വഭാവം വായിക്കുക. പിന്തുണയുള്ള തിരുത്തലിന് ശേഷം ഗസ്റ്റ് അപ്ലിക്കേഷനും നിങ്ങൾ ആവശ്യപ്പെടുന്ന പരാജയ നയവും വീണ്ടും പരിശോധിക്കുക. വിജയകരമായി വീണ്ടും ബന്ധിപ്പിക്കുന്ന ഹോസ്റ്റ് ഗസ്റ്റിന്റെ റൂട്ടിനെയോ പരിഹാരകത്തെയോ കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല.
ഏത് വശമാണ് ഡിഫോൾട്ട് റൂട്ടിന്റെ ഉടമ എന്ന് തീരുമാനിച്ച് അത് പ്രവർത്തന പുസ്തകത്തിൽ എഴുതുക. ഗസ്റ്റിന്റെ പുനരാരംഭമോ ഉടമസ്ഥത നിശബ്ദമായി തലകീഴാക്കുന്ന ഹോസ്റ്റിലെ നെറ്റ്വർക്ക് മാറ്റമോ ഒരിക്കലും കുറ്റക്കാരനല്ലാത്ത ഒരു VPN-നെക്കുറിച്ചുള്ള ബഗ് റിപ്പോർട്ട് സൃഷ്ടിക്കുന്നു. എന്തുകൊണ്ട് അത് പ്രവർത്തിച്ചു എന്ന് ആരും ഓർക്കാതെയും ക്രമീകരണം റീബൂട്ടിനെ അതിജീവിക്കണം.