ตำแหน่งที่โควตาข้อมูลรายเดือนควรอยู่ต่อบัญชี OpenVPN

โควตาที่รีเซ็ตทุกครั้งที่อุโมงค์เชื่อมต่อใหม่ไม่ใช่ขีดจำกัด และนั่นคือสิ่งที่ได้เมื่อติดตั้งตัวนับไบต์บนเซิร์ฟเวอร์ VPN โดยไม่มีที่เก็บสถานะถาวร ตัวนับเป็นของเซสชัน ส่วนโควตาเป็นของบุคคลหรือสัญญาอุปกรณ์ ความยากทั้งหมดของฟีเจอร์นี้มาจากความไม่สอดคล้องนั้น ดังนั้นการตรวจสอบด้านล่างจึงเกี่ยวกับว่าสถานะอยู่ที่ไหนและชั้นใดได้รับอนุญาตให้ตัดสินใจ

ผูกโควตากับบัญชี ไม่ใช่กับอุโมงค์

เริ่มด้วยการระบุหัวข้อของโควตา บุคคลหนึ่งอาจถือใบรับรองอุปกรณ์สามใบ และไม่ควรมีใบใดได้รับงบประมาณรายเดือนแยกต่างหากเพียงเพราะตรวจสอบสิทธิ์แยกกัน ตัวระบุบัญชีที่คงที่ซึ่งอยู่รอดจากการเชื่อมต่อใหม่ ที่อยู่อุโมงค์ใหม่ และการย้ายไปยังเกตเวย์ที่สองคือสมอเดียวที่โควตาจะใช้ได้ ชื่อสามัญของใบรับรองทำหน้าที่เป็นกุญแจนั้นได้ก็ต่อเมื่อนโยบายการออกใบรับรองของคุณรับประกันหนึ่งบัญชีต่อหนึ่งชื่อ

ที่อยู่อุโมงค์ที่จัดสรรให้ไม่เคยเป็นคำตอบ ที่อยู่ถูกนำกลับมาใช้ใหม่ พูลถูกแบ่งปัน และบัญชีเดียวกันอาจปรากฏสองครั้งบนเกตเวย์สองตัวในนาทีเดียวกัน หากบัญชีแยกประเภทผูกกับที่อยู่ การตัดการเชื่อมต่อแล้วเชื่อมต่อใหม่ก็เพียงพอที่จะเติมถังให้เต็มอีกครั้ง

บันทึกต่อเซสชันให้มากพอเพื่อให้การคำนวณตรวจสอบได้: บัญชี รอบการเรียกเก็บเงิน อินสแตนซ์เกตเวย์ ตัวระบุเซสชัน ตัวนับที่สังเกตล่าสุด และยอดรวมที่ยืนยันแล้ว รวมรุ่นการเริ่มต้นของดีมอนไว้ในตัวระบุเซสชัน เพราะเซิร์ฟเวอร์ที่รีสตาร์ทจะใช้ ID ของไคลเอนต์ซ้ำ และการจับคู่แบบง่ายจะสืบทอดเส้นฐานเดิม

กำหนดหน่วย ทิศทาง และขอบเขตการรีเซ็ต

ต้องกำหนดคำนิยามสี่ข้อเป็นลายลักษณ์อักษรก่อนเริ่มการเก็บข้อมูลใด ๆ โควตานับไบต์ที่ไคลเอนต์ส่ง ไบต์ที่ได้รับ หรือผลรวมของทั้งสอง หนึ่งกิกะไบต์คือ 10^9 ไบต์หรือ 2^30 รอบระยะเวลาหมุนเวลาใดตามเวลาท้องถิ่นและเขตเวลาใด และตัวนับวัดอะไรกันแน่ เมื่อพิจารณาว่าภาระส่วนเกินของอุโมงค์และการส่งซ้ำรวมอยู่ด้วย แต่ขนาดไฟล์แอปพลิเคชันและใบแจ้งหนี้ของผู้ให้บริการไม่รวม

ไม่มีตัวเลือกใดผิด แต่การนำไปใช้และตัวเลขที่ลูกค้าเห็นต้องตรงกัน สองครึ่งของระบบเดียวกันที่ไม่ตรงกันเรื่อง GiB หรือเรื่องการหมุนที่เกิดขึ้นเที่ยงคืน UTC แทนเวลาท้องถิ่น จะสร้างตั๋วชนิดเดียวกับที่กัดกร่อนความเชื่อมั่นในโควตาทั้งหมด

เปลี่ยนยอดรวมไบต์เป็นส่วนต่างที่เรียกเก็บหนึ่งค่า

