VPN മാറി: നിങ്ങളുടെ OpenVPN ക്ലയന്റ് ഇപ്പോഴും പഴയ IP-യിൽ വിളിക്കുന്നത് എന്തുകൊണ്ട്

പ്രൊവൈഡർ നിങ്ങളുടെ പൊതു വിലാസം മാറ്റി, നിങ്ങൾ ഡൈനാമിക് DNS റെക്കോർഡ് അപ്ഡേറ്റ് ചെയ്തു, എന്നിട്ടും ക്ലയന്റിന് കണക്ട് ചെയ്യാൻ കഴിയുന്നില്ല. പുറത്തുനിന്ന് നോക്കുമ്പോൾ റെക്കോർഡ് പ്രചരിച്ചിട്ടില്ല എന്നാണ് തോന്നുക. മിക്കപ്പോഴും റെക്കോർഡ് ശരിയാണ്, ക്ലയന്റ് മാറ്റത്തിന് മുമ്പ് റിസോൾവ് ചെയ്ത വിലാസത്തിലാണ് വിളിക്കുന്നത്, കാരണം പ്രവർത്തിക്കുന്ന ടണലിനും സേവ് ചെയ്ത പ്രൊഫൈലിനും സർവർ എവിടെയാണെന്നതിൽ അതാതിന്റെ സ്വന്തം ധാരണയുണ്ട്. മൂന്ന് പാളികൾ യോജിക്കണം, അവ വ്യത്യസ്ത ഷെഡ്യൂളുകളിൽ അപ്ഡേറ്റ് ചെയ്യപ്പെടുന്നു.

DNS പറയുന്നതല്ല, പ്രൊഫൈൽ എന്തിനെ വിളിക്കുന്നു എന്നത് നോക്കുക

നിങ്ങൾ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന കണക്ഷൻ തുറന്ന് remote വരി വായിക്കുക. അവിടെയുള്ള സംഖ്യാ വിലാസം റെക്കോർഡ് എത്ര ശരിയായാലും ഹോസ്റ്റ്നെയിം അപ്ഡേറ്റ് പിന്തുടരുന്നില്ല.

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

രണ്ട് ഫയലുകൾ, ഒരു എൻഡ്പോയിന്റ് — ഇവിടെ സാധാരണ കണ്ടെത്തുന്നത് ഇതാണ്.

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

ക്ലയന്റിന്റെ അടുത്ത കണക്ഷൻ ശ്രമം വായിക്കുക

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

റിസോൾവർ കാഷെയിൽ മുമ്പത്തെ ഉത്തരം ഇപ്പോഴും ഉണ്ടാകാം, ചില നെറ്റ്വർക്കുകൾ റെക്കോർഡിന്റെ TTL ആവശ്യപ്പെടുന്നതിനേക്കാൾ കൂടുതൽ സമയം അത് സൂക്ഷിക്കുന്നു. മറ്റൊരിടത്തുനിന്ന് പരീക്ഷിച്ച പൊതു റിസോൾവറിനെയല്ല, ക്ലയന്റ് യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന റിസോൾവറിനോട് ചോദിക്കുക.

ലോഗ് പുതിയ വിലാസം കാണിക്കുകയും കണക്ഷൻ ഇപ്പോഴും പരാജയപ്പെടുകയും ചെയ്താൽ, പ്രശ്നം മാറിയിരിക്കുന്നു: പാക്കറ്റ് എവിടേക്കോ പോകുന്നു, ആരും ഉത്തരം നൽകുന്നില്ല. ഇത് ഒരു ലിസണർ, ഫയർവാൾ, പോർട്ട് ഫോർവേഡിംഗ് ചോദ്യമാണ്, ഇത് ക്ലയന്റിന്റെ റിസല്യൂഷൻ പാതയിലല്ല, സർവർ ഭാഗത്താണ്. ഈ രണ്ട് പരാജയങ്ങൾ വേർതിരിച്ച് സൂക്ഷിക്കുക, കാരണം എത്തിപ്പെടാനാകാത്ത ലിസണറെ DNS പ്രശ്നമായി കാണുന്നത് അതേ ലൂപ്പിൽ രണ്ടുതവണ നിങ്ങളെ ചുറ്റിക്കുന്നു.

ഏത് പുനരാരംഭമാണ് ചെയ്യുന്നതെന്ന് അറിയുക

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

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

ഏറ്റവും വ്യക്തമായ പരിശോധന ഉദ്ദേശിച്ച പ്രൊഫൈലിൽ നിന്നുള്ള പുതിയ തുടക്കവും, തുടർന്ന് എൻഡ്പോയിന്റ് പറയുന്ന ലോഗ് വരിയിലേക്കുള്ള ഒരു നോട്ടവുമാണ്. ഭാഗികമായി സൂക്ഷിച്ച സെഷനിൽ നിന്ന് നിങ്ങൾ പഠിക്കുന്നതെല്ലാം ആ സെഷനെക്കുറിച്ചുള്ള പ്രസ്താവനയാണ്.

നാല് ഓപ്ഷനുകളും അവയുടെ വേറിട്ട ജോലികളും

