ఒక tc రూపకర్త తనంతట తానే ప్రతి VPN క్లయింట్ను పరిమితం చేయదు
ప్రతి క్లయింట్కు పరిమితికి లెక్కింపు గుర్తింపు, రెండు దిశలు మరియు ఒక వర్గీకరణ బిందువు అవసరం. టన్నెల్పై ఒక రూపకర్త అంటే ప్రతి వినియోగదారుకు ఒక కోటా కాదు.
సూచన పూర్తిగా వినిపిస్తుంది: ప్రతి VPN క్లయింట్ను 20 Mbit/s కు పరిమితం చెయ్యి. కానీ అది పూర్తి కాదు, మరియు టన్నెల్ ఇంటర్ఫేస్పై ఒకే క్యూ క్రమశిక్షణ దాన్ని ఇవ్వదు. «ప్రతి క్లయింట్» అంటే ప్రతి టన్నెల్ చిరునామా, ప్రతి పరికరం లేదా ప్రతి ఖాతా అని అర్థం కావచ్చు, మరియు ప్రతి ఎంపిక ప్యాకెట్లను వేరే విధంగా వర్గీకరిస్తుంది. ఏ నియమాన్నైనా రాసే ముందు అవసరం నిజంగా ఏది పేర్కొంటుందో నిర్ణయించు.
క్రింద ఉన్నవన్నీ ఆ వాక్యానికి మరియు పనిచేసే దానికి మధ్య ఉన్న దూరం గురించి.
«ప్రతి క్లయింట్» మొదట ఏమి అర్థం చేయాలి
టన్నెల్ చిరునామాను వర్గీకరించడం సులభం, మళ్లీ ఉపయోగించడం కూడా సులభం. పరికరం కష్టతరం, ఎందుకంటే ఒక ఖాతా అనేకాన్ని మోయవచ్చు, ఒక పరికరానికి అనేక చిరునామాలు ఉండవచ్చు, ముఖ్యంగా IPv6 తో. న్యాయ విధానానికి ఖాతాయే అత్యంత అర్థవంతమైన యూనిట్, ప్యాకెట్ హెడర్లో గుర్తించడం అత్యంత కష్టమైనది కూడా అదే. ప్రతి నిర్వచనం తన సొంత లెక్కింపు కీని సూచిస్తుంది, కాబట్టి వాటి మధ్య ఊగిసలాడే విధానం వివరణ చెప్పేది చేయదు.
దిశ రెండవ మిస్ అయిన పదం. అప్లోడ్, డౌన్లోడ్ మరియు సంయుక్తం మూడు వేర్వేరు అవసరాలు, ఒక ఇంటర్ఫేస్పై ఒకే నిర్గమన నియమం రెండు మార్గాలను అరుదుగా కవర్ చేస్తుంది.
క్లయింట్ ఇంకా కనిపించే బిందువును ఎంచుకో
ప్రతి దిశ ఒక ఇంటర్ఫేస్కు సంబంధించి నిర్వచించబడుతుంది. సర్వర్ టన్నెల్ నుండి దూరపు క్లయింట్ వైపు వెళ్లేది ఆ క్లయింట్కు డౌన్లోడ్గా లెక్కించబడుతుంది; క్లయింట్ పంపేది టన్నెల్లోకి ప్రవేశించి తర్వాత తన గమ్యం వైపు బయటకు వెళుతుంది. ప్రతి దిశకు ఒక షెడ్యూలింగ్ బిందువును ఎంచుకుని అక్కడ ఏ ఫీల్డ్లు ఉన్నాయో అడుగు. మూల NAT కు ముందు అప్లోడ్ ఇంకా క్లయింట్ లోపలి చిరునామాను మోస్తుంది; అనువాదం తర్వాత సాధారణ మూల సరిపోలిక దాన్ని ఇక గుర్తించకపోవచ్చు.
ఎన్క్రిప్ట్ చేసిన మార్గంలో హెడర్లు VPN రవాణాకు చెందుతాయి, కాబట్టి లోపలి చిరునామాలను సరిపోల్చే ఫిల్టర్కు సరిపోల్చడానికి ఏమీ ఉండదు. ఒక రూపకల్పన ముందుగా వర్గీకరించి తర్వాతి షెడ్యూలర్కు ఒక గుర్తును అప్పగించవచ్చు, కానీ ఆ అప్పగింపు ఉద్దేశపూర్వకంగా ఉండాలి: ప్యాకెట్ గుర్తులు, కనెక్షన్ గుర్తులు మరియు షెడ్యూలర్ తరగతులు వేరే స్థితి, ముందుకు పంపబడే ఒకే విలువ కాదు.
బకెట్లు తమంతట తామే రావు
ఇంటర్ఫేస్కు జోడించిన టోకెన్ బకెట్ దాన్ని ఉపయోగించే ఏ ట్రాఫిక్నైనా రూపొందిస్తుంది; అది ప్రతి మూల చిరునామాకు కొత్త బకెట్ను తయారు చేయదు. తరగతి ఆధారిత రూపకల్పన బదులుగా ఎంచుకున్న ట్రాఫిక్ను తరగతుల్లో అమర్చుతుంది, ఫిల్టర్లు సభ్యత్వాన్ని నిర్ణయిస్తాయి, మరియు HTB చేతిపుస్తకం తల్లిదండ్రులకు అదనపు బ్యాండ్విడ్త్ ఉన్నప్పుడు తరగతి రేటును దాని పరిమితి నుండి వేరు చేస్తుంది. ఉద్దేశం కఠిన పరిమితి అయితే, పరిమితిని పెట్టి అప్పు తీసుకునే ప్రవర్తనను ఉద్దేశపూర్వకంగా నిర్ణయించు; ప్రతి రేటు సంఖ్యను సంపూర్ణ గరిష్ఠంగా పరిగణించవద్దు.
అవసరం ప్రతి క్లయింట్కు అయినప్పుడు, ఒకేసారి నడుస్తున్న రెండు బదిలీలు ఒకే కోటాను పంచుకోవాలి. ప్రతి ప్రవాహానికి పూర్తి రేటు ఇవ్వడం మరో విధానం, మరియు ఒకే డౌన్లోడ్ను చూసే ఏ పరీక్షలోనైనా అది తప్పించుకుంటుంది.
రెండు పరికరాలు, ఒక ఖాతా, ఒక కోటా?
రెండు పరికర చిరునామాలను విడివిడిగా పరిమితం చేయడం, రెండు పరికరాలు ఒకే వ్యక్తిగా లాగిన్ అయినా, ఎప్పుడూ ఖాతా స్థాయి ఒకే కోటాగా కలవదు. ఒక పీర్ వెనుక అనువదించబడే మొత్తం LAN కి, వర్గీకర్త ఎప్పుడూ ఊహించని అదనపు IPv6 చిరునామాలకు కూడా ఇదే వర్తిస్తుంది. చిరునామా-గుర్తింపు అనుబంధాన్ని తాజాగా ఉంచు, స్థిరమైన చిరునామం మ్యాప్ను సులభతరం చేస్తుంది కానీ దాని యజమానిని ధృవీకరించదు అని గుర్తుంచుకో.
పేలుడు మరియు క్యూ ప్రవర్తనను కూడా నిర్వచించు. టోకెన్ బకెట్లు సగటు కంటే ఎక్కువ చిన్న పేలుళ్లను అనుమతిస్తాయి, బఫరింగ్ ఆలస్యాన్ని జోడిస్తుంది; అదనపును పోలీస్ చేయడం మరియు తర్వాత కోసం క్యూలో పెట్టడం వేర్వేరు లక్షణాలున్న వేర్వేరు నిర్ణయాలు.
ధృవీకరణ కోసం ఒక క్లయింట్ నుండి రెండు బదిలీలు నడపు, రెండవ క్లయింట్ను జోడించు, ప్రతి దిశలో తరగతి కౌంటర్లను చదువు.