OpenVPN di Windows: mulai terowongan otomatis dan pertahankan rute

Ada dua persyaratan yang bertaut di sini: terowongan harus naik sebelum siapa pun masuk, dan lalu lintas ke situs kedua harus mengikutinya. Keduanya masalah terpisah dengan mekanisme terpisah. Mulainya layanan menentukan yang pertama, dan masa hidup rute menentukan yang kedua. Menyelesaikan satu membiarkan yang lain persis di tempatnya.

Langkah satu: letakkan profil di tempat layanan mencarinya

Layanan Windows membaca profil dari direktori tetap, dan GUI membaca dari tempat yang sama, jadi profil yang berfungsi saat Anda mengimpornya bisa tetap tak terlihat saat boot. Letakkan berkas .ovpn di direktori config instalasi, yang biasanya berada di bawah Program Files. Profil yang dibiarkan di folder Downloads pengguna sama sekali tidak masuk cakupan layanan.

Panduan lama menunjuk folder config-auto, yang dihormati sebagian build era 2.5 dan tidak oleh rilis berikutnya. Itu sebabnya peningkatan versi bisa mengubah autostart yang berfungsi menjadi keheningan, tanpa apa pun di log tentang kredensial. Pastikan direktori mana yang benar-benar dibaca build terpasang sebelum memindahkan berkas.

Dengan beberapa profil di satu mesin, beri masing-masing adaptor bernama melalui dev-node. Jika tidak, mereka bersaing untuk antarmuka yang sama dan yang kedua gagal dengan cara yang tampak seperti masalah kredensial.

Langkah dua: jalankan layanan, bukan ikon baki

Menyetel layanan OpenVPN ke Automatic membuatnya mulai saat boot tanpa login. Itulah mekanismenya, dan ikon baki bukan bagian darinya. Saat layanan memiliki koneksi, GUI mungkin tidak menampilkan ikon maupun status, yang merupakan hal yang wajar dan bukan kerusakan.

Konsekuensinya, memutus koneksi berarti menghentikan layanan, bukan mengeklik Disconnect. Beri tahu siapa pun yang mendukung mesin itu, atau panggilan dukungan pertama akan soal ikon yang hilang.

Periksa bahwa akun layanan dapat membaca profil dan materi kunci. Masalah izin saat boot di log tampak persis seperti kegagalan autentikasi.

Langkah tiga: ikat rute ke terowongan

Entri permanen adalah alat yang salah di sini. Menambahkan rute dengan -P membuatnya bertahan dari reboot dan, lebih buruk, bertahan dari penutupan terowongan. Saat VPN mati, prefiks masih menunjuk gateway yang sudah tidak ada, sehingga host tidak dapat mencapai tujuan itu sampai seseorang menghapus entrinya.

Tiga alternatif berperilaku benar. Dorong rute dari server, yang menambahkannya saat terhubung dan menghapusnya saat terputus. Tambahkan di skrip route-up yang membaca route_vpn_gateway, sehingga lompatan berikutnya datang dari terowongan yang dinegosiasikan. Atau gunakan Add-VpnConnectionRoute dengan profil VPN asli Windows, yang mengikat prefiks ke koneksi itu.

Saat server menawarkan lebih dari yang dibutuhkan situs ini, route-nopull menolak rute yang didorong dan membiarkan tabel sepenuhnya lokal. Itu cocok untuk profil bersama yang penggunanya tidak boleh menerima rute default korporat.

Langkah empat: bertahan dari boot dingin

Memulai layanan sebelum tumpukan jaringan ada menghasilkan satu percobaan gagal dan tanpa percobaan ulang. Menyetelnya ke Automatic (Delayed Start), atau menambahkan dependensi pada layanan jaringan, menghilangkan balapan itu. Lalu ulangi uji boot dan pastikan percobaan kedua tidak lagi diperlukan.

Perubahan rute dan adaptor memerlukan hak administrator. Pintasan startup per pengguna tidak memilikinya, jadi skrip yang berfungsi dari shell yang ditingkatkan bisa diam-diam tidak melakukan apa pun saat login. Jadwalkan sebagai tugas dengan hak tertinggi, atau biarkan layanan mengambil alih perubahan. Lalu uji sebagai pengguna yang benar-benar akan login.

Uji urutan yang benar-benar Anda terapkan, bukan yang bisa Anda picu dengan tangan. Boot dingin adalah satu-satunya uji yang melatih urutan itu.

Langkah lima: verifikasi tanpa GUI

Setelah reboot dan login, periksa tiga hal tanpa membuka GUI. Adaptor harus memegang alamat,tabel rute harus menampilkan prefiks situs dengan gateway terowongan sebagai lompatan berikutnya, dan ping ke alamat di sisi jauh harus menjawab. Setiap pemeriksaan memetakan ke mekanisme berbeda dari langkah di atas.

Saat adaptor tidak pernah muncul, tersangka adalah pengandar dan bukan profil. Kedua kegagalan itu sama sekali tidak mirip di log, dan hanya satu di antaranya yang merespons pemasangan ulang perangkat lunak.