DHCP പുതുക്കലിന് ശേഷം OpenVPN വീഴുന്നു: എൻഡ്പോയിന്റ് റൂട്ട് നിലനിർത്തുക

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

രോഗലക്ഷണം പകുതി-സ്ഥിര റൂട്ടുകളുമായി താരതമ്യം ചെയ്യുക

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

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

മറ്റെന്തെങ്കിലും തൊടുന്നതിന് മുമ്പ് പട്ടികയുടെ ആകൃതി സ്ഥിരീകരിക്കുക. ip route show രണ്ട് പകുതികളും സെർവർ വിലാസത്തിനായുള്ള ഒരു ഹോസ്റ്റ് റൂട്ടും പട്ടികപ്പെടുത്തണം; ഹോസ്റ്റ് റൂട്ട് ഇല്ലെങ്കിൽ, ബാക്കി അന്വേഷണത്തിന് വ്യക്തമായ ഒരു തുടക്കം ഉണ്ട്.

മെട്രിക് മാറ്റാതെ പകുതി-സ്ഥിര റൂട്ടുകൾ എന്തുകൊണ്ട് ജയിക്കുന്നു

കുറഞ്ഞ മെട്രിക് നീളമുള്ള പ്രിഫിക്സിനെ തോൽപ്പിക്കുന്നില്ല. /1 റൂട്ടുകൾ ജയിക്കുന്നത് കർണൽ ആദ്യം ഏറ്റവും നിർദ്ദിഷ്ട റൂട്ട് പൊരുത്തപ്പെടുത്തുന്നതിനാലാണ്, അതിനാൽ സ്ഥിര റൂട്ടിലെ മെട്രിക് കൂട്ടുന്നത് ടണലിലേക്കുള്ള ട്രാഫിക് എവിടേക്ക് പോകുന്നു എന്നതിൽ ഒന്നും മാറ്റുന്നില്ല. മെട്രിക്കുകൾക്ക് പിന്നാലെ പോകുന്നത് ഈ രോഗനിർണ്ണയത്തിലെ ഏറ്റവും സാധാരണ തെറ്റായ തിരിവാണ്.

ip route get 203.0.113.10 ഉപയോഗിച്ച് തിരഞ്ഞെടുപ്പ് പരിശോധിക്കുക, അതിൽ യഥാർത്ഥ സെർവർ വിലാസം ഇടുക. ഉത്തരം കർണൽ യഥാർത്ഥത്തിൽ ഉപയോഗിക്കുന്ന ഇന്റർഫേസും അടുത്ത ഹോപ്പും പേരിടുന്നു, ഇത് പട്ടിക വായിച്ച് അതിനെക്കുറിച്ച് ചിന്തിക്കുന്നതിനേക്കാൾ വിവരദായകമാണ്.

ആ കമാൻഡ് ടണൽ തുടങ്ങുന്നതിന് മുമ്പ്, അത് പ്രവർത്തിക്കുമ്പോൾ, ലീസ് ഇവന്റിന് ശേഷം എന്നിങ്ങനെ പ്രവർത്തിപ്പിക്കുക. ഒരു കമാൻഡിൽ നിന്ന് മൂന്ന് ഉത്തരങ്ങൾ, വ്യതിയാനത്തിന്റെ ബിന്ദു ദൃശ്യമാകുന്നു.

ഒന്നല്ല, മൂന്ന് സ്നാപ്പ്ഷോട്ടുകൾ എടുക്കുക

ആക്സസ് വിലാസം, ആക്സസ് ഗേറ്റ്വേ, എൻഡ്പോയിന്റ് ലക്ഷ്യം, തിരഞ്ഞെടുത്ത റൂട്ട്, ഏതെങ്കിലും നയ നിയമങ്ങൾ എന്നിവ മൂന്ന് നിമിഷങ്ങളിൽ ശേഖരിക്കുക: ആക്സസ് ലിങ്ക് കോൺഫിഗർ ചെയ്തതിന് ശേഷം, VPN ബന്ധിപ്പിച്ചതിന് ശേഷം, ലീസ് അല്ലെങ്കിൽ കാരിയർ ഇവന്റിന് ശേഷം. ഓരോ സ്നാപ്പ്ഷോട്ടും ഒരു പിടി കമാൻഡുകളാണ്, അവ ഒരുമിച്ച് മാത്രമേ അർത്ഥം നൽകുന്നുള്ളൂ. പരാജയത്തിന് ശേഷമുള്ള ഒരൊറ്റ സ്നാപ്പ്ഷോട്ട് മാറ്റമല്ല, അവസ്ഥ രേഖപ്പെടുത്തുന്നു. കമാൻഡുകൾ ഒരു ചെറിയ സ്ക്രിപ്റ്റിൽ എഴുതുക, ഓരോ സ്നാപ്പ്ഷോട്ടും ഒരേ രീതിയിൽ എടുക്കാൻ.

