Πού ανήκει ένα μηνιαίο όριο δεδομένων ανά λογαριασμό OpenVPN

Ένα όριο που επαναφέρεται κάθε φορά που το τούνελ επανασυνδέεται δεν είναι όριο, και αυτό ακριβώς παίρνετε όταν ένας μετρητής byte βιδώνεται σε έναν διακομιστή VPN χωρίς χώρο για μόνιμη κατάσταση. Ο μετρητής ανήκει σε μια συνεδρία· το όριο ανήκει σε ένα πρόσωπο ή σε ένα συμβόλαιο συσκευής. Όλη η δυσκολία του χαρακτηριστικού προέρχεται από αυτή την αναντιστοιχία, οπότε οι έλεγχοι παρακάτω αφορούν το πού ζει η κατάσταση και ποιο στρώμα επιτρέπεται να αποφασίζει.

Καρφιτσώστε το όριο σε λογαριασμό, όχι σε τούνελ

Ξεκινήστε ονομάζοντας το υποκείμενο του ορίου. Ένα πρόσωπο μπορεί να έχει τρία πιστοποιητικά συσκευών, και κανένα από αυτά δεν θα έπρεπε να παίρνει ανεξάρτητο μηνιαίο προϋπολογισμό μόνο επειδή πιστοποιείται ξεχωριστά. Ένα σταθερό αναγνωριστικό λογαριασμού που επιβιώνει από επανασυνδέσεις, νέες διευθύνσεις τούνελ και μετακίνηση σε δεύτερη πύλη είναι η μόνη άγκυρα που μπορεί να χρησιμοποιήσει ένα όριο. Το κοινό όνομα ενός πιστοποιητικού λειτουργεί ως κλειδί μόνο όταν η πολιτική έκδοσης εγγυάται έναν λογαριασμό ανά όνομα.

Μια εκχωρημένη διεύθυνση τούνελ δεν είναι ποτέ η απάντηση. Οι διευθύνσεις ανακυκλώνονται, οι δεξαμενές μοιράζονται, και ο ίδιος λογαριασμός μπορεί να εμφανιστεί δύο φορές σε δύο πύλες το ίδιο λεπτό. Αν το καθολικό κλειδώνει σε μια διεύθυνση, αρκεί η αποσύνδεση και η επανασύνδεση για να ξαναγεμίσει το ντεπόζιτο.

Καταγράψτε αρκετά ανά συνεδρία ώστε η αριθμητική να είναι ελέγξιμη: τον λογαριασμό, την περίοδο χρέωσης, το στιγμιότυπο της πύλης, την ταυτότητα της συνεδρίας, τους τελευταίους παρατηρημένους μετρητές και το δεσμευμένο σύνολο. Συμπεριλάβετε μια γενιά εκκίνησης του δαίμονα στην ταυτότητα της συνεδρίας, γιατί ένας επανεκκινημένος διακομιστής επαναχρησιμοποιεί αναγνωριστικά πελατών και μια αφελής αντιστοίχιση θα κληρονομούσε την προηγούμενη βάση.

Καθορίστε τη μονάδα, την κατεύθυνση και το όριο επαναφοράς

Τέσσερις ορισμοί πρέπει να καθοριστούν γραπτώς πριν ξεκινήσει οποιαδήποτε συλλογή. Το όριο μετρά byte που στέλνει ο πελάτης, byte που λαμβάνει, ή το άθροισμα και των δύο; Είναι το γκιγκαμπάιτ 10^9 byte ή 2^30; Σε ποια τοπική ώρα και σε ποια ζώνη ώρας γυρίζει η περίοδος; Και τι ακριβώς μετρά ο μετρητής, δεδομένου ότι τα γενικά έξοδα του τούνελ και οι αναμεταδόσεις περιλαμβάνονται, ενώ το μέγεθος του αρχείου της εφαρμογής και το τιμολόγιο του παρόχου όχι;

Καμία από αυτές τις επιλογές δεν είναι λάθος, αλλά η υλοποίηση και ο αριθμός που βλέπει ο πελάτης πρέπει να συμφωνούν. Δύο μισά του ίδιου συστήματος που διαφωνούν για τα GiB, ή για μια αλλαγή που συμβαίνει τα μεσάνυχτα UTC αντί για τοπική ώρα, παράγουν ακριβώς το είδος του δελτίου που υπονομεύει την εμπιστοσύνη σε ολόκληρο το όριο.

Μετατρέψτε τα σύνολα byte σε ένα χρεωμένο δέλτα

Η διεπαφή διαχείρισης αναφέρει περιοδικές γραμμές BYTECOUNT_CLI που μεταφέρουν αναγνωριστικό πελάτη και αθροιστικά σύνολα byte σε κάθε κατεύθυνση, και η εντολή bytecount ορίζει πόσο συχνά φτάνουν. Από τη σκοπιά του διακομιστή, το νούμερο που λαμβάνεται μετρά τα byte που έστειλε ο πελάτης και το νούμερο που στέλνεται μετρά τα byte που παραδόθηκαν σε αυτόν. Ορίστε το διάστημα σε κάτι που το καθολικό μπορεί να απορροφήσει· ένα πολύ σύντομο διάστημα αγοράζει ακρίβεια που στην πραγματικότητα δεν παίρνετε.

Ένας περιορισμός διαμορφώνει όλο τον σχεδιασμό: η υποδοχή διαχείρισης δέχεται μία μόνο σύνδεση ελέγχου. Ένας εξαγωγέας παρακολούθησης, ένα 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

