ഒരു സബ്നെറ്റ് ഇപ്പോഴും നിങ്ങളുടെ VPN ഡിഫോൾട്ട് റൂട്ട് ബൈപാസ് ചെയ്യുന്നത് എന്തുകൊണ്ട്

VPN പൂർണ്ണ ടണലിലേക്ക് മാറ്റുന്നു, മിക്ക ട്രാഫിക്കും അനുസരിക്കുന്നു, പിന്നെ ഒരു വിലാസം നേരിട്ട് ഉത്തരം നൽകുന്നു — പ്രിന്റർ, NAS, 10.x-ലെ ജമ്പ് ഹോസ്റ്റ്. വ്യക്തമായ വായന ടണൽ ചോർന്ന് പോകുന്നു എന്നാണ്, അതിനാൽ ഡിഫോൾട്ട് റൂട്ടിലെ മെട്രിക് കുറയ്ക്കുന്നു, ഒന്നും മാറുന്നില്ല. ആ പരാജയപ്പെട്ട ശ്രമമാണ് സൂചന: ഡിഫോൾട്ട് റൂട്ട് ഒരു ബാക്കപ്പാണ്, വിധിയല്ല. റൂട്ട് തിരയൽ മെട്രിക്കുകൾ താരതമ്യം ചെയ്യുന്നതിന് മുമ്പ് തന്നെ ഏറ്റവും നീളമുള്ള പൊരുത്തപ്പെടുന്ന പ്രിഫിക്സ് എടുക്കുന്നു, അതിനാൽ /24 ഏതു സംഖ്യ ചേർത്താലും /0-നെതിരെ വിജയിക്കുന്നു. ആ ക്രമം വ്യക്തമായാൽ, ചോർച്ച സാധാരണയായി ആരോ ബോധപൂർവ്വം ഇൻസ്റ്റാൾ ചെയ്ത ഒരു റൂട്ട്, അല്ലെങ്കിൽ ക്ലയന്റ് ഒരിക്കലും മൂടാൻ ഉദ്ദേശിക്കാത്ത ഒരു പ്രിഫിക്സ് ആണ്.

ഡിഫോൾട്ട് റൂട്ട് യഥാർത്ഥത്തിൽ എന്താണ് വാഗ്ദാനം ചെയ്യുന്നത്

0.0.0.0/0 പൂജ്യം ബിറ്റ് പ്രത്യേകതയോടെ എല്ലാ IPv4 ലക്ഷ്യസ്ഥാനത്തിനും പൊരുത്തപ്പെടുന്നു. ഹോസ്റ്റിന് അതിന്റെ പട്ടിക മികച്ചതായി വിവരിക്കാത്ത എന്തിനെയും എത്താൻ ഇത് നിലകൊള്ളുന്നു. 192.168.1.0/24-ലേക്കുള്ള റൂട്ട് 24 പൊരുത്തപ്പെടുന്ന ബിറ്റുകൾ വഹിക്കുന്നു, അതിനാൽ 192.168.1.40-ന് ആരും മെട്രിക്, അഡ്മിനിസ്ട്രേറ്റീവ് ദൂരം അല്ലെങ്കിൽ ക്ലയന്റ് മുൻഗണനാ ഫീൽഡ് എന്ന് വിളിക്കുന്നത് താരതമ്യം ചെയ്യുന്നതിന് മുമ്പേ അത് വിജയിക്കുന്നു. അതേ നിയമം Linux FIB, Windows റൂട്ടിംഗ് പട്ടിക, macOS-ന് പിന്നിലെ BSD സ്റ്റാക്ക് എന്നിവയിൽ ബാധകമാണ്.

