UDP ബ്ലോക്ക് ചെയ്യുന്നത് ISP ആണോ, അതോ ടണലിനുള്ളിലെ ആപ്പോ?

VPN „UDP ബ്ലോക്ക് ചെയ്യുന്നു“ എന്ന് ആരോ റിപ്പോർട്ട് ചെയ്യുന്നു, ഈ വാക്യം തികച്ചും വ്യത്യസ്തമായ രണ്ട് വാദങ്ങൾ ഒളിപ്പിക്കുന്നു. ഒന്ന് ആക്സസ് നെറ്റ്‌വർക്കിന് കാണാവുന്ന ട്രാൻസ്പോർട്ടിനെക്കുറിച്ച്, മറ്റൊന്ന് ടണലിനുള്ളിൽ ഡീക്രിപ്റ്റ് ചെയ്തതിന് ശേഷമുള്ള ആപ്പിന്റെ പാക്കറ്റുകളെക്കുറിച്ച്. എൻക്രിപ്റ്റ് ചെയ്ത ടണൽ ഒരു കീയും കൂടാതെ പുറത്തുനിന്ന് ഫിൽട്ടർ ചെയ്യാം, ആന്തരിക UDP ആപ്പ് ഫിൽട്ടറിംഗുമായി യാതൊരു ബന്ധവുമില്ലാത്ത കാരണങ്ങളാൽ പരാജയപ്പെടാം. തെളിവുകൾ ശേഖരിക്കുന്നതിന് മുമ്പ് നിങ്ങൾ ഏത് വാദമാണ് പരിശോധിക്കുന്നതെന്ന് തീരുമാനിക്കുക.

രണ്ട് ഹെഡറുകൾ, ഒരു വാക്ക്

NAT-traversal ഉള്ള IPsec വിന്യാസത്തിൽ പുറം പാക്കറ്റ് UDP ആണ്, രണ്ട് VPN എൻഡ്‌പോയിന്റുകൾക്കിടയിൽ വിലാസം നൽകിയത്, സാധാരണയായി പോർട്ട് 4500-ൽ. അതിനുള്ളിൽ എൻക്രിപ്റ്റ് ചെയ്ത പേലോഡ് ടണൽ കൈമാറുന്ന എല്ലാം വഹിക്കുന്നു, അത് തന്നെ TCP അല്ലെങ്കിൽ UDP ആകാം. അതിനാൽ UDP എന്ന വാക്ക് രണ്ടുതവണ വരുന്നു, വ്യത്യസ്ത അർത്ഥത്തിലും വ്യത്യസ്ത ദൃശ്യതയിലും.

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

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

നെറ്റ്‌വർക്കിന് ഇപ്പോഴും കാണാനാകുന്നത്

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

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

ആദ്യ ക്യാപ്ചർ ഫിസിക്കൽ ഇന്റർഫേസിലെ പുറം ഫ്ലോ കാണിക്കുന്നു, രണ്ടാമത്തേത് ടണൽ ഇന്റർഫേസിലെ ആന്തരിക ഫ്ലോ കാണിക്കുന്നു. രണ്ടും ഒരുമിച്ച് പ്രവർത്തിപ്പിക്കുന്നത് ചോദ്യത്തിന് നേരിട്ട് ഉത്തരം നൽകുന്നു: പുറം ഫ്ലോ ഉണ്ടായിരിക്കുകയും ആന്തരികം ഇല്ലാതിരിക്കുകയും ചെയ്താൽ, ആപ്പ് ടണലിലേക്ക് ഒന്നും അയച്ചിട്ടില്ല. രണ്ടും ഉണ്ടായിരിക്കുകയും ഒന്നും തിരികെ വരാതിരിക്കുകയും ചെയ്താൽ, പ്രശ്നം ടണലിന് അപ്പുറമാണ്, ലക്ഷ്യത്തിലോ മടക്കയാത്രയിലോ.

