Pelayan but semula, OpenVPN bermula, dan RRAS naik sementara penyesuai atau laluan yang menjadi kebergantungannya masih tiada. Memulakan semula RRAS secara manual seminit kemudian membaikinya, yang membuat masalah kelihatan selesai dan menyembunyikan yang sebenar. Dua keadaan berbeza dicampuradukkan di sini: perkhidmatan prasyarat sedang berjalan, dan sumber rangkaian yang benar-benar diperlukan RRAS telah menjadi boleh digunakan. Kebergantungan perkhidmatan Windows boleh menyatakan keadaan pertama dan tidak pernah yang kedua, jadi menambahnya tanpa mentakrifkan sumber memberi anda but yang kelihatan lebih kemas dan kegagalan yang sama.

Rupa gejala semasa but sejuk

Petunjuknya ialah perbezaan antara permulaan sejuk dan mula semula. Semasa permulaan sejuk RRAS melaporkan dirinya berjalan sementara penyesuai terowong tiada, laluan hilang, atau alamat rakan sejawat belum diselesaikan. Mula semula manual kemudian berjaya kerana pada masa itu sumber sudah ada, dan perkhidmatan hanya membaca semula dunia yang tidak dapat dilihatnya seminit lebih awal. Log perkhidmatan akan menunjukkan permulaan bersih dalam kedua-dua kes, sebab itulah pemapar peristiwa sahaja jarang menjelaskan perkara ini.

Rakam kedua-dua keadaan sebelum mengubah apa-apa: apa yang dilaporkan RRAS semasa but, dan apa yang wujud pada saat mula semula manual berjaya. Jika kedua-dua pemerhatian itu sama, urutan permulaan bukan penjelasan anda dan kebergantungan tidak akan membantu. Perbandingan itu mengambil sepuluh minit dan menjimatkan seminggu meneka.

Kebergantungan yang ditambah atas dasar „ia berfungsi selepas mula semula“ hanya melengahkan kegagalan yang sama selama masa yang diambil perkhidmatan prasyarat untuk melaporkan RUNNING. Ia juga menjadikan but lebih sukar difahami, kerana kekangan urutan kini kelihatan seperti penjelasan. Tanya objek apa yang dijamin oleh kebergantungan itu dan sama ada objek itulah yang tidak dapat dilihat RRAS.

Namakan sumber, bukan hanya perkhidmatan

Tulis perkara khusus yang hilang. Ia mungkin penyesuai terowong dengan alamat, laluan ke subnet rakan sejawat, jawapan DNS, atau sijil yang masih diperuntukkan. „Perkhidmatan VPN berjalan“ bukan huraian sumber, dan ikon hijau dalam klien juga bukan. Sehingga anda boleh menamakan objek dan arahan yang menunjukkannya, anda belum mentakrifkan keadaan yang anda cuba tunggu.

Tentukan juga bagaimana instans OpenVPN ini dilancarkan. Terowong yang diuruskan GUI dan terowong yang diuruskan perkhidmatan mempunyai kitaran hayat but yang berbeza, dan nama perkhidmatan mesti datang dari mesin di hadapan anda, bukan daripada contoh yang ditulis untuk pemasang lain. Senaraikan calon dan bukan mempercayai nama yang diingati.

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

Baca rantaian kebergantungan sebelum menambahnya

Pengurus Kawalan Perkhidmatan melaporkan keadaan seperti START_PENDING dan RUNNING, dan SERVICE_STATUS reference mentakrifkan dengan tepat apa maksud setiap medan. Tiada satu pun keadaan itu menjanjikan rakan sejawat, nama DNS atau aplikasi hiliran boleh dicapai. Jurang itulah seluruh sebab kegagalan ini bertahan terhadap kebergantungan yang dikonfigurasi dengan betul.

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

Baris DEPENDENCIES daripada sc.exe qc ialah senarai yang mesti anda kekalkan, kerana sc.exe config RemoteAccess depend= menggantikan seluruh senarai dan bukan menambahnya. Menggugurkan prasyarat yang tidak berkaitan semasa menambah perkhidmatan VPN mencipta kesalahan kedua yang muncul pada but lain, dan ia jauh lebih sukar didiagnosis daripada yang asal. Salin senarai sedia ada ke dalam rekod perubahan anda sebelum menyentuhnya.

Kebergantungan juga mengubah tingkah laku penutupan, kerana menghentikan prasyarat menghentikan perkhidmatan yang bergantung padanya. Periksa apa yang berlaku semasa penyelenggaraan sebelum menyambungkan RRAS kepada sesuatu yang sering dimulakan semula.

Jadikan mula semula bergantung pada keadaan, bukan pemasa

Tunggu tetap menganggap terowong akan sentiasa sedia dalam tetingkap itu, dan itulah tepat andaian yang gagal pada but apabila sijil lambat atau pautan terputus. Periksa sumber itu sendiri, dengan had masa, dan biarkan pemeriksaan memutuskan sama ada mula semula 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 berjadual semasa but yang menjalankan pemeriksaan itu dan memulakan semula RRAS hanya apabila penyesuai atau laluan masih tiada adalah terhad, boleh diaudit dan mudah dibuang. Alternatifnya, memulakan semula RRAS pada setiap sambungan semula, mengganggu sesi sihat dan mengubah pautan tidak stabil menjadi gelung mula semula. Gelung itu lebih teruk daripada kegagalan asal, kerana kini ia menjejaskan pengguna yang selama ini baik.

Berikan pemeriksaan itu tunggu maksimum yang sepadan dengan masa yang terowong ambil secara munasabah pada perkakasan anda, dan biarkan tugas keluar dengan status bukan sifar apabila ia mengalah. Tugas senyap yang sekadar berhenti mencuba tidak dapat dibezakan daripada tugas yang berjaya.

Log peralihan itu supaya but seterusnya menjelaskan dirinya

Rakam tiga cap masa pada baris yang sama: bila perkhidmatan kebergantungan mencapai RUNNING, bila sumber yang diperlukan muncul, dan bila RRAS akhirnya menerimanya. Baris tunggal itu menjawab soalan yang akan ditanya jurutera seterusnya, dan menghasilkannya hampir tidak berkos. Tanpanya, siasatan seterusnya bermula daripada tekaan yang sama seperti ini.

Hentikan automasi selepas bilangan percubaan yang ditetapkan dan laporkan kegagalan dan bukan mencuba semula selamanya. But yang berakhir dengan mesej jelas „sumber itu tidak pernah muncul“ lebih bernilai daripada yang terus memulakan semula perkhidmatan dalam gelap. Apabila mesej itu muncul, nama sumber yang anda tulis dalam bahagian kedua ialah apa yang akan dicari oleh orang seterusnya.

Artikel berkaitan