VPN Windows menampilkan 255.255.255.255: apakah masknya salah?

Tunnel tersambung, Anda membuka detail adaptor dan mask menampilkan 255.255.255.255. Dibandingkan dengan 255.255.255.0 LAN kantor, itu tampak rusak, dan di situlah kesalahan biasanya dimulai. Pada tautan point-to-point, mask host adalah deskripsi yang benar untuk titik akhir lokal, dan jaringan jarak jauh datang sebagai rute, bukan sebagai subnet yang terpasang. Prosedur di bawah memisahkan kedua pertanyaan agar Anda tidak membangun ulang cakupan DHCP yang berfungsi hanya untuk memperbaiki nilai yang ditampilkan.

Tautan point-to-point bukan segmen Ethernet

Antarmuka Ethernet memerlukan mask subnet karena setiap alamat dalam rentang itu berpotensi dijangkau pada kabel yang sama. Tunnel bergaya PPP memiliki tepat satu peer di ujung lainnya. Tidak ada domain siaran, tidak ada ARP, dan tidak ada alasan bagi alamat lokal untuk mendeskripsikan rentang.

Negosiasi pengalamatan untuk model itu didefinisikan dalam RFC 1332, yang mencakup bagaimana kedua ujung menyepakati alamatnya. Yang tidak dilakukannya adalah memberikan LAN kantor kepada klien sebagai jaringan yang terhubung langsung. Klien mempelajari lokasi kantor dengan memasang rute melalui tautan, dan rute itulah yang benar-benar menentukan keterjangkauan.

Ini bukan berarti setiap mask yang Anda lihat benar. Klien yang salah konfigurasi juga dapat menghasilkan pengalamatan aneh. Intinya lebih sempit: mask host pada jenis adaptor ini memang diharapkan, jadi itu sendiri bukan bukti kesalahan.

Langkah 1: konfirmasi model antarmuka

Lihat apa adaptor itu sebelum menilai apa yang dikatakannya. String deskripsi mengidentifikasi driver, dan panjang prefiks pada alamat yang ditetapkan mengonfirmasi apa yang dinegosiasikan klien:

Get-NetAdapter | Select-Object Name,InterfaceDescription,Status,ifIndex
Get-NetIPAddress -InterfaceAlias 'Corp VPN' | Select-Object IPAddress,PrefixLength,PrefixOrigin
Get-NetIPInterface -InterfaceAlias 'Corp VPN' | Select-Object AddressFamily,ConnectionState,NlMtu

Perintah ketiga adalah yang menyelesaikan sebagian besar perdebatan. Unit transmisi maksimum yang rendah adalah ciri tautan terenkapsulasi, sedangkan nilai mirip Ethernet menunjukkan model adaptor virtual yang berbeda. Jika deskripsi menyebut driver PPP atau RAS dan prefiksnya 32, Anda melihat persis desain yang dijelaskan di atas dan bisa berhenti mengkhawatirkan mask.

Langkah 2: baca rute untuk tujuan yang gagal

Keterjangkauan ditentukan per tujuan, dan satu antarmuka yang terhubung tidak memberi tahu apa pun tentang itu. Tanyakan tabel rute secara langsung untuk alamat yang benar-benar ingin dijangkau pengguna:

Get-NetRoute -InterfaceAlias 'Corp VPN' | Select-Object DestinationPrefix,NextHop,RouteMetric
Find-NetRoute -RemoteIPAddress 10.24.6.15
route print -4

Find-NetRoute adalah jawaban langsungnya: perintah ini menyebut antarmuka dan alamat sumber yang akan digunakan sistem untuk tujuan itu. Jika hasilnya tunnel, lalu lintas ke host tersebut melewati tunnel dan mask tidak pernah menjadi masalah.

Jika hasilnya adaptor fisik, bandingkan dua rute kandidat dan metriknya. Rute lokal yang lebih spesifik, sisa entri dari klien lain, atau metrik lebih rendah pada jalur fisik semuanya mengalahkan rute tunnel yang lebar. Hasil yang terlihat adalah sumber daya yang tidak terjangkau sementara semua yang lain berfungsi. Prefiks yang lebih panjang selalu menang, jadi pemenangnya sering kali rute host yang ditambahkan seseorang berbulan-bulan lalu dan terlupakan.

Periksa juga kedua arah selama Anda di sini. Rute ke sisi server diperlukan tetapi tidak cukup, karena balasannya juga harus kembali melalui tunnel. Ketika satu host internal berfungsi dan yang lain tidak, perbedaannya biasanya ada di tabel ini dan bukan di konfigurasi adaptor.

Langkah 3: pisahkan resolusi nama dari akses layanan

Aplikasi yang gagal membuka berbagi pakai bisa gagal pada salah satu dari dua tahap yang sangat berbeda. Selesaikan nama, lalu jangkau alamatnya. Jika yang pertama gagal dan yang kedua berhasil, tunnel baik-baik saja dan resolver tidak:

Resolve-DnsName files.corp.example.internal
Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Test-NetConnection -ComputerName 10.24.6.15 -Port 445

Uji alamat yang berhasil bersama uji nama yang gagal melokalisasi masalah pada resolusi, dan perintah kedua menunjukkan apakah antarmuka tunnel menerima server sama sekali. Banyak klien mendorong DNS sebagai bagian dari konfigurasi tunnel, dan profil yang mengabaikan opsi yang didorong itu akan membuat mesin memakai resolver yang tidak melihat zona privat.

Jangan jadikan alamat yang berfungsi sebagai perbaikan permanen. Menghubungkan lewat alamat melewati resolusi nama dan dapat melemahkan pemeriksaan identitas server yang seharusnya dilakukan aplikasi. Itu adalah kemunduran keamanan yang menyamar sebagai solusi sementara. Gunakan untuk melokalisasi kesalahan, lalu perbaiki resolusinya.

Pengembalian: jangan bangun ulang DHCP karena nilai yang ditampilkan

Jika Anda sudah mulai mengubah layanan pengalamatan, berhentilah dan periksa apakah ada yang Anda ubah bersifat menopang. Membuat ulang cakupan, menerbitkan ulang sewa, atau memindahkan kumpulan mengubah keadaan yang menjadi sandaran klien lain, dan tidak ada yang dibenarkan oleh mask host pada adaptor point-to-point.

Get-DnsClientServerAddress -InterfaceAlias 'Corp VPN'
Find-NetRoute -RemoteIPAddress 10.24.6.15
Test-NetConnection -ComputerName files.corp.example.internal -Port 445

Jalankan ketiganya setelah setiap perubahan yang ditargetkan dan bandingkan dengan jalannya sebelumnya. Hasil yang berguna adalah jalur terdokumentasi ke sumber daya, bukan adaptor yang masknya mirip LAN kantor.

Lalu tuliskan apa arti mask itu sebenarnya, karena orang berikutnya akan membuka dialog yang sama dan sampai pada kesimpulan keliru yang sama. Satu kalimat di catatan profil, bahwa tunnel bersifat point-to-point dan subnet jarak jauh datang sebagai rute, menghemat seluruh penyelidikan lain kali.