OpenVPN 443-ൽ ഇപ്പോഴും തടയപ്പെട്ടിരിക്കുന്നോ? നെറ്റ്വർക്ക് എന്താണ് പരിശോധിക്കുന്നതെന്ന് നോക്കുക

ടണൽ വീട്ടിലെ ലൈനിൽ നിന്ന് കണക്ട് ചെയ്ത് ഹോട്ടലിലെയോ ഓഫീസിലെയോ നെറ്റ്വർക്കിൽ നിൽക്കുന്നു, സെർവർ പോർട്ട് 443-ലേക്ക് മാറ്റിയത് ഒന്നും മാറ്റിയില്ല. ഈ ഫലം എത്ര സാധാരണമാണെന്നാൽ അതിനൊരു രൂപമുണ്ട്: പോർട്ട് എളുപ്പമുള്ള ഭാഗമായിരുന്നു, ബാക്കി തീരുമാനം ക്ലയന്റിനും സെർവറിനും ഇടയിൽ ഇരിക്കുന്ന എല്ലാറ്റിനും സ്വന്തമാണ്. രണ്ട് ചോദ്യങ്ങൾ മിക്ക കേസുകളും തീർപ്പാക്കുന്നു, അവയൊന്നും സൈഫറുകളെക്കുറിച്ചല്ല. ആ വിലാസത്തിലേക്ക് TLS ഹാൻഡ്ഷേക്ക് നെറ്റ്വർക്ക് സ്വീകരിക്കുന്നുണ്ടോ, ടണൽ ഉയർന്നിരിക്കുമ്പോൾ ക്ലയന്റ് തന്റെ സ്വന്തം പൊതിയിലേക്കുള്ള റൂട്ട് സൂക്ഷിക്കുന്നുണ്ടോ?

ഹാൻഡ്ഷേക്ക് സംഖ്യയേക്കാൾ കൂടുതൽ വെളിപ്പെടുത്തുന്നു

TCP 443-ലെ തദ്ദേശീയ VPN ശ്രോതാവ് ആദ്യ പാക്കറ്റിൽ നിന്നുതന്നെ സ്വന്തം പ്രോട്ടോക്കോളിൽ സംസാരിക്കുന്നു. ClientHello-ൽ ഒരു പതിപ്പ് ഫീൽഡ്, ക്രമരഹിത മൂല്യം, വിപുലീകരണങ്ങളുടെ പട്ടിക എന്നിവയുണ്ട്, കുറച്ച് നൂറ് ബൈറ്റ് വായിക്കുന്ന ഉപകരണത്തിന് ഒന്നും ഡീക്രിപ്റ്റ് ചെയ്യാതെ വ്യത്യാസം തിരിച്ചറിയാം. പോർട്ട് നമ്പറുകൾ തൃപ്തിപ്പെടുത്താൻ വിലകുറവാണ്, ഫിൽട്ടർ യഥാർത്ഥത്തിൽ പരിശോധിക്കുന്നത് പ്രോട്ടോക്കോളിന്റെ രൂപമാണ്. നിയമങ്ങൾ സാധാരണയായി പ്രോട്ടോക്കോൾ അനുസരിച്ചും എഴുതുന്നു, അതിനാൽ TLS പരിശോധിക്കുന്ന നയം UDP-യെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല.

സാധുവായ TLS സെഷൻ നിർബന്ധിക്കുന്ന സുതാര്യ പ്രോക്സി ക്രമീകരണ വേളയിൽ തന്നെ കണക്ഷൻ വീഴ്ത്തുന്നു, പലപ്പോഴും TCP ഹാൻഡ്ഷേക്ക് പൂർത്തിയായതിന് ശേഷം. ആ വിശദാംശം പിന്നീട് പ്രധാനമാണ്, കാരണം സോക്കറ്റ് സ്ഥാപിച്ചതിന് ശേഷം ക്ലയന്റ് ലോഗ് നിലയ്ക്കുന്നു എന്നാണ് അതിന്റെ അർത്ഥം.

സ്ട്രീം പൊതിയുന്നത് രണ്ട് പരാജയ ബിന്ദുക്കൾ സൃഷ്ടിക്കുന്നു

stunnel പോലുള്ള TLS പൊതി പ്രതീക്ഷിച്ച രൂപം തിരികെ കൊണ്ടുവരുന്നു: ക്ലയന്റ് പ്രാദേശിക ശ്രോതാവുമായി ബന്ധപ്പെടുന്നു, പൊതി 443-ൽ സെർവറുമായി യഥാർത്ഥ TLS സെഷൻ തുറക്കുന്നു, സെർവറിലെ രണ്ടാമത്തെ പൊതി ഡീക്രിപ്റ്റ് ചെയ്ത ബൈറ്റുകൾ VPN ഡീമണിലേക്ക് കൈമാറുന്നു. പുറം സെഷൻ ഇപ്പോൾ മറ്റേതെങ്കിലും HTTPS കണക്ഷൻ പോലെ തോന്നുന്നു. സെർവറിലെ VPN ഡീമൺ loopback-ൽ മാത്രം കേൾക്കണം, കാരണം പൊതിക്ക് പുറത്തുള്ള ഒന്നിനും അതിൽ എത്തേണ്ടതില്ല.

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

പൊതിയിലേക്കുള്ള വഴിയാണ് കെണി

