Pemasa sesi VPN dan token pengesahan tamat tempoh secara berasingan

Terputusnya VPN boleh berlaku atas sebab yang kelihatan sama dari sisi klien dan tidak berkongsi apa-apa di bawahnya: sesi terowong tamat, pemasa melahu tercetus, atau kelayakan yang digunakan semula oleh klien menjadi lapuk. Setiap satu mempunyai pemilik dan pembaikan berbeza. Urutan ralat pada saat terputus itulah yang memisahkannya, dan biasanya ia satu baris.

Tiga jam berjalan melawan satu terowong, dan hanya satu daripadanya ialah terowong itu.

Tiga jam berbeza pada satu terowong

Jam sesi milik gateway: tempoh sambungan maksimum, had masa melahu atau kedua-duanya, dan ia menamatkan terowong apabila mana-mana satu dicapai. Jam token milik sistem pengesahan, dan ia menentukan berapa lama kelayakan boleh dikemukakan semula tanpa manusia. Jam laluan milik mana-mana NAT atau tembok api antara klien dan gateway, dan ia membiarkan pemetaan tamat tempoh bagi aliran yang dianggap selesai. Ketiga-tiganya menghasilkan pemutusan, dan tiada satu pun menghasilkan baris log yang sama.

Hanya yang pertama ialah konsep VPN. Dua lagi dipinjam daripada identiti dan rangkaian, dan ia sering dikelirukan dengannya.

Bagaimana token sebenarnya diguna semula

Pelayan OpenVPN boleh mengeluarkan token pengesahan selepas log masuk awal, jadi rundingan semula saluran kawalan tidak meminta kelayakan pengguna lagi. Klien terus mengemukakan token itu dan pelayan menentukan berapa lama ia kekal boleh diterima. Apabila jangka hayat token lebih pendek daripada selang rundingan semula, rundingan semula berikutnya gagal dan klien melaporkan ralat pengesahan dan bukan had masa. Itulah sebabnya profil yang sama berfungsi selama satu jam dan kemudian gagal pada titik tetap.

Selang rundingan semula ialah tetapan berasingan. Mengubahnya mengalihkan bila token dikemukakan, bukan berapa lama ia hidup.

Bagaimana setiap tamat tempoh kelihatan dari klien

Had masa sesi biasanya datang sebagai pemutusan bersih dengan sebab dari pihak pelayan, selalunya selepas tempoh yang boleh dijangka dan tanpa ralat pengesahan. Had masa melahu kelihatan seperti kesenyapan: terowong berhenti membawa trafik, kemudian keepalive mengalah. Tamat tempoh token datang sebagai AUTH_FAILED di tengah-tengah sesi yang berfungsi sesaat sebelumnya.

Baca baris itu, kemudian lihat jam. Tempoh yang sepadan dengan nilai yang dikonfigurasikan bukan kebetulan.

Mengapa kata laluan yang disimpan tidak membantu

Kata laluan dalam cache menjawab cabaran untuk kata laluan. Ia tidak memanjangkan jangka hayat token dan tidak memenuhi cabaran faktor kedua atau semakan keadaan peranti. Meningkatkan kekerapan cubaan semula, memendekkan had masa sambungan atau mengimport semula profil tidak mengubah apa-apa tentang berapa lama sistem identiti akan menerima kelayakan itu.

Pembaikan yang tahan lama ialah jangka hayat yang betul pada objek yang betul, atau aliran klien yang boleh melengkapkan cabaran yang diperlukan tanpa manusia.

Apa yang perlu didokumen dan diuji

Tuliskan ketiga-tiga nilai: had sesi dan melahu gateway, jangka hayat token dan had masa pemetaan terpendek yang relevan pada laluan. Kemudian uji setiap tamat tempoh dengan sengaja dengan memendekkan satu nilai, memerhati apa yang dilaporkan klien, dan memulihkannya. Sahkan apa yang pengguna mesti lakukan pada setiap sempadan, kerana menuntut log masuk penuh setiap jam ialah keputusan dasar yang sepatutnya diambil dengan sengaja.

Pemutusan yang datang tanpa sebarang peristiwa pengesahan tergolong dalam laluan atau pemasa melahu, dan itu ialah siasatan lain dengan bukti lain.