Linux-ൽ VPN പുഷ് ചെയ്ത റൂട്ടുകളെ സ്റ്റാറ്റിക് റൂട്ടുകളിൽ നിന്ന് എങ്ങനെ വേർതിരിക്കാം

ടണൽ ഉയരുമ്പോൾ ലാപ്‌ടോപ്പിൽ ഒരു പ്രിഫിക്സ് പ്രത്യക്ഷപ്പെടുന്നു, അതിനാൽ VPN അത് ഇൻസ്റ്റാൾ ചെയ്തതായി തോന്നുന്നു. അങ്ങനെയാകാം, പക്ഷേ അതേ ഫലം കണക്ട് സമയത്ത് പ്രവർത്തിക്കുന്ന ഒരു ക്ലയന്റ് സ്ക്രിപ്റ്റിൽ നിന്നോ, സബ്‌നെറ്റ് പട്ടികപ്പെടുത്തുന്ന ഒരു കണക്ഷൻ പ്രൊഫൈലിൽ നിന്നോ, അല്ലെങ്കിൽ തുടക്കം മുതലേ ഉണ്ടായിരുന്നു ഇന്റർഫേസ് ഉണ്ടായതിനുശേഷം മാത്രം പ്രവർത്തിക്കാൻ തുടങ്ങിയ ഒരു സ്റ്റാറ്റിക് റൂട്ടിൽ നിന്നോ വരാം. തെറ്റായ ഉറവിടം തിരഞ്ഞെടുക്കുന്നത് ഓരോ വൃത്തിയാക്കലിനും ശേഷം റൂട്ട് തിരികെ വരുമെന്നും അടുത്ത വ്യക്തി അതേ പരിഹാരം ആവർത്തിക്കുമെന്നും അർഥം. ചുവടെയുള്ള ക്രമം എന്തും മാറ്റുന്നതിന് മുൻപ് ഈ മൂന്നിനെ വേർതിരിക്കുന്നു.

ഘട്ടം 1: പ്രിഫിക്സുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്ന സംവിധാനത്തിന് പേര് നൽകുക

വിവിധ പ്രോട്ടോക്കോളുകൾ വ്യത്യസ്ത രീതികളിൽ എത്തിച്ചേരാനുള്ള കഴിവ് നൽകുന്നു, ഇതെല്ലാം പ്രഖ്യാപനം എന്ന് വിളിക്കുന്നത് വ്യത്യാസം മറയ്ക്കുന്നു. ഒരു OpenVPN സെർവർ നിയന്ത്രണ ചാനലിലൂടെ റൂട്ട് നിർദ്ദേശം പുഷ് ചെയ്യുന്നു, pull ഫിൽട്ടർ തടയുന്നില്ലെങ്കിൽ ക്ലയന്റ് അത് ഇൻസ്റ്റാൾ ചെയ്യുന്നു. WireGuard കോൺഫിഗറേഷൻ അനുവദിച്ച പ്രിഫിക്സുകൾ പ്രാദേശികമായി പട്ടികപ്പെടുത്തുന്നു, ക്ലയന്റ് അവ ക്രിപ്റ്റോ-കീ റൂട്ടിംഗിനും താൻ ചേർക്കുന്ന റൂട്ടുകൾക്കും ഉപയോഗിക്കുന്നു. IPsec ടണൽ പിയറുമായി ട്രാഫിക് സെലക്ടറുകൾ യോജിക്കുന്നു, കെർണൽ ആ സെലക്ടറുകളിൽ നിന്ന് റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു.

ഏതെങ്കിലും പട്ടിക വായിക്കുന്നതിന് മുൻപ് നിങ്ങളുടെ ടണൽ ഇവയിൽ ഏതാണ് ഉപയോഗിക്കുന്നതെന്ന് തിരിച്ചറിയുക. കണക്ട് സമയത്ത് പുഷ് ചെയ്യുന്ന റൂട്ട് റൂട്ടിംഗ് പ്രോട്ടോക്കോളിന്റെ പ്രഖ്യാപനമല്ല, പ്രിഫിക്സ് ദൂരെ അറ്റത്തിന് പിന്നിൽ എത്താമെന്ന് അത് വാഗ്ദാനം ചെയ്യുന്നുമില്ല. പരിഹാരം എവിടെയാണ് വേണ്ടതെന്ന് അത് തീരുമാനിക്കുന്നതിനാൽ, പ്രിഫിക്സിന് അടുത്തായി സംവിധാനം കുറിച്ചുവയ്ക്കുക.