സാധാരണ LAN-ൽ ആ പെരുമാറ്റം ഒരു സവിശേഷതയാണ്. പ്രാദേശിക സബ്നെറ്റ് നേരിട്ട് ബന്ധിപ്പിച്ചിരിക്കുന്നു, ടണൽ നിങ്ങളുടെ ബ്രൗസിംഗ് വഹിക്കുമ്പോൾ പ്രിന്റർ പ്രവർത്തിക്കുന്നു, ഒന്നും തെറ്റായി കോൺഫിഗർ ചെയ്തിട്ടില്ല. ചോദിക്കാൻ യോഗ്യമായ ചോദ്യം ആ ഒരു വിലാസം എന്തുകൊണ്ട് നേരിട്ട് പോകുന്നു എന്നല്ല, മറിച്ച് ഏത് പട്ടികയിലെ ഏത് പ്രിഫിക്സ് അതിനോട് പൊരുത്തപ്പെടുന്നു, അത് അവിടെ ആരാണ് വെച്ചത് എന്നതാണ്.

പകുതി-ഡിഫോൾട്ടുകൾ, അല്ലെങ്കിൽ ഡിഫോൾട്ട് എൻട്രി എന്തുകൊണ്ട് തൊടാത്തതായി തോന്നാം

ഏറ്റവും വ്യക്തമായ ഉദാഹരണം redirect-gateway def1 OpenVPN-ൽ ആണ്. നിങ്ങളുടെ ഡിഫോൾട്ട് ഇല്ലാതാക്കി പകരം വെക്കുന്നതിന് പകരം, അത് 0.0.0.0/1 ഉം 128.0.0.0/1 ഉം ചേർക്കുന്നു. ഒരുമിച്ച് ആ ജോഡി മുഴുവൻ IPv4-ഉം മൂടുന്നു, ഓരോ പ്രിഫിക്സും /0-നേക്കാൾ നീളമുള്ളതാണ്, രണ്ടും റൂട്ടറിന്റെ ഡിഫോൾട്ടിനെ അതിന്റെ സ്ഥാനത്ത് നിർത്തിക്കൊണ്ട് തോൽപ്പിക്കുന്നു. പിന്നീട് ഒരു റൂട്ട് ലിസ്റ്റ് പ്രവർത്തിപ്പിക്കുക, യഥാർത്ഥ ഡിഫോൾട്ട് ഇപ്പോഴും അവിടെയുണ്ട്, ഇപ്പോഴും നിങ്ങളുടെ ഗേറ്റ്വേയിലേക്ക് ചൂണ്ടുന്നു; അത് ഇന്റർനെറ്റ് ലക്ഷ്യസ്ഥാനങ്ങൾക്കായി ഒരിക്കലും തിരഞ്ഞെടുക്കപ്പെടുന്നില്ല എന്ന് മാത്രം.

WireGuard-ന്റെ wg-quick നയ അടിസ്ഥാനമാക്കിയ റൂട്ടിംഗിലൂടെ അതേ ഫലത്തിൽ എത്തുന്നു. AllowedIPs 0.0.0.0/0 മൂടുമ്പോൾ അത് സ്വന്തം പട്ടിക സൃഷ്ടിക്കുന്നു, അടയാളപ്പെടുത്തിയ പാക്കറ്റുകൾ അങ്ങോട്ട് അയക്കുന്നു, പ്രധാന പട്ടികയുടെ പൂജ്യം നീളമുള്ള പ്രിഫിക്സ് അവഗണിക്കുന്ന ഒരു നിയമം ചേർക്കുന്നു. പ്രധാന പട്ടിക അതിന്റെ ഡിഫോൾട്ട് എൻട്രി നിലനിർത്തുന്നു, ഇന്റർഫേസിന് ഉള്ള ട്രാഫിക്കിന് ആദ്യം ടണൽ പട്ടികയോട് ചോദിക്കുന്നു എന്ന് നിയമങ്ങൾ തീരുമാനിക്കുന്നു.

