Linux-ൽ VPN ടണൽ യഥാർത്ഥത്തിൽ പ്രവർത്തിക്കുന്നുണ്ടോ എന്ന് എങ്ങനെ പരിശോധിക്കാം

Cron പത്ത് മിനിറ്റിലൊരിക്കൽ പൂർണ്ണമായും ആരോഗ്യമുള്ള VPN പുനരാരംഭിക്കുന്നു, അതേ ജോലി മരിച്ച ഒന്നിനെ ഒരു ആഴ്ച മുഴുവൻ പ്രവർത്തിപ്പിക്കാൻ വിടുന്നു. രണ്ട് പരാജയങ്ങളും «പ്രവർത്തിക്കുന്നു» എന്നതിനെ ഒരു വസ്തുതയായി കാണുന്നതിൽ നിന്നാണ് വരുന്നത്, എന്നാൽ അത് കുറഞ്ഞത് നാലാണ്. ഒരു ഉപകരണം ഭരണപരമായി സജീവവും ശരിയായി റൂട്ട് ചെയ്തതും പൂർണ്ണമായി എൻക്രിപ്റ്റ് ചെയ്തതും ആയിരിക്കാം, എന്നിട്ടും ഉപയോഗപ്രദമായ ഒന്നും വഹിക്കുന്നില്ലായിരിക്കാം. ആദ്യം നിരീക്ഷണങ്ങൾ വേർതിരിക്കുക, പരിശോധന ഏതാണ്ട് സ്വയം എഴുതപ്പെടും.

ലിങ്ക് ഫ്ലാഗുകൾ ഉപകരണത്തെ വിവരിക്കുന്നു, പാതയെയല്ല

എല്ലാവരും പകർത്തുന്ന പരിശോധന പൂർണ്ണമായും പൂജ്യങ്ങളാൽ നിർമ്മിതമായ ഹാർഡ്വെയർ വിലാസം തിരയുന്നു. ആ തന്ത്രം ചില ഡ്രൈവറുകളിൽ യഥാർത്ഥ ഇന്റർഫേസിനെ പ്ലേസ്ഹോൾഡറിൽ നിന്ന് വേർതിരിക്കുന്നു, ബാക്കിയുള്ളവയിൽ ഒന്നും തെളിയിക്കുന്നുമില്ല, കാരണം tun ഉപകരണത്തിന് റിപ്പോർട്ട് ചെയ്യാൻ MAC ഇല്ലതന്നെ. ip -brief link show tun0 പകരം ഫ്ലാഗുകൾ നൽകുന്നു: UP എന്നാൽ ഒരു അഡ്മിനിസ്ട്രേറ്റർ ഉപകരണം സജീവമാക്കി എന്നാണ്, കൂടാതെ LOWER_UP എന്നാൽ ഡ്രൈവർ ലിങ്ക് ഉപയോഗയോഗ്യമായി കണക്കാക്കുന്നു എന്നാണ്. ഒരുമിച്ച് വായിക്കുമ്പോൾ, ഉപകരണം നിലനിൽക്കുന്നു എന്നും ഭരണപരമായി അടച്ചിട്ടില്ല എന്നും അവ പറയുന്നു. പാക്കറ്റിന് പോകാൻ ഇടമുണ്ട് എന്ന് അവയൊന്നും പറയുന്നില്ല.

OpenVPN റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നതിന് മുമ്പേ തന്റെ tun ഉപകരണം സൃഷ്ടിക്കുന്നു, അതിനാൽ ഒന്നും റൂട്ട് ചെയ്യപ്പെടാത്തപ്പോഴും ഫ്ലാഗുകൾ മികച്ചതായി തോന്നാം. അവയെ മുൻവ്യവസ്ഥയായി കാണുക, ഒരിക്കലും ഉത്തരമായി അല്ല.

പാക്കറ്റ് എവിടേക്ക് പോകുമെന്ന് ചോദിക്കുക