ഘട്ടം 2: ഒരു കണക്ഷനിലുടനീളം പട്ടിക താരതമ്യം ചെയ്യുക

ടണൽ താഴെയിരിക്കുമ്പോൾ പ്രധാന പട്ടിക സംരക്ഷിക്കുക, അത് ഉയർത്തുക, വീണ്ടും സംരക്ഷിക്കുക, രണ്ട് ക്യാപ്ചറുകളും താരതമ്യം ചെയ്യുക. പ്രത്യക്ഷപ്പെട്ടതെല്ലാം കണക്ഷന്റെ ജീവിതചക്രത്തിന്റേതാണ്, അവശേഷിച്ചതെല്ലാം പ്രാദേശിക കോൺഫിഗറേഷന്റേതാണ്.

ip route show table main > /tmp/route-down.txt ഉപയോഗിച്ച് അത് ക്യാപ്ചർ ചെയ്യുക, കണക്ട് ചെയ്യുക, വീണ്ടും ക്യാപ്ചർ ചെയ്യുക. സൈറ്റ് IPv6 ഉപയോഗിക്കുന്നുവെങ്കിൽ ip -6 route-നും അതേ കാര്യം ചെയ്യുക, കാരണം അവിടെ ഇല്ലാത്ത പ്രിഫിക്സ് റൂട്ടിംഗുമായി ബന്ധമില്ലാത്തതായി തോന്നുന്ന തകരാറുകൾ സൃഷ്ടിക്കുന്നു.

ഘട്ടം 3: സാന്നിധ്യം മാത്രമല്ല, മെട്രിക് വായിക്കുക

ഒരേ പ്രിഫിക്സിന് രണ്ട് എൻട്രികൾ ഒരുമിച്ച് നിലനിൽക്കാം, കെർണൽ കുറഞ്ഞ മെട്രിക് തിരഞ്ഞെടുക്കുന്നു. മെട്രിക് 50 ഉള്ള സ്റ്റാറ്റിക് റൂട്ട് രണ്ടും കാണാമെങ്കിലും 100-ലെ പുഷ് ചെയ്ത റൂട്ടിനെ തോൽപ്പിച്ചുകൊണ്ടിരിക്കും, അതിനാൽ ‘റൂട്ട് അവിടെയുണ്ട്’ എന്നതും ‘ട്രാഫിക് അത് ഉപയോഗിക്കുന്നു’ എന്നതും വ്യത്യസ്ത പ്രസ്താവനകളാണ്.

ip route get 10.20.5.7 ഉപയോഗിച്ച് കെർണലിനോട് നേരിട്ട് ചോദിക്കുക, അത് റിപ്പോർട്ട് ചെയ്യുന്ന ഇന്റർഫേസ് വായിക്കുക. പട്ടികയിൽ ടണൽ റൂട്ട് ഉണ്ടായിരിക്കെ ട്രാഫിക് ഭൗതിക അഡാപ്റ്ററിലൂടെ പുറത്തുപോകുന്നുവെങ്കിൽ, അത് മെട്രിക് അല്ലെങ്കിൽ പ്രിഫിക്സ് നീളം വിശദീകരിക്കുന്നു, VPN ക്ലയന്റല്ല. ടണലിന് പിന്നിലുണ്ടെന്ന് നിങ്ങൾക്കറിയാവുന്ന ഒരു ഹോസ്റ്റിനും ഇല്ലെന്നറിയാവുന്ന ഒരു ഹോസ്റ്റിനും തിരയൽ ആവർത്തിക്കുക, വ്യത്യാസം വിഭജനം ഉദ്ദേശിച്ചതുപോലെ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് കാണിക്കും.

ഘട്ടം 4: ടണലിനെക്കാൾ കൂടുതൽ നിലനിൽക്കുന്ന എൻട്രികൾ കണ്ടെത്തുക

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

