Сарын өгөгдлийн квот OpenVPN бүртгэлд хаана хамаарах вэ
Дахин холбогдох бүрт шинэчлэгддэг квот нь хязгаар биш. Хэрэглээг бүртгэлээр хянаж, байт бүрийн зөрүүг нэг удаа тооцож, дууссаныг нэвтрэхэд саад болго.
Туннель дахин холбогдох бүрт шинэчлэгддэг квот нь хязгаар биш бөгөөд тогтвортой төлөв хадгалах газаргүйгээр VPN серверт байт тоолуур боолт хийхэд яг үүнийг авна. Тоолуур нь сессэд хамаарах; квот нь хүн эсвэл төхөөрөмжийн гэрээнд хамаарна. Энэ функцын бүх хүндрэл тэр зөрүүнээс үүдэлтэй тул доорх шалгалтууд төлөв хаана амьдардаг, ямар давхарга шийдвэр гаргах эрхтэй вэ гэдэгт чиглэнэ.
Квотыг туннельд биш, бүртгэлд бэхлээрэй
Квотын субьектийг нэрлэж эхэл. Нэг хүн гурван төхөөрөмжийн гэрчилгээтэй байж болох бөгөөд тэдгээрийн аль нь ч тусдаа баталгаажуулдаг гэсэн шалтгаанаар бие даасан сарын төсөв авах ёсгүй. Дахин холбогдолт, шинэ туннелийн хаяг, хоёр дахь гарц руу шилжихийг даван туулдаг тогтвортой бүртгэлийн танигч нь квотын ашиглаж болох цорын ганц зангуу юм. Гэрчилгээний нийтлэг нэр нь таны олголтын бодлого нэр бүрт нэг бүртгэл баталгаажуулж байж л тэр түлхүүр болно.
Олгосон туннелийн хаяг хэзээ ч хариулт биш. Хаягууд дахин боловсруулагдана, сангууд хуваалцдаг, нэг бүртгэл нэг минутад хоёр гарцад хоёр удаа гарч болно. Хэрэв дэвтэр хаяг дээр тулгуурласан бол савыг дахин дүүргэхэд салгаж дахин холбогдох хангалттай.
Тооцоог шалгах боломжтой болгохын тулд сесс бүрт хангалттай бич: бүртгэл, тооцооны хугацаа, гарцын хувилбар, сессийн таних, хамгийн сүүлд ажигласан тоолуурууд, баталгаажсан нийт дүн. Сессийн таних дотор демоны эхлэлийн үеийг оруул, учир нь дахин эхлүүлсэн сервер клиентийн ID-г дахин ашигладаг бөгөөд гэнэн тааруулга өмнөх суурь шугамыг өвлөх байсан.
Нэгж, чиглэл, шинэчлэх хязгаарыг тогтоо
Аливаа цуглуулалт эхлэхийн өмнө дөрвөн тодорхойлолтыг бичгээр тогтоох ёстой. Квот нь клиентийн илгээсэн байт, хүлээн авсан байт, эсвэл хоёрын нийлбэрийг тоолдог уу? Гигабайт 10^9 байт уу эсвэл 2^30 уу? Аль орон нутгийн цагт, аль цагийн бүсэд хугацаа эргэдэг вэ? Тоолуур яг юуг хэмждэг вэ, туннелийн нэмэлт зардал болон дахин дамжуулалт орсон ч програмын файлын хэмжээ, нийлүүлэгчийн нэхэмжлэх ороогүй?
Эдгээр сонголтын аль нь ч буруу биш, гэхдээ хэрэгжүүлэлт болон харилцагчийн харж буй тоо санал нийлэх ёстой. Нэг системийн хоёр хагас GiB эсвэл орон нутгийн цагийн оронд UTC шөнө дунд болдог эргэлтийн талаар санал нийлэхгүй бол бүх квотод итгэлийг сулруулдаг яг тэр төрлийн тасалбар үүсдэг.
Байтын нийлбэрийг нэг тооцсон зөрүү болго
Удирдлагын интерфейс клиентийн ID болон чиглэл бүрийн хуримтлагдсан байтын нийлбэрийг агуулсан үечилсэн 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
Шинэ суурь шугам болон хэрэглээний өсөлтийг хамт баталгаажуул, ингэснээр дээжийг дахин тоглуулах нь хоёр удаа тооцохын оронд юу ч тооцохгүй. Хойш хөдөлж буй тоолуур нь дохио, өр биш: энэ нь сесс солигдсон эсвэл демон дахин эхэлсэн гэсэн үг бөгөөд зөв хариулт нь сөрөг дүн кредитлэх биш, сессийн танихыг тааруулах явдал юм.
Салгах зам мөн адил анхаарал шаарддаг. Хэрэв эцсийн үйл явдал сессийн төгсгөлийн нийлбэрийг агуулж байвал хамгийн сүүлд баталгаажсан дээжээс зөвхөн зөрүүг тооц. Тогтмол дээж авалт аль хэдийн тооцогдсоны дараа бүтэн нийлбэрийг нэмэх нь гэрийн квотын системд хамгийн түгээмэл давхар тооцоо юм. Хугацааны хил давсан сессүүдэд ч дүрэм хэрэгтэй, учир нь нэг эцсийн нийлбэр нь байтууд шөнө дундыг хэзээ давсан тухай мэдээлэл агуулдаггүй.
Дууссаныг нэвтрэхийг хоригло, зөвхөн туннелийг алж болохгүй
Бүртгэл хязгаартаа хүрэхэд хоёр зүйл тохиолдох ёстой: одоо байгаа сессүүд дуусч, шинэ нь татгалзагдана. Удирдлагын протокол клиентийн ID-аар client-kill санал болгодог бөгөөд энэ нь бүртгэлийн бүх амьд сессийг тоолбол эхний хагасыг шийднэ, санамсаргүй анзаарсан нэг хаягийг алахын оронд.
Хоёр дахь хагас нь квотын загварууд бүтэлгүйтдэг газар юм. Зөвхөн алах нь клиентийн дахин холбогдох циклтэй уралдаан бөгөөд тэр хэдхэн секундын дараа баяртайгаар буцаж ирнэ. Нэвтрэх нь хуваалцсан дэвтэртэй зөвлөлдөх ёстой бөгөөд олон гарцтай байршуулалтад тэр шалгалт машин бүрийн файл байж болохгүй. Нэвтрэлт хүлээн авч чадах хувилбар бүр ижил дууссан төлөвийг харах ёстой.
Токенд суурилсан дахин холбогдолт өөрийн шалгалтыг хүртэх ёстой. OpenVPN 2.6 нь auth-gen-token ашиглан сессийн токеныг дотоодоос баталгаажуулж, таны хянагч хязгаарыг хэрэгжүүлэхэд ашигладаг гадаад баталгаажуулалтын дуудлагыг алгасна. Тиймээс хүчинтэй хэвээр байгаа токен нь танихыг баталж, үлдсэн квотыг биш, шинэ клиентийн хувилбар бүр дэвтэртэй зөвлөлдөх ёстой хэвээр. Үүний оронд management-client-auth-ыг идэвхжүүлбэл хянагч нь баталгаажуулагч болж, сессийн төлөвийг өөрөө шинжилж, хугацаа дууссан эсвэл хүчингүй токеныг өөрөө татгалзах үүргийг өвлөнө.
Дээж авалтын үүсгэдэг хэтрэлтийг хүлээн зөвшөөр
Тогтмол ажиглалт болон салгалт нь мэдэгдэж буй хүлцэл бүхий дээжлэсэн квотыг өгнө. Клиент нэг тайлангийн интервал болон хянагчид үйлдэл хийхэд шаардагдах хугацаагаар ойролцоогоор хэтрэх боломжтой бөгөөд нэг бүртгэл дэх зэрэгцээ сессүүд тэр цонхыг олон дахин нэмэгдүүлнэ. Өгч чадахгүй сүүлчийн байт дээрх нарийн зүсэлтийг сурталчлахын оронд үүнийг интерфейсд хэл.
Жинхэнэ хатуу дээд хязгаар нь өөр инженерийн асуудал: дамжуулах замын дотор, сессүүдийн туршид нэг бүртгэлд холбогдсон хэрэгжилт. Тоолуурыг илүү хурдан унших нь ижил зүйл биш бөгөөд зүгээр л илүү олон туннель нээдэг клиентийг даахгүй.
Нэвтрүүлэхийн өмнө гэнэн хэрэгжүүлэлтийг эвддэг хүлээн авалтын тохиолдлуудыг ажиллуул: давтан дахин холбогдолт, нэгэн зэрэг хоёр төхөөрөмж, хянагч болон гарцын дахин эхлэлт, алдагдсан салгалтын үйл явдал, сессийн дунд хугацааны эргэлт, дууссаны дараа шууд токеноор дахин холбогдох оролдлого. Дараа нь нягтлан бодох бүртгэлийн тасалдлын эвдрэлийн горимыг шийд. Тогтвортой дэвтэр нь бүртгэсэн хэрэглээг хамгаална; хэзээ ч ирээгүй ажиглалтыг сэргээж чадахгүй бөгөөд харилцагч эдгээр хоёр нөхцөл байдлын алинд нь байгаагаа мэдэх эрхтэй.