Hová tartozik a havi adatkeret OpenVPN-fiókonként

Az a keret, amely minden alkalommal nullázódik, amikor az alagút újracsatlakozik, nem korlát, és pontosan ezt kapja, ha egy bájtszámlálót egy VPN-kiszolgálóra csavaroznak anélkül, hogy lenne hely a tartós állapotnak. A számláló egy munkamenethez tartozik; a keret egy személyhez vagy egy eszközszerződéshez. A funkció minden nehézsége ebből az eltérésből fakad, ezért az alábbi ellenőrzések arról szólnak, hol él az állapot, és melyik réteg dönthet.

A keretet fiókhoz rögzítse, ne alagúthoz

Kezdje a keret alanyának megnevezésével. Egy személynek három eszköztanúsítványa is lehet, és egyikük sem kaphat önálló havi keretet csak azért, mert külön hitelesít. Az a stabil fiókazonosító, amely túléli az újracsatlakozásokat, az új alagútcímeket és a második átjáróra költözést, az egyetlen horgony, amelyet egy keret használhat. A tanúsítvány köznapi neve csak akkor működik kulcsként, ha a kibocsátási szabályzata névenként egy fiókot garantál.

Egy kiosztott alagútcím soha nem a válasz. A címek újrahasznosulnak, a poolok megosztottak, és ugyanaz a fiók ugyanabban a percben kétszer is megjelenhet két átjárón. Ha a főkönyv címre kulcsol, az leválasztás és újracsatlakozás elég a tartály újratöltéséhez.

Munkamenetenként annyit rögzítsen, hogy az aritmetika ellenőrizhető legyen: a fiókot, az elszámolási időszakot, az átjáró példányát, a munkamenet identitását, az utoljára megfigyelt számlálókat és az elkötelezett összeget. Vegye fel a daemon indítási generációját a munkamenet identitásába, mert az újraindított kiszolgáló újrahasználja az ügyfél-azonosítókat, és egy naiv egyeztetés örökölné az előző alapvonalat.

Rögzítse az egységet, az irányt és az alaphelyzetbe állítás határát

Négy definíciót kell írásban rögzíteni, mielőtt bármilyen gyűjtés elkezdődik. A keret az ügyfél által küldött bájtokat, a fogadott bájtokat vagy a kettő összegét számolja? Egy gigabájt 10^9 bájt vagy 2^30? Melyik helyi órában és melyik időzónában fordul át az időszak? És pontosan mit mér a számláló, tekintve, hogy az alagút többletterhelése és az újraküldések benne vannak, az alkalmazásfájl mérete és a szolgáltató számlája viszont nem?

Egyik választás sem hibás, de a megvalósításnak és az ügyfél által látott számnak egyeznie kell. Ugyanazon rendszer két fele, amely nem ért egyet a GiB-ben, vagy abban, hogy az átfordulás UTC-éjfélkor történik helyi idő helyett, pontosan olyan jegyet állít elő, amely aláássa a bizalmat az egész keretben.

Alakítsa a bájtösszegeket egyetlen felszámított különbséggé

A felügyeleti felület rendszeres BYTECOUNT_CLI sorokat jelent, amelyek ügyfél-azonosítót és mindkét irányban halmozott bájtösszegeket hordoznak, a bytecount parancs pedig beállítja, milyen gyakran érkeznek. A kiszolgáló szemszögéből a fogadott érték az ügyfél által küldött bájtokat számolja, a küldött érték pedig a neki kézbesített bájtokat. Állítsa az intervallumot olyasmire, amit a főkönyv el tud viselni; a nagyon rövid intervallum olyan pontosságot vásárol, amelyet valójában nem kap meg.

Egy korlát formálja az egész tervezést: a felügyeleti socket egyetlen vezérlőkapcsolatot fogad el. Egy monitorozási exportáló, egy grafikus felület és a vezérlője nem nyithat mindegyike sajátot. Döntse el, melyik folyamat birtokolja a csatornát, és hagyja, hogy a többiek onnan olvassák az állapotot, mert ez a felület adminisztratív műveleteket ad, és amúgy sem szabad a gazdagépen kívülre tenni.

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

