വലിയ ഡൗൺലോഡുകളും VPN-യും: അഭ്യർത്ഥനയിൽ വഴി തിരഞ്ഞെടുക്കുക

“വലിയ ഡൗൺലോഡുകൾ VPN-യുടെ ചുറ്റിലൂടെ അയച്ച് ചെറിയ പ്രതികരണങ്ങൾ അതിൽ തന്നെ നിർത്തുക” എന്നത് റൗട്ടിംഗ് നയമായി തോന്നാം, പക്ഷേ അല്ല. റൗട്ടർ ആ നിമിഷത്തിൽ ലഭ്യമായ വിവരങ്ങൾ കൊണ്ടാണ് തീരുമാനിക്കുന്നത്: വിലാസങ്ങൾ, പോർട്ടുകൾ, പ്രോട്ടോക്കോൾ, firewall അടയാളങ്ങൾ, തിരിച്ചറിഞ്ഞ ഫ്ലോ. പ്രതികരണത്തിന്റെ അന്തിമ വലിപ്പം ആ ഗണത്തിൽ ഇല്ല, കാരണം അത് ഇനിയും എത്തിയിട്ടില്ല, റൗട്ടറിന് ബൈറ്റുകൾ അളക്കാനാകുമ്പോഴേക്കും അത് അവ കൊണ്ടുപോകുന്നു. ജോലി അനുസരിച്ച് നിയന്ത്രിക്കണമെങ്കിൽ തീരുമാനം ജോലി അറിയുന്ന ബിന്ദുവിലേക്ക് മാറണം, താഴെയുള്ള പരിശോധനാ പട്ടിക നിങ്ങളുടെ രൂപകൽപ്പനയിൽ അത്തരം ബിന്ദു ഉണ്ടോ എന്ന് കാണിക്കുന്നു.

റൗട്ടറിന് പ്രതികരണം അളക്കാനാകാത്തത് എന്തുകൊണ്ട്

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

പ്രോട്ടോക്കോളിന്റെ സ്വന്തം മെറ്റാഡാറ്റ പോലും കാണുന്നതിലും ദുർബലമാണ്. HTTP ശരീരത്തിന് മുമ്പ് നീളം പ്രഖ്യാപിക്കാത്ത പ്രതികരണങ്ങൾ അനുവദിക്കുന്നു, ഒരു ഉപയോക്തൃ പ്രവർത്തനം ഒരു ഹെഡർ മൂല്യത്തോടും സമാനമല്ലാത്ത ആകെ ചെലവുള്ള നിരവധി അഭ്യർത്ഥനകൾ സൃഷ്ടിച്ചേക്കാം. ഒരു ഹെഡറിനെ ജോലിയുടെ വലിപ്പമായി കാണുന്നത് റൗട്ടിംഗ് പിശകാകുന്നതിന് മുമ്പ് മോഡലിംഗ് പിശകാണ്.

പരിശോധന 1: വഴി തിരഞ്ഞെടുക്കാനാകുന്ന തീരുമാന ബിന്ദു ഉണ്ടോ?

തിരഞ്ഞെടുപ്പ് നടത്തുന്ന ഘടകത്തിന്റെ പേര് പറയുക, തുടർന്ന് തിരഞ്ഞെടുപ്പിന്റെ നിമിഷത്തിൽ അത് എന്തറിയുന്നു എന്ന് പറയുക. രേഖപ്പെടുത്തിയ ഹോസ്റ്റ് കൂട്ടത്തിൽ നിന്ന് എടുക്കുന്ന അപ്ഡേറ്റർ കൈമാറ്റം തുടങ്ങുന്നതിന് മുമ്പ് അതിന്റെ ലക്ഷ്യം അറിയുന്നു. മെറ്റാഡാറ്റ നോക്കി പിന്നീട് അഭ്യർത്ഥന തുറക്കുന്ന ഡൗൺലോഡ് സേവനം കണക്ഷൻ ഉണ്ടാകുന്നതിന് മുമ്പ് ജോലി അറിയുന്നു. സഹകരിക്കുന്ന proxy, താൻ റൗട്ടറാണെന്ന് നടിക്കാതെ, അഭ്യർത്ഥനാ തലത്തിലുള്ള നയം പ്രയോഗിക്കാനോ പ്രതികരണം കാഷെ ചെയ്യാനോ കഴിയും.

