Handshake berhasil, internet tidak: apa yang diperbaiki dulu di Windows 11

Di Windows 11, handshake baru sering berdampingan dengan peramban yang tidak membuka apa pun. Handshake hanya membuktikan pertukaran UDP dengan peer selesai. Ia tidak mengatakan apa pun tentang rute yang dipasang Windows, resolver yang dipakainya, atau apakah jalur keluar meneruskan apa pun.

Empat kondisi menentukan lapisan mana yang gagal. Menelusurinya berurutan butuh beberapa menit, sedangkan menulis ulang kunci butuh lebih lama dan tidak mengubah apa pun.

Tentukan lapisannya sebelum menyentuh kunci

Telusuri tiga tujuan, dalam urutan ini. Mulai dari alamat di sisi tunnel, lalu IP publik sebagai angka, dan akhiri dengan nama host. Di titik rangkaian itu putus, di situ lapisannya disebut. Kegagalan pada langkah pertama adalah perutean, pada langkah kedua adalah penerusan atau NAT, dan pada langkah ketiga adalah resolusi nama.

Urutan itu adalah seluruh metodenya. Ia mencegah gangguan DNS didiagnosis sebagai tunnel rusak, yang merupakan kesalahan arah paling umum di sini.

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

Jika waktu handshake kosong

Ketika waktu handshake kosong, pertukaran terenkripsi tidak pernah selesai. Jadi gangguan itu berada lebih awal daripada perutean. Lihat dulu alamat endpoint dan port, lalu apakah jaringan menyaring UDP. Penyedia hosting yang membuang lalu lintas WireGuard menghasilkan persis ini, begitu pula klien yang menyalin endpoint dari profil lama.

Bita yang keluar tanpa ada yang masuk adalah kasus lain. Itu menunjuk ke NAT atau firewall yang mengembalikan lalu lintas ke tempat yang salah.

Jika rute kalah dari adaptor fisik

Untuk tunnel penuh, bagian peer harus mencakup tujuan yang Anda perkirakan akan dipakai. Windows kadang mempertahankan rute bawaan adaptor fisik bahkan saat aturan menyeluruh sudah diatur. Memecah aturan menyeluruh menjadi 0.0.0.0/1 plus 128.0.0.0/1 membuat dua prefiks yang lebih spesifik yang memenangkan pencarian. Pemecahan itu adalah akal-akalan yang terdokumentasi, bukan preferensi.

Pastikan dengan route print atau pencarian alamat publik. Antarmuka yang dipilih seharusnya adaptor tunnel. Jika yang fisik masih menang, perbaiki rentang peer sebelum menyentuh server.

Jika alamat berfungsi dan nama gagal

WireGuard membawa paket IP dan tidak berpendapat soal DNS. Letakkan baris DNS = di bagian antarmuka, atau atur adaptor lewat Windows. Tanpanya, ping berdasarkan alamat berhasil sementara setiap nama host gagal, dan pengguna melaporkannya sebagai tidak ada internet.

Periksa server mana yang benar-benar dipakai Windows setelah terhubung. Resolver sisa pada adaptor fisik menjelaskan kegagalan sebagian, ketika sebagian nama berhasil diresolusi dan sebagian lagi tidak. Bersihkanlah daripada menambahkan yang kedua di atasnya.

Jika mesin Windows adalah jalur keluarnya

Internet Connection Sharing menulis ulang pengalamatan saat diaktifkan, yang dapat memindahkan adaptor bersama ke rentang lain. Klien yang masih menunjuk ke alamat asli lalu berhenti berfungsi. Nilai registri ScopeAddress dan StandaloneDHCPAddress mengendalikan rentang itu, dan pengaturannya bisa kembali setelah reboot.

Dua konflik lain khas Windows layak dilihat. Layanan Routing and Remote Access dapat mengganggu tunnel. Installer yang dibuat untuk arsitektur salah gagal dengan pesan yang tidak pernah menyebut arsitektur.

Perbaiki lapisan yang disebut pengujian, lalu jalankan lagi tiga tujuan yang sama. Perubahan yang memperbaiki uji nama host tetapi merusak alamat tunnel diterapkan pada lapisan yang salah.