Rögzítse együtt az új alapvonalakat és a használat növekedését, hogy egy minta újrajátszása semmit ne számoljon fel a kétszeri felszámítás helyett. A hátrafelé mozduló számláló jelzés, nem tartozás: azt jelenti, hogy a munkamenetet lecserélték vagy a daemon újraindult, és a helyes válasz a munkamenet identitásának egyeztetése, nem negatív összeg jóváírása.

A leválasztás útja ugyanilyen gondosságot igényel. Ha egy záró esemény munkamenet-végi összegeket hordoz, csak az utoljára elkötelezett mintától számított különbséget számolja fel. A teljes összeg hozzáadása azután, hogy az időszakos mintavétel már felszámításra került, a legelterjedtebb kettős számolás a házilag épített keretrendszerekben. Az időszakhatárt átlépő munkameneteknek is szabály kell, mert egyetlen záró összeg nem hordoz információt arról, mikor lépték át a bájtok az éjfélt.

A kimerülés tagadja meg a belépést, ne csak az alagutat ölje meg

Amikor egy fiók eléri a korlátját, két dolognak kell történnie: a meglévő munkamenetek véget érnek, és az újakat elutasítják. A felügyeleti protokoll client-kill-t kínál ügyfél-azonosító szerint, ami az első felét kezeli, feltéve, hogy felsorolja a fiók minden élő munkamenetét, ahelyett hogy az egyetlen címet ölné meg, amelyet véletlenül észrevett.

A második fél az, ahol a kerettervek megbuknak. Az ölés önmagában versenyfutás az ügyfél újracsatlakozási hurkával, amely szívesen visszatér másodpercekkel később. A belépésnek a megosztott főkönyvet kell kérdeznie, és többátjárós telepítésnél ez az ellenőrzés nem lehet gépenkénti fájl. Minden példánynak, amely bejelentkezést fogadhat, ugyanazt a kimerült állapotot kell látnia.

A tokenalapú újracsatlakozások saját próbát érdemelnek. Az OpenVPN 2.6 auth-gen-token segítségével belsőleg érvényesíthet egy munkamenet-tokent, kihagyva azt a külső hitelesítési hívást, amelyet a vezérlője a plafon érvényesítésére használt. Egy még érvényes token tehát identitást bizonyít, nem fennmaradó keretet, és minden új ügyfélpéldánynak továbbra is a főkönyvet kell kérdeznie. Ha helyette a management-client-auth-ot engedélyezi, a vezérlő lesz a hitelesítő, és örökli a kötelezettséget, hogy maga elemezze a munkamenet állapotát, és utasítsa el a lejárt vagy érvénytelen tokeneket.

Fogadja el a túllövést, amelyet a mintavétel okoz

Az időszakos megfigyelés és a leválasztás ismert toleranciájú mintavételezett keretet ad. Egy ügyfél nagyjából egy jelentési intervallummal plusz a vezérlő cselekvéséhez szükséges idővel lóghat túl, és egy fiókon az egyidejű munkamenetek megsokszorozzák ezt az ablakot. Mondja ezt a felületen, ahelyett hogy pontos utolsó bájtos levágást hirdetne, amelyet nem tud teljesíteni.

Az igazi kemény plafon más mérnöki probléma: érvényesítés a továbbítási útvonalon belül, ugyanahhoz a fiókhoz kötve a munkameneteken át. A számlálók gyorsabb olvasása nem ugyanaz, és nem éli túl azt az ügyfelet, amely egyszerűen több alagutat nyit.

Bevezetés előtt futtassa azokat az átvételi eseteket, amelyek megtörik a naiv megvalósításokat: ismételt újracsatlakozások, két eszköz egyszerre, a vezérlő és az átjáró újraindításai, egy elveszett leválasztási esemény, időszakváltás a munkamenet közepén és tokenes újracsatlakozási kísérlet közvetlenül a kimerülés után. Ezután döntse el az elszámolási kiesések hibaüzemmódját. A tartós főkönyv védi a rögzített használatot; nem tudja feltámasztani azokat a megfigyeléseket, amelyek soha nem érkeztek meg, és az ügyfél megérdemli, hogy tudja, a két helyzet közül melyikben van.