രണ്ട് ഡിസൈനുകൾക്കും ടണലിന് പുറത്ത് കൃത്യമായി ഒരു റൂട്ട് വേണം: യഥാർത്ഥ ഗേറ്റ്വേയിലൂടെ VPN സെർവറിന്റെ സ്വന്തം വിലാസത്തിലേക്കുള്ള ഹോസ്റ്റ് റൂട്ട്. അതില്ലാതെ ക്ലയന്റ് ടണൽ നിർമ്മിക്കുന്ന പാക്കറ്റുകൾ ടണലിനുള്ളിൽ കൊണ്ടുപോകാൻ ശ്രമിക്കും, കണക്ഷൻ ഒരിക്കലും പൂർത്തിയാകില്ല. അതിനാൽ കർശനമായ പൂർണ്ണ-ടണൽ പ്രൊഫൈലിൽ പോലും നിങ്ങളുടെ പട്ടികയിൽ ടണലല്ലാത്ത റൂട്ട് സാധാരണമാണ്. സംശയിക്കാൻ യോഗ്യമായ റൂട്ടുകൾ നിങ്ങൾക്ക് യഥാർത്ഥത്തിൽ പ്രധാനമായ ലക്ഷ്യസ്ഥാനങ്ങൾ മൂടുന്നവയാണ്.

മെട്രിക്കുകൾ സമനില തീരുമാനിക്കുന്നു, പ്രിഫിക്സുകൾ വിജയികളെ തീരുമാനിക്കുന്നു

ലക്ഷ്യസ്ഥാനവുമായി തുല്യമായി പൊരുത്തപ്പെടുന്ന സ്ഥാനാർത്ഥികൾക്കിടയിൽ മാത്രമാണ് മെട്രിക്കുകൾ താരതമ്യം ചെയ്യുന്നത്. Linux-ൽ ip route get 10.20.5.9 വിജയിയെ അതിന്റെ പട്ടികയോടൊപ്പം പ്രിന്റ് ചെയ്യുന്നു, ip route show table all സ്ഥാനാർത്ഥികളെ ലിസ്റ്റ് ചെയ്യുന്നു, ഏതെങ്കിലും പകുതി-ഡിഫോൾട്ടുകളും ഒരു നിയമം ചൂണ്ടിക്കാണിക്കുന്ന ഏതെങ്കിലും പട്ടികയും ഉൾപ്പെടെ. Windows-ൽ Find-NetRoute -RemoteIPAddress 10.20.5.9 തിരഞ്ഞെടുത്ത റൂട്ടും സോഴ്സ് വിലാസവും തിരികെ നൽകുന്നു, Get-NetRoute അസംസ്കൃത പട്ടിക കാണിക്കുന്നു — പക്ഷേ ഫലപ്രദമായ ചെലവ് റൂട്ട് മെട്രിക് കൂടെ ഇന്റർഫേസ് മെട്രിക് ആണ്, അതിനാൽ വേഗത കുറഞ്ഞ അഡാപ്റ്റർ വിജയിക്കുന്നതായി തോന്നുന്ന സമനില നഷ്ടപ്പെടുത്താം.

നിങ്ങൾ കാണുന്നതിൽ മിക്കതും മൂന്ന് കേസുകൾ ഉൾക്കൊള്ളുന്നു:

• അതേ ലക്ഷ്യസ്ഥാനം, /24 vs /0: മെട്രിക്കുകൾ എന്ത് പറഞ്ഞാലും പ്രിഫിക്സ് നീളത്തിൽ /24 വിജയിക്കുന്നു.
• അതേ ലക്ഷ്യസ്ഥാനം, വ്യത്യസ്ത മെട്രിക്കുകളുള്ള രണ്ട് /24: കുറഞ്ഞ ഫലപ്രദമായ മെട്രിക് വിജയിക്കുന്നു.
• അതേ ലക്ഷ്യസ്ഥാനം, രണ്ട് പട്ടികകൾ, ഒന്ന് ഒരു നയ നിയമം തിരഞ്ഞെടുക്കുന്നു: നിയമം ആദ്യം പട്ടിക തിരഞ്ഞെടുക്കുന്നു, പ്രിഫിക്സ് താരതമ്യം അതിനുള്ളിൽ നടക്കുന്നു.

