એક tc શેપર પોતે જ દરેક VPN ક્લાયન્ટને મર્યાદિત કરતું નથી

સૂચના પૂર્ણ લાગે છે: દરેક VPN ક્લાયન્ટને 20 Mbit/s સુધી મર્યાદિત કરો. તે પૂર્ણ નથી, અને ટનલ ઇન્ટરફેસ પર એક જ કતાર-શિસ્ત તે આપશે નહીં. દરેક ક્લાયન્ટનો અર્થ દરેક ટનલ સરનામું, દરેક ઉપકરણ અથવા દરેક ખાતું હોઈ શકે, અને દરેક પસંદગી પેકેટને અલગ રીતે વર્ગીકૃત કરે છે. કોઈપણ નિયમ લખતા પહેલાં નક્કી કરો કે જરૂરિયાત ખરેખર કઈ વસ્તુનું નામ આપે છે.

નીચેનું બધું તે વાક્ય અને કામ કરતી કોઈ વસ્તુ વચ્ચેના અંતર વિશે છે.

«દરેક ક્લાયન્ટ» નો પહેલા શું અર્થ થવો જોઈએ

ટનલ સરનામું વર્ગીકૃત કરવું સરળ છે અને ફરી વાપરવું પણ સરળ છે. ઉપકરણ વધુ અઘરું છે, કારણ કે એક ખાતું ઘણાં રાખી શકે છે, અને ઉપકરણ ઘણાં સરનામાં રાખી શકે છે, ખાસ કરીને IPv6 સાથે. ન્યાયની નીતિ માટે ખાતું સૌથી અર્થપૂર્ણ એકમ છે, અને પેકેટ હેડરમાં સૌથી અઘરું દેખાય છે. દરેક વ્યાખ્યા પોતાની ગણતરીની કી સૂચવે છે, તેથી તેમની વચ્ચે ભટકતી નીતિ વર્ણન જે દાવો કરે છે તે કરશે નહીં.

દિશા બીજો ખૂટતો શબ્દ છે. અપલોડ, ડાઉનલોડ અને સંયુક્ત એ ત્રણ અલગ જરૂરિયાતો છે, અને એક ઇન્ટરફેસ પર એક જ આઉટગોઇંગ નિયમ ભાગ્યે જ બંને માર્ગોને આવરી લે છે.

એવું બિંદુ પસંદ કરો જ્યાં ક્લાયન્ટ હજી દેખાય છે

દરેક દિશા ઇન્ટરફેસ સામે વ્યાખ્યાયિત થાય છે. સર્વરની ટનલમાંથી દૂરના ક્લાયન્ટ તરફ જે નીકળે છે તે તે ક્લાયન્ટ માટે ડાઉનલોડ ગણાય છે; ક્લાયન્ટ જે મોકલે છે તે ટનલમાં પ્રવેશે છે અને પછી તેના ગંતવ્ય તરફ નીકળે છે. દરેક દિશા માટે સુનિશ્ચિત બિંદુ પસંદ કરો અને પૂછો કે ત્યાં કઈ ફીલ્ડ છે. સ્રોત NAT પહેલાં અપલોડ હજી ક્લાયન્ટનું આંતરિક સરનામું વહન કરે છે; અનુવાદ પછી સાદું સ્રોત મેળ તેને હવે ઓળખી શકે નહીં.

એન્ક્રિપ્ટેડ માર્ગ પર હેડર VPN પરિવહનના છે, તેથી આંતરિક સરનામાં મેળવતા ફિલ્ટર પાસે મેળવવા માટે કંઈ નથી. ડિઝાઇન પહેલાં વર્ગીકૃત કરી શકે છે અને પછીના શેડ્યુલરને માર્ક સોંપી શકે છે, પણ તે સોંપણી જાણી જોઈને હોવી જોઈએ: પેકેટ માર્ક, કનેક્શન માર્ક અને શેડ્યુલર વર્ગો અલગ સ્થિતિ છે, આગળ પસાર થતું એક મૂલ્ય નહીં.

બકેટ જાતે દેખાતી નથી

ઇન્ટરફેસ સાથે જોડાયેલી ટોકન બકેટ તેનો ઉપયોગ કરતા કોઈપણ ટ્રાફિકને ઘડે છે; તે દરેક સ્રોત સરનામા માટે નવી બકેટ બનાવતી નથી. વર્ગ-આધારિત ડિઝાઇન તેના બદલે પસંદ કરેલા ટ્રાફિકને વર્ગોમાં ગોઠવે છે, ફિલ્ટર સભ્યપદ નક્કી કરે છે, અને HTB માર્ગદર્શિકા વર્ગનો દર તેની ટોચમર્યાદાથી અલગ કરે છે જ્યારે પિતૃ પાસે વધારાની બેન્ડવિડ્થ હોય. જો હેતુ કઠોર મર્યાદા હોય, તો ટોચમર્યાદા સેટ કરો અને ઉધાર વર્તન જાણી જોઈને નક્કી કરો; દરેક દરના આંકડાને સંપૂર્ણ મહત્તમ ન ગણો.

જ્યારે જરૂરિયાત દરેક ક્લાયન્ટ માટે હોય, ત્યારે એક સાથે ચાલતી બે ટ્રાન્સફરે એક જ કોટા વહેંચવો જોઈએ. દરેક પ્રવાહને પૂરો દર આપવો એ બીજી નીતિ છે, અને તે ફક્ત એક ડાઉનલોડ જોતી કોઈપણ કસોટીમાં ટકી રહે છે.

બે ઉપકરણ, એક ખાતું, એક કોટા?

બે ઉપકરણ સરનામાંને અલગ રીતે મર્યાદિત કરવાથી ક્યારેય ખાતા-વ્યાપી એક કોટા નથી બનતો, જ્યારે બંને ઉપકરણો એક જ વ્યક્તિ તરીકે લોગિન કરે ત્યારે પણ. આ જ વાત આખા LAN પર લાગુ પડે છે જે એક પીઅર પાછળ અનુવાદિત થાય છે, અથવા વર્ગીકારક ક્યારેય ધારેલા ન હોય તેવા વધારાના IPv6 સરનામાંઓ પર. સરનામા-ઓળખ સંબંધ અદ્યતન રાખો, અને યાદ રાખો કે સ્થિર સરનામું નકશાને સરળ બનાવે છે પણ તેના માલિકને પ્રમાણિત કરતું નથી.

બર્સ્ટ અને કતાર વર્તન પણ વ્યાખ્યાયિત કરો. ટોકન બકેટ સરેરાશથી ઉપર ટૂંકા બર્સ્ટની મંજૂરી આપે છે, અને બફરિંગ વિલંબ ઉમેરે છે; વધારાને પોલીસ કરવો અને તેને પછી માટે કતારમાં મૂકવો એ અલગ નિર્ણયો છે જેનાં અલગ લક્ષણો છે.

ચકાસણી માટે એક ક્લાયન્ટથી બે ટ્રાન્સફર ચલાવો, બીજો ક્લાયન્ટ ઉમેરો, અને દરેક દિશામાં વર્ગ કાઉન્ટર વાંચો.