ഒരു tc രൂപകൻ തനിയെ ഓരോ VPN ക്ലയന്റിനെയും പരിമിതപ്പെടുത്തുന്നില്ല

നിർദ്ദേശം പൂർണ്ണമായി തോന്നുന്നു: ഓരോ VPN ക്ലയന്റിനെയും 20 Mbit/s ആയി പരിമിതപ്പെടുത്തുക. പക്ഷേ അത് പൂർണ്ണമല്ല, ടണൽ ഇന്റർഫേസിലെ ഒരു ക്യൂ വിനയം അത് നൽകില്ല. «ഓരോ ക്ലയന്റിനും» എന്നത് ഓരോ ടണൽ വിലാസത്തിനും, ഓരോ ഉപകരണത്തിനും അല്ലെങ്കിൽ ഓരോ അക്കൗണ്ടിനും എന്നർത്ഥമാകാം, ഓരോ തിരഞ്ഞെടുപ്പും പാക്കറ്റുകളെ വ്യത്യസ്തമായി വർഗ്ഗീകരിക്കുന്നു. ഏതെങ്കിലും നിയമം എഴുതുന്നതിന് മുൻപ് ആവശ്യകത യഥാർത്ഥത്തിൽ ഏതിനെയാണ് പേരിടുന്നതെന്ന് തീരുമാനിക്കുക.

താഴെയുള്ളതെല്ലാം ആ വാക്യത്തിനും പ്രവർത്തിക്കുന്ന എന്തിനും ഇടയിലുള്ള ദൂരത്തെക്കുറിച്ചാണ്.

«ഓരോ ക്ലയന്റിനും» ആദ്യം എന്താണ് അർത്ഥമാക്കേണ്ടത്

ടണൽ വിലാസം വർഗ്ഗീകരിക്കാൻ എളുപ്പവും വീണ്ടും ഉപയോഗിക്കാൻ എളുപ്പവുമാണ്. ഉപകരണം കൂടുതൽ ബുദ്ധിമുട്ടാണ്, ഒരു അക്കൗണ്ടിന് പലതും വഹിക്കാം, ഒരു ഉപകരണത്തിന് പല വിലാസങ്ങളും ഉണ്ടാകാം, പ്രത്യേകിച്ച് IPv6 ഉപയോഗിക്കുമ്പോൾ. നീതിയുടെ നയത്തിന് അക്കൗണ്ടാണ് ഏറ്റവും അർത്ഥവത്തായ യൂണിറ്റ്, പാക്കറ്റ് ഹെഡറിൽ കാണാൻ ഏറ്റവും ബുദ്ധിമുട്ടുള്ളതും അതാണ്. ഓരോ നിർവചനവും അതിന്റേതായ എണ്ണൽ കീ ഉൾക്കൊള്ളുന്നു, അതിനാൽ അവയ്ക്കിടയിൽ ചാഞ്ചാടുന്ന നയം വിവരണം അവകാശപ്പെടുന്നത് ചെയ്യില്ല.

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

ക്ലയന്റ് ഇപ്പോഴും കാണാവുന്ന ഒരു പോയിന്റ് തിരഞ്ഞെടുക്കുക

ഓരോ ദിശയും ഒരു ഇന്റർഫേസിന് എതിരായി നിർവചിക്കപ്പെടുന്നു. സെർവറിന്റെ ടണലിൽ നിന്ന് വിദൂര ക്ലയന്റിലേക്ക് പുറത്തുപോകുന്നത് ആ ക്ലയന്റിനുള്ള ഡൗൺലോഡായി കണക്കാക്കുന്നു; ക്ലയന്റ് അയയ്ക്കുന്നത് ടണലിൽ പ്രവേശിച്ച് പിന്നീട് അതിന്റെ ലക്ഷ്യസ്ഥാനത്തേക്ക് പുറത്തുപോകുന്നു. ഓരോ ദിശയ്ക്കും ഒരു ഷെഡ്യൂളിംഗ് പോയിന്റ് തിരഞ്ഞെടുത്ത് അവിടെ ഏതൊക്കെ ഫീൽഡുകൾ ഉണ്ടെന്ന് ചോദിക്കുക. സ്രോതസ്സ് NAT-ന് മുൻപ് അപ്ലോഡ് ഇപ്പോഴും ക്ലയന്റിന്റെ ആന്തരിക വിലാസം വഹിക്കുന്നു; വിവർത്തനത്തിന് ശേഷം ലളിതമായ സ്രോതസ്സ് പൊരുത്തം അതിനെ ഇനി തിരിച്ചറിയണമെന്നില്ല.

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