റൂട്ട് തിരയൽ ഫ്ലാഗുകൾക്ക് ഉത്തരം നൽകാൻ കഴിയാത്ത ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു. ip route get 10.8.0.1 from 10.8.0.2 ഇന്റർഫേസ്, ഉറവിട വിലാസം, കെർണൽ ഉപയോഗിക്കുന്ന പട്ടിക എന്നിവയെ പേരിടുന്നു, വിഭജിത ടണലിനെ കൃത്യമായി അതിനെതിരെ പരിശോധിക്കണം. ഉറവിട വിലാസമില്ലാതെ നിങ്ങൾ മറ്റെന്തോ ചോദിക്കുകയാണ്, നയാധിഷ്ഠിത റൂട്ടിംഗിൽ ഉത്തരം ഉറവിടത്തിനനുസരിച്ച് വ്യത്യാസപ്പെടാം. ഇതാണ് ഏറ്റവും വിലകുറഞ്ഞ സത്യസന്ധമായ പരീക്ഷണം, കാരണം ഇത് നിങ്ങളുടെ ട്രാഫിക് ഉപയോഗിക്കുന്ന അതേ നിയമങ്ങളോട് ആലോചിക്കുന്നു.

WireGuard-ന്, ഹാൻഡ്ഷേക്ക് ചേർക്കുക. wg show ഓരോ പിയറിനും അവസാന ഹാൻഡ്ഷേക്കിന്റെ സമയ മുദ്ര അച്ചടിക്കുന്നു, മുന്നോട്ട് പോകുന്നത് നിർത്തിയ മുദ്ര പിയർ പോയി എന്നർത്ഥം, ഇന്റർഫേസ് ഫ്ലാഗുകൾ എന്ത് പറഞ്ഞാലും. സമീപകാല ഹാൻഡ്ഷേക്ക് ഇല്ലാത്ത കോൺഫിഗർ ചെയ്ത ഇന്റർഫേസ് വീട്ടിൽ നിർമ്മിച്ച മോണിറ്ററിംഗിലെ ഏറ്റവും സാധാരണ തെറ്റായ പോസിറ്റീവുകളിൽ ഒന്നാണ്.

പട്ടിക 220 IPsec-ന്റെ കഥ പറയുന്നു

strongSwan റൂട്ട് ഇൻസ്റ്റാളേഷൻ സജീവമായിരിക്കുമ്പോൾ ചർച്ച ചെയ്ത സെലക്ടർമാർക്കായി പട്ടിക 220-ൽ റൂട്ടുകൾ ഇൻസ്റ്റാൾ ചെയ്യുന്നു. ip route list table 220 അതിനാൽ ചർച്ച ചെയ്തതിനെ റൂട്ട് ചെയ്തതിൽ നിന്ന് വേർതിരിക്കുന്നു: ലോഡ് ചെയ്ത കണക്ഷന്റെ അടുത്ത് ശൂന്യമായ പട്ടിക എന്നാൽ IKE, CHILD SA-കൾ ഉയർന്നു, പക്ഷേ അവയിലേക്ക് ഒരു ട്രാഫിക്കും നയിക്കപ്പെടുന്നില്ല എന്നാണ്. പരിശോധിക്കുക ip xfrm state അതിനൊപ്പം, കാരണം അത് ഇൻസ്റ്റാൾ ചെയ്ത സുരക്ഷാ അസോസിയേഷനുകളും അവയുടെ അന്തിമ പോയിന്റുകളും പട്ടികപ്പെടുത്തുന്നു.

ട്രാപ്പ് നയമാണ് ശ്രദ്ധിക്കേണ്ട കേസ്. അത് റൂട്ട് ചെയ്യുന്നതിന് പകരം താൽപര്യമുള്ള ട്രാഫിക്കിനായി കാത്തിരിക്കുന്നു, അതിനാൽ എന്തെങ്കിലും ടണൽ പ്രവർത്തിപ്പിക്കുന്നതുവരെ പട്ടിക ശൂന്യമായി തുടരും.