മൂന്നാമത്തെ കേസാണ് ഈ റിപ്പോർട്ടുകളിൽ മിക്കതും അവസാനിക്കുന്നിടം. Linux-ന്റെ ip rule അല്ലെങ്കിൽ Windows VPN ട്രാഫിക് ഫിൽട്ടർ ട്രാഫിക്ക് ഒരിക്കലും ടണൽ ഡിഫോൾട്ട് ഇല്ലാത്ത ഒരു പട്ടികയിലേക്ക് അയക്കാം, പ്രധാന പട്ടിക എപ്പോഴും തികഞ്ഞതായി കാണപ്പെടുന്നു.

സാധാരണയായി ഈ ബൈപാസിന്റെ ഉടമ ആരാണ്

പട്ടികയിൽ നിന്നല്ല, പ്രൊഫൈലിൽ നിന്ന് തുടങ്ങുക. Split-tunnel കോൺഫിഗറേഷനുകളും ആപ്പ് അനുസരിച്ചുള്ള VPN ക്രമീകരണങ്ങളും പേരുള്ള പ്രിഫിക്സുകൾ ബോധപൂർവ്വം ടണലിന് പുറത്ത് വിടുന്നു; ഒരു സ്വകാര്യ സബ്നെറ്റ് സംരക്ഷിച്ച് പൊതു ബ്രൗസിംഗ് നേരിട്ട് പോകാൻ അനുവദിക്കുന്ന ഒരു ജോലി പ്രൊഫൈൽ രൂപകൽപ്പന ചെയ്തതുപോലെ പ്രവർത്തിക്കുന്നു, അത് അതിലംഘിക്കുന്നത് അത് നടപ്പാക്കേണ്ടിയിരുന്ന നയം തകർക്കുന്നു. Microsoft-ന്റെ VPN റൂട്ടിംഗ് മാർഗ്ഗനിർദ്ദേശം നിർബന്ധിത ടണൽ ട്രാഫിക്കിനും വ്യക്തമായ ഒഴിവുകൾക്കും ഇടയിൽ അതേ രേഖ വരയ്ക്കുന്നു, ഇത് എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ് ഉപയോഗപ്രദമായ ക്രോസ്-ചെക്ക് ആക്കുന്നു.

പിന്നെ അവശിഷ്ടങ്ങൾ തിരയുക. ഇനി നിലവിലില്ലാത്ത ഒരു ഇന്റർഫേസിലേക്കോ മുൻ നെറ്റ്വർക്കിലെ വിലാസത്തിലേക്കോ ചൂണ്ടുന്ന റൂട്ട്, ഡോക്കിംഗ് സ്റ്റേഷനുകളും USB അഡാപ്റ്ററുകളും കണ്ടെയ്നർ ബ്രിഡ്ജുകളും വന്നു പോയതിന് ശേഷം പ്രത്യക്ഷപ്പെടുന്നു. ഒരിക്കൽ ഇല്ലാതാക്കുന്നത് അവസാനമല്ല: NetworkManager കണക്ഷൻ പ്രൊഫൈലുകൾ, netplan ഫയലുകൾ, Windows-ന്റെ സ്ഥിരമായ റൂട്ടുകൾ എന്നിവ അടുത്ത കണക്ഷനിലോ ബൂട്ടിലോ അത് വീണ്ടും ഇൻസ്റ്റാൾ ചെയ്യുന്നു, അതിനാൽ എന്തെങ്കിലും തിരുത്തുന്നതിന് മുമ്പ് അതിന്റെ ഉടമയായ ഫയലോ പ്രൊഫൈലോ കണ്ടെത്തുക.

