OpenVPN വീട്ടിൽ പ്രവർത്തിക്കുന്നു, എന്നാൽ ഒരു നെറ്റ്വർക്കിൽ ഇല്ല: UDP അല്ലെങ്കിൽ TCP?

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

ഏത് ഘട്ടം പരാജയപ്പെട്ടു എന്നത് ഏത് താരതമ്യമാണ് പ്രധാനം എന്ന് പറയുന്നു

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

പിന്നീടല്ല, വീണ്ടും ശ്രമിക്കുമ്പോൾ ക്യാപ്ചർ ചെയ്യുക. ക്ലയന്റിൽ tcpdump -ni any udp port 1194 ഏതെങ്കിലും പ്രതികരണം തിരികെ വരുന്നുണ്ടോ എന്ന് കാണിക്കുന്നു. നിങ്ങൾ നിയന്ത്രിക്കുന്ന ഒരു സെർവറിന്റെ WAN ഇന്റർഫേസിൽ ഇത് ആവർത്തിക്കുക, അത് ആ പാക്കറ്റുകൾ ദൂരെ അറ്റത്ത് എത്തുന്നുണ്ടോ എന്ന് വെളിപ്പെടുത്തും.

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

UDP ഫിൽട്ടറിംഗും അടച്ച പോർട്ടും

പല ആക്സസ് നെറ്റ്വർക്കുകളും തുടർച്ചയായ UDP-യെ സംശയാസ്പദമായി കാണുന്നു, ചില ISP-കൾ അവരോട് യോജിക്കുന്നു. അടച്ച പോർട്ട് ക്ലയന്റ് ഭാഗത്ത് നിന്ന് അതേ നിശ്ശബ്ദത സൃഷ്ടിക്കുന്നു. വ്യത്യാസം തിരഞ്ഞെടുപ്പാണ്: ഫിൽട്ടർ ഏത് ലക്ഷ്യസ്ഥാനങ്ങളോ പോർട്ടുകളോ ഉപേക്ഷിക്കുന്നു എന്നതിൽ വിവേചനം കാണിക്കുന്നു, അടച്ച പോർട്ട് ആ പോർട്ടിലേക്ക് ലക്ഷ്യമിട്ട എല്ലാം നിരസിക്കുന്നു.

പോർട്ട് 443-ലെ TCP പ്രൊഫൈൽ സാധാരണ പരിഹാരമാണ്, കാരണം അത് സാധാരണ HTTPS പ്രവാഹത്തോട് സാദൃശ്യമുള്ളതും മിക്ക captive പോർട്ടലുകളും എഗ്രസ് ഫിൽട്ടറുകളും കടക്കുന്നതുമാണ്. രണ്ട് വ്യവസ്ഥകൾ പാലിക്കണം. സെർവർ proto tcp-server ഉപയോഗിച്ച് കേൾക്കണം, ക്ലയന്റ് proto tcp-client മായി പൊരുത്തപ്പെടണം, ഓപ്പറേറ്റർ ആ ഇതര എൻഡ്പോയിന്റ് പ്രസിദ്ധീകരിക്കണം. പ്രവർത്തിക്കുന്ന ഒരു UDP പ്രൊഫൈൽ TCP 443 എന്ന് അവകാശപ്പെടാൻ മാറ്റിയെഴുതുന്നത് മറുവശത്ത് ആരും കേൾക്കാത്തപ്പോൾ ഒന്നും നേടുന്നില്ല.

അടച്ച പോർട്ട് സെൻസർഷിപ്പ് പ്രശ്നമല്ല, കോൺഫിഗറേഷൻ പ്രശ്നമാണ്. വീട്ടിലെ റൗട്ടറിന് പിന്നിലുള്ള സെർവറിന് അതിന്റെ UDP പോർട്ട് ഫോർവേഡ് ചെയ്യേണ്ടതുണ്ട്, റൗട്ടറിന്റെ ഫയർവാൾ അത് അനുവദിക്കണം. പോർട്ട് ഒരിക്കലും അനുവദിച്ചിട്ടില്ലെങ്കിൽ, ക്രെഡൻഷ്യലുകൾ പരിഗണിക്കാതെ ഓരോ ക്ലയന്റും ചർച്ചയിൽ പരാജയപ്പെടുന്നു, പരാജയം നെറ്റ്വർക്കിനെയല്ല, സെർവറിനെ പിന്തുടരുന്നു.

പഴയ പ്രോട്ടോക്കോളുകൾ ഈ അച്ചുതണ്ടിൽ മോശമായി താരതമ്യപ്പെടുന്നു. PPTP-യ്ക്ക് TCP 1723-ഉം GRE-യും ആവശ്യമാണ്, GRE പോർട്ടല്ല, IP പ്രോട്ടോക്കോൾ 47 ആണ്, അതിനാൽ സാധാരണ പോർട്ട് ഫോർവേഡിംഗിന് അത് പ്രകടിപ്പിക്കാനാവില്ല.

പാക്കറ്റുകൾ ഉപേക്ഷിക്കുന്നത് സ്വിച്ച് ആയിരിക്കുമ്പോൾ