ടണൽ ഉയർന്നാൽ ഡിഫോൾട്ട് റൂട്ട് അതിലേക്ക് ചൂണ്ടുന്നു, പുറം TLS സെഷന് അത് വഹിക്കുന്ന ടണലിൽ പ്രവേശിക്കാത്ത ഒരു വഴി വേണം. സാധാരണ VPN ക്ലയന്റ് താൻ വിളിക്കുന്ന വിലാസം സംരക്ഷിക്കുന്നു; പൊതിഞ്ഞ ക്ലയന്റ് സ്വന്തം loopback വിളിക്കുന്നു, അതിനാൽ പൊതിയുടെ ലക്ഷ്യ വിലാസം ആ സംരക്ഷണത്തിന് അദൃശ്യമാണ്.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

കൃത്യമായ വിലാസങ്ങൾ നിങ്ങൾ തന്നെ പൂരിപ്പിക്കണം, റൂട്ട് കണക്ഷന്റെ മുഴുവൻ ആയുസ്സിലും ഉണ്ടായിരിക്കണം, തുടക്കത്തിൽ മാത്രമല്ല. ക്ലയന്റിന് മുൻപ് റൂട്ട് ചേർത്ത് പിന്നീട് നീക്കുന്ന ചെറിയ പൊതി സ്ക്രിപ്റ്റ് ഓർത്തുവെച്ച കമാൻഡിനേക്കാൾ വിശ്വസനീയമാണ്.

Android-ൽ ആ ഒഴിവാക്കലിന്റെ തുല്യമായത് ഓരോ ആപ്പിനുമുള്ള ക്രമീകരണമാണ്: പൊതി ആപ്പ് ടണലിൽ നിന്ന് ഒഴിവാക്കുക, അതിന്റെ സ്വന്തം ട്രാഫിക് മൊബൈൽ കണക്ഷനിലൂടെ പുറത്തുപോകാൻ. ഒഴിവാക്കിയില്ലെങ്കിൽ പൊതി നിർമ്മിക്കാൻ ശ്രമിക്കുന്ന ടണലിലേക്ക് തന്നെ അത് വഴിതിരിച്ചുവിടപ്പെടുന്നു, വീണ്ടും ബന്ധിപ്പിക്കാനുള്ള ചക്രം സെർവർ പ്രശ്നമായി തോന്നുന്നു.

എന്തെങ്കിലും മാറ്റുന്നതിന് മുൻപ് സമയം വായിക്കുക

ഓരോ തവണയും അതേ ഇടവേളയ്ക്ക് ശേഷം മരിക്കുന്ന സെഷൻ ക്രിപ്റ്റോഗ്രാഫിക് പരാജയമല്ല, നയത്തിന്റെ ഒപ്പാണ്, ദീർഘകാല ഫ്ലോ പരിധികൾ കൃത്യമായി ആ മാതൃക സൃഷ്ടിക്കുന്നു. ഹാൻഡ്ഷേക്കിന് തൊട്ടുപിന്നാലെ റീസെറ്റ് ചെയ്യുന്ന കണക്ഷൻ സർട്ടിഫിക്കറ്റ് ശൃംഖല ഇഷ്ടപ്പെടാത്ത ഒരു പ്രോക്സിയെ സൂചിപ്പിക്കുന്നു.

രണ്ട് നെറ്റ്വർക്കുകളിൽ നിന്നും ഒരു സാധാരണ HTTPS സൈറ്റിന്റെ സർട്ടിഫിക്കറ്റ് ഇഷ്യൂവറെ താരതമ്യം ചെയ്യുക. നിയന്ത്രിത നെറ്റ്വർക്കിൽ ഇഷ്യൂവർ വ്യത്യസ്തമാണെങ്കിൽ എന്തോ TLS ഇടയിൽ അവസാനിപ്പിക്കുന്നു, ആ തടസ്സം മാറ്റമില്ലാതെ അതിജീവിക്കുന്ന പൊതിയില്ല. അതേ താരതമ്യം തടയൽ നിങ്ങളുടെ സെർവർ പേരിനെയാണോ ആ വിലാസത്തിലെ എല്ലാ TLS സെഷനെയാണോ ലക്ഷ്യമിടുന്നതെന്ന് പറയും.

കണ്ട പെരുമാറ്റം എഴുതിവയ്ക്കുക: സെഷൻ എത്ര നേരം നിന്നു, സോക്കറ്റ് തുറന്നോ, പൊതി ഹാൻഡ്ഷേക്ക് ലോഗ് ചെയ്തോ. ഇവയോരോന്നും അടുത്ത പരിശോധന ചുരുക്കുന്നു.

ഒരു സമയത്ത് ഒരു ചരം പരിശോധിക്കുക

ആദ്യം UDP പരിശോധിക്കുക, ചില നെറ്റ്വർക്കുകൾ അത് പൂർണ്ണമായി വീഴ്ത്തുന്നു, UDP പരാജയം 443-നെക്കുറിച്ച് ഒന്നും പറയുന്നില്ല. പിന്നീട് പൊതിയില്ലാതെ TCP 443 പരീക്ഷിക്കുക, അതിനുശേഷം 443-ൽ പൊതി. ഓരോ ഘട്ടത്തിലും ക്ലയന്റ് ലോഗ് വായിക്കുക, പെരുമാറ്റം മാറിയാൽ ഉടൻ നിർത്തുക.

ഓരോ ശ്രമത്തിലും ഒരു ഘടകം മാറ്റുക. പുതിയ പോർട്ട്, പുതിയ പൊതി, പുതിയ സൈഫർ ഒരേ ഓട്ടത്തിൽ ആണെങ്കിൽ മൂന്നിൽ ഏതാണ് പ്രധാനമായിരുന്നതെന്ന് നിങ്ങൾക്ക് പറയാനാകില്ല.