อินเทอร์เฟซการจัดการรายงานบรรทัด BYTECOUNT_CLI เป็นระยะซึ่งนำ ID ของไคลเอนต์บวกยอดรวมไบต์สะสมในแต่ละทิศทาง และคำสั่ง 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 ตาม ID ของไคลเอนต์ ซึ่งจัดการครึ่งแรกได้ตราบใดที่คุณแจกแจงทุกเซสชันที่ยังมีชีวิตของบัญชี แทนที่จะฆ่าเพียงที่อยู่เดียวที่คุณบังเอิญสังเกตเห็น

ครึ่งหลังคือจุดที่การออกแบบโควตาล้มเหลว การฆ่าเพียงอย่างเดียวคือการแข่งกับลูปเชื่อมต่อใหม่ของไคลเอนต์ ซึ่งจะกลับมาอย่างยินดีในไม่กี่วินาที การรับเข้าต้องปรึกษาบัญชีแยกประเภทที่ใช้ร่วมกัน และในการติดตั้งหลายเกตเวย์ การตรวจสอบนั้นไม่สามารถเป็นไฟล์ต่อเครื่องได้ ทุกอินสแตนซ์ที่รับการเข้าสู่ระบบได้ต้องเห็นสถานะหมดโควตาเดียวกัน

การเชื่อมต่อใหม่ด้วยโทเคนสมควรได้รับการทดสอบของตัวเอง OpenVPN 2.6 สามารถตรวจสอบโทเคนเซสชันภายในด้วย auth-gen-token โดยข้ามการเรียกการรับรองความถูกต้องภายนอกที่คอนโทรลเลอร์ของคุณใช้บังคับเพดาน ดังนั้นโทเคนที่ยังใช้ได้จึงพิสูจน์ตัวตน ไม่ใช่โควตาที่เหลือ และไคลเอนต์อินสแตนซ์ใหม่ทุกตัวยังต้องปรึกษาบัญชีแยกประเภท หากคุณเปิดใช้ management-client-auth แทน คอนโทรลเลอร์จะกลายเป็นผู้รับรองและสืบทอดหน้าที่ในการวิเคราะห์สถานะเซสชันและปฏิเสธโทเคนที่หมดอายุหรือไม่ถูกต้องด้วยตนเอง

ยอมรับการเกินที่การสุ่มตัวอย่างสร้างขึ้น

การสังเกตเป็นระยะบวกกับการตัดการเชื่อมต่อให้โควตาที่สุ่มตัวอย่างพร้อมความคลาดเคลื่อนที่ทราบ ไคลเอนต์สามารถเกินได้ประมาณหนึ่งช่วงการรายงานบวกเวลาที่คอนโทรลเลอร์ใช้ในการดำเนินการ และเซสชันพร้อมกันบนบัญชีเดียวจะคูณหน้าต่างนั้น บอกสิ่งนี้ในอินเทอร์เฟซแทนการโฆษณาการตัดที่แน่นอนที่ไบต์สุดท้ายซึ่งคุณให้ไม่ได้

เพดานแข็งที่แท้จริงคือปัญหาทางวิศวกรรมอีกอย่างหนึ่ง คือการบังคับใช้ภายในเส้นทางการส่งต่อ ผูกกับบัญชีเดียวกันตลอดเซสชัน การอ่านตัวนับเร็วขึ้นไม่ใช่สิ่งเดียวกัน และไม่ทนต่อไคลเอนต์ที่เพียงเปิดอุโมงค์เพิ่ม

ก่อนการเปิดตัว ให้รันกรณีทดสอบการยอมรับที่ทำให้การนำไปใช้แบบง่ายพัง: การเชื่อมต่อใหม่ซ้ำ ๆ อุปกรณ์สองเครื่องพร้อมกัน การรีสตาร์ทคอนโทรลเลอร์และเกตเวย์ เหตุการณ์ตัดการเชื่อมต่อที่สูญหาย การหมุนรอบกลางเซสชัน และความพยายามเชื่อมต่อใหม่ด้วยโทเคนทันทีหลังหมดโควตา จากนั้นตัดสินใจโหมดความล้มเหลวสำหรับการหยุดชะงักของการบัญชี บัญชีแยกประเภทที่ทนทานปกป้องการใช้งานที่คุณบันทึกไว้ มันไม่สามารถชุบชีวิตการสังเกตที่ไม่เคยมาถึง และลูกค้าสมควรรู้ว่าตนอยู่ในสถานการณ์ใดจากสองสถานการณ์นั้น