OpenVPN ఖాతాకు నెలవారీ డేటా కోటా ఎక్కడ ఉండాలి
ప్రతి తిరిగి కనెక్షన్లో రీసెట్ అయ్యే కోటా పరిమితి కాదు. ఖాతా వారీగా వినియోగాన్ని ట్రాక్ చేయండి, ప్రతి బైట్ తేడాను ఒకసారి వసూలు చేయండి మరియు కోటా అయిపోయినప్పుడు ప్రవేశాన్ని నిలిపివేయండి.
టన్నెల్ తిరిగి కనెక్ట్ అయ్యే ప్రతిసారీ రీసెట్ అయ్యే కోటా పరిమితి కాదు, మరియు శాశ్వత స్థితిని ఉంచడానికి స్థలం లేకుండా VPN సర్వర్కు బైట్ కౌంటర్ను బిగించినప్పుడు సరిగ్గా అదే లభిస్తుంది. కౌంటర్ ఒక సెషన్కు చెందుతుంది; కోటా ఒక వ్యక్తి లేదా పరికర ఒప్పందానికి చెందుతుంది. ఈ ఫీచర్ యొక్క మొత్తం కష్టం ఆ అసమతుల్యత నుండే వస్తుంది, కాబట్టి క్రింది తనిఖీలు స్థితి ఎక్కడ నివసిస్తుంది మరియు ఏ పొరకు నిర్ణయం తీసుకోవడానికి అనుమతి ఉంది అనే దానిపై ఉన్నాయి.
కోటాను టన్నెల్కు కాదు, ఖాతాకు కట్టండి
కోటా యొక్క విషయాన్ని పేరు పెట్టడంతో ప్రారంభించండి. ఒక వ్యక్తి మూడు పరికర ధృవపత్రాలను కలిగి ఉండవచ్చు, అవి విడివిడిగా ధృవీకరించుకుంటాయనే కారణంతో మాత్రమే వాటిలో ఏదీ స్వతంత్ర నెలవారీ బడ్జెట్ పొందకూడదు. తిరిగి కనెక్షన్లు, కొత్త టన్నెల్ చిరునామాలు మరియు రెండవ గేట్వేకు మారడాన్ని తట్టుకునే స్థిరమైన ఖాతా గుర్తింపు మాత్రమే కోటా ఉపయోగించగల ఏకైక లంగరు. ధృవపత్రం యొక్క సాధారణ పేరు ఆ కీగా పనిచేయడం, మీ జారీ విధానం ప్రతి పేరుకు ఒక ఖాతాను హామీ ఇచ్చినప్పుడు మాత్రమే.
కేటాయించిన టన్నెల్ చిరునామా ఎప్పుడూ సమాధానం కాదు. చిరునామాలు పునర్వినియోగించబడతాయి, పూల్లు పంచుకోబడతాయి, అదే ఖాతా ఒకే నిమిషంలో రెండు గేట్వేలపై రెండుసార్లు కనిపించవచ్చు. లెడ్జర్ చిరునామాపై ఆధారపడితే, ట్యాంక్ను తిరిగి నింపడానికి డిస్కనెక్ట్ చేసి తిరిగి కనెక్ట్ అవ్వడం సరిపోతుంది.
గణన ఆడిట్ చేయదగినదిగా ఉండటానికి ప్రతి సెషన్కు సరిపడా నమోదు చేయండి: ఖాతా, బిల్లింగ్ కాలం, గేట్వే ఇన్స్టాన్స్, సెషన్ గుర్తింపు, చివరగా గమనించిన కౌంటర్లు మరియు నిర్ధారించిన మొత్తం. సెషన్ గుర్తింపులో డీమన్ ప్రారంభ తరం చేర్చండి, ఎందుకంటే తిరిగి ప్రారంభించిన సర్వర్ క్లయింట్ ఐడీలను తిరిగి ఉపయోగిస్తుంది మరియు సాధారణ సరిపోలిక మునుపటి ఆధార రేఖను వారసత్వంగా పొందుతుంది.
యూనిట్, దిశ మరియు రీసెట్ హద్దును నిర్ణయించండి
ఏదైనా సేకరణ ప్రారంభం కావడానికి ముందు నాలుగు నిర్వచనాలు లిఖితపూర్వకంగా నిర్ణయించబడాలి. కోటా క్లయింట్ పంపే బైట్లను, స్వీకరించే బైట్లను, లేదా రెండింటి మొత్తాన్ని లెక్కిస్తుందా? ఒక గిగాబైట్ 10^9 బైట్లా లేదా 2^30ా? ఏ స్థానిక గంటలో మరియు ఏ కాల మండలంలో కాలం తిరుగుతుంది? మరియు కౌంటర్ సరిగ్గా ఏమి కొలుస్తుంది, టన్నెల్ ఓవర్హెడ్ మరియు పునఃప్రసారాలు చేర్చబడి ఉన్నాయి కానీ అప్లికేషన్ ఫైల్ పరిమాణం మరియు ప్రదాత బిల్లు చేర్చబడలేదు?
ఈ ఎంపికలలో ఏదీ తప్పు కాదు, కానీ అమలు మరియు కస్టమర్ చూసే సంఖ్య సరిపోలాలి. ఒకే వ్యవస్థలోని రెండు సగాలు GiB గురించి, లేదా స్థానిక సమయానికి బదులు UTC అర్ధరాత్రి జరిగే మార్పు గురించి అంగీకరించకపోతే, మొత్తం కోటాపై నమ్మకాన్ని క్షీణింపజేసే అదే రకమైన టికెట్ ఏర్పడుతుంది.
బైట్ మొత్తాలను ఒక వసూలు చేసిన తేడాగా మార్చండి
నిర్వహణ ఇంటర్ఫేస్ క్లయింట్ ఐడీ మరియు ప్రతి దిశలో సంచిత బైట్ మొత్తాలను మోసుకొచ్చే క్రమానుగత BYTECOUNT_CLI లైన్లను నివేదిస్తుంది, bytecount ఆదేశం అవి ఎంత తరచుగా వస్తాయో నిర్ణయిస్తుంది. సర్వర్ దృష్టికోణంలో, స్వీకరించిన సంఖ్య క్లయింట్ పంపిన బైట్లను లెక్కిస్తుంది మరియు పంపిన సంఖ్య అతనికి అందించిన బైట్లను లెక్కిస్తుంది. లెడ్జర్ జీర్ణించుకోగల విరామాన్ని సెట్ చేయండి; చాలా చిన్న విరామం వాస్తవానికి లభించని ఖచ్చితత్వాన్ని కొంటుంది.
ఒక పరిమితి మొత్తం రూపకల్పనను రూపొందిస్తుంది: నిర్వహణ సాకెట్ ఒకే నియంత్రణ కనెక్షన్ను అంగీకరిస్తుంది. పర్యవేక్షణ ఎగుమతిదారు, ఒక GUI మరియు మీ నియంత్రకం ఒక్కొక్కటి తమ స్వంతాన్ని తెరవలేవు. ఏ ప్రక్రియ ఛానెల్ను కలిగి ఉందో నిర్ణయించి మిగిలినవి దాని నుండి స్థితిని చదవనివ్వండి, ఎందుకంటే ఈ ఇంటర్ఫేస్ పరిపాలనా చర్యలను ఇస్తుంది మరియు ఏమైనా హోస్ట్ వెలుపల దాన్ని బహిర్గతం చేయకూడదు.
rx_delta = sample.rx_now - session.prev_rx
tx_delta = sample.tx_now - session.prev_tx
charge = rx_delta + tx_delta
# same transaction:
ledger.total += charge
session.prev_rx, session.prev_tx = sample.rx_now, sample.tx_now
కొత్త ఆధార రేఖలు మరియు వినియోగ పెరుగుదలను కలిసి నిర్ధారించండి, తద్వారా నమూనాను తిరిగి నడపడం రెండుసార్లు వసూలు చేయడానికి బదులు ఏమీ వసూలు చేయదు. వెనుకకు కదిలే కౌంటర్ సంకేతం, అప్పు కాదు: సెషన్ భర్తీ చేయబడింది లేదా డీమన్ తిరిగి ప్రారంభించబడింది అని అర్థం, సరైన ప్రతిస్పందన ప్రతికూల మొత్తాన్ని జమ చేయడం కాదు, సెషన్ గుర్తింపును సరిపోల్చడం.
డిస్కనెక్ట్ మార్గానికి కూడా అదే శ్రద్ధ అవసరం. చివరి సంఘటన సెషన్ ముగింపు మొత్తాలను మోసుకొస్తే, చివరగా నిర్ధారించిన నమూనా నుండి తేడాను మాత్రమే వసూలు చేయండి. క్రమానుగత నమూనా ఇప్పటికే వసూలు చేయబడిన తర్వాత పూర్తి మొత్తాన్ని జోడించడం ఇంట్లో తయారు చేసిన కోటా వ్యవస్థలలో అత్యంత సాధారణ ద్వంద్వ గణన. కాల హద్దును దాటే సెషన్లకు కూడా నియమం అవసరం, ఎందుకంటే ఒక చివరి మొత్తం బైట్లు ఎప్పుడు అర్ధరాత్రిని దాటాయనే సమాచారాన్ని మోసుకోదు.
అయిపోవడం ప్రవేశాన్ని నిరాకరించాలి, టన్నెల్ను చంపడం మాత్రమే కాదు
ఒక ఖాతా తన పరిమితిని చేరుకున్నప్పుడు రెండు విషయాలు జరగాలి: ఉన్న సెషన్లు ముగుస్తాయి మరియు కొత్తవి నిరాకరించబడతాయి. నిర్వహణ ప్రోటోకాల్ క్లయింట్ ఐడీ ద్వారా client-kill అందిస్తుంది, ఖాతా యొక్క ప్రతి సజీవ సెషన్ను లెక్కిస్తే అది మొదటి సగాన్ని నిర్వహిస్తుంది, అనుకోకుండా గమనించిన ఒకే చిరునామాను చంపడానికి బదులు.
రెండవ సగం కోటా రూపకల్పనలు విఫలమయ్యే చోటు. చంపడం మాత్రమే క్లయింట్ యొక్క తిరిగి కనెక్షన్ లూప్తో పోటీ, అది కొన్ని సెకన్ల తర్వాత సంతోషంగా తిరిగి వస్తుంది. ప్రవేశం పంచుకున్న లెడ్జర్ను సంప్రదించాలి, బహు-గేట్వే అమరికలో ఆ తనిఖీ ప్రతి యంత్రానికి ఒక ఫైల్ కాకూడదు. లాగిన్ను అంగీకరించగల ప్రతి ఇన్స్టాన్స్ అదే అయిపోయిన స్థితిని చూడాలి.
టోకెన్ ఆధారిత తిరిగి కనెక్షన్లు తమ స్వంత పరీక్షకు అర్హత కలిగి ఉన్నాయి. OpenVPN 2.6 auth-gen-tokenతో సెషన్ టోకెన్ను అంతర్గతంగా ధృవీకరించగలదు, మీ నియంత్రకం పరిమితిని అమలు చేయడానికి ఉపయోగించిన బాహ్య ధృవీకరణ కాల్ను దాటవేస్తుంది. కాబట్టి ఇంకా చెల్లుబాటు అయ్యే టోకెన్ గుర్తింపును నిరూపిస్తుంది, మిగిలిన కోటాను కాదు, మరియు ప్రతి కొత్త క్లయింట్ ఇన్స్టాన్స్ ఇప్పటికీ లెడ్జర్ను సంప్రదించాలి. బదులుగా management-client-auth ప్రారంభిస్తే, నియంత్రకమే ధృవీకర్త అవుతుంది మరియు సెషన్ స్థితిని తానే విశ్లేషించి గడువు ముగిసిన లేదా చెల్లని టోకెన్లను తానే తిరస్కరించే బాధ్యతను వారసత్వంగా పొందుతుంది.
నమూనా సృష్టించే అతిక్రమణను అంగీకరించండి
క్రమానుగత పర్యవేక్షణ మరియు డిస్కనెక్ట్ మీకు తెలిసిన సహనశీలతతో నమూనా చేసిన కోటాను ఇస్తాయి. ఒక క్లయింట్ సుమారు ఒక నివేదిక విరామం మరియు నియంత్రకం పనిచేయడానికి పట్టే సమయం మేరకు మించవచ్చు, ఒక ఖాతాపై ఏకకాల సెషన్లు ఆ విండోను పలు రెట్లు చేస్తాయి. మీరు అందించలేని చివరి బైట్పై ఖచ్చితమైన కటాఫ్ను ప్రచారం చేయడానికి బదులు దాన్ని ఇంటర్ఫేస్లో చెప్పండి.
నిజమైన కఠినమైన పై పరిమితి మరో ఇంజనీరింగ్ సమస్య: ఫార్వార్డింగ్ మార్గం లోపల అమలు, సెషన్ల అంతటా అదే ఖాతాకు కట్టుబడి ఉంటుంది. కౌంటర్లను వేగంగా చదవడం అది కాదు, మరియు ఎక్కువ టన్నెల్లను తెరిచే క్లయింట్ను అది తట్టుకోదు.
అమలు చేయడానికి ముందు సాధారణ అమలులను విచ్ఛిన్నం చేసే అంగీకార సందర్భాలను నడపండి: పునరావృత తిరిగి కనెక్షన్లు, ఒకేసారి రెండు పరికరాలు, నియంత్రకం మరియు గేట్వే పునఃప్రారంభాలు, కోల్పోయిన డిస్కనెక్ట్ సంఘటన, సెషన్ మధ్యలో కాల మార్పు, మరియు కోటా అయిపోయిన వెంటనే టోకెన్ తిరిగి కనెక్షన్ ప్రయత్నం. తర్వాత లెక్కల అంతరాయాలకు వైఫల్య విధానాన్ని నిర్ణయించండి. శాశ్వత లెడ్జర్ మీరు నమోదు చేసిన వినియోగాన్ని రక్షిస్తుంది; ఎప్పుడూ రాని పరిశీలనలను అది పునరుజ్జీవింపజేయలేదు, మరియు ఆ రెండు పరిస్థితులలో ఏది తనది అని తెలుసుకోవడానికి కస్టమర్ అర్హుడు.