സ്നാപ്പ്ഷോട്ടുകൾ സമയമുദ്രകളോടെ ഒരു ഫയലിൽ സൂക്ഷിക്കുക, കാരണം പിന്നീട് താൽപ്പര്യമുള്ള ചോദ്യം ക്രമമാണ്. DHCP ഇവന്റ് OpenVPN അതിന്റെ റൂട്ട് പുതുക്കുന്നതിന് മുമ്പോ ശേഷമോ വന്നത്? ഉത്തരം ആര് അത് തിരുത്തണം എന്ന് തീരുമാനിക്കുന്നു. തെറ്റായ ക്ലോക്കിൽ നിന്നുള്ള സമയമുദ്ര ഇല്ലാത്തതിനേക്കാൾ മോശമാണ്, അതിനാൽ റൂട്ടിംഗ് പട്ടികയുള്ള ഹോസ്റ്റിൽ നിന്ന് എടുക്കുക.

എൻഡ്പോയിന്റ് വിലാസത്തിന് പകരം പേരായി കോൺഫിഗർ ചെയ്തിട്ടുണ്ടെങ്കിൽ, ഓരോ സ്നാപ്പ്ഷോട്ടിലും അത് പരിഹരിക്കുക. ആക്സസ് ലിങ്കിലെ DNS മാറ്റം ഒരു റൂട്ടിനെയും തൊടാതെ എൻഡ്പോയിന്റ് നീക്കാം.

ഏത് ഘടകം അപവാദം പുതുക്കുന്നു എന്ന് തീരുമാനിക്കുക

dhcpcd സിസ്റ്റത്തിൽ, ഹൂക്കുകൾ ഹൂക്ക് ഡയറക്ടറിയിൽ നിന്നും എക്സിറ്റ് ഹൂക്കിൽ നിന്നും പ്രവർത്തിക്കുന്നു, മാനേജർ മോഡ് വ്യാപ്തിയിൽ ഓരോ ഇന്റർഫേസ് മോഡിൽ നിന്ന് വ്യത്യസ്തമാണ്. ഹൂക്ക് എന്ത് ചെയ്താലും അത് ഇഡെംപോട്ടന്റ് ആയിരിക്കണം, കാരണം പുതുക്കലുകൾ കൂട്ടമായി വരാം.

വിശ്വസനീയമായ ഉടമ ഇരുവശവും ഇതിനകം അറിയുന്ന സംയോജനമാണ്: VPN കണക്ഷൻ കൈകാര്യം ചെയ്യുന്ന ഒരു നെറ്റ്വർക്ക് മാനേജർ, അല്ലെങ്കിൽ ആക്സസ് ലിങ്ക് ഉയർന്നതിന് ശേഷം ക്രമീകരിച്ച ഒരു യൂണിറ്റ്. ഹൂക്ക് ചേർത്ത സ്ഥിര റൂട്ട് അടുത്ത ഗേറ്റ്വേ മാറ്റം വരെ പ്രവർത്തിക്കുന്നു, പിന്നീട് അതേ രീതിയിൽ തന്നെ പരാജയപ്പെടുന്നു. നിങ്ങൾ ഹൂക്ക് ഉപയോഗിക്കുകയാണെങ്കിൽ, ഇന്ന് കണ്ട ഗേറ്റ്വേ ഹാർഡ്കോഡ് ചെയ്യുന്നതിന് പകരം പ്രവർത്തനസമയത്ത് നിലവിലെ ഗേറ്റ്വേ വായിക്കാൻ അനുവദിക്കുക.

ഉടമയെ കോൺഫിഗറേഷനിൽ രേഖപ്പെടുത്തുക. വീണ്ടും ബന്ധിപ്പിക്കൽ ഡീബഗ് ചെയ്യുന്ന അടുത്ത വ്യക്തി എൻഡ്പോയിന്റ് റൂട്ടിന്റെ ഉത്തരവാദിത്തം VPN അല്ല, ഒരു ഹൂക്ക് ആണെന്ന് അറിയണം.

വീണ്ടും ബന്ധിപ്പിക്കൽ മാത്രമല്ല, ജീവിതചക്രം പരീക്ഷിക്കുക

dhcpcd -n eth0 ഉപയോഗിച്ചോ ലീസ് വിട്ട് വീണ്ടും എടുത്തോ പുതുക്കൽ നിർബന്ധമാക്കുക, പിന്നീട് എൻഡ്പോയിന്റിനായി ip route get വീണ്ടും പരിശോധിക്കുക. ഇത് രണ്ടുതവണ ചെയ്യുക, കാരണം രണ്ടാം റൗണ്ട് തനിപ്പകർപ്പ് റൂട്ടുകൾ ചേർക്കുന്ന ഹൂക്കുകളെ പിടിക്കുന്നു. പിന്നീട് റീബൂട്ട് ചെയ്യുക, കാരണം സ്ഥിരത കൃത്യതയിൽ നിന്ന് വ്യത്യസ്തമായ ഒരു ഗുണമാണ്.

പുതുക്കലും റീബൂട്ടും അതിജീവിക്കുന്ന ടണലിന് ഒരു ഉടമയും പ്രവർത്തിക്കുന്ന അപവാദവും ഉണ്ട്. മാനുവൽ റീസ്റ്റാർട്ട് മാത്രം അതിജീവിക്കുന്നതിന് രണ്ടും ഇല്ല, നിങ്ങൾക്ക് ഷെഡ്യൂൾ ചെയ്യാൻ കഴിയാത്ത അടുത്ത ഇവന്റിൽ അത് പരാജയപ്പെടും.