നിങ്ങളുടെ വിതരണം ഉപയോഗിക്കുന്ന സ്ഥലത്ത് സ്ഥിരമായ ഭാഗം പരിശോധിക്കുക, അത് systemd-networkd യൂണിറ്റോ NetworkManager പ്രൊഫൈലോ ക്ലയന്റിന്റെ up ഡയറക്ടറിയിലെ സ്ക്രിപ്റ്റോ ആകാം. ip route del ഉപയോഗിച്ച് ജീവനുള്ള പട്ടിക ശരിയാക്കുന്നത് അടുത്ത കണക്ട് വരെ മാത്രം നിൽക്കും. ആ ഡിലീറ്റ് അറ്റകുറ്റപ്പണിയല്ല, സിദ്ധാന്തത്തിന്റെ പരിശോധനയായി കാണുക.

ദൂരെയുള്ള അറ്റം തെറ്റായ കവറേജ് നൽകുന്നിടത്ത്, എല്ലാം ഫിൽട്ടർ ചെയ്യുന്നതിന് പകരം ഓപ്പറേറ്ററെ അറിയിക്കുക. പുഷ് ചെയ്ത എല്ലാ ക്രമീകരണങ്ങളും ഒഴിവാക്കുന്നത് പ്രൊഫൈൽ ആശ്രയിക്കുന്ന DNS-ഉം സ്പ്ലിറ്റ്-ടണൽ നയവും ഒഴിവാക്കുന്നു.

ഘട്ടം 5: ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുൻപ് മടങ്ങിവരവ് പാത ഉറപ്പാക്കുക

സൈറ്റ്-ടു-സൈറ്റ് അല്ലെങ്കിൽ ടണലിന് പിന്നിലെ സബ്‌നെറ്റിന്, ദൂരെയുള്ള വശത്തിന് നിങ്ങളുടെ ക്ലയന്റ് വിലാസത്തിലേക്ക് തിരികെയുള്ള റൂട്ടും ഗേറ്റ്‌വേയിൽ ഫോർവേഡിംഗ് ഓണും ആവശ്യമാണ്. ഏകദിശാ പാത കൃത്യമായി ക്ലയന്റ് റൂട്ടിംഗ് ബഗ് പോലെ തോന്നുന്നു, പക്ഷേ ഹാൻഡ്‌ഷേക്കും പുറത്തേക്കുള്ള പാക്കറ്റും രണ്ടും വിജയിക്കുന്നു.

റിവേഴ്സ്-പാത്ത് ഫിൽട്ടറിംഗ് Linux ഗേറ്റ്‌വേകളിൽ രണ്ടാമത്തെ കെണി ചേർക്കുന്നു. റൂട്ട് പ്രതീക്ഷിക്കുന്നതിൽ നിന്ന് വ്യത്യസ്ത ഇന്റർഫേസിൽ എത്തുന്ന മറുപടി കർശന മോഡിൽ ഒഴിവാക്കപ്പെടുന്നു, രണ്ട് ദാതാക്കളിലൂടെയുള്ള അസമമായ പാതകൾ അത് വിശ്വസനീയമായി പ്രവർത്തിപ്പിക്കുന്നു. ഫിൽട്ടറിംഗാണ് കാരണമോ എന്ന് ഗേറ്റ്‌വേയിലെ, ക്ലയന്റിലെ അല്ലാത്ത, ഡ്രോപ്പ് കൗണ്ടറുകൾ പറയുന്നു.

ഘട്ടം 6: ping അല്ല, വിഭവം പരിശോധിക്കുക

തിരഞ്ഞെടുത്ത റൂട്ട് ശരിയായാൽ യഥാർത്ഥ വിഭവം തുറന്ന് മടങ്ങിവരവ് ട്രാഫിക് ഉറപ്പാക്കുക. ping മറുപടി ഒരു ദിശയിലെ പാത തെളിയിക്കുന്നു, സേവനത്തെക്കുറിച്ച് ഒന്നുമല്ല, കാഷ് ചെയ്ത കണക്ഷനിൽ മറുപടി നൽകുന്ന സേവനം അതിലും കുറവ് തെളിയിക്കുന്നു.

തുടർന്ന് വീണ്ടും കണക്ട് ചെയ്തതിന് ശേഷം മുഴുവൻ പരിശോധനയും ആവർത്തിക്കുക. ക്രമത്തിന്റെ മൂല്യം അടുത്ത കണക്ട് എന്ത് ചെയ്യുമെന്ന് അത് പ്രവചിക്കുന്നു എന്നതാണ്, അതിനാൽ താരതമ്യവും മെട്രിക്കും രണ്ടും ടിക്കറ്റിൽ വരുന്നു.