ബക്കറ്റുകൾ സ്വയം വരുന്നില്ല

ഇന്റർഫേസിൽ ഘടിപ്പിച്ച ഒരു ടോക്കൺ ബക്കറ്റ് അത് ഉപയോഗിക്കുന്ന ഏത് ട്രാഫിക്കിനെയും രൂപപ്പെടുത്തുന്നു; അത് ഓരോ സ്രോതസ്സ് വിലാസത്തിനും പുതിയ ബക്കറ്റ് അടിക്കുന്നില്ല. ക്ലാസ് അധിഷ്ഠിത രൂപകൽപ്പന പകരം തിരഞ്ഞെടുത്ത ട്രാഫിക്കിനെ ക്ലാസുകളിലേക്ക് ക്രമീകരിക്കുന്നു, ഫിൽട്ടറുകൾ അംഗത്വം തീരുമാനിക്കുന്നു, പിതാവിന് ഒഴിവുള്ള ബാൻഡ്‌വിഡ്ത്ത് ഉള്ളപ്പോൾ HTB കൈപ്പുസ്തകം ഒരു ക്ലാസിന്റെ നിരക്ക് അതിന്റെ പരിധിയിൽ നിന്ന് വേർതിരിക്കുന്നു. ഉദ്ദേശ്യം കർശന പരിധിയാണെങ്കിൽ പരിധി സജ്ജമാക്കി കടമെടുക്കൽ സ്വഭാവം ബോധപൂർവ്വം തീരുമാനിക്കുക; ഓരോ നിരക്ക് സംഖ്യയെയും കേവല പരമാവധിയായി കാണരുത്.

ആവശ്യകത ഓരോ ക്ലയന്റിനുമാകുമ്പോൾ, ഒരേ സമയം നടക്കുന്ന രണ്ട് കൈമാറ്റങ്ങൾ ഒരു കോട്ട പങ്കിടണം. ഓരോ പ്രവാഹത്തിനും പൂർണ്ണ നിരക്ക് നൽകുന്നത് മറ്റൊരു നയമാണ്, ഒരു ഡൗൺലോഡ് മാത്രം നോക്കുന്ന ഏത് പരീക്ഷണത്തിലും അത് അതിജീവിക്കും.

രണ്ട് ഉപകരണം, ഒരു അക്കൗണ്ട്, ഒരു കോട്ട?

രണ്ട് ഉപകരണ വിലാസങ്ങൾ വെവ്വേറെ പരിമിതപ്പെടുത്തുന്നത് രണ്ട് ഉപകരണങ്ങളും ഒരേ വ്യക്തിയായി ലോഗിൻ ചെയ്താലും ഒരിക്കലും അക്കൗണ്ട് തലത്തിലുള്ള ഒരു കോട്ടയായി കൂടിച്ചേരില്ല. ഒരു പിയറിന് പിന്നിൽ വിവർത്തനം ചെയ്യുന്ന മുഴുവൻ LAN-നും, വർഗ്ഗീകരണകൻ ഒരിക്കലും പ്രതീക്ഷിക്കാത്ത അധിക IPv6 വിലാസങ്ങൾക്കും ഇതേ കാര്യം ബാധകമാണ്. വിലാസ-ഐഡന്റിറ്റി ബന്ധം കാലികമായി സൂക്ഷിക്കുക, സ്ഥിരമായ വിലാസം ഭൂപടം ലളിതമാക്കുന്നു പക്ഷേ ഉടമസ്ഥനെ സാക്ഷ്യപ്പെടുത്തുന്നില്ല എന്ന് ഓർക്കുക.

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

സാധൂകരിക്കാൻ ഒരു ക്ലയന്റിൽ നിന്ന് രണ്ട് കൈമാറ്റങ്ങൾ നടത്തുക, രണ്ടാമത്തെ ക്ലയന്റ് ചേർക്കുക, ഓരോ ദിശയിലും ക്ലാസ് കൗണ്ടറുകൾ വായിക്കുക.