RFC 3948 പുറം UDP എൻക്യാപ്സുലേഷൻ നിർവചിക്കുന്നു, ESP വിശദീകരണം അതിനുള്ളിലെ സംരക്ഷിത ക്രമീകരണം നിർവചിക്കുന്നു. രണ്ട് രേഖകളും ആക്സസ് നെറ്റ്‌വർക്ക് പുറം ഫ്ലോ കടത്തിവിടുമെന്ന് വാഗ്ദാനം ചെയ്യുന്നില്ല, അതിനാൽ ആന്തരികത്തെക്കുറിച്ചുള്ള ഏതെങ്കിലും സിദ്ധാന്തത്തിന് മുമ്പ് പുറം ട്യൂപിളിൽ എത്തിച്ചേരാനുള്ള പരിശോധന നടത്തുന്നത് മൂല്യവത്താണ്. ബ്ലോക്ക് ചെയ്ത പുറം ട്യൂപിൾ ഒരിക്കലും രൂപപ്പെടാത്ത ടണൽ സൃഷ്ടിക്കുന്നു, രൂപപ്പെട്ട് പിന്നീട് ഒരു ആപ്പ് നഷ്ടപ്പെടുന്ന ടണലല്ല.

പ്രവർത്തിക്കുന്ന ടണലിനുള്ളിൽ ഒരു UDP ആപ്പ് പരാജയപ്പെടുന്നത് എന്തുകൊണ്ട്

വെബ് ആപ്പ് കൊണ്ടുപോകുന്നുവെങ്കിലും UDP ആപ്പ് കൊണ്ടുപോകാത്ത ടണലിന് സാധ്യമായ നിരവധി വിശദീകരണങ്ങളുണ്ട്, ISP ആന്തരിക പ്രോട്ടോക്കോൾ ഫിൽട്ടർ ചെയ്യുന്നത് ആദ്യത്തേതല്ല. ഏറ്റവും സാധാരണമായത് കവറേജാണ്: രണ്ട് ആപ്പുകളും ഒരേ ടണലിൽ പ്രവേശിക്കുന്നില്ല, കാരണം UDP ലക്ഷ്യത്തിലേക്കുള്ള റൂട്ട് ഇല്ല അല്ലെങ്കിൽ ക്ലയന്റിന്റെ സ്പ്ലിറ്റ്-ടണൽ നിയമങ്ങൾ അതിനെ ഒഴിവാക്കുന്നു.

രണ്ടാമത്തേത് എൻഡ്‌പോയിന്റാണ്. പ്രോട്ടോക്കോൾ പട്ടിക അനുവദിക്കുന്ന VPN സർവർ, ലക്ഷ്യത്തിലെ ഫയർവാൾ, അല്ലെങ്കിൽ പ്രതീക്ഷിക്കുന്ന പോർട്ടിൽ ഒരിക്കലും കേൾക്കാത്ത സേവനം — എല്ലാം നെറ്റ്‌വർക്ക് ബ്ലോക്കിന് സമാനമായി തോന്നുന്ന ടൈംഔട്ട് സൃഷ്ടിക്കും.

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

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

ആദ്യ കമാൻഡ് വലിയ പാക്കറ്റ് ഫ്രാഗ്മെന്റേഷൻ ഓഫ് ചെയ്ത അവസ്ഥയിൽ പാത കടക്കുന്നുണ്ടോ എന്ന് പരിശോധിക്കുന്നു, ഇത് MTU പ്രശ്നം വേഗത്തിൽ വെളിപ്പെടുത്തുന്നു. രണ്ടാമത്തേത് ചെറിയ, പരിമിതമായ UDP സ്ട്രീം അയച്ച് നഷ്ടവും ജിറ്ററും റിപ്പോർട്ട് ചെയ്യുന്നു. തുടങ്ങി പിന്നീട് നിലയ്ക്കുന്ന സ്ട്രീം ബ്ലോക്കിലേക്കല്ല, വലുപ്പത്തിലേക്കാണ് സൂചന നൽകുന്നത്.

പ്രോട്ടോക്കോളല്ല, പാളി റിപ്പോർട്ട് ചെയ്യുക

കണ്ടെത്തൽ മൂന്ന് രൂപങ്ങളിൽ ഒന്നിൽ എഴുതുക: പുറം ഡെലിവറി പരാജയപ്പെട്ടു, ആന്തരിക ഫോർവേഡിംഗ് പരാജയപ്പെട്ടു, അല്ലെങ്കിൽ ആപ്പ് പരാജയപ്പെട്ടു. ഓരോന്നിനും വ്യത്യസ്ത ഉടമയുണ്ട്, അവ കലർത്തുന്നത് ടിക്കറ്റ് തെറ്റായ ടീമിന് അയയ്ക്കുന്നു.

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

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