Handshake berjaya, internet tidak: apa yang perlu dibetulkan dahulu pada Windows 11

Pada Windows 11, handshake baharu sering berdiri di sebelah pelayar yang tidak membuka apa-apa. Handshake hanya membuktikan pertukaran UDP dengan rakan setara selesai. Ia tidak menyatakan apa-apa tentang laluan yang dipasang Windows, resolver yang digunakannya, atau sama ada laluan keluar memajukan apa-apa.

Empat syarat menentukan lapisan mana yang gagal. Menelitinya mengikut urutan mengambil masa beberapa minit, manakala menulis semula kunci mengambil masa lebih lama dan tidak mengubah apa-apa.

Tentukan lapisan sebelum menyentuh kunci

Lalui tiga destinasi, mengikut urutan ini. Mulakan dengan alamat di sebelah terowong, kemudian IP awam sebagai nombor, dan akhiri dengan nama hos. Di tempat rantaian itu putus, di situ lapisan dinamakan. Kegagalan pada langkah pertama ialah penghalaan, pada yang kedua ialah pemajuan atau NAT, dan pada yang ketiga ialah penyelesaian nama.

Urutan itu ialah keseluruhan kaedah. Ia menghalang kerosakan DNS daripada didiagnosis sebagai terowong rosak, yang merupakan kesilapan hala tuju paling biasa di sini.

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

Jika masa handshake kosong

Apabila masa handshake kosong, pertukaran yang disulitkan tidak pernah selesai. Jadi kerosakan itu terletak lebih awal daripada penghalaan. Lihat alamat titik hujung dan port dahulu, kemudian sama ada rangkaian menapis UDP. Penyedia pengehosan yang menggugurkan trafik WireGuard menghasilkan perkara ini, begitu juga klien yang menyalin titik hujung daripada profil lama.

Bait yang keluar tanpa ada yang masuk ialah kes lain. Itu menunjuk kepada NAT atau firewall yang memulangkan trafik ke tempat yang salah.

Jika laluan tewas kepada penyesuai fizikal

Untuk terowong penuh, bahagian rakan setara mesti meliputi destinasi yang anda jangkakan untuk digunakan. Windows kadangkala mengekalkan laluan lalai penyesuai fizikal walaupun peraturan menyeluruh telah ditetapkan. Memecahkan peraturan menyeluruh kepada 0.0.0.0/1 tambah 128.0.0.0/1 mencipta dua awalan yang lebih khusus yang memenangi carian. Pemecahan itu ialah penyelesaian jalan pintas yang didokumenkan, bukan keutamaan.

Sahkan dengan route print atau carian alamat awam. Antara muka yang dipilih sepatutnya penyesuai terowong. Jika yang fizikal masih menang, betulkan julat rakan setara sebelum menyentuh pelayan.

Jika alamat berfungsi dan nama gagal

WireGuard membawa paket IP dan tidak mempunyai pendapat tentang DNS. Letakkan baris DNS = dalam bahagian antara muka, atau tetapkan penyesuai melalui Windows. Tanpanya, ping mengikut alamat berjaya manakala setiap nama hos gagal, dan pengguna melaporkannya sebagai tiada internet.

Semak pelayan mana yang sebenarnya digunakan Windows selepas bersambung. Resolver yang tertinggal pada penyesuai fizikal menjelaskan kegagalan separa, apabila sesetengah nama diselesaikan dan yang lain tidak. Bersihkannya daripada menambah yang kedua di atasnya.

Jika mesin Windows ialah laluan keluar

Internet Connection Sharing menulis semula pengalamatan apabila dihidupkan, yang boleh memindahkan penyesuai dikongsi ke julat lain. Klien yang masih menunjuk ke alamat asal kemudian berhenti berfungsi. Nilai registri ScopeAddress dan StandaloneDHCPAddress mengawal julat itu, dan tetapan boleh kembali selepas but semula.

Dua konflik lain khusus Windows wajar dilihat. Perkhidmatan Routing and Remote Access boleh mengganggu terowong. Pemasang yang dibina untuk seni bina salah gagal dengan mesej yang tidak pernah menyebut seni bina.

Betulkan lapisan yang dinamakan oleh ujian, kemudian jalankan semula tiga destinasi yang sama. Perubahan yang membaiki ujian nama hos tetapi merosakkan alamat terowong telah digunakan pada lapisan yang salah.