VPN Windows memaparkan 255.255.255.255: adakah mask itu salah?

Terowong bersambung, anda membuka butiran penyesuai dan mask memaparkan 255.255.255.255. Berbanding 255.255.255.0 LAN pejabat, ia kelihatan rosak, dan di situlah kesilapan biasanya bermula. Pada pautan titik-ke-titik, mask hos ialah penerangan yang betul bagi hujung setempat, dan rangkaian jauh tiba sebagai laluan dan bukan sebagai subrangkaian yang dipasang. Prosedur di bawah memisahkan kedua-dua soalan supaya anda tidak membina semula skop DHCP yang berfungsi hanya untuk membetulkan nilai yang dipaparkan.

Pautan titik-ke-titik bukan segmen Ethernet

Antara muka Ethernet memerlukan mask subrangkaian kerana setiap alamat dalam julat itu berpotensi boleh dicapai pada kabel yang sama. Terowong gaya PPP mempunyai tepat satu rakan di hujung yang lain. Tiada domain siaran, tiada ARP dan tiada sebab alamat setempat perlu menerangkan julat.

Rundingan pengalamatan untuk model itu ditakrifkan dalam RFC 1332, yang merangkumi cara kedua-dua hujung bersetuju tentang alamat masing-masing. Apa yang tidak dilakukannya ialah memberikan LAN pejabat kepada klien sebagai rangkaian yang disambung terus. Klien mempelajari lokasi pejabat dengan memasang laluan melalui pautan, dan laluan itulah yang benar-benar menentukan kebolehcapaian.

Ini tidak bermakna setiap mask yang anda lihat betul. Klien yang salah konfigurasi juga boleh menghasilkan pengalamatan yang pelik. Intinya lebih sempit: mask hos pada jenis penyesuai ini memang dijangka, jadi ia sendiri bukan bukti kerosakan.

Langkah 1: sahkan model antara muka

Lihat apakah penyesuai itu sebelum menilai apa yang dikatakannya. Rentetan penerangan mengenal pasti pemacu, dan panjang awalan pada alamat yang diberikan mengesahkan apa yang dirundingkan oleh 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 ialah yang menyelesaikan kebanyakan perdebatan. Unit penghantaran maksimum yang rendah adalah ciri pautan terkapsul, manakala nilai seperti Ethernet menunjukkan model penyesuai maya yang berbeza. Jika penerangan menyebut pemacu PPP atau RAS dan awalannya 32, anda melihat tepat reka bentuk yang diterangkan di atas dan boleh berhenti risau tentang mask.

Langkah 2: baca laluan untuk destinasi yang gagal

Kebolehcapaian ditentukan bagi setiap destinasi, dan satu antara muka yang bersambung tidak memberitahu apa-apa tentangnya. Tanya jadual laluan secara terus tentang alamat yang benar-benar cuba dicapai oleh pengguna:

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

Find-NetRoute ialah jawapan terus: ia menamakan antara muka dan alamat sumber yang akan digunakan sistem untuk destinasi itu. Jika ia mengembalikan terowong, trafik ke hos itu melalui terowong dan mask tidak pernah menjadi masalah.

Jika ia mengembalikan penyesuai fizikal, bandingkan dua laluan calon dan metriknya. Laluan setempat yang lebih khusus, sisa daripada klien lain atau metrik yang lebih rendah pada laluan fizikal semuanya mengalahkan laluan terowong yang luas. Hasil yang kelihatan ialah sumber yang tidak boleh dicapai sementara semua yang lain berfungsi. Awalan yang lebih panjang sentiasa menang, jadi pemenangnya selalunya laluan hos yang ditambah seseorang berbulan-bulan lalu dan dilupakan.

Periksa juga kedua-dua arah semasa anda di sini. Laluan ke sebelah pelayan perlu tetapi tidak mencukupi, kerana balasan juga mesti kembali melalui terowong. Apabila satu hos dalaman berfungsi dan satu lagi tidak, perbezaannya biasanya ada dalam jadual ini dan bukan dalam konfigurasi penyesuai.

Langkah 3: pisahkan penyelesaian nama daripada akses perkhidmatan

Aplikasi yang gagal membuka perkongsian boleh gagal pada salah satu daripada dua peringkat yang sangat berbeza. Selesaikan nama, kemudian capai alamat. Jika yang pertama gagal dan yang kedua berjaya, terowong itu baik dan penyelesai tidak:

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

Ujian alamat yang berjaya bersama ujian nama yang gagal menyetempatkan masalah pada penyelesaian, dan perintah kedua menunjukkan sama ada antara muka terowong menerima pelayan langsung. Banyak klien menolak DNS sebagai sebahagian daripada konfigurasi terowong, dan profil yang mengabaikan pilihan yang ditolak itu akan membiarkan mesin menggunakan penyelesai yang tidak nampak zon peribadi.

Jangan anggap alamat yang berfungsi sebagai pembaikan kekal. Menyambung melalui alamat memintas penyelesaian nama dan boleh melemahkan pemeriksaan identiti pelayan yang sepatutnya dilakukan aplikasi. Itu kemunduran keselamatan yang menyamar sebagai penyelesaian sementara. Gunakannya untuk menyetempatkan kerosakan, kemudian baiki penyelesaian.

Pengunduran: jangan bina semula DHCP kerana nilai yang dipaparkan

Jika anda sudah mula menukar perkhidmatan pengalamatan, berhenti dan periksa sama ada apa-apa yang anda ubah itu menanggung beban. Mencipta semula skop, mengeluarkan semula pajakan atau memindahkan kolam mengubah keadaan yang bergantung pada klien lain, dan tiada satu pun itu wajar disebabkan mask hos pada penyesuai titik-ke-titik.

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

Jalankan ketiga-tiganya selepas setiap perubahan bersasar dan bandingkan dengan jalanan sebelumnya. Hasil yang berguna ialah laluan berdokumen ke sumber, bukan penyesuai yang masknya menyerupai LAN pejabat.

Kemudian tuliskan apa sebenarnya maksud mask itu, kerana orang seterusnya akan membuka dialog yang sama dan sampai pada kesimpulan salah yang sama. Satu ayat dalam nota profil, bahawa terowong itu titik-ke-titik dan subrangkaian jauh tiba sebagai laluan, menyelamatkan seluruh siasatan lain kali.