Penghala dalam mod klien VPN: mengapa peranti LAN hilang

Kepercayaan bahawa mod klien sendiri membunuh akses LAN membawa orang ke menu tetapan yang salah, dan punca sebenar biasanya dua. Terowong tidak membuang jambatan LAN dan tidak menghalang klien berwayar dan tanpa wayar daripada saling mencapai. Yang memecahkan akses tempatan ialah ciri pemeriksaan dalam laluan penghantaran penghala atau julat alamat LAN yang bergerak apabila firmware melakukannya. Kedua-duanya menghasilkan aduan yang sama, dan tiada satu pun dibaiki dengan memasang semula profil VPN.

Mitos, dan apa yang sebenarnya diubah oleh mod klien

Mod klien menambah antara muka terowong dan laluan lalai yang melaluinya, kemudian menghantar trafik LAN ke terowong itu. Jambatan antara port berwayar dan radio tanpa wayar kekal utuh, begitu juga pensuisan tempatan. Yang berubah ialah dasar: trafik mana yang dihantar, di mana ia diterjemahkan dan penyelesai mana yang diterima oleh klien.

Perbezaan itu penting kerana LAN yang rosak biasanya bermaksud salah satu daripada tiga dasar itu berubah, bukan penghala berhenti menjadi suis. Penghala yang masih menjawab halaman pentadbirannya sendiri ialah bukti antara muka LAN masih hidup. Penghala yang tidak menjawab apa-apa mempunyai masalah lain, seperti alamat LAN yang berubah atau klien pada subnet yang salah.

Jadi langkah pertama yang berguna ialah mencari lapisan mana yang rosak, bukan menukar lapisan yang anda syaki.

Uji tiga sasaran sebelum menyentuh tetapan

Dari klien berwayar, uji tiga sasaran secara berasingan dan catat setiap hasil: alamat LAN penghala itu sendiri, peranti lain pada suis yang sama mengikut IP, dan sesuatu yang hanya boleh dicapai melalui terowong. Lakukan dalam urutan itu, kerana setiap hasil menyingkirkan lapisan yang berbeza. Gunakan alamat dan bukan nama pada pusingan pertama, kerana kegagalan nama mencampurkan DNS ke dalam soalan konektiviti.

Corak jawapan itulah diagnosis. Penghala yang menjawab manakala peranti tempatan tidak menunjukkan pensuisan tempatan atau ciri penapisan, bukan penghalaan. Peranti tempatan yang menjawab manakala bahagian terowong tidak menunjukkan laluan terowong atau firewall jauh. Jika semuanya menjawab mengikut alamat tetapi nama gagal, itu soalan penyelesai, dan tiada penyuntingan laluan akan membetulkannya.

Simpan jadual di sebelah hasil ujian. Ia menukar aduan kabur menjadi satu baris yang boleh anda tindak lanjuti.

Lapisan keselamatan di dalam laluan penghantaran

Penghala pengguna semakin kerap disertakan dengan ciri pemeriksaan yang memantau trafik yang dihantar, dan ia berjalan dalam laluan yang sama yang membawa paket dari LAN ke terowong. Apabila pemeriksaan itu tidak dapat mengelaskan trafik terowong, penghantaran boleh tersekat manakala terowong itu sendiri kekal aktif dan penghala melaporkan sambungan sihat. Tiada apa dalam log VPN menunjukkan ini, kerana VPN memang bersambung.

Diagnosis ialah eksperimen terkawal, bukan perubahan kekal. Catat tetapan semasa, matikan ciri itu selama satu ujian, naikkan semula terowong dan uji satu hos tempatan mengikut alamat. Penghantaran yang kembali ialah bukti yang anda perlukan, dan pertukaran itu kemudian menjadi keputusan dan bukan tekaan. Jika tiada apa berubah, hidupkan semula dengan segera dan beralih kepada punca pengalamatan.

Membiarkan ciri keselamatan berbayar dimatikan supaya terowong terus berfungsi ialah pertukaran yang perlu dibuat dengan sengaja dan dicatat. Elok juga ditanya sama ada terowong itu patut berada pada peranti lain, kerana penghala yang mesti memeriksa segala-galanya dan penghala yang mesti menghantar segala-galanya ialah dua kerja berbeza.

Punca kedua: julat LAN bergerak

Kemas kini firmware sering mengembalikan alamat LAN kepada nilai lalai pengeluar, dan sesetengah penghala mempunyai suis mod jelas yang menentukan sama ada LAN mengekalkan julat peribadi atau mewarisi satu daripada peranti di atasnya. Klien yang menjangkakan 192.168.8.x boleh berakhir pada 10.64.0.x, dan kemudian sesi SSH ke hos tamat walaupun terowong sihat sepenuhnya.

ipconfig /all
ip addr show
ip route get 192.168.8.20

Baca awalan dan get laluan daripada pajakan sebelum membuka halaman penghala. Dua arahan pertama menunjukkan apa yang sebenarnya diterima oleh klien, dan yang ketiga menunjukkan antara muka mana yang akan digunakan oleh klien untuk alamat tempatan, dan begitulah laluan sisa atau subnet lama mendedahkan dirinya. Kemudian bandingkan dengan halaman LAN dan mod penghala.

Jika julat tidak dapat kembali, kemas kini setiap objek yang menamakannya: tempahan DHCP, mana-mana laluan statik ke subnet lama, dan setiap peraturan firewall yang membawa awalan sebelumnya. Julat yang berlanggar dengan subnet jauh terowong ialah varian yang lebih teruk, kerana peranti tempatan kekal boleh dicapai manakala destinasi jauh dihalakan secara senyap ke LAN.

Sambung semula dan uji semula mengikut urutan paket

Selepas mana-mana satu daripada dua perubahan, sambung semula terowong dan ulangi ujian mengikut urutan paket: penghala, hos tempatan, hos jauh, kemudian nama, kemudian aplikasi. Menguji aplikasi dahulu menyembunyikan lapisan mana yang masih rosak, dan cubaan semula pelayar terhadap nama yang dicache boleh kelihatan seperti kegagalan penghalaan.

Catat versi firmware, awalan LAN dan keadaan ciri pemeriksaan di sebelah profil VPN. Ketiga-tiganya ialah konfigurasi yang mungkin ditimpa oleh kemas kini seterusnya, dan dua baris nota menjimatkan sejam yang baru anda habiskan.