Mengapa Koneksi Ulang VPN Kembali Meminta Kredensial
Kata sandi tersimpan dan token yang dapat digunakan ulang kedaluwarsa menurut jadwal berbeda. Baca materi mana yang diminta koneksi ulang sebelum mengubah apa pun di klien.
Terowongan yang bekerja selama berjam-jam meminta kata sandi pada saat laptop bangun, dan tidak ada yang berubah dalam konfigurasi. Yang berubah adalah keadaan kredensial yang coba digunakan ulang oleh koneksi ulang itu. Tiga jenis materi mengaturnya, dan hanya satu yang bertahan melewati jeda sembarang.
Baca mana yang diminta klien, karena ketiganya kedaluwarsa menurut jam berbeda dan gagal dengan pesan berbeda.
Tiga jenis materi yang dapat digunakan ulang
Kata sandi yang di-cache adalah rahasia yang dipegang klien, dan tetap berlaku sampai akun mengubahnya. Token sesi diterbitkan server setelah login berhasil, membawa masa hidupnya sendiri dan dapat dicabut kapan saja. Tiket sesi TLS atau asosiasi keamanan IKE adalah keadaan protokol, murah untuk dilanjutkan dan sepenuhnya independen dari kata sandi Anda. Masing-masing diterbitkan komponen berbeda, dan masing-masing kedaluwarsa dengan syaratnya sendiri.
Yang pertama bertahan melewati reboot, yang kedua biasanya bertahan melewati suspend, dan yang ketiga mungkin tidak bertahan sama sekali melewati perubahan jaringan. Mencampuradukkannya menghasilkan perbaikan yang salah, seperti mengatur ulang kata sandi yang tidak pernah ditolak.
Prompt itu sendiri adalah diagnosisnya. Jendela peramban atau kode faktor kedua berarti server menuntut autentikasi interaktif, sedangkan kegagalan senyap tanpa prompt berarti klien tidak pernah cukup jauh untuk ditanya.
| Material | Typical lifetime | What invalidates it |
|---|---|---|
| Cached password | Until changed | Account or password policy change |
| Session token | Minutes to hours | Expiry, revocation, reauthentication policy |
| Tunnel SA or TLS ticket | Configured rekey interval | Rekey, network change, peer restart |
Pembaruan kunci bukan autentikasi ulang
Pembaruan kunci mengganti kunci sambil mempertahankan identitas yang terautentikasi, itulah sebabnya hal itu terjadi diam-diam sesekali pada terowongan yang sehat. Autentikasi ulang mengulang pemeriksaan identitas itu sendiri, dan itulah peristiwa yang membutuhkan Anda. IKEv2 memisahkan keduanya secara eksplisit, dan peer dapat menuntut autentikasi ulang penuh pada interval tertentu terlepas dari berapa banyak pembaruan kunci yang terjadi di antaranya. Kedua peristiwa tampak identik dari luar sampai Anda membaca mana yang disebut log.
OpenVPN berperilaku sama dalam kosakatanya sendiri: interval negosiasi ulang menyegarkan kanal data, dan token autentikasi dapat dikembalikan ke klien untuk menghindari login penuh pada koneksi berikutnya. Token itu punya masa hidup, dan server yang memutuskan apakah menerimanya lagi.
Jadi koneksi ulang setelah delapan jam bisa gagal di tempat koneksi ulang setelah delapan menit berhasil, tanpa perubahan konfigurasi di kedua sisi. Itulah seluruh penjelasan atas prompt yang hanya muncul setelah makan siang.
Ketika klien tidak dapat menyelesaikan tantangan baru
Kebijakan yang menuntut langkah peramban akan gagal pada klien yang tidak punya cara menampilkannya. Server tanpa antarmuka, skrip startup, dan profil lama yang dibangun untuk autentikasi hanya kata sandi semuanya menabrak dinding itu, dan kegagalan sering muncul sebagai batas waktu umum alih-alih kesalahan autentikasi.
Perpindahan perangkat dan jaringan juga dapat jatuh di dalam jendela evaluasi kebijakan, sehingga roaming dari Wi-Fi ke hotspot bertepatan dengan pemeriksaan yang akan terjadi pula. Kebetulan itu membuat jaringan tampak bersalah padahal penyebabnya pengatur waktu.
openvpn --config client.ovpn --verb 3 2>&1 | grep -i -E "reneg|auth" ipsec statusall | grep -i -E "rekey|reauth"
Baris pertama menampilkan peristiwa negosiasi ulang dan autentikasi di log klien sendiri, dan baris kedua menampilkan asosiasi keamanan yang dipegang peer strongSwan saat ini. Bandingkan stempel waktu dengan saat prompt muncul; kecocokan menegaskan pengatur waktu, bukan jaringan.
Apa yang dilaporkan, dan apa yang tidak boleh dimatikan
Jika login manual berhasil dan penggunaan ulang otomatis terus gagal, katakan persis itu kepada operator. Itu menyebut komponennya: jalur penggunaan ulang, bukan kredensialnya. Sertakan waktu kegagalan, akun yang dipakai, dan jenis prompt yang Anda lihat.
Jangan menonaktifkan faktor kedua, melewati validasi sertifikat, atau menempelkan kredensial ke skrip agar koneksi ulang menjadi senyap. Masing-masing menghapus pemeriksaan yang ada agar kebijakan ditegakkan, dan masing-masing mengubah prompt login menjadi insiden.
Mintalah alur yang didukung sebagai gantinya: klien yang dapat menyelesaikan tantangan, masa hidup token yang cocok dengan hari kerja, atau profil non-interaktif yang disetujui untuk mesin yang tidak dapat meminta. Itu semua keputusan konfigurasi yang dapat disetujui seseorang, yang bukan merupakan akal-akalan.