പിന്നെ IPv6 വെവ്വേറെ പരിശോധിക്കുക. ip -6 route ഉം Get-NetRoute -AddressFamily IPv6 ഉം വെവ്വേറെ അവസ്ഥ, വെവ്വേറെ ഡിഫോൾട്ടുകൾ, വെവ്വേറെ ക്ലയന്റ് പെരുമാറ്റം എന്നിവ സൂക്ഷിക്കുന്നു. IPv4 മാത്രമുള്ള ഓഡിറ്റ്, തദ്ദേശീയ IPv6 പാതയെ നിശബ്ദമായി മുൻഗണന നൽകുന്ന ഇരട്ട-സ്റ്റാക്ക് ഹോസ്റ്റിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല, അത് മാത്രം ഒരു ക്ലയന്റിനെ split-tunnel ആയി കാണിക്കാം.

ആപ്ലിക്കേഷന്റെ സ്വന്തം ഒഴുക്ക് ഉപയോഗിച്ച് സ്ഥിരീകരിക്കുക

ആപ്ലിക്കേഷൻ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ലക്ഷ്യസ്ഥാനം രേഖപ്പെടുത്തുക, തുടർന്ന് ആ ആപ്ലിക്കേഷൻ ബന്ധിക്കുന്ന സോഴ്സ് വിലാസത്തിൽ നിന്ന് എടുക്കുന്ന പാത സിസ്റ്റത്തോട് ചോദിക്കുക. ip route get 10.20.5.9 from 192.168.1.40 Linux-ൽ അതിന് ഉത്തരം നൽകുന്നു; Find-NetRoute -RemoteIPAddress 10.20.5.9 കൂടെ ലോക്കൽ വിലാസം Windows-ൽ അത് ചെയ്യുന്നു. ഫലം പ്രൊഫൈൽ അവകാശപ്പെടുന്നതുമായി താരതമ്യം ചെയ്യുക. ബ്രൗസറിന്റെ പൊതു-IP പേജ് ഒരു പ്രോട്ടോക്കോളിൽ ഒരു ലക്ഷ്യസ്ഥാനം പരിശോധിക്കുന്നു, പരാതി ആരംഭിച്ച സ്വകാര്യ വിലാസത്തെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

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

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

• ആപ്പ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ലക്ഷ്യസ്ഥാനവും സോഴ്സ് വിലാസവും പേര് പറയുക.
• വിജയിക്കുന്ന റൂട്ട് ip route get അല്ലെങ്കിൽ Find-NetRoute ഉപയോഗിച്ച് പ്രിന്റ് ചെയ്യുക.
• ഇന്റർനെറ്റ് പാതയുടെ ഉടമ /1 ജോഡിയാണോ നയ പട്ടികയാണോ എന്ന് പരിശോധിക്കുക.
• ലക്ഷ്യസ്ഥാനവുമായി പൊരുത്തപ്പെടുന്ന /0-നേക്കാൾ നീളമുള്ള ഓരോ പ്രിഫിക്സും ലിസ്റ്റ് ചെയ്യുക.
• IPv6 പരിശോധന വെവ്വേറെ ആവർത്തിക്കുക.
• അവശേഷിക്കുന്ന റൂട്ട് അത് ഇൻസ്റ്റാൾ ചെയ്യുന്ന ഫയലിലേക്കോ പ്രൊഫൈലിലേക്കോ ഫിൽട്ടറിലേക്കോ പിന്തുടരുക.
• ശരിയായി എന്ന് പറയുന്നതിന് മുമ്പ് വീണ്ടും ബന്ധിപ്പിച്ച് ക്വറി വീണ്ടും പ്രവർത്തിപ്പിക്കുക.

ഏഴും പ്രൊഫൈലുമായി യോജിക്കുന്നുവെങ്കിൽ, ടണൽ കോൺഫിഗർ ചെയ്തത് കൃത്യമായി ചെയ്യുന്നു, പരിഹാരം മെട്രിക്കിലല്ല, പ്രൊഫൈലിലാണ്.