Rangkaian setempat tidak dapat dicapai semasa VPN disambungkan? Empat semakan

Terowong naik, intranet muncul, dan pencetak berhenti menjawab. Tiada apa-apa pada LAN yang rosak; klien telah menukar laluan yang digunakannya untuk alamat yang tidak lagi dianggap setempat. Lakukan empat semakan di bawah mengikut urutan dan berhenti apabila satu daripadanya menunjukkan ketakselarasan yang konkrit, kerana gejala yang sama mempunyai empat punca lazim dan hanya satu daripadanya diperbaiki dengan mengubah VPN.

Pertama, lihat jadual laluan yang dipasang oleh klien

Buka jadual laluan klien semasa VPN disambungkan. Pada Linux gunakan ip route, pada Windows gunakan route print atau Get-NetRoute, dan pada macOS gunakan netstat -rn. Anda mencari laluan lalai melalui terowong dan apa yang berlaku kepada laluan lalai fizikal.

Klien terowong penuh sering menambah dua laluan separa lalai, 0.0.0.0/1 dan 128.0.0.0/1, daripada menggantikan 0.0.0.0/0. Laluan lalai asal kekal kelihatan tetapi kalah dalam setiap carian, sebab itu jadual boleh kelihatan utuh sementara semua trafik di luar subnet bergerak. Jika klien VPN menawarkan pilihan terowong berpecah dan dasar membenarkannya, itulah pembaikan paling bersih.

Jika terowong mesti kekal sebagai laluan lalai, sematkan subnet setempat sebaliknya. Pada Linux laluan itu menamakan antara muka fizikal dan get laluan; pada Windows tambah -p supaya kekal dan baca nombor antara muka daripada route print dan bukannya menekanya:

sudo ip route add 192.168.1.0/24 via 192.168.1.1 dev wlan0
route add -p 192.168.1.0 MASK 255.255.255.0 192.168.1.1 METRIC 1 IF 12

Laluan yang disematkan hanya bertahan selagi alamat yang dinamakannya kekal sama. Komputer riba yang mendapat nombor baharu bagi penyesuai Wi-Fi pada setiap sambungan akan melanggar peraturan itu semula, jadi periksa alamat antara muka sebelum memutuskan pembaikan itu gagal.

Kedua, pastikan alamat itu memang setempat sejak awal

Jika destinasi berada dalam subnet yang disambungkan, laluan lalai terowong tidak pernah terpakai dan VPN bukan puncanya. Pencetak pada 192.168.1.40 pada klien dengan 192.168.1.0/24 menggunakan laluan bersambung; jika alamat itu gagal, lihat peranti, suis atau tembok api pada klien dan bukan VPN.

Kes yang mengelirukan orang ialah alamat awam untuk pelayan setempat. Dari dalam LAN, mencapai alamat WAN penghala dan kembali semula memerlukan NAT jepit rambut, dan banyak penghala langsung tidak melaksanakannya untuk pemajuan port. Uji alamat persendirian di sebelah alamat awam. Jika alamat persendirian berfungsi dan yang awam tidak, VPN hanya mendedahkan had NAT yang sudah ada.

Nama hos menjadikannya lebih teruk. Jika nama setempat kini diselesaikan ke alamat awam, klien akan terus mencuba laluan yang tidak boleh kembali. Gunakan alamat persendirian untuk ujian, kemudian betulkan nama itu dan bukannya menambah satu lagi pemajuan port.

Ketiga, lihat siapa yang menjawab nama sekarang

Penyelesai korporat mengetahui intranet dan biasanya tidak tahu apa-apa tentang nama hos NAS, nama Bonjour pencetak atau alias setempat penghala. Apabila VPN menolak pelayan DNSnya, nama-nama itu berhenti diselesaikan walaupun alamatnya masih boleh dicapai. Tanya nama itu secara langsung dan bandingkan jawapannya dengan alamat yang anda tahu dipegang oleh peranti.

Pada Linux, resolvectl query nas.local menunjukkan penyelesai mana yang menjawab. Pada Windows, nslookup nas.local menamakan pelayan, dan ipconfig /all menunjukkan susunan penyelesai. Jika akhiran setempat kini dikendalikan oleh penyelesai korporat, halakan akhiran itu kembali ke penyelesai setempat atau gunakan alamat IP untuk peranti.

Penemuan ialah lapisan berasingan. mDNS dan siaran tidak melintasi terowong yang dilalukan, jadi peranti boleh dicapai melalui alamat sementara namanya kekal tidak kelihatan. Pemantul atau entri DNS setempat menyelesaikannya; laluan tidak.

Keempat, periksa sama ada mesin lain juga berada pada VPN

Apabila mesin yang anda mahu capai juga menjalankan klien VPN, sesi anda boleh tiba sementara balasannya keluar melalui terowong yang lain. Itu menghasilkan sambungan yang terbentuk dan kemudian tersekat, atau percubaan RDP dan SSH yang tamat masa tanpa ralat di pihak anda. Periksa jadual laluan hos lain itu dan laluan lalainya sebelum menyalahkan klien anda.

Periksa juga alamat tempat perkhidmatan mendengar. Pendengar yang terikat hanya pada alamat terowong menerima sambungan daripada VPN dan menolaknya daripada LAN, walaupun penghalaan sempurna. Itu konfigurasi perkhidmatan, bukan laluan rangkaian, dan ia lazim pada antara muka pengurusan yang dikunci kepada alamat VPN.

Kekalkan laluan pengurusan yang tidak bergantung pada terowong: laluan statik yang menamakan rangkaian sumber anda, antara muka lain yang dipasang pada LAN, atau konsol yang memintas terowong sepenuhnya. Mereka bentuk laluan itu selepas sesi terputus jauh lebih sukar daripada menambahnya sebelum sambungan seterusnya.

Gunakan pembaikan yang sepadan dengan semakan yang gagal

Jika jadual laluan menunjukkan pengambilalihan separa lalai, pilih terowong berpecah apabila dasar membenarkan dan laluan setempat yang disematkan apabila tidak. Jika alamat itu ternyata awam, tukar ujian dan nama kepada alamat persendirian. Jika penyelesai bertukar tangan, hadkan kepada akhiran setempat atau gunakan alamat itu. Jika hos lain berada dalam terowong, betulkan laluan pulangnya atau pengikatan pendengarnya.

Ubah satu perkara, kemudian ulangi semakan yang sama. Laluan yang ditambah untuk subnet yang salah, akhiran penyelesai dengan salah taip dan laluan tersemat pada antara muka yang mendapat nombor baharu semuanya kelihatan seperti kegagalan asal. Pengulangan itulah yang memisahkan pembaikan daripada kebetulan.

Catat laluan, alamat dan penyelesai yang berfungsi semasa VPN disambungkan. Sambungan semula seterusnya akan menukar sekurang-kurangnya satu daripadanya, dan catatan itu menjadikan gangguan seterusnya sebagai perbandingan ringkas dan bukan siasatan baharu.