VPN ബന്ധിപ്പിക്കുമ്പോൾ Vagrant VM അപ്രത്യക്ഷമാകുന്നു: പൊട്ടിയ റൂട്ട് ആരുടേത്

യന്ത്രം ഒരു മിനിറ്റ് മുൻപ് ഉത്തരം നൽകിയിരുന്നു, VPN ബന്ധിച്ചു, ഇപ്പോൾ അതേ വിലാസം സമയപരിധി കവിയുന്നു. മൂന്ന് തകരാറുകൾ ഈ ലക്ഷണം ഉണ്ടാക്കുന്നു, അവ വ്യത്യസ്ത യന്ത്രങ്ങളിൽ കഴിയുന്നു. ഹോസ്റ്റിന് സ്വകാര്യ നെറ്റ്‌വർക്കിലേക്കുള്ള റൂട്ട് നഷ്ടപ്പെടാം, അതിഥിയുടെ NAT ശ്രേണി ടണൽ ഇപ്പോൾ പ്രഖ്യാപിക്കുന്ന ശ്രേണിയുമായി കൂട്ടിയിടിക്കാം, അല്ലെങ്കിൽ പൂർണ ടണൽ ഹോസ്റ്റിലെ എല്ലാ റൂട്ടുകളുടെയും ഉടമസ്ഥത ഏറ്റെടുക്കാം. ഏതെങ്കിലും ക്രമീകരണം മാറ്റുന്നതിന് മുൻപ് ഏതാണ് സംഭവിച്ചതെന്ന് കണ്ടെത്തുക, കാരണം ഓരോ പരിഹാരവും വേറെ എവിടെയോ കഴിയുന്നു.

റൂട്ട് നോക്കുക, യന്ത്രമല്ല

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

ബന്ധിപ്പിക്കുന്ന കൃത്യ നിമിഷത്തിൽ വീഴുന്ന SSH സെഷൻ പ്രതീക്ഷിത സ്വഭാവമാണ്. ക്ലയന്റ് അഡാപ്റ്ററുകൾ പുനരുപയോഗിച്ച് റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതിനാൽ ബന്ധം കുറച്ച് സെക്കൻഡ് മരിക്കുന്നു. തകരാറ് ഒരിക്കലും തിരികെ വരാത്ത ബന്ധമാണ്, ഒരു നിമിഷം മിന്നിയതല്ല.

ടണലിന് മുൻപ് പട്ടിക പിടിച്ചെടുക്കുക, അതിന് ശേഷം വീണ്ടും, എന്നിട്ട് ആ രണ്ട് ഔട്ട്പുട്ടുകൾ താരതമ്യം ചെയ്യുക. വ്യത്യാസമാണ് നിർണ്ണയം, അത് നെറ്റ്‌വർക്ക് ഉടമ ആവശ്യപ്പെടുന്ന തെളിവുമാണ്.

ip -4 route get 192.168.56.10
ip -brief addr show
ip route show table main | head -20

ബന്ധിപ്പിക്കുന്നതിന് മുൻപും ശേഷവും ഹോസ്റ്റിന്റെ പട്ടിക വായിക്കുക

ലിനക്സിൽ ഓവർലാപ്പ് ചെയ്യുന്ന റൂട്ടുകൾ തമ്മിലുള്ള മുൻഗണന പ്രിഫിക്സ് നീളത്തിലും മെട്രിക്കിലും നിന്നാണ്, അതിനാൽ കൂടുതൽ നിർദ്ദിഷ്ട VPN റൂട്ട് തെറ്റായാലും വിജയിക്കും. വിൻഡോസിൽ ഇന്റർഫേസ് മെട്രിക് സമനില തീരുമാനിക്കുന്നു, ടണൽ അഡാപ്റ്റർ സാധാരണയായി വെർച്വലിനേക്കാൾ കുറഞ്ഞ മെട്രിക്കോടെ വരുന്നു. രണ്ട് സാഹചര്യങ്ങളിലും കാണുന്ന ലക്ഷണം ഒന്നുതന്നെ: പാക്കറ്റുകൾ ടണൽ അഡാപ്റ്ററിലൂടെ പുറത്തുപോയി അപ്രത്യക്ഷമാകുന്നു.

അതിഥി പ്രിഫിക്സിന്റെ റൂട്ടിന് അരികിൽ അഡാപ്റ്ററുകളും അവയുടെ മെട്രിക്കുകളും പ്രിന്റ് ചെയ്യുക. ആ ഔട്ട്പുട്ട് ജോടി ഉടമസ്ഥതയുടെ ചോദ്യത്തിന് ഒരു നോട്ടത്തിൽ ഉത്തരം നൽകുന്നു.

Get-NetAdapter | Select-Object Name, InterfaceIndex, InterfaceMetric
Get-NetRoute -DestinationPrefix 192.168.56.0/24
route print -4 | Select-String '192.168.56'

റൂട്ട് മാറിയെങ്കിലും അഡാപ്റ്റർ മെട്രിക് മാറിയില്ലെങ്കിൽ, ക്ലയന്റ് ഒരു മത്സര റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്തു. മെട്രിക് മാറിയെങ്കിൽ, ക്ലയന്റ് അഡാപ്റ്ററുകൾ പുനഃക്രമീകരിച്ചു. രണ്ടും പരിഹരിക്കാം, രണ്ടും വ്യത്യസ്ത സ്ഥലങ്ങളിൽ പരിഹരിക്കുന്നു.

അതിഥിയുടെ NAT ശ്രേണി കൂട്ടിയിടിയാകുമ്പോൾ

VirtualBox NAT സ്വതവേ 10.0.2.0/24 ഉപയോഗിക്കുന്നു, അതേ ശ്രേണി തള്ളുന്ന ടണൽ അതിഥിയെ ആ ട്രാഫിക് യഥാർത്ഥ ലക്ഷ്യത്തിലേക്കല്ല, സ്വന്തം NAT ഗേറ്റ്‌വേയിലേക്ക് അയക്കാൻ നിർബന്ധിക്കുന്നു. പാക്കറ്റ് ഒരിക്കലും ഹോസ്റ്റ് വിടുന്നില്ല, അതിനാൽ മറുവശത്തെ ഒരു ഫയർവാൾ ലോഗും അത് കാണിക്കില്ല. Docker Machine-ന്റെ ഹോസ്റ്റ്-മാത്ര പ്ലാനിലും ഇതേ വിഭാഗത്തിലുള്ള സംഘർഷമുണ്ട്, ആ പ്ലാൻ മാറ്റാൻ യന്ത്രം അതിന്റെ സർട്ടിഫിക്കറ്റുകളോടെ വീണ്ടും നിർമ്മിക്കേണ്ടിവന്നേക്കാം.

ടണൽ ഇതിനകം പ്രഖ്യാപിക്കുന്നത്, പിന്നെ ഓഫീസ് നെറ്റ്‌വർക്ക് ഉപയോഗിക്കുന്നത്, പിന്നെ ഈ ഹോസ്റ്റിലെ ഓരോ വെർച്വൽ അഡാപ്റ്ററും ആവശ്യപ്പെട്ടത് എന്നിവ പട്ടികപ്പെടുത്തി പകരം തിരഞ്ഞെടുക്കുക. റൂട്ടിംഗ് തകർക്കുന്നത് ഓവർലാപ്പാണ്, സാദൃശ്യത്തിന് പ്രസക്തിയില്ല. ഒരു ശ്രേണി മറ്റൊന്നിന്റെ ഉള്ളിൽ പൂർണമായി ഇരിക്കാം, എന്നാൽ ഒറ്റനോട്ടത്തിൽ ഒട്ടും സാദൃശ്യമില്ല.

യന്ത്രം നിർമ്മിക്കുമ്പോൾ പുതിയ ശ്രേണി സജ്ജമാക്കുക, അല്ലെങ്കിൽ അത് മാറ്റി വീണ്ടും ലോഡ് ചെയ്യുക, എന്നിട്ട് പരാജയപ്പെടുന്ന ബന്ധം അതിഥിയിൽ നിന്ന് വീണ്ടും പരിശോധിക്കുക. അതിഥിയുടെ സ്വന്തം പട്ടികയാണ് പ്രധാനമായ കാഴ്ച.

VBoxManage modifyvm devbox --natnet1 10.77.0.0/24
vagrant reload devbox --provision
vagrant ssh devbox -c 'ip route get 10.20.0.15'

ക്ലയന്റുമായി പോരാടാതെ പാത പുനഃസ്ഥാപിക്കുക

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

ബൂട്ടിൽ അന്ധമായി വീണ്ടും ബന്ധിപ്പിക്കുന്നതിന് പകരം പരിശോധന സ്ക്രിപ്റ്റ് ചെയ്യുക. ഓരോ ബന്ധത്തിനും ശേഷം അതിഥി പ്രിഫിക്സിന്റെ റൂട്ട് പ്രിന്റ് ചെയ്യുന്ന ചെറിയ സ്ക്രിപ്റ്റ് ഒരു രഹസ്യത്തെ ലോഗിലെ ഒരു വരിയാക്കുന്നു.

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

പരിഹാരം ഇരുവശത്തും പരിശോധിക്കുക

മാറ്റത്തിന് ശേഷം മൂന്ന് പാതകൾ പരിശോധിക്കുക: ഹോസ്റ്റിൽ നിന്ന് അതിഥിയിലേക്ക്, അതിഥിയിൽ നിന്ന് കോർപ്പറേറ്റ് ഹോസ്റ്റിലേക്ക്, അതിഥിയിൽ നിന്ന് ഇന്റർനെറ്റിലേക്ക്. ഒന്ന് പുനഃസ്ഥാപിച്ച് മറ്റൊന്ന് തകർക്കുന്ന പരിഹാരം അറ്റകുറ്റപ്പണിയുടെ വേഷത്തിലുള്ള ക്രമീകരണ മാറ്റമാണ്. താരതമ്യം തുല്യമായിരിക്കാൻ മാറ്റത്തിന് മുൻപ് ശേഖരിച്ച അതേ ഔട്ട്പുട്ടുകൾ പിടിച്ചെടുക്കുക.

മാറിയ ഇന്റർഫേസ്, മെട്രിക്, റൂട്ട് എന്നിവ സമയത്തോടൊപ്പം രേഖപ്പെടുത്തുക, അടുത്ത സംഭവം പുനർനിർമ്മാണമല്ല, തിരയലാകാൻ. ആ കുറിപ്പ് നീണ്ട ടിക്കറ്റ് ത്രെഡിനേക്കാൾ വിലയുള്ളതാണ്.

ip -4 route get 192.168.56.10
traceroute -n -m 4 10.20.0.15
curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

ഹോസ്റ്റ് വീണ്ടും അതിഥിയിലെത്തി അതിഥി LAN-ൽ എത്തുമ്പോൾ, നിങ്ങൾ തുടങ്ങിയ പാത പുനഃസ്ഥാപിച്ചിരിക്കുന്നു. അവയിൽ ഒന്ന് മാത്രം പ്രവർത്തിക്കുമ്പോൾ, ബാക്കിയുള്ള തകരാറ് മറ്റേ ഉടമയുടെ പ്രദേശത്താണ്, വ്യത്യാസം ഏത് പ്രദേശമെന്ന് പറയുന്നു.