Bakit muling nagtatanong ng mga kredensyal ang isang muling pagkonekta sa VPN

Ang isang tunel na gumana nang ilang oras ay humihingi ng password sa sandaling magising ang laptop, at wala namang nagbago sa configuration. Ang nagbago ay ang kalagayan ng kredensyal na sinubukang gamitin muli ng muling pagkonekta. Tatlong uri ng materyal ang namamahala dito, at isa lang sa kanila ang nakakalampas sa anumang patlang.

Basahin kung alin ang hiniling ng kliyente, dahil nag-expire ang tatlo sa magkaibang orasan at nabigo sila sa magkaibang mensahe.

Tatlong uri ng materyal na magagamit muli

Ang naka-cache na password ay isang lihim na hawak ng kliyente, at nananatili itong may bisa hanggang baguhin ito ng account. Ang session token ay inilalabas ng server pagkatapos ng matagumpay na pag-log in, may sariling haba ng buhay at maaaring bawiin anumang oras. Ang TLS session ticket o IKE security association ay estado ng protocol, mura upang ipagpatuloy at ganap na independiyente sa iyong password. Bawat isa ay inilalabas ng ibang component, at bawat isa ay nag-expire sa sariling mga tuntunin.

Ang una ay nakakalampas sa reboot, ang pangalawa ay karaniwang nakakalampas sa suspend, at ang pangatlo ay maaaring hindi makalampas sa pagbabago ng network. Ang paghahalo sa kanila ay nagdudulot ng maling ayos, tulad ng pag-reset ng password na hindi naman tinanggihan.

Ang prompt mismo ang diagnosis. Ang window ng browser o code ng pangalawang factor ay nangangahulugang hiniling ng server ang interactive na pagpapatotoo, samantalang ang tahimik na pagpalya na walang prompt ay nangangahulugang hindi umabot ang kliyente sa puntong tatanungin.

Ang muling pag-renew ng mga key ay hindi muling pagpapatotoo

Ang muling pag-renew ng key ay pinapalitan ang mga key habang pinapanatili ang napatotohanang pagkakakilanlan, kaya tahimik itong nangyayari paminsan-minsan sa isang malusog na tunel. Ang muling pagpapatotoo ay inuulit ang pagsusuri ng pagkakakilanlan mismo, at iyon ang kaganapang kailangan mo. Malinaw na hinihiwalay ng IKEv2 ang dalawa, at maaaring hilingin ng peer ang buong muling pagpapatotoo sa itinakdang pagitan anuman ang bilang ng pag-renew ng key sa pagitan. Magkamukha ang dalawang kaganapan mula sa labas hanggang basahin mo kung alin ang tinutukoy ng log.

OpenVPN ay ganoon din sa sarili nitong bokabularyo: ang pagitan ng muling pag-uusap ay nagre-refresh ng data channel, at ang authentication token ay maaaring ibalik sa kliyente upang maiwasan ang buong pag-log in sa susunod na koneksyon. May haba ng buhay ang token na iyon, at ang server ang nagpapasya kung tatanggapin itong muli.

Kaya ang muling pagkonekta pagkalipas ng walong oras ay maaaring mabigo kung saan nagtagumpay ang muling pagkonekta pagkalipas ng walong minuto, nang walang anumang pagbabago sa configuration sa magkabilang panig. Iyon ang buong paliwanag sa isang prompt na lumilitaw lamang pagkatapos ng tanghalian.

Kapag hindi matapos ng kliyente ang bagong hamon

Ang patakarang nangangailangan ng hakbang sa browser ay mabibigo sa isang kliyenteng walang paraan upang ipakita iyon. Ang mga headless server, startup script at lumang profile na ginawa para sa pagpapatotoo gamit lamang ang password ay lahat bumabangga sa pader na iyon, at ang pagpalya ay madalas lumitaw bilang pangkalahatang timeout kaysa error sa pagpapatotoo.

Ang paglipat ng device at network ay maaari ring mahulog sa loob ng window ng pagsusuri ng patakaran, kaya ang paglipat mula Wi-Fi patungo sa hotspot ay sumasabay sa pagsusuring mangyayari pa rin. Ang pagkakataon ay nagpapalabas na may kasalanan ang network gayong ang dahilan ay ang timer.

openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth"
ipsec statusall | grep -i -E "rekey|reauth"

Ipinapakita ng unang linya ang mga kaganapan ng muling pag-uusap at pagpapatotoo sa sariling log ng kliyente, at ipinapakita ng pangalawa ang mga security association na hawak ng peer ng strongSwan ngayon. Ihambing ang mga timestamp sa sandaling lumitaw ang prompt; ang pagtutugma ay nagpapatunay na ang timer ang dahilan, hindi ang network.

Ano ang iuulat, at ano ang hindi dapat patayin

Kung nagtagumpay ang manu-manong pag-log in at palaging nabigo ang awtomatikong muling paggamit, sabihin iyon nang eksakto sa operator. Pinangalanan nito ang component: ang landas ng muling paggamit, hindi ang kredensyal. Isama ang oras ng pagpalya, ang account na ginagamit at ang uri ng prompt na nakita mo.

Huwag patayin ang pangalawang factor, huwag laktawan ang validation ng certificate at huwag idikit ang mga kredensyal sa isang script upang gawing tahimik ang muling pagkonekta. Ang bawat isa sa mga ito ay nag-aalis ng pagsusuring umiiral ang patakaran upang ipatupad, at ang bawat isa ay ginagawang insidente ang isang prompt sa pag-log in.

Hilingin sa halip ang sinusuportahang daloy: isang kliyenteng kayang tapusin ang hamon, haba ng buhay ng token na tugma sa araw ng trabaho, o naaprubahang hindi interactive na profile para sa makinang hindi makapagtanong. Lahat ng iyon ay desisyon sa configuration na maaaring aprubahan ng isang tao, na hindi isang pansamantalang solusyon.