OpenVPN bumabagsak ng OTP session mamaya: ano ang kailangan ng muling pagpapatotoo

Sa panig ng kliyente, mukha itong random na pagkadiskonekta isang oras pagkatapos magsimula ang isang session sa trabaho. Nawawala ang icon sa tray, muling nabubuo ang tunnel, at ang log ay nagpapakita ng kabiguan sa pagpapatotoo sa halip na error sa network. Ang totoong nangyari ay nag-renegotiate ang session at ang ikalawang handshake ay nangailangan ng mga kredensyal na wala nang wastong kopya ang kliyente. Ang isang beses na code na gumana sa pag-login ay hindi na makakagana muli, kaya ang rekey ay nabigo nang eksakto ayon sa disenyo.

Ang solusyon ay isang desisyon kung ano ang dapat ipakita ng ikalawang handshake, hindi isang mas mahabang timer ng muling pagsubok.

Sundan ang palitan mula sa pananaw ng kliyente

Sa pag-login, ipinapadala ng kliyente ang username, password at code mula sa token device, at tinatanggap ng server ang kombinasyon. Pagkatapos ay tumatakbo ang session hanggang pumutok ang isang trigger ng renegotiation, na nagpapasimula ng bagong TLS handshake sa loob ng umiiral na tunnel. Ang handshake na iyon ay humihingi muli ng pagpapatotoo. Kung inaasahan ng landas ng pagpapatotoo sa server ang password at kasalukuyang isang beses na code, walang bagong code na maiaalok ang kliyente maliban kung naroon ang gumagamit upang i-type ito.

Karamihan sa mga kliyente ay hindi nagbubukas ng prompt sa gitna ng session, kaya nag-expire ang handshake at bumabagsak ang tunnel. Nakikita ng gumagamit ang muling pagkonekta, hindi ang prompt ng pagpapatotoo, kaya ang unang ulat ay kadalasang sinisisi ang network.

Binabago ng auth-gen-token kung sino ang sasagot sa ikalawang tanong

Ang opsyon auth-gen-token ay nagbibigay-daan sa server na maglabas ng token pagkatapos ng matagumpay na pag-login, at ang mga susunod na renegotiation ay nagpapakita ng token na iyon sa halip na ulitin ang password at code. Dinodokumento ng manwal ang haba ng buhay at pag-uugali ng pag-renew, at ang token ay dapat ituring na kredensyal na may sariling pag-expire. Sa default na landas, ang server mismo ang nagpapatunay ng token sa halip na tawagin muli ang panlabas na authenticator ng password.

Sa isang panlabas na integrasyon ng pagpapatotoo, nagbabago ang paghahating iyon. Kailangang maunawaan ng plugin ang estado ng token at ilapat ang sariling mga pagsusuri, dahil ang server ay hindi na ang tanging bahagi na nagpapasya kung magpapatuloy ang session. Ang pagtrato sa token bilang isa pang numerong isang beses na code ay hindi isang pagpapatupad ng tampok na ito.

Magpasya kung ano ang mangyayari sa status ng account

Ang token na nabubuhay nang mas matagal kaysa sa access ng isang account ay isang butas sa patakaran. Magpasya kung paano magkakabisa ang isang hindi pinagana na account, isang tinanggal na pagiging miyembro ng grupo o isang binawi na device habang valid pa ang token. Ang maiikling haba ng buhay ng token ay nagpapaliit ng window; ang tahasang landas ng pagbawi ay ginagawa itong sinasadya. Isulat ang sagot bago paganahin ang opsyon, dahil ang default na landas ay hindi kumukonsulta sa panlabas na authenticator sa bawat renegotiation.

Sa isang deployment na may maraming server, ang lihim ng pagpirma ng token ay dapat ibahagi, kung hindi ay maaaring ipadala ang kliyente sa isang node na hindi maaaring magpatunay ng token nito.

Subukan ang pag-expire at muling pagkonekta, hindi lamang ang pag-login

Bawasan ang agwat ng renegotiation sa isang test profile upang ang ikalawang handshake ay mangyari habang nanonood ka, pagkatapos ay sundan ang dalawang log. Kumpirmahin na ang token ay inilalabas sa pag-login, ipinapakita sa rekey, at nire-renew o muling inilalabas ayon sa naka-configure na haba ng buhay. Pagkatapos ay pilitin ang pag-expire ng token at isang buong muling pagkonekta, dahil ang isang kliyenteng malinis na muling kumokonekta ay maaari pa ring mabigo sa landas ng rekey.

Subukan ang pagtanggal ng account sa huli. Sinasabi ng kasong iyon kung ang patakarang isinulat mo ay ipinapatupad o dokumentado lamang.

Huwag ayusin ito sa pamamagitan ng pag-disable ng pag-renew

Ang pagtatakda ng agwat ng renegotiation sa zero sa parehong panig ay nag-aalis ng sintomas at kasama nito ang pag-ikot ng susi. Itinatago nito ang isang problema sa muling paggamit ng kredensyal sa likod ng pagbabago sa patakaran na walang nagsuri. Panatilihin ang pag-renew, at pumili sa pagitan ng token na inilabas ng server at ng bagong interactive na hamon batay sa kung naroon ang isang gumagamit.

Ang mas mahabang timer ng muling pagsubok ay hindi ginagawang valid muli ang isang nagastos na code. Pinapaantala lamang nito ang pagkadiskonekta at pinapahirapan ang pagbasa ng log.