VPN-ൽ SSH ഓരോ മിനിറ്റിലും വീഴുന്നു? കാരണം keepalive അല്ല

SSH കണക്റ്റ് ചെയ്യുന്നു, ഏകദേശം ഒരു മിനിറ്റ് പ്രവർത്തിക്കുന്നു, പിന്നീട് ഓരോ തവണയും ഏകദേശം അതേ ഇടവേളയിൽ മരവിക്കുന്നു. സാധാരണ വിശദീകരണം നിഷ്ക്രിയ ടൈംഔട്ട് ആണ്, അതിനാൽ ആളുകൾ MTU കുറയ്ക്കുകയും ക്ലയന്റ് keepalives ക്രമീകരിക്കുകയും ചെയ്യുന്നു. ഞാൻ പ്രവർത്തിച്ച WireGuard ലിങ്ക് ഇതെല്ലാം കഴിഞ്ഞിരുന്നു: ചെറിയ ടണൽ MTU, client-alive ക്രമീകരണങ്ങൾ, കോൺഫിഗർ ചെയ്ത ടണൽ keepalive. വിച്ഛേദനങ്ങൾ മാറ്റമില്ലാതെ തുടർന്നു. കാരണം അസമമിത LAN റൂട്ട് ആയിരുന്നു, ഈ പാറ്റേൺ തിരിച്ചറിയേണ്ടതാണ് കാരണം ഇത് ടൈമർ അടിസ്ഥാനമാക്കിയ എല്ലാ പരിഹാരത്തെയും തോൽപ്പിക്കുന്നു.

keepalive നിങ്ങളുടെ ഹോസ്റ്റ് ഇപ്പോഴും അയയ്ക്കാൻ സന്നദ്ധമാണെന്ന് തെളിയിക്കുന്നു. ഒരിക്കലും അതിലൂടെ കടന്നുപോകാത്ത ഒരു മറുപടി അവസ്ഥ സൂക്ഷിക്കുന്ന ഉപകരണത്തിന് കാണാൻ അതിന് കഴിയില്ല.

മിത്ത്: keepalives നിശ്ശബ്ദ വിച്ഛേദനം പരിഹരിക്കുന്നു

SSH keepalives ഒരു ജോലിക്ക് മാത്രമുള്ളതാണ്: നിശ്ശബ്ദത എണ്ണുന്ന എന്തെങ്കിലും നിഷ്ക്രിയ സെഷൻ നീക്കം ചെയ്യുന്നത് തടയുക. അവർ അത് നന്നായി ചെയ്യുന്നു. ഒരു ദിശയിൽ ആദ്യ പാക്കറ്റ് കണ്ടിട്ട് പിന്നീട് ഒരിക്കലും മറുപടി കാണാത്ത അവസ്ഥ സൂക്ഷിക്കുന്ന ഉപകരണത്തിന്റെ പ്രശ്നം അവർ പരിഹരിക്കുന്നില്ല, കാരണം ക്ലയന്റ് അയയ്ക്കുന്ന ഒന്നും മറുപടി ഏത് ഇന്റർഫേസ് ഉപയോഗിക്കുന്നു എന്നത് മാറ്റുന്നില്ല.

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

സൂചന ക്രമവും, ആ ഇടവേളയ്ക്കുള്ളിൽ സെഷൻ ഉപയോഗയോഗ്യമായി തുടരുന്നതും ചേർന്നതാണ്. നിഷ്ക്രിയ ടൈംഔട്ടുകൾ ഒന്നും സംഭവിക്കാത്തപ്പോൾ പ്രഹരിക്കുന്നു; ഇത് നിങ്ങൾ ടൈപ്പ് ചെയ്യുമ്പോൾ പ്രഹരിക്കുന്നു.

അധിക ഗേറ്റ്വേ യഥാർത്ഥത്തിൽ എന്ത് ചെയ്യുന്നു

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

താഴെയുള്ള വിലാസങ്ങൾ ആ ക്രമീകരണം പ്രതിഫലിപ്പിക്കുന്നു:

Laptop:             192.168.50.20
LAN firewall:       192.168.50.1
WireGuard gateway:  192.168.50.10
Remote VPN subnet:  10.77.0.0/24

റീഡയറക്ടുകളും അവസ്ഥ കൈകാര്യം ചെയ്യലും പിന്നീട് പ്രവർത്തിക്കുന്ന ഹാൻഡ്ഷേക്കിനെ ഉടനടിയല്ല, പിന്നീട് മരിക്കുന്ന കണക്ഷനാക്കി മാറ്റുന്നു. കാലതാമസം അവസ്ഥ എൻട്രി പഴകുന്നതോ കർശനമായ പരിശോധന പരാജയപ്പെടുന്നതോ ആണ്, അതുകൊണ്ടാണ് ഇടവേള ഇത്ര യാന്ത്രികമായി തോന്നുന്നത്.

ഇവയൊന്നും ക്ലയന്റ് കോൺഫിഗറേഷനിൽ കാണുന്നില്ല, അതുകൊണ്ടാണ് അതിന്റെ തിരയൽ സാധാരണയായി തെറ്റായ ഫയലിൽ തുടങ്ങുന്നത്.