മാനേജർ അവസ്ഥയും ഡെമോൺ അവസ്ഥയും വ്യത്യസ്ത പട്ടികകളാണ്

NetworkManager തനിക്കുള്ള കണക്ഷനുകൾ മാത്രം പട്ടികപ്പെടുത്തുന്നു. nmcli -t -f NAME,TYPE connection show --active നേരിട്ട് wg-quick അല്ലെങ്കിൽ OpenVPN ഡെമോൺ ആരംഭിച്ച ടണലിന് ഒന്നും തിരികെ നൽകുന്നില്ല.

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

അടുത്ത ഘട്ടത്തെ അതിന് ആവശ്യമായ പരിശോധനയുമായി ബന്ധിപ്പിക്കുക

UDP പോർട്ട് പോൾ ചെയ്യുന്നത് തയ്യാറെടുപ്പിനെക്കുറിച്ച് ഒന്നും തെളിയിക്കുന്നില്ല, കാരണം UDP-ക്ക് ഹാൻഡ്ഷേക്ക് ഇല്ല, nc -u പാക്കറ്റ് പുറത്തുപോകുന്ന ഉടൻ വിജയിക്കുന്നു. അടുത്ത ഘട്ടം യഥാർത്ഥത്തിൽ എന്ത് ഉപഭോഗിക്കുന്നു എന്ന് പരിശോധിക്കുക: ഫോർവേഡ് ചെയ്ത പോർട്ടിലേക്കുള്ള TCP കണക്ഷൻ, ടണലിനുള്ളിലെ ഹോസ്റ്റിലേക്കുള്ള അഭ്യർത്ഥന, അവിടെ മാത്രം പരിഹരിക്കപ്പെടുന്ന ഒരു പേര്. കാത്തിരിപ്പ് ഒരു സമയപരിധിയും ശ്രമങ്ങളുടെ എണ്ണവും കൊണ്ട് പരിമിതപ്പെടുത്തുക, അത് തീരുമ്പോൾ ഉറക്കെ പരാജയപ്പെടുക.

ക്ലയന്റ് ഹുക്കുകൾ നൽകുമ്പോൾ ഹുക്കുകൾ പോളിംഗിനെ തോൽപ്പിക്കുന്നു. --up കൂടാതെ --down OpenVPN-ന്റെ സ്ക്രിപ്റ്റുകൾ ഇന്റർഫേസ് അവസ്ഥ മാറിയതിന് ശേഷം പ്രവർത്തിക്കുന്നു, അത് മത്സരം പൂർണ്ണമായി ഒഴിവാക്കുന്നു, പക്ഷേ അവ ഡെമോൺ സൂക്ഷിച്ച വിശേഷാധികാരങ്ങളോടെ പ്രവർത്തിക്കുന്നു. OpenVPN user കൂടാതെ group വഴി പ്രിവിലേജില്ലാത്ത അക്കൗണ്ടിലേക്ക് താഴ്ന്നാൽ, ഹുക്ക് ആ അക്കൗണ്ടായി പ്രവർത്തിക്കുന്നു. സിസ്റ്റം സേവനം പുനരാരംഭിക്കാൻ അപ്പോൾ sudo വേണം, അത് കൃത്യമായി ആ കമാൻഡിന് അനുമതി നൽകുന്നു. വീണ്ടും ശ്രമിക്കുന്നത് cron ലൂപ്പിന് പകരം സേവന മാനേജർക്ക് ഏൽപ്പിക്കുക: തുടക്ക പരിധിയുള്ള പരിമിതമായ പുനരാരംഭ നയം തകർന്ന ടണൽ പുറത്തുകാണിക്കുന്നു, അതേസമയം പരിധിയില്ലാത്ത ലൂപ്പ് അത് അനിശ്ചിതമായി മറയ്ക്കുന്നു.