RRAS mulai sebelum tunnel OpenVPN siap saat boot

Server reboot, OpenVPN mulai, dan RRAS naik sementara adapter atau rute yang menjadi dependensinya masih hilang. Me-restart RRAS secara manual satu menit kemudian memperbaikinya, sehingga masalah tampak selesai dan yang sebenarnya tersembunyi. Dua kondisi berbeda tertukar di sini: layanan prasyarat sedang berjalan, dan sumber daya jaringan yang benar-benar dibutuhkan RRAS sudah dapat digunakan. Dependensi layanan Windows dapat menyatakan kondisi pertama dan tidak pernah yang kedua, jadi menambahkannya tanpa mendefinisikan sumber daya memberi Anda boot yang tampak lebih rapi dan kegagalan yang sama.

Seperti apa gejalanya saat boot dingin

Petunjuknya adalah perbedaan antara boot dingin dan restart. Saat boot dingin RRAS melaporkan dirinya berjalan sementara adapter tunnel tidak ada, rute hilang, atau alamat peer belum terurai. Restart manual kemudian berhasil karena saat itu sumber daya sudah ada, dan layanan hanya membaca ulang dunia yang satu menit sebelumnya tidak dapat dilihatnya. Log layanan akan menunjukkan start yang bersih pada kedua kasus, itulah sebabnya Event Viewer saja jarang menjelaskan ini.

Catat kedua keadaan sebelum mengubah apa pun: apa yang dilaporkan RRAS saat boot, dan apa yang ada pada saat restart manual berhasil. Jika kedua pengamatan itu identik, urutan boot bukan penjelasan Anda dan dependensi tidak akan membantu. Perbandingan itu memakan sepuluh menit dan menghemat sepekan tebakan.

Dependensi yang ditambahkan atas dasar „berfungsi setelah restart“ hanya menunda kegagalan yang sama selama waktu yang dibutuhkan layanan prasyarat untuk melaporkan RUNNING. Itu juga membuat boot lebih sulit dipahami, karena batasan urutan kini tampak seperti penjelasan. Tanyakan objek apa yang dijamin dependensi itu dan apakah objek itulah yang tidak dapat dilihat RRAS.

Sebutkan sumber dayanya, bukan hanya layanannya

Tuliskan hal spesifik yang hilang. Bisa berupa adapter tunnel dengan alamat, rute ke subnet peer, jawaban DNS, atau sertifikat yang masih disediakan. „Layanan VPN berjalan“ bukan deskripsi sumber daya, dan ikon hijau di klien juga bukan. Sampai Anda dapat menyebutkan objek dan perintah yang menunjukkannya, Anda belum mendefinisikan kondisi yang coba Anda tunggu.

Tetapkan juga bagaimana instans OpenVPN ini diluncurkan. Tunnel yang dikelola GUI dan tunnel yang dikelola layanan memiliki siklus hidup boot berbeda, dan nama layanan harus berasal dari mesin di depan Anda, bukan dari contoh yang ditulis untuk installer lain. Daftarkan kandidatnya alih-alih memercayai nama yang diingat.

Get-Service | Where-Object Name -match 'vpn|openvpn' | Select-Object Name, Status, StartType

Baca rantai dependensi sebelum menambahkannya

Service Control Manager melaporkan status seperti START_PENDING dan RUNNING, dan SERVICE_STATUS reference mendefinisikan persis apa arti setiap bidang. Tidak satu pun status itu menjanjikan bahwa peer, nama DNS, atau aplikasi hilir dapat dijangkau. Celah itulah seluruh alasan kegagalan ini bertahan terhadap dependensi yang dikonfigurasi dengan benar.

Get-Service -Name RemoteAccess | Select-Object Status, StartType
sc.exe qc RemoteAccess
Get-Service -Name RemoteAccess | Select-Object -ExpandProperty DependentServices

Baris DEPENDENCIES dari sc.exe qc adalah daftar yang harus Anda pertahankan, karena sc.exe config RemoteAccess depend= mengganti seluruh daftar, bukan menambahkannya. Menghilangkan prasyarat tak terkait saat menambahkan layanan VPN menciptakan kesalahan kedua yang muncul pada boot lain, dan jauh lebih sulit didiagnosis daripada yang asli. Salin daftar yang ada ke catatan perubahan Anda sebelum menyentuhnya.

Dependensi juga mengubah perilaku shutdown, karena menghentikan prasyarat menghentikan layanan yang bergantung padanya. Periksa apa yang terjadi selama pemeliharaan sebelum menghubungkan RRAS ke sesuatu yang sering restart.

Gantungkan restart pada kondisi, bukan pada pengatur waktu

Jeda tetap mengasumsikan tunnel akan selalu siap dalam jendela itu, dan itulah tepatnya asumsi yang gagal pada boot ketika sertifikat lambat atau tautan mati. Periksa sumber dayanya sendiri, dengan tenggat, dan biarkan pemeriksaan memutuskan apakah restart sama sekali diperlukan.

Get-NetAdapter | Where-Object Status -eq 'Up'
Get-NetRoute -DestinationPrefix 0.0.0.0/0
Get-WinEvent -LogName System -MaxEvents 40 |
  Where-Object ProviderName -eq 'Service Control Manager'

Tugas terjadwal saat boot yang menjalankan pemeriksaan itu dan me-restart RRAS hanya ketika adapter atau rute masih hilang bersifat terbatas, dapat diaudit, dan mudah dihapus. Alternatifnya, me-restart RRAS pada setiap penyambungan ulang, mengganggu sesi sehat dan mengubah tautan tidak stabil menjadi lingkaran restart. Lingkaran itu lebih buruk daripada kegagalan asli, karena kini mengenai pengguna yang tadinya baik-baik saja.

Beri pemeriksaan itu batas tunggu maksimum yang cocok dengan waktu yang wajar dibutuhkan tunnel pada perangkat keras Anda, dan buat tugas keluar dengan status bukan nol ketika menyerah. Tugas senyap yang sekadar berhenti mencoba tidak dapat dibedakan dari tugas yang berhasil.

Catat transisinya agar boot berikutnya menjelaskan dirinya sendiri

Catat tiga stempel waktu pada baris yang sama: kapan layanan dependensi mencapai RUNNING, kapan sumber daya yang diperlukan muncul, dan kapan RRAS akhirnya menerimanya. Satu baris itu menjawab pertanyaan yang akan diajukan insinyur berikutnya, dan membuatnya hampir tidak memakan biaya. Tanpanya, penyelidikan berikutnya dimulai dari tebakan yang sama dengan yang ini.

Hentikan otomatisasi setelah jumlah percobaan tertentu dan laporkan kegagalan alih-alih mencoba ulang selamanya. Boot yang berakhir dengan pesan jelas „sumber daya tidak pernah muncul“ bernilai lebih daripada yang terus me-restart layanan dalam gelap. Saat pesan itu muncul, nama sumber daya yang Anda tulis di bagian kedua adalah yang akan dicari orang berikutnya.