OpenVPN-hokoj: kial nomo kaj tempmarko ne estas ŝlosilo

Malkonekta rikordo alvenas post kiam dua konekto sub la sama nomo jam komenciĝis, kaj administrilo, kiu ĝisdatigas la plej novan vicon por tiu uzanto, fermas la malĝustan seancon. La eraro ne estas la komparo de tempmarkoj. Ĝi estas la supozo, ke nomo plus tuta sekundo identigas unu seancon. Hokaj eventoj priskribas konektojn, kaj konekto bezonas ŝlosilon, kiu apartenas nur al ĝi.

Komencu per tio, kion la malkonektaj variabloj vere signifas. Nur tiam la elekto de identigilo havas sencon.

Kion la malkonekta hoko vere portas

En Community OpenVPN 2.6, la hoka referenco time_unix difinas kiel la momenton, kiam la kliento konektiĝis; ĝi estas agordita antaŭ ol la konekta hoko ruliĝas, kaj ĝi ne estas redefinita kiam la malkonekta hoko poste ekfunkcias. time_duration donas la longon de tiu seanco en sekundoj, do la fino estas proksimume la konekta tempo plus la daŭro. Ambaŭ estas tutaj sekundoj, kaj nek unu estas la momento, kiam via datumbazo prilaboris la eventon. Teni tiujn tri tempojn apartaj estas tio, kio igas korelacion teniĝi anstataŭ nur aspekti ĝusta dum testado.

Ĉi tiu aritmetiko meritas esti skribita, ĉar ĝi estas la sola fina tempo, kiun la hoko mem proponas. Prilabora prokrasto kaj horloĝaj diferencoj inter gastigantoj ankoraŭ restas ekster ĝi.

Kial la evidenta paro ne estas unika

Parigi la nomon kun la konekta tempo mallarĝigas la serĉon kaj ankoraŭ ne identigas seancon. Kliento povas rekonekti ene de la sama sekundo, do du seancoj povas kunhavigi ambaŭ valorojn. Du demoninstancoj, aŭ servila anstataŭigo, kiu konservas la saman agordon, povas produkti tiun paron el malsamaj procezoj. Tunelaj adresoj estas recikligitaj pro la sama kialo, kio igas ilin atributoj de seanco anstataŭ identigiloj por ĝi.

La malsukcesa reĝimo estas silenta. Malfrua malkonekto por la unua seanco kongruas kun la plej nova vico kaj finas asignon, kiun la dua seanco ankoraŭ uzas, do la uzanto spertas hazardan perdon de aliro, kiun li neniel kaŭzis. Vica nombro, kiu poste aspektas ĝusta, malfaciligas rimarki la problemon.

De kie venas stabila identeco

La administra interfaco asignas al ĉiu kliento klientan instancidentigilon, kaj tiu identigilo estas limigita al la demoninstanco, kiu ĝin eldonis. Uzebla ekstera ŝlosilo kombinas stabilan servilan identigilon, epokon, kiu ŝanĝiĝas kiam la demono ekfunkcias, kaj tiun klientan ID. La epoko gravas ĉar identigiloj rekomenciĝas kun la procezo, kaj nuda proceza ID povas poste esti reuzata de io neligita.

Ĉirkaŭaj variabloj agorditaj ene de infana konekta skripto ne vojaĝas al la posta malkonekta skripto de la patra demono, ĉar tiuj skriptoj ruliĝas kiel apartaj procezoj kun propraj ĉirkaŭaĵoj. Generi UUID ĉe konekta tempo do estas duona solvo. La malkonekta flanko devas povi nomi la saman UUID, kio signifas, ke la identeco devas vivi ie, kien ambaŭ eventoj povas atingi.

Igu la finadon kondiĉa kaj idempotenta

Finu laŭ seanca posedanto, ne laŭ uzanto. Administrilo, kiu forigas ajnan asignon nuntempe apartenantan al nomo, eventuale forigos la malĝustan, kaj la sola defendo estas kontroli, ke la forigata rikordo estas la rikordo, kiun ĉi tiu evento priskribas.

La administra interfaco akceptas unu konektitan administran klienton samtempe, do integriĝu kun tiu, kiu jam posedas ĝin, anstataŭ alligi duan observanton, kiu konkuras pri la sama ingo.

Traktu ripetitajn eventojn sen dufoje ŝanĝi la rezulton, kaj konservu neparigitajn eventojn por repacigo anstataŭ forĵeti ilin. Malkonekta retrovoko havas dokumentitajn vivciklajn kondiĉojn kaj eble neniam alvenos post paneo aŭ malmola halto, do la dezajno bezonas manieron reprezenti seancon, kies fina evento mankas.

Testu la malfacilajn kazojn intence: du rekonektojn ene de unu sekundo, du demoninstancojn, konekton, kies prilaborado malsukcesis, kaj demonan restartigon meze de seanco. Ŝlosilo, kiu postvivas ĉiujn kvar, estas ŝlosilo fidinda.