WAN IP മാറി ടണൽ വീണു: ക്രമത്തിൽ പരിശോധന
WAN സംഭവം രേഖപ്പെടുത്തുക, പിന്നെ അതിനെ പിന്തുടരാത്തത് നോക്കുക: പഴയ വിവർത്തന എൻട്രികൾ, പഴയ ഗേറ്റ്വേയിൽ ബന്ധിപ്പിച്ച റൂട്ടുകൾ, പഴയ വിലാസത്തിലേക്ക് ഇപ്പോഴും അയയ്ക്കുന്ന പിയർമാർ.
ടണൽ വീഴുന്നു, റൗട്ടർ വീണ്ടും ബന്ധിപ്പിക്കൽ രേഖപ്പെടുത്തുന്നു, LAN-ൽ ഒന്നും നീങ്ങിയിട്ടില്ല. പുതിയ WAN വിലാസം ഉള്ളിൽ ഒന്നും മാറ്റാതെ പുറം ബന്ധം അസാധുവാക്കുന്നു: ക്ലയന്റിന്റെ ഉറവിട വിലാസം മാറി, പഴയ NAT അവസ്ഥ ഇനി ഇല്ലാത്ത ഒരു ഉറവിടത്തിലേക്ക് ചൂണ്ടുന്നു, കൂടാതെ ദൂരെയുള്ള പിയർ ഇപ്പോഴും മുൻ വിലാസത്തിലേക്ക് അയയ്ക്കുന്നുണ്ടാകാം. വീണ്ടെടുക്കൽ സാധാരണ സ്വഭാവമാണ്, ഉപയോഗപ്രദമായ ചോദ്യം ഏത് അവസ്ഥ പുതുക്കപ്പെട്ടില്ല എന്നതാണ്.
ലോഗ് വായിക്കുന്നതിന് മുൻപ് സംഭവത്തിന് പേരിടുക
ആക്സസ് പാളിയിൽ യഥാർത്ഥത്തിൽ എന്ത് സംഭവിച്ചുവെന്ന് പരിശോധിക്കുക. ISP ലീസ് പുതുക്കൽ ഒരു സംഭവമാണ്. വീണ്ടും ബന്ധിപ്പിച്ച PPPoE സെഷൻ മറ്റൊന്നാണ്. റീബൂട്ട് ചെയ്ത ഫൈബർ മോഡം, അല്ലെങ്കിൽ ഒരു അപ്ലിങ്കിൽ നിന്ന് മറ്റൊന്നിലേക്കുള്ള WAN ഫെയിൽഓവർ, പുറം വിലാസത്തെയോ അതിന്റെ പാതയെയോ മൂന്നാമത്തെ രീതിയിൽ മാറ്റുന്നു. ഇവ ഒരേ സംഭവമല്ല, ഒരേ അവശിഷ്ടവും അവശേഷിപ്പിക്കുന്നില്ല.
VPN ലോഗിലെ വീണ്ടും ബന്ധിപ്പിക്കൽ വരിയും WAN മാറ്റത്തിന്റെ തെളിവല്ല. നിഷ്ക്രിയ കാലപരിധി, വീണ്ടും പ്രാമാണീകരണ ഇടവേള, മരിച്ച പിയർ കണ്ടെത്തൽ — എല്ലാം വിലാസ മാറ്റമില്ലാതെ വീണ്ടും ബന്ധിപ്പിക്കലുകൾ സൃഷ്ടിക്കുന്നു. എന്തെങ്കിലും തീരുമാനിക്കുന്നതിന് മുൻപ് ആക്സസ് ലോഗിലെ സമയ മുദ്രകൾ VPN ലോഗുമായി താരതമ്യം ചെയ്യുക, രാത്രിയിൽ സംഭവിച്ച മാറ്റവും പിടിക്കാൻ താരതമ്യ വിൻഡോ മതിയായ വീതിയിൽ സൂക്ഷിക്കുക.
റോമിംഗും വീണ്ടും ബന്ധിപ്പിക്കലും വ്യത്യസ്ത പ്രോട്ടോക്കോളുകളാണ്
WireGuard-ൽ പ്രാമാണീകരിച്ച റോമിംഗ് പ്രോട്ടോക്കോളിൽ തന്നെ ഉൾക്കൊള്ളിച്ചിട്ടുണ്ട്: ഒരു പിയർ പുതിയ ഉറവിട വിലാസത്തിൽ നിന്ന് ശരിയായി പ്രാമാണീകരിച്ച പാക്കറ്റ് സ്വീകരിക്കുമ്പോൾ, അത് ആ പിയറിന്റെ എൻഡ്പോയിന്റ് പുതുക്കുന്നു. WireGuard വേഗത്തിലുള്ള തുടക്കം ഇത് സാധ്യമാക്കുന്ന പിയർ കോൺഫിഗറേഷൻ വിവരിക്കുന്നു, അതുകൊണ്ട് മാറുന്ന വിലാസത്തിലുള്ള ക്ലയന്റ് പലപ്പോഴും ദൃശ്യമായ പുനരാരംഭമില്ലാതെ കരകയറുന്നു.
OpenVPN സ്വതേ വ്യത്യസ്തമായി പെരുമാറുന്നു. UDP സെഷൻ അവസാനിച്ച് വീണ്ടും ബന്ധിപ്പിക്കാം, ഒപ്പം ഓപ്ഷണൽ float സ്വഭാവം പ്രാമാണീകരിച്ച പിയറിന് കോൺഫിഗറേഷൻ അനുവദിക്കുന്നിടത്ത് പുതിയ വിലാസത്തിൽ നിന്ന് തുടരാൻ അനുവദിക്കുന്നു. TCP അടിസ്ഥാനമാക്കിയ ടണലുകൾ കൂടുതൽ കർശനമാണ്, കാരണം കണക്ഷൻ തന്നെ വിലാസ ജോടിയിൽ ബന്ധിതമാണ്. ആ വ്യത്യാസമാണ് വീണ്ടെടുക്കൽ അദൃശ്യമായി കാണപ്പെടുമോ അതോ ഓരോ തവണയും ലോഗിൽ സ്വയം പ്രഖ്യാപിക്കുമോ എന്ന് നിർണ്ണയിക്കുന്നത്.
രണ്ട് സ്വഭാവങ്ങളും ഉള്ളിലെ അപ്ലിക്കേഷനുകളെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. വീണ്ടെടുത്ത ടണൽ പിയർ ഇതിനകം മരിച്ചതായി കണക്കാക്കിയ TCP സെഷൻ പുനഃസ്ഥാപിക്കുന്നില്ല.
ടണലിന് അവകാശമില്ലാത്ത അവസ്ഥ
വിവർത്തന-റൂട്ടിംഗ് അവസ്ഥ ആളുകളെ അത്ഭുതപ്പെടുത്തുന്ന രീതിയിൽ വീണ്ടും ബന്ധിപ്പിക്കലിനെ അതിജീവിക്കുന്നു. പഴയ ഉറവിടത്തിനായി സൃഷ്ടിച്ച conntrack എൻട്രി മറുപടി പാതയെ ഇനി ഇല്ലാത്ത ഒരു വിലാസത്തിൽ ഉറപ്പിച്ചു നിർത്തുന്നു, അത് ടണൽ തിരികെ വന്നപ്പോഴല്ല, സ്വന്തം ഷെഡ്യൂൾ പ്രകാരം കാലഹരണപ്പെടുന്നു. ടണൽ സേവനം പുനരാരംഭിക്കുന്നത് ആ കാത്തിരിപ്പ് കുറയ്ക്കുന്നില്ല, അതിനാൽ നന്നാക്കിയ ലിങ്ക് കുറച്ചുനേരം കൂടി പൊട്ടിയതായി തോന്നാം.
റൂട്ടുകളും നയ നിയമങ്ങളും പഴയ ഗേറ്റ്വേയെയോ ഇന്റർഫേസിനെയോ പരാമർശിക്കാം. WAN മാറ്റത്തിന് മുൻപ് ശരിയായിരുന്ന ഒരു നിയമ സമൂഹം ഇപ്പോൾ പ്രവർത്തനരഹിതമായ ഒരു ഉപകരണത്തിലേക്ക് ചൂണ്ടാം, അത് ബന്ധിപ്പിച്ചതായി റിപ്പോർട്ട് ചെയ്യുന്ന ടണലും എവിടെയും പോകാത്ത ട്രാഫിക്കും സൃഷ്ടിക്കുന്നു. നിങ്ങൾ ഹോസ്റ്റ് ചെയ്യുന്ന സെർവറിനുള്ള ഡൈനാമിക് DNS പുതിയ ഉറവിടം നേടുന്ന ക്ലയന്റിൽ നിന്ന് വേറിട്ട ഒരു പ്രശ്നമാണ്. ദൂരെയുള്ള ക്ലയന്റുകൾ നിങ്ങളെ കണ്ടെത്താൻ റെക്കോർഡ് പുതുക്കണം, മേൽഭാഗത്തെ വിവർത്തനം കൈമാറാത്ത വിലാസത്തിന് ഒരു ക്ലയന്റ് വശ കോൺഫിഗറേഷനും പകരം വയ്ക്കുന്നില്ല.
പരിശോധനകൾ പുറത്തുനിന്ന് ഉള്ളിലേക്ക് ക്രമീകരിക്കുക
താഴെയുള്ള ക്രമം പുറം ബന്ധത്തിൽ നിന്ന് ഉള്ളിലേക്ക് പോകുന്നു, ആദ്യം പരാജയപ്പെടുന്ന ഘട്ടത്തിൽ നിർത്തുന്നതാണ് അതിനെ ഉപയോഗപ്രദമാക്കുന്നത്: ഓരോ പരിശോധനയും അതിന് മുകളിലുള്ള പാളിയെ ഒഴിവാക്കുന്നു. തകരാർ വ്യക്തമായി തോന്നിയാലും ഈ ക്രമം പാലിക്കുക.
wg show
ip -br addr show
ip route get 198.51.100.7
conntrack -L 2>/dev/null | grep -c ESTABLISHED
journalctl -u openvpn-client@home --since '-2 hours' | tail -n 40
ആദ്യ കമാൻഡ് ഓരോ പിയറിന്റെയും നിലവിലെ എൻഡ്പോയിന്റും ഹാൻഡ്ഷേക്കിന്റെ പ്രായവും കാണിക്കുന്നു. രണ്ടാമത്തേതും മൂന്നാമത്തേതും പുറം ഇന്റർഫേസും എൻഡ്പോയിന്റിലേക്കുള്ള റൂട്ടും ഇപ്പോഴും അർത്ഥവത്താണോ എന്ന് കാണിക്കുന്നു. conntrack എണ്ണം പഴയ വിലാസത്തിൽ നിന്ന് ശേഷിക്കുന്ന അവസ്ഥയ്ക്കുള്ള ഒരു പരുക്കൻ പരിശോധനയാണ്, ജേണൽ വീണ്ടും ബന്ധിപ്പിക്കലിന്റെ കാരണം രേഖപ്പെടുത്തുന്ന സ്ഥലവുമാണ്.
പിന്നെ റൗട്ടറിൽ നിന്നല്ല, LAN ക്ലയന്റിൽ നിന്ന് പരീക്ഷിക്കുക. റൗട്ടർ തന്നെ അയച്ച പിംഗ് ഫോർവേഡ് ചെയ്ത ട്രാഫിക്കിൽ നിന്ന് വ്യത്യസ്തമായ പാത ഉപയോഗിക്കുന്നു, അതിനാൽ വിജയകരമായ റൗട്ടർ പിംഗ് ടണൽ ഉണ്ടെന്ന് തെളിയിക്കുന്നു, ക്ലയന്റിന്റെ എത്തിച്ചേരലിനെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.
പ്രതീക്ഷിക്കുന്ന സ്വഭാവം തീരുമാനിച്ച് എഴുതിവയ്ക്കുക
മിക്ക വിന്യാസങ്ങൾക്കും വീണ്ടും ബന്ധിപ്പിക്കൽ ശരിയായ സ്വഭാവമാണ്, അതിനാൽ ലക്ഷ്യം അത് തടയലല്ല. പകരം ഇടവേളയിൽ ട്രാഫിക്കിന് എന്ത് സംഭവിക്കണമെന്ന് തീരുമാനിക്കുക: നിർത്തുക, പിടിച്ചുവയ്ക്കുക, അല്ലെങ്കിൽ മറ്റൊരു പാതയിലേക്ക് ഫെയിൽഓവർ ചെയ്യുക. ആ തീരുമാനം ഫയർവാളിനും റൂട്ടിംഗ് നയത്തിനും സ്വന്തമാണ്, VPN പ്രൊഫൈലിനല്ല.
ഒരു ആഴ്ചയോളം ആക്സസ് സംഭവങ്ങളും വീണ്ടും ബന്ധിപ്പിക്കൽ സമയങ്ങളും ഒരുമിച്ച് രേഖപ്പെടുത്തുക. യോജിക്കുന്ന ആക്സസ് സംഭവമില്ലാത്ത ആവർത്തിച്ചുള്ള മാറ്റങ്ങൾ ആക്സസ് സേവനത്തിലേക്ക് ചൂണ്ടുന്നു, VPN പ്രൊഫൈൽ മാറ്റുന്നത് വീണ്ടും വീണ്ടും ചർച്ച ചെയ്യുന്ന അപ്ലിങ്ക് ശരിയാക്കില്ല. ഒരേ മിനിറ്റിലെ ഒരു ജോടി എൻട്രികൾ ആ സംഭവത്തിന്റെ ചോദ്യം തീർക്കുകയും അടുത്തതിന് അടിസ്ഥാനരേഖ നൽകുകയും ചെയ്യുന്നു.