ഒരു ഉദ്ദേശിത പാത തിരഞ്ഞെടുക്കുക

മുകളിലെ ക്രമീകരണത്തിന്, ദൂരെയുള്ള സബ്നെറ്റ് നേരിട്ട് VPN ഗേറ്റ്വേയിലേക്ക് റൂട്ട് ചെയ്യുന്നത് പകുതി കണക്ഷൻ നീക്കം ചെയ്യുന്നു:

sudo ip route add 10.77.0.0/24 via 192.168.50.10
ip route get 10.77.0.42

ഇവ ഉദാഹരണ വിലാസങ്ങളാണ്. അടുത്ത ഹോപ്പ് നിങ്ങളുടെ LAN-ൽ എത്താവുന്നതായിരിക്കണം, പ്രിഫിക്സ് ഉദ്ദേശിച്ച ദൂരെയുള്ള നെറ്റ്വർക്കായിരിക്കണം, രണ്ടാമത്തെ കമാൻഡ് അതിൽ ആശ്രയിക്കുന്നതിന് മുൻപ് ഫലം കാണിക്കുന്നു. ഗേറ്റ്വേ നിങ്ങളുടെ സബ്നെറ്റിൽ ഇല്ലെങ്കിൽ, ഈ റൂട്ട് നിങ്ങൾ ആഗ്രഹിക്കുന്ന പരിഹാരമല്ല.

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

Netgate-ന്റെ അസമമിത റൂട്ടിംഗിനെക്കുറിച്ചുള്ള കുറിപ്പുകൾ അതേ ഇന്റർഫേസ് തലത്തിലുള്ള അസമമിതിയും അത് സൃഷ്ടിക്കുന്ന അവസ്ഥ പ്രശ്നങ്ങളും വിവരിക്കുന്നു, അതിനാൽ അവസ്ഥ കൈകാര്യം ചെയ്യൽ ആഗോളമായി അയയ്ക്കുന്നതിന് മുൻപ് അവ വായിക്കുക. ഈ കേസിന് സമാനമായ സമയബന്ധിത വിച്ഛേദനങ്ങൾ അവയൊന്നും തന്നെ തെളിവല്ല. ലേഖനത്തെ ഒരു പരാജയ രീതിയുടെ വിവരണമായി കാണുക, പിന്നീട് ആഗോള അവസ്ഥ നയം മാറ്റുന്നതിന് മുൻപ് നിങ്ങളുടെ സ്വന്തം നെറ്റ്വർക്ക് അതിനോട് ഒത്തുപോകുന്നുവെന്ന് തെളിയിക്കുക.

രണ്ട് അറ്റങ്ങളിൽ നിന്നും പരീക്ഷിക്കുക

ലാപ്ടോപ്പിൽ നിന്ന് ലക്ഷ്യസ്ഥാനത്തേക്കുള്ള റൂട്ടും ലക്ഷ്യസ്ഥാനത്ത് നിന്ന് ലാപ്ടോപ്പിലേക്കുള്ള തിരിച്ചുവരവ് റൂട്ടും വായിക്കുക; ഇവ രണ്ട് വേറിട്ട തീരുമാനങ്ങളാണ്, അവയിൽ ഒന്ന് മാത്രമായിരിക്കാം തെറ്റ്. ഗേറ്റ്വേയിൽ നിന്ന് തന്നെ വിജയിക്കുന്ന ping പ്രശ്നം പൂർണ്ണമായി മറയ്ക്കാം, കാരണം അത് പാത ഇതിനകം ശരിയായ യന്ത്രത്തിൽ നിന്നാണ് ആരംഭിക്കുന്നത്. യഥാർത്ഥ സെഷന്റെ രണ്ട് അറ്റങ്ങൾ കാണുന്നതുപോലെ രണ്ട് ദിശകളും നിങ്ങൾക്ക് വേണം.

പരിഹാരത്തിന് ശേഷം SSH വീണ്ടും തുറക്കുക, മുൻപ് പരാജയപ്പെട്ട ഇടവേളയ്ക്ക് വളരെ അപ്പുറം വരെ സെഷൻ തുറന്നിടുക. പിന്നീട് അംഗീകൃത നെറ്റ്വർക്ക് കോൺഫിഗറേഷനിൽ റൂട്ട് സ്ഥിരമാക്കുക, കാരണം ഒറ്റത്തവണ കമാൻഡ് റീബൂട്ട് പ്ലാനല്ല, അടുത്ത റീബൂട്ടിൽ പ്രശ്നം പുതിയൊരു രഹസ്യവുമായി തിരിച്ചുവരും.

അസമമിതി ശരിയാകുമ്പോൾ

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

നിലനിൽക്കുന്ന ഉത്തരം രണ്ട് പാതകളെയും, രണ്ടും കാണേണ്ട ഉപകരണത്തെയും, അത് സാധ്യമാക്കുന്ന റൂട്ടിനെയും പേരിടുന്നു. ഉപകരണത്തിന് പേരിടാൻ കഴിയുന്നില്ലെങ്കിൽ, നിങ്ങൾ ഇതുവരെ കാരണം കണ്ടെത്തിയിട്ടില്ല.