27850, 442 dan 651: satu tindanan, tiga pemeriksaan pertama

Pemasang berhenti pada 27850, sambungan ditolak dengan 442, dan profil lain memulangkan 651. Nombor-nombor itu kelihatan seperti tiga kerosakan berasingan, dan tindak balas biasa ialah memasang semula klien tiga kali. Tetapi semuanya datang daripada satu subsistem: penyesuai maya dan tindanan penapis di sekelilingnya. Nombor ralat memberitahu lapisan mana yang gagal, dan itulah yang menentukan pemeriksaan pertama. Memasang semula sebelum membaca nombor biasanya menghasilkan semula kerosakan yang sama.

Padankan nombor dengan lapisan

Setiap ralat timbul pada titik berbeza, jadi pemeriksaan pertama berbeza walaupun gejala yang kelihatan ialah sambungan ditolak yang sama. Tiga keluarga meliputi setiap kes: pemasang, penyesuai dan port di bawahnya. Jadual di bawah meletakkan setiap nombor di sebelah pemeriksaan yang diperlukan.

Jika ralat muncul sebelum mana-mana profil dipilih, ia milik keluarga pemasang. Jika ia muncul apabila klien cuba menaikkan penyesuai, ia milik keluarga penyesuai. Jika penyesuai kelihatan tetapi port tidak pernah dibuka, itu keluarga miniport. Catat nombor sebelum mengubah apa-apa. Ketiga-tiga pembaikan menyentuh bahagian tindanan yang berbeza, dan perubahan untuk keluarga yang salah menjadikan percubaan seterusnya lebih sukar dibaca.

Tindanan penapis penuh, atau suite keselamatan yang menyekat pemacu

Memasang klien mendaftarkan komponen penapis kecil dalam rantaian penyesuai. Windows mempunyai had keras berapa banyak komponen sebegitu boleh diikat, dan nilai lalai meninggalkan sedikit ruang apabila ada antivirus, jambatan virtualisasi dan pemacu tangkapan. Pemasangan kemudian gagal dengan 27850 walaupun pakej VPN elok. Pemasang tidak dapat membezakan tindanan penuh daripada yang rosak.

Baca nilai semasa, naikkan, dan mulakan semula sebelum mencuba lagi. Penapis baharu tidak boleh diikat sehingga tindanan dibina semula:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters /t REG_DWORD /d 14 /f

Punca lain ialah suite keselamatan yang menyekat pemasangan pemacu tanpa gesaan yang kelihatan. Ciri pertahanan dirinya boleh menghalang penapis daripada mendaftar, jadi pemasang melaporkan kegagalan komponen umum. Semak log suite itu sendiri, dan jika pertahanan diri menjadi penghalang, matikannya hanya untuk tetingkap pemasangan dan pulihkan semula sejurus selepas itu. Jika nilai sudah dinaikkan dan tiada suite menyekat, cari pemacu penapis yatim daripada produk VPN terdahulu. Penapis lama yang tidak lagi mempunyai perkhidmatan sepadan masih mengisi satu slot dan boleh menggagalkan pemasangan baharu.

Penyesuai ada dan kekal di bawah

Ralat 442 bermaksud penyesuai maya ada tetapi klien tidak dapat menaikkannya. Pemeriksaan pertama ialah Pengurus Peranti dengan peranti tersembunyi dipaparkan: penyesuai dilumpuhkan, penyesuai dengan tanda amaran dan penyesuai yang hilang kelihatan sama dalam klien tetapi memerlukan pembaikan berbeza. Internet Connection Sharing sering memegangnya. Jika perkhidmatan telah mengambil penyesuai, hentikan perkhidmatan dan cuba lagi sebelum menyentuh registri. Konfigurasi perkongsian yang tertinggal boleh mengambilnya semula selepas dimulakan semula, jadi catat sama ada pembaikan itu kekal selepas dimulakan semula.

Pemasangan semula boleh meninggalkan nama paparan cacat yang menjadikan penyesuai tidak terurus. Nilai itu hendaklah teks biasa, bukan token pemasang yang belum diselesaikan:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName -Value "Cisco Systems VPN Adapter for 64-bit Windows"

Gunakan nama paparan yang dijangka oleh klien anda, kemudian mulakan semula supaya penyesuai disenaraikan semula. Menetapkan nilai tanpa memulakan semula biasanya meninggalkan keadaan lama dan sambungan seterusnya memberi 442 lagi.

Port di bawahnya tidak pernah dibuka

Ralat 651 dilaporkan apabila pengurus sambungan tidak dapat membuka miniport WAN. Penyesuai mungkin kelihatan sihat dalam klien manakala port di bawahnya tidak pernah mencapai keadaan dimulakan. Senaraikan miniport dan statusnya sebelum memasang semula apa-apa:

Get-PnpDevice -Class Net | Where-Object { $_.FriendlyName -like "*WAN Miniport*" } | Select-Object Status, FriendlyName

Miniport dengan status ralat ialah petunjuk langsung. Memasang semula dari Pengurus Peranti mencipta semula port, dan itulah sebabnya pembaikan ini berkesan apabila pemasangan semula klien tidak. Pemacu pihak ketiga yang diikat pada penyesuai fizikal ialah punca biasa yang lain. Pemacu rangkaian jambatan VirtualBox, pemacu TAP tinggalan daripada OpenVPN atau penapis tangkapan boleh mengambil port itu dahulu. Menyahtanda komponen semasa pemasangan tidak mencukupi apabila pemacu sudah diikat; ia mesti dibuang daripada sifat penyesuai atau dinyahpasang daripada stor pemacu.

Melumpuhkan IPv6 pada sambungan VPN telah menyelesaikan ralat ini pada sesetengah binaan, tetapi anggapnya sebagai ujian dan bukan reka bentuk kekal. Jika sambungan hanya bermula dengan IPv6 dilumpuhkan, miniport atau pemacu di bawahnya masih menjadi punca.

Ubah satu lapisan dan simpan buktinya

Simpan nilai registri yang anda ubah, catat senarai penyesuai dan penapis sebelum dan selepas, dan mulakan semula antara percubaan. Permulaan semula ialah bahagian pembaikan bagi setiap keluarga di sini, kerana tindanan penyesuai dibina semasa but dan memulakan semula perkhidmatan tidak membinanya semula.

Pasang semula klien hanya selepas penyesuai, penapis dan miniport lama hilang. Memasang klien baharu di atas tindanan rosak ialah cara 27850 yang boleh dibaiki bertukar menjadi mesin dengan dua penyesuai separa berdaftar dan tanpa ralat yang jelas. Berhenti dan eskalasi apabila ralat yang sama bertahan dua kali pada pemeriksaan khusus lapisan. Pada ketika itu langkah seterusnya yang berguna ialah semakan tindanan rangkaian bersih dengan log pemasang daripada vendor, bukan percubaan lain pemasangan semula yang sama.