Mengapa rute VPN yang lebar memutus beberapa situs publik
Beberapa situs gagal sementara sisanya dimuat karena prefiks yang lebar menangkap alamatnya. Cocokkan rute dengan alamat yang telah diresolusi, lalu cari tahu siapa yang memasangnya.
Sebagian besar halaman dimuat, dua atau tiga habis waktu, dan peramban menyalahkan koneksi. Situs yang gagal memiliki kesamaan yang tidak dimiliki situs yang berfungsi: alamat teresolusi mereka jatuh di dalam prefiks yang dipasang VPN. Rute yang cukup lebar untuk mencakup rentang publik akan menangkap lalu lintas yang tidak pernah dimaksudkan terowongan untuk membawanya, dan gejalanya tampak seperti masalah situs web, bukan keputusan perutean.
Resolusi nama yang gagal, lalu lihat tabel perutean, bukan peramban.
Bandingkan alamatnya, bukan nama situsnya
Cari alamat yang benar-benar dicoba klien, lalu periksa rute mana yang cocok dengannya. Tujuan di dalam 45.61.20.10 berada di bawah 45.0.0.0/8 jika prefiks itu ada, meskipun situs itu sendiri tidak ada hubungannya dengan terowongan. Membandingkan alamat yang gagal dengan prefiks yang terpasang adalah soal pengurangan, bukan tebakan.
Windows dapat menjawab kedua bagian secara langsung, dan pencarian menunjukkan antarmuka serta hop berikutnya mana yang memenangkan pemilihan. Resolusi nama dua kali jika situs mengembalikan beberapa alamat. Catat masing-masing dengan rute yang cocok. Alamat berbeda dapat menghasilkan jawaban berbeda, dan hanya satu di antaranya mungkin kasus yang gagal.
Resolve-DnsName www.example.org Get-NetRoute -AddressFamily IPv4 | Select-Object DestinationPrefix,InterfaceIndex,NextHop,RouteMetric Find-NetRoute -RemoteIPAddress 45.61.20.10 Get-VpnConnection | Format-List Name,SplitTunneling,Routes
Baca prefiks yang paling spesifik, bukan baris pertama yang tampak familier. Rute yang ada di tabel tidak membuktikan bahwa ia memenangkan pencarian; kecocokan terpanjanglah yang menentukannya. Dua prefiks dapat cocok dengan satu alamat, dan hanya satu yang menerima paket. Yang kalah tetap ada di tabel dan tampak sama nyata dalam daftar.
Catat prefiks, antarmukanya, dan alamat teresolusi. Ketiga nilai itu adalah seluruh diagnosis.
Cari tahu siapa yang memasang rute
Rute datang dari empat tempat: profil VPN asli, kebijakan manajemen, skrip koneksi, atau klien yang sama sekali lain. Menghapus entri aktif dapat memastikan relevansinya, tetapi koneksi berikutnya membuatnya kembali dari konfigurasi yang tersimpan, jadi sumbernya yang harus diubah.
Periksa daftar rute profil lebih dulu, lalu kebijakan manajemen, lalu skrip apa pun yang berjalan saat terhubung. Urutan itu sesuai dengan seberapa sering masing-masing terbukti bertanggung jawab. Urutan itu juga menjaga perubahan tetap pada satu lapisan alih-alih tiga.
Baca perilaku berbasis kelas bawaan dengan cermat
Profil Windows bawaan memiliki pengaturan terdokumentasi, NativeProfile/DisableClassBasedDefaultRoute, yang mengendalikan rute otomatis yang disimpulkan dari alamat antarmuka. Alamat profil yang dimulai dengan 45 dapat menghasilkan entri 45.0.0.0/8 di bawah perilaku itu, dan begitulah satu alamat publik menangkap seluruh rentang kelas A.
Nama propertinya mengundang pembacaan yang salah: menyetelnya ke true menonaktifkan inferensi, dan false mengaktifkannya. Properti itu juga bukan objek yang sama dengan rute default, dan tidak mengatur klien pihak ketiga yang memasang prefiksnya sendiri.
Jika inferensi adalah penyebab yang terbukti, perbaiki profil melalui pemilik manajemennya dan sediakan prefiks privat yang dimaksud secara eksplisit. Jika skrip menambahkan entri itu, perbaiki skripnya. Mengganti satu rute lebar yang tak dijelaskan dengan yang lain mengubah gejalanya tanpa menjawab pertanyaannya.
Perbaiki sumbernya, lalu periksa ulang kedua jalur
Setelah perubahan, sambungkan lagi dan ulangi pencarian untuk situs publik yang gagal dan untuk sumber daya yang harus menggunakan terowongan. Yang pertama sekarang harus teresolusi ke antarmuka fisik, dan yang kedua harus tetap memilih VPN. Jangan berhenti pada keberhasilan pertama; perbaikan yang juga merusak akses privat telah menukar satu kesalahan dengan kesalahan lain.
Tinjau rencana alamat server pada saat yang sama. Pool yang tumpang tindih dengan ruang publik menyebabkan masalah jenis ini berulang kali. Rentang yang dipilih operator dengan sengaja layak mendapat pembicaraan lain, bukan penomoran ulang otomatis.
Menaikkan MTU atau membersihkan DNS tidak akan memperbaiki prefiks yang masih mengarahkan alamat itu ke terowongan. Uji pemilihannya dulu, lalu jalurnya.