നിയന്ത്രിത സ്വിച്ചിന് ഉദ്ദേശ്യപൂർവ്വം ടണൽ ഉപേക്ഷിക്കാനാകും. ചില HPE, Aruba മോഡലുകൾ വിപുലീകൃത സുരക്ഷാ വിഭാഗത്തിൽ UDP ഫ്ലഡ് സംരക്ഷണ നിയന്ത്രണം നൽകുന്നു, ചിലപ്പോൾ Prevent UDP Blat Attack എന്ന് ലേബൽ ചെയ്യുന്നു. ആ നിയന്ത്രണം സജീവമാകുമ്പോൾ, സ്വിച്ചിന് പിന്നിലുള്ള സെർവർ ഒന്നിനും ഉത്തരം നൽകുന്നില്ല, ഓരോ ക്ലയന്റും അതേ രീതിയിൽ സമയപരിധി കവിയുന്നു. അത് മായ്ച്ച് പ്രവർത്തിക്കുന്ന കോൺഫിഗറേഷൻ സംരക്ഷിക്കുന്നതാണ് മുഴുവൻ അറ്റകുറ്റപ്പണി, എന്നാൽ സ്വിച്ച് യഥാർത്ഥത്തിൽ പാതയിലുണ്ടെന്ന് സ്ഥാപിച്ചതിന് ശേഷം മാത്രം.

വിപരീത തെളിവുകളാണ് സ്വിച്ച് ഉപേക്ഷിക്കലിനെ ദാതാവിന്റെ ബ്ലോക്കിൽ നിന്ന് വേർതിരിക്കുന്നത്. ISP-യിൽ ടിക്കറ്റ് തുറക്കുന്നതിന് മുമ്പ് ഇന്റർഫേസ് കൗണ്ടറുകളും ഫ്ലഡ് സംരക്ഷണ ലോഗും വായിക്കുക. DoS അല്ലെങ്കിൽ ഫ്ലഡ് സംരക്ഷണമുള്ള ഉപഭോക്തൃ റൗട്ടറുകളും അതേ രൂപത്തിൽ പരാജയപ്പെടുന്നു, ചെറിയ UDP ഐഡിൽ സമയപരിധിയുള്ള ഏത് മിഡിൽബോക്സും അങ്ങനെതന്നെ. ഒരിക്കലും പൂർത്തിയാകാത്ത ഹാൻഡ്ഷേക്ക് ഉപേക്ഷിക്കലിനെ സൂചിപ്പിക്കുന്നു, കുറച്ച് മിനിറ്റ് നിശ്ശബ്ദതയ്ക്ക് ശേഷം മരിക്കുന്ന ടണൽ സമയപരിധിയെ സൂചിപ്പിക്കുന്നു.

പ്രൊഫൈൽ മാറ്റുന്നതിന് മുമ്പ് ക്ലയന്റിനും സെർവറിനും ഇടയിലുള്ള ഓരോ ഉപകരണവും എഴുതിവയ്ക്കുക. തെറ്റായ പാളിയിൽ പ്രയോഗിച്ച പരിഹാരം അടുത്ത നെറ്റ്വർക്ക് വരെ ശരിയായി തോന്നും. ആ പട്ടിക അടുത്ത എഞ്ചിനീയറോട് മുഴുവൻ അന്വേഷണവും ആവർത്തിക്കാതെ എവിടെ നോക്കണമെന്നും പറയുന്നു.

DNS പരാജയമായി തോന്നുന്ന വിലാസ ഓവർലാപ്പ്

10.0.0.0/8-നുള്ളിൽ നമ്പർ ചെയ്ത ആക്സസ് നെറ്റ്വർക്ക് ടണൽ പൂളുമായി ഓവർലാപ്പ് ചെയ്യാം, റെസോൾവർ സാധാരണയായി ആ പൂളിനുള്ളിലാണ്. ലാപ്ടോപ്പിന് Wi-Fi-യിൽ 10.184.178.50 പോലുള്ള ഒരു വിലാസം /8 മാസ്കോടെ ലഭിക്കുമ്പോൾ, ഓരോ 10.x ലക്ഷ്യവും നിർവചനപ്രകാരം പ്രാദേശികമാണ്. 10.4.0.1 ലേക്കുള്ള പാക്കറ്റുകൾ പിന്നീട് LAN-ലേക്ക് പോകുന്നു, ടണൽ സജീവമായി തുടരുന്നു, പേര് വിവർത്തനം പരാജയപ്പെടുന്നു.

ip addr ഓവർലാപ്പ് ഒറ്റനോട്ടത്തിൽ വെളിപ്പെടുത്തുന്നു, ip route get 10.4.0.1 പാക്കറ്റ് യഥാർത്ഥത്തിൽ എവിടെ എത്തിക്കുമെന്ന് കാണിക്കുന്നു. കാണാവുന്ന ലക്ഷണം റെസോൾവർ പരാജയമായതിനാൽ, ഇത് പലപ്പോഴും നിരവധി DNS മാറ്റങ്ങളെ അതിജീവിക്കുന്നു.

പൂൾ വീണ്ടും നമ്പർ ചെയ്യുക അല്ലെങ്കിൽ ആ ആക്സസ് നെറ്റ്വർക്ക് പരിധിക്ക് പുറത്ത് നിർത്തുക. ഏതെങ്കിലും ക്ലയന്റ് സൈഡ് ക്രമീകരണത്തിന് ഓവർലാപ്പിൽ നിന്ന് കരകയറാനാവില്ല.

TCP ബാക്കപ്പും പാത പരിഹാരവും തമ്മിൽ തീരുമാനിക്കൽ

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

ഫലം ഉപയോക്താവിനനുസരിച്ചല്ല, നെറ്റ്വർക്കിനനുസരിച്ച് രേഖപ്പെടുത്തുക. അതേ പരാജയത്തിന്റെ അടുത്ത റിപ്പോർട്ട് പിന്നീട് സർട്ടിഫിക്കറ്റ് സിദ്ധാന്തത്തിൽ നിന്നല്ല, അറിയപ്പെടുന്ന ഘട്ടത്തിൽ നിന്ന് ആരംഭിക്കുന്നു. ആ രേഖയാണ്, എപ്പോഴെങ്കിലും ആവശ്യമായാൽ, സ്ഥിരമായ രണ്ടാമത്തെ listener-നെ ന്യായീകരിക്കുന്നതും.