ഉത്തരം “ഗേറ്റ്‌വേ” ആണെങ്കിൽ, പരിശോധനാ പട്ടിക ഇതിനകം പരാജയപ്പെട്ടു. ഗേറ്റ്‌വേയ്ക്ക് അറിയപ്പെടുന്ന ഫ്ലോകളെ ലക്ഷ്യസ്ഥാനം, അടയാളം അല്ലെങ്കിൽ ക്ലയന്റ് വിഭാഗം അനുസരിച്ച് തരംതിരിച്ച് ആദ്യ പാക്കറ്റിൽ നിന്ന് നിർവചിച്ച വഴിയിലൂടെ അയക്കാം, ഇത് അനുവദിച്ച അപ്ഡേറ്ററിന് പലപ്പോഴും മതിയാകും, അജ്ഞാത പ്രതികരണ വലിപ്പത്തിന് ഒരിക്കലും മതിയാകില്ല.

പരിശോധന 2: മെറ്റാഡാറ്റ യഥാർത്ഥത്തിൽ എന്താണ് പറയുന്നത്?

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

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

പരിശോധന 3: ഫ്ലോ ഇതിനകം ഉണ്ടോ?

ഫ്ലോയ്ക്ക് റൗട്ടിംഗ് കണക്ഷന്റെ അടയാളം മാറ്റാതെ മാറാം, ആ വ്യത്യാസം കൃത്യമായി നിലനിർത്തേണ്ടതാണ്. TCP കണക്ഷൻ അതിന്റെ അറ്റങ്ങളുടെ വിലാസങ്ങളും പോർട്ടുകളും കൊണ്ട് തിരിച്ചറിയപ്പെടുന്നു, റൗട്ടിംഗ് പട്ടിക അവയ്ക്ക് താഴെ മാറിയാൽ പാക്കറ്റുകൾക്ക് മറ്റൊരു വഴി എടുക്കാം. അദൃശ്യമായി മാറാൻ കഴിയാത്തത് നെറ്റ്‌വർക്ക് വിലാസ പരിഭാഷയുടെ അവസ്ഥയാണ്: ട്രാഫിക് മറ്റൊരു എക്സിറ്റിലേക്ക് മാറ്റുന്നത് സാധാരണയായി പൊതു ഉറവിട ട്യൂപ്പിൾ മാറ്റുന്നു, യോജിക്കുന്ന അവസ്ഥയില്ലാത്ത മറ്റൊരു പങ്കാളിയെ ദൂരെയുള്ള വശം കാണും.

conntrack -L -p tcp --dport 443 | head -5
ip route get 203.0.113.10
ss -tn state established dst 203.0.113.10

അതിനാൽ പ്രായോഗിക നിയമം, കണക്ഷന്റെ നടുവിൽ ഒരു എക്സിറ്റിൽ നിന്ന് മറ്റൊന്നിലേക്ക് മാറ്റുന്നത് പുതിയ ബന്ധമാണ്, കുടിയേറ്റമല്ല. രൂപകൽപ്പന അതേ കണക്ഷൻ തുടരണമെന്ന് ആവശ്യപ്പെടുന്നുവെങ്കിൽ, തീരുമാനം ആദ്യ SYN-ന് മുമ്പ് എടുക്കേണ്ടതായിരുന്നു, പിന്നീട് ചേർത്ത ഒരു പാക്കറ്റ് നിയമത്തിനും അത് വൃത്തിയായി പുനർനിർമ്മിക്കാനാവില്ല.

പരിശോധന 4: യഥാർത്ഥ ആവശ്യം കാലതാമസമാണോ, എക്സിറ്റല്ലേ?

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

tc qdisc replace dev eth0 root cake bandwidth 100mbit

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

ആവശ്യം യഥാർത്ഥത്തിൽ മറ്റൊരു ഇന്റർനെറ്റ് എക്സിറ്റ് ആണെങ്കിൽ, അത് ആ വാക്കുകളിൽ തന്നെ പറയുക, പിന്തുണയുള്ള അതിർത്തിയിൽ നടപ്പാക്കുക: അനുവദിച്ച വർക്ക്ഫ്ലോയിൽ നിന്നുള്ള പുതിയ കണക്ഷൻ, അല്ലെങ്കിൽ തിരഞ്ഞെടുത്ത എക്സിറ്റിലൂടെ സ്വന്തം അഭ്യർത്ഥന തുറക്കുന്ന ആപ്ലിക്കേഷൻ. തുടർന്ന് ഏത് ജോലികൾ ഏത് എക്സിറ്റ് ഉപയോഗിക്കുന്നു എന്ന് രേഖപ്പെടുത്തുക, അടുത്തയാൾ അത് റൗട്ടിംഗ് പട്ടികയിൽ നിന്ന് ഊഹിക്കേണ്ടിവരാതിരിക്കാൻ.

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