ഹോസ്റ്റ്നെയിമുള്ള remote ആണ് വീണ്ടും റിസോൾവ് ചെയ്യൽ സാധ്യമാക്കുന്ന ക്രമീകരണം; ആ വരിയിൽ അക്ഷരാർത്ഥ വിലാസം അത് അസാധ്യമാക്കുന്നു. resolv-retry ലുക്കപ്പ് പരാജയപ്പെടുമ്പോൾ എന്ത് സംഭവിക്കുന്നു എന്ന് നിയന്ത്രിക്കുന്നു, 2.6 അത് ഇതിനകം സ്ഥിരസ്ഥിതിയായി അനന്തമാക്കിയിട്ടുണ്ട്. അതിനാൽ അത് ചേർക്കുന്നത് ഒന്നും മാറ്റുന്നില്ല, വ്യത്യസ്ത ഉത്തരത്തിനായി അത് ഒരിക്കലും ആനുകാലിക പരിശോധന ഷെഡ്യൂൾ ചെയ്യുന്നുമില്ല. അത് പുതിയ വിലാസങ്ങൾ സർവേ ചെയ്യുന്നു എന്ന് പറയുന്നവർ വീണ്ടെടുക്കലും പുതുമയും കൂട്ടിക്കുഴച്ചിരിക്കുന്നു.

persist-remote-ip പുതുമയല്ല, തുടർച്ചയെക്കുറിച്ചാണ്: അവസാനം പ്രാമാണീകരിച്ച എൻഡ്പോയിന്റ്, അത് പിന്തുണയ്ക്കുന്ന സോഫ്റ്റ് പുനരാരംഭങ്ങളിലുടനീളം വീണ്ടും ഉപയോഗിക്കുന്നു. നിങ്ങൾ മാറ്റം പരീക്ഷിക്കുമ്പോൾ അത് നിങ്ങൾ ആഗ്രഹിക്കുന്നതിന്റെ വിപരീതമാണ്. നിങ്ങളുടെ ബിൽഡ് അത് പ്രവർത്തനക്ഷമമാക്കുന്നുവെങ്കിൽ പരിശോധനയ്ക്കായി അത് ഓഫ് ചെയ്യുക, പുതിയ എൻഡ്പോയിന്റ് തെളിയിച്ചതിന് ശേഷം പുനഃസ്ഥാപിക്കുക. ഓണായി വിട്ടാൽ, വിജയകരമായ പുനഃസംയോജനം DNS-നെക്കുറിച്ച് നിങ്ങളോട് ഒന്നും പറഞ്ഞെന്നിരിക്കില്ല.

സെഷന്റെ നടുവിൽ വിലാസം മാറിയ പ്രാമാണീകൃത പിയറിനെ float സ്വീകരിക്കുന്നു, അതിനെ പിന്തുണയ്ക്കുന്ന ക്രമീകരണങ്ങളിൽ മാത്രം. അത് DNS പുതുക്കുന്നില്ല, പ്രൊവൈഡർ മാറ്റം സ്വയം പിന്തുടരുകയുമില്ല. റോമിംഗ് ചെയ്യുന്ന പിയറുകൾക്കുള്ള പ്രതിരോധശേഷി സവിശേഷതയായി അതിനെ കാണുക, സർവറുകൾക്കുള്ള ഡൈനാമിക് വിലാസ സംവിധാനമായല്ല.

ക്ലയന്റിനെ കുറ്റപ്പെടുത്തുന്നതിന് മുമ്പ് പുതിയ എൻഡ്പോയിന്റ് സ്ഥിരീകരിക്കുക

നിങ്ങളുടെ നെറ്റ്വർക്കിന് പുറത്തുനിന്ന്, പുതിയ വിലാസത്തിന് കോൺഫിഗർ ചെയ്ത പോർട്ടിൽ ലിസണർ ഉണ്ടോ എന്നും പ്രൊവൈഡറുടെ ഫോർവേഡിംഗ് അതിനെ ചൂണ്ടുന്നുണ്ടോ എന്നും പരിശോധിക്കുക. തുറന്ന പോർട്ടില്ലാത്ത യന്ത്രത്തിനുള്ള ശരിയായ A റെക്കോർഡ്, ആളുകൾ കാഷിംഗിന് ആരോപിക്കുന്ന അതേ ലക്ഷണം തന്നെ ഉണ്ടാക്കുന്നു.

തുടർന്ന് വീണ്ടും കണക്ട് ചെയ്ത് രണ്ട് കാര്യങ്ങൾ പരിശോധിക്കുക: ക്ലയന്റ് പ്രതീക്ഷിച്ച സർവർ സർട്ടിഫിക്കറ്റിനെതിരെ പ്രാമാണീകരിച്ചു, സെഷൻ നിങ്ങൾ ഉദ്ദേശിച്ച വിഭവത്തിൽ എത്തുന്നു. വിലാസ മാറ്റം ഐഡന്റിറ്റി ആവശ്യകതകൾ കുറയ്ക്കുന്നില്ല, തെറ്റായ എൻഡ്പോയിന്റിലേക്ക് വിജയിക്കുന്ന കണക്ഷൻ പരാജയപ്പെടുന്നതിനേക്കാൾ മോശമാണ്. OpenVPN 2.6 മാനുവൽ നാല് ഓപ്ഷനുകളും അവയുടെ സ്വന്തം പരിധിയോടെ പട്ടികപ്പെടുത്തുന്നു, അതാണ് പ്രൊഫൈലിന് അരികിൽ സൂക്ഷിക്കേണ്ട ചെക്ക്ലിസ്റ്റ്.

നിങ്ങളുടെ അഡ്മിനിസ്ട്രേറ്റീവ് പ്രവേശനം വഹിക്കുന്ന ടണൽ പുനരാരംഭിക്കുന്നതിന് മുമ്പ് സർവറിലേക്ക് ഒരു ഔട്ട്-ഓഫ്-ബാൻഡ് വഴി സൂക്ഷിക്കുക. ആ ഒരു മുൻകരുതൽ ഈ സാഹചര്യം ഉണ്ടാക്കുന്ന മിക്ക സംഭവങ്ങളും തടയുന്നു.