Δεσμεύστε τις νέες βάσεις και την αύξηση χρήσης μαζί, ώστε η επανάληψη ενός δείγματος να μη χρεώνει τίποτα αντί να χρεώνει δύο φορές. Ένας μετρητής που κινείται προς τα πίσω είναι σήμα, όχι χρέος: σημαίνει ότι η συνεδρία αντικαταστάθηκε ή ότι ο δαίμονας επανεκκινήθηκε, και η σωστή απάντηση είναι να συμφιλιώσετε την ταυτότητα της συνεδρίας αντί να πιστώσετε αρνητικό ποσό.

Η διαδρομή αποσύνδεσης χρειάζεται την ίδια φροντίδα. Αν ένα τελικό γεγονός μεταφέρει σύνολα τέλους συνεδρίας, χρεώστε μόνο τη διαφορά από το τελευταίο δεσμευμένο δείγμα. Το να προσθέσετε το πλήρες σύνολο αφού έχει ήδη χρεωθεί η περιοδική δειγματοληψία είναι η πιο συνηθισμένη διπλή μέτρηση σε σπιτικά συστήματα ορίων. Οι συνεδρίες που διασχίζουν ένα όριο περιόδου χρειάζονται επίσης κανόνα, αφού ένα τελικό σύνολο δεν μεταφέρει πληροφορία για το πότε τα byte πέρασαν τα μεσάνυχτα.

Η εξάντληση να αρνείται την εισαγωγή, όχι μόνο να σκοτώνει το τούνελ

Όταν ένας λογαριασμός φτάνει στο όριό του, πρέπει να συμβούν δύο πράγματα: οι υπάρχουσες συνεδρίες τελειώνουν και οι νέες απορρίπτονται. Το πρωτόκολλο διαχείρισης παρέχει client-kill κατά αναγνωριστικό πελάτη, που χειρίζεται το πρώτο μισό αρκεί να απαριθμήσετε κάθε ζωντανή συνεδρία του λογαριασμού αντί να σκοτώσετε τη μία διεύθυνση που τυχαία προσέξατε.

Το δεύτερο μισό είναι εκεί όπου αποτυγχάνουν τα σχέδια ορίων. Ένα σκότωμα μόνο του είναι αγώνας δρόμου με τον βρόχο επανασύνδεσης του πελάτη, που θα επιστρέψει πρόθυμα δευτερόλεπτα αργότερα. Η εισαγωγή πρέπει να συμβουλεύεται το κοινό καθολικό, και σε ανάπτυξη με πολλές πύλες αυτός ο έλεγχος δεν μπορεί να είναι αρχείο ανά μηχάνημα. Κάθε στιγμιότυπο που μπορεί να δεχτεί σύνδεση πρέπει να βλέπει την ίδια εξαντλημένη κατάσταση.

Οι επανασυνδέσεις με διακριτικό αξίζουν το δικό τους τεστ. Το OpenVPN 2.6 μπορεί να επικυρώσει ένα διακριτικό συνεδρίας εσωτερικά με το auth-gen-token, παρακάμπτοντας την εξωτερική κλήση πιστοποίησης που χρησιμοποιούσε ο ελεγκτής σας για να επιβάλει το ανώτατο όριο. Ένα διακριτικό που είναι ακόμη έγκυρο αποδεικνύει επομένως ταυτότητα, όχι υπόλοιπο ορίου, και κάθε νέο στιγμιότυπο πελάτη πρέπει ακόμη να συμβουλεύεται το καθολικό. Αν αντίθετα ενεργοποιήσετε το management-client-auth, ο ελεγκτής γίνεται ο πιστοποιητής και κληρονομεί την υποχρέωση να αναλύει μόνος την κατάσταση της συνεδρίας και να απορρίπτει ληγμένα ή άκυρα διακριτικά.

Δεχτείτε την υπέρβαση που δημιουργεί η δειγματοληψία

Η περιοδική παρατήρηση μαζί με την αποσύνδεση σας δίνουν ένα δειγματοληπτικό όριο με γνωστή ανοχή. Ένας πελάτης μπορεί να υπερβεί κατά περίπου ένα διάστημα αναφοράς συν τον χρόνο που χρειάζεται ο ελεγκτής για να δράσει, και οι ταυτόχρονες συνεδρίες σε έναν λογαριασμό πολλαπλασιάζουν αυτό το παράθυρο. Πείτε το στη διεπαφή αντί να διαφημίζετε έναν ακριβή αποκλεισμό στο τελευταίο byte που δεν μπορείτε να παραδώσετε.

Ένα πραγματικό σκληρό ανώτατο όριο είναι άλλο μηχανικό πρόβλημα: επιβολή μέσα στη διαδρομή προώθησης, δεμένη στον ίδιο λογαριασμό κατά μήκος συνεδριών. Το να διαβάζετε τους μετρητές γρηγορότερα δεν είναι το ίδιο πράγμα, και δεν αντέχει σε έναν πελάτη που απλώς ανοίγει περισσότερα τούνελ.

Πριν από την κυκλοφορία, εκτελέστε τις περιπτώσεις αποδοχής που σπάνε τις αφελείς υλοποιήσεις: επαναλαμβανόμενες επανασυνδέσεις, δύο συσκευές ταυτόχρονα, επανεκκινήσεις ελεγκτή και πύλης, ένα χαμένο γεγονός αποσύνδεσης, μια αλλαγή στα μέσα της συνεδρίας και μια προσπάθεια επανασύνδεσης με διακριτικό αμέσως μετά την εξάντληση. Στη συνέχεια αποφασίστε τον τρόπο αποτυχίας για διακοπές της λογιστικής. Ένα μόνιμο καθολικό προστατεύει τη χρήση που καταγράψατε· δεν μπορεί να αναστήσει παρατηρήσεις που δεν έφτασαν ποτέ, και ο πελάτης αξίζει να ξέρει σε ποια από τις δύο καταστάσεις βρίσκεται.