VPN ഓണാണ്, VM എത്തിപ്പെടാനാകുന്നില്ലേ? പാത ഒരിക്കലും പ്രശ്നമായിരുന്നിരിക്കില്ല

VPN ബന്ധിപ്പിക്കുക, ഒരു മിനിറ്റ് മുമ്പ് പ്രതികരിച്ചിരുന്ന വികസന VM നിശ്ശബ്ദമാകുന്നു. വ്യക്തമായ കഥ സ്വയം എഴുതപ്പെടുന്നു: ടണൽ പാത ഏറ്റെടുത്തു, ഹോസ്റ്റ് ഇപ്പോൾ അതിഥി ട്രാഫിക് കോർപ്പറേറ്റ് നെറ്റ്വർക്കിലേക്ക് അയയ്ക്കുന്നു, പരിഹാരം സ്റ്റാറ്റിക് റൂട്ട് ചേർക്കുകയോ അഡാപ്റ്റർ ബ്രിഡ്ജ് മോഡിലേക്ക് മാറ്റുകയോ ആണ്. ആ കഥ ചിലപ്പോൾ ശരിയാണ്. പക്ഷേ അത് സാധാരണ കാരണമല്ല, അതിനെ അടിസ്ഥാനമാക്കി ആദ്യം പ്രവർത്തിക്കുന്നത് സാധാരണയായി മറ്റെന്തെങ്കിലും തകർക്കുന്നു.

host-only നെറ്റ്വർക്കിംഗ് ഹോസ്റ്റിന്റെ ഉടമസ്ഥതയിലുള്ളതും അതിന്റെ അതിഥികളുമായി പങ്കിടുന്നതുമായ ഒരു സോഫ്റ്റ്വെയർ നെറ്റ്വർക്കാണ്, ഏതെങ്കിലും ഭൗതിക കണക്ഷനിൽ നിന്ന് വേർതിരിച്ചത്. VPN ക്ലയന്റിന്റെ സ്വന്തം ഇന്റർഫേസിൽ ഒന്നും ആ നെറ്റ്വർക്ക് മാറ്റുന്നില്ല, അതിനാൽ അത് തൊടുന്നതിന് മുമ്പ് നാല് പാളികളിൽ ഏതാണ് യഥാർത്ഥത്തിൽ പരാജയപ്പെട്ടതെന്ന് കണ്ടെത്തുക.

പാത സാധാരണയായി ഇപ്പോഴും പ്രാദേശികമാണ്

റൂട്ടിംഗ് ടേബിളിന്റെ ആദ്യ പേജിന് പകരം കെർണലിനോട് ചോദിക്കുക. Linux-ൽ ip route get 192.168.56.10 ഉപയോഗിക്കുന്ന കൃത്യമായ റൂട്ട്, ഇന്റർഫേസ്, ഉറവിട വിലാസം എന്നിവ റിപ്പോർട്ട് ചെയ്യുന്നു, ഇത് ഡിഫോൾട്ട് റൂട്ട് വായിച്ച് ഊഹിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്തമായ ഉത്തരമാണ്. ഔട്ട്പുട്ട് host-only ഇന്റർഫേസ് പേരിട്ടാൽ, ആ പാതയിൽ ടണൽ ഒട്ടും പങ്കെടുക്കുന്നില്ല.

രണ്ട് കാര്യങ്ങൾക്ക് അത് ശരിക്കും തകർക്കാനാകും, രണ്ടും VPN അല്ല, വിലാസ പ്രശ്നങ്ങളാണ്. host-only പ്രിഫിക്സുമായി ഓവർലാപ്പ് ചെയ്യുന്ന ദൂരസ്ഥ ഉപനെറ്റ്വർക്ക് കൂടുതൽ നിർദ്ദിഷ്ട റൂട്ടിനെ വിജയിക്കാൻ അനുവദിക്കുന്നു, കൂടാതെ താഴ്ന്ന മെട്രിക് ഉള്ള വിശാല റൂട്ട് ഇൻസ്റ്റാൾ ചെയ്യുന്ന VPN ക്ലയന്റിന് പ്രിഫിക്സ് വലിച്ചെടുക്കാനാകും. രണ്ടും ഒരേ കമാൻഡിൽ കാണാം: ഔട്ട്പുട്ടിൽ പേരിടുന്ന ഇന്റർഫേസ് ടണലായിരിക്കും, തിരുത്ത് ആ വിലാസ പ്ലാനിന്റെ ഉടമയുടേതാണ്.

റൂട്ട് തിരഞ്ഞെടുപ്പും പാക്കറ്റ് സ്വീകരണവും വ്യത്യസ്ത തീരുമാനങ്ങളാണ്

മാനസിക മാതൃക സാധാരണയായി വിട്ടുപോകുന്ന ഭാഗമാണിത്. തികഞ്ഞ പ്രാദേശിക റൂട്ട് ഉണ്ടായാലും VPN ക്ലയന്റിന് പാക്കറ്റ് നിരസിക്കാനാകും. പല ക്ലയന്റുകളും ടണലിന് പുറത്ത് ഏത് ലക്ഷ്യങ്ങൾ അനുവദനീയമെന്ന് തീരുമാനിക്കുന്ന പ്രാദേശിക നെറ്റ്വർക്ക് ആക്സസ് നയം നടപ്പാക്കുന്നു, ബന്ധിപ്പിച്ച ഉപനെറ്റ്വർക്ക് ആ പട്ടിക സ്വയം പുതുക്കുന്നുമില്ല.

അതിനാൽ പരാജയം ആപ്ലിക്കേഷന്റെ ഭാഗത്തുനിന്ന് റൂട്ടിംഗ് പ്രശ്നത്തോട് സമാനമായി തോന്നുന്നു, ക്ലയന്റിന്റെ ഭാഗത്തുനിന്ന് തികച്ചും വ്യത്യസ്തവും. ip route get ശരിയായ ഇന്റർഫേസ് പേരിട്ടിട്ടും കണക്ഷൻ സമയം കഴിഞ്ഞാൽ, റൂട്ടുകൾ തിരുത്തുന്നത് നിർത്തി പകരം ക്ലയന്റിന്റെ രേഖപ്പെടുത്തിയ പ്രാദേശിക ആക്സസ് സ്വഭാവം വായിക്കുക. ചില ക്ലയന്റുകൾ പ്രാദേശിക ഉപനെറ്റ്വർക്കുകൾക്ക് അനുവദനീയ പട്ടിക നൽകുന്നു, ചിലത് ടണലല്ലാത്ത എല്ലാം തടയുന്നു, മറ്റുള്ളവ kill switch സജീവമാകുമ്പോൾ മാത്രം തടയുന്നു.

ആ വ്യത്യാസം പ്രധാനമാണ്, കാരണം തിരുത്തുകൾ പരസ്പരം മാറ്റാനാകില്ല. റൂട്ട് ചേർക്കുന്നത് ഒരു ഫിൽട്ടറിനെ തൃപ്തിപ്പെടുത്തില്ല, ഒരു അതിഥിയിലെത്താൻ ഫിൽട്ടർ ഓഫാക്കുന്നത് ലക്ഷണം സൂചിപ്പിക്കുന്നതിനേക്കാൾ വലിയ തീരുമാനമാണ്.

അതിഥിക്ക് വേണ്ട എന്ന് പറയാൻ മൂന്ന് വഴികളുണ്ട്

ഇന്റർനെറ്റ് ബ്രൗസ് ചെയ്യാനാകുന്ന അതിഥി നിങ്ങൾ ആഗ്രഹിക്കുന്ന സേവനത്തെക്കുറിച്ച് ഒന്നും തെളിയിച്ചിട്ടില്ല. കേൾക്കുന്നത് അതിഥിക്കുള്ളിൽ 127.0.0.1-ലേക്ക് ബന്ധിച്ചിരിക്കാം, അങ്ങനെയെങ്കിൽ പാത എത്ര നല്ലതായാലും ഹോസ്റ്റിൽ നിന്ന് ഒരു അഭ്യർത്ഥനയും എത്താൻ കഴിയില്ല. അതിഥിയിൽ ss -ltn ഉപയോഗിച്ച് പരിശോധിച്ച് പോർട്ട് മാത്രമല്ല, പ്രാദേശിക വിലാസ കോളവും നോക്കുക.

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

VM-ന്റെ നെറ്റ്വർക്ക് മോഡ് മാറ്റുന്നതിനെക്കുറിച്ച് ചിന്തിക്കുന്നതിന് മുമ്പ് ഈ മൂന്നും പരിശോധിക്കുക. ഓരോന്നും അതിഥിയുടെ ബന്ധം പുനർരൂപകൽപ്പന ചെയ്യുന്നതിനേക്കാൾ ചെറിയ മാറ്റമാണ്, ഓരോന്നിനും വ്യക്തമായ പരിശോധനയുണ്ട്.

ബ്രിഡ്ജ് യഥാർത്ഥത്തിൽ എന്താണ്, അതിന് എത്ര ചെലവാകുന്നു

അഡാപ്റ്റർ ബ്രിഡ്ജ് മോഡിലേക്ക് മാറ്റുന്നത് host-only പാതയുടെ അറ്റകുറ്റപ്പണിയല്ല. അതിഥിയെ മറ്റൊരു നെറ്റ്വർക്കിൽ, സാധാരണയായി ഭൗതിക LAN-ൽ, ഇടാനുള്ള തീരുമാനമാണ്, അവിടെ അത് അവിടെ താമസിക്കുന്ന മറ്റെല്ലാവർക്കും ദൃശ്യമാകുന്നു. അത് നിങ്ങൾ ആഗ്രഹിക്കുന്നത് കൃത്യമായി ആയിരിക്കാം. പക്ഷേ യഥാർത്ഥ കോൺഫിഗറേഷൻ ചെയ്തിരുന്നത് അതല്ല.

അതിഥി ശരിക്കും ആ LAN-ൽ സമനിലയിലുള്ള അംഗമാകേണ്ടതും എക്സ്പോഷർ അനുവദിച്ചതുമാകുമ്പോൾ അത് ഉപയോഗിക്കുക. ഒരു സേവനം പ്രതികരിക്കുന്നത് നിർത്തിയതിനാൽ അത് ഉപയോഗിക്കരുത്, കാരണം മാറ്റം അതിഥിയെ അതിനെതിരെ വികസിപ്പിക്കാൻ സുരക്ഷിതമാക്കിയ ഒറ്റപ്പെടുത്തലിൽ നിന്ന് പുറത്താക്കിയേക്കാം.

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

VirtualBox-ന്റെ host-only നെറ്റ്വർക്കിംഗ് വിഭാഗം ഹോസ്റ്റ് ഭാഗത്തെ സോഫ്റ്റ്വെയർ ഇന്റർഫേസും അത് ബ്രിഡ്ജ് കണക്ഷനിൽ നിന്ന് എങ്ങനെ വ്യത്യാസപ്പെടുന്നുവെന്നും വിവരിക്കുന്നു, രണ്ട് മോഡുകളും പരസ്പരം മാറ്റാവുന്നതാണെന്ന് കരുതുന്നതിന് മുമ്പ് വായിക്കാൻ യോഗ്യമായ റഫറൻസാണിത്.