Internet hanya berfungsi dengan aplikasi VPN? Periksa empat lapisan

Anda mencuba klien VPN percuma atau sambungan pelayar selama seminggu, mematikannya, dan internet terhenti. Ikon Wi-Fi masih menunjukkan sambungan, peranti lain pada penghala yang sama berfungsi, dan satu-satunya yang mengembalikan pelayaran ialah menghidupkan semula aplikasi itu atau menyahpasangnya. Corak itu bukan penyulitan yang mencipta kebergantungan. Ia ialah konfigurasi yang ditulis aplikasi di tempat yang tidak dimiliki terowong.

Klien menyunting tetapan yang tidak dimiliki terowong

Klien privasi pada Windows atau macOS biasanya menyentuh tiga tempat serentak. Ia menetapkan proksi HTTP sistem, iaitu medan yang sama yang dipaparkan Pilihan Internet. Ia memasang penyesuai maya, selalunya pemacu TAP, supaya dapat menangkap paket. Dan ia menulis semula senarai penyelesai, sedangkan hanya terowong yang hilang apabila anda menekan putuskan sambungan.

Sambungan pelayar ialah perkara yang lebih sempit. Ia biasanya mengubah profilnya sendiri atau proksi yang diikut oleh satu pelayar. Itulah sebabnya satu pelayar boleh gagal sementara alat baris arahan terus berfungsi, atau sebaliknya: sambungan itu tidak pernah mempunyai kuasa untuk menyentuh lapisan lain. Lapisan mana yang disuntingnya menentukan alat mana yang rosak.

Sama ada cara, keputusan lapuk itu dibuat oleh perisian yang tidak mempunyai sebab untuk membatalkannya. Terowong ialah bahagian yang kelihatan, dan ia juga satu-satunya bahagian dengan laluan penutupan yang bersih. Segala-galanya ialah tetapan dalam stor yang hidup lebih lama daripada proses, jadi menyahpasang aplikasi ialah satu langkah yang membatalkan ketiga-tiganya serentak. Membaca stor itu sebelum memasang semula apa-apa ialah yang menukar gejala kepada diagnosis.

Tiga sisa, tiga kegagalan berbeza

Sisa pertama ialah proksi yang tidak menunjuk ke apa-apa: kotak proksi LAN masih ditanda, atau URL skrip konfigurasi ditujukan ke port localhost tempat tiada proses lagi mendengar. Pelayar memajukan setiap permintaan ke port mati itu dan terhenti sehingga tamat masa kelihatan seperti rangkaian mati. Yang kedua ialah penyesuai yang masih memiliki laluan lalai, kerana peranti TAP-Windows atau pemacu penghalaan vendor kekal sebagai antara muka sebenar selepas penyahpasangan. Ia mengekalkan laluan yang diberikan kepadanya, dan trafik hilang ke dalam terowong yang tidak wujud. Kedua-dua sisa tidak mengumumkan dirinya; kedua-duanya kelihatan tepat seperti gangguan.

Yang ketiga ialah DNS, dan ia gagal lebih awal daripada dua yang lain. Jika senarai penyelesai mengandungi hanya pelayan yang boleh dicapai melalui terowong, setiap carian tamat masa sebelum satu halaman pun diminta, jadi pelayar melaporkan tapak tidak boleh dicapai dan bukan proksi mati. Mana pun yang anda ada, tiada satu pun daripadanya gangguan dalam erti kata rangkaian. Setiap satu ialah sisa yang tiada siapa batalkan, dan setiap satu dibaiki di tempat yang berbeza.

Turuni keempat-empat lapisan

Mulakan paling dekat dengan aplikasi dan turun ke bawah, kerana lapisan gagal mengikut urutan keterlihatan itu. Tukar satu lapisan bagi setiap ujian, dan uji semula selepas setiap satu. Menetapkan semula segala-galanya serentak biasanya memulihkan pelayaran, tetapi ia membuat anda tidak dapat menyatakan sisa mana yang menyebabkannya, jadi pemasangan seterusnya mencipta semula teka-teki yang sama. Urutannya ialah proksi, penyesuai, laluan, penyelesai.

Pada Windows setiap semakan ialah satu arahan yang dibawa bersama sistem pengendalian, jadi tiada apa perlu dipasang. Jalankannya mengikut urutan dan simpan output bersama, kerana keempat-empat jawapan hanya bermakna apabila bersebelahan. Ia melaporkan proksi, penyesuai, laluan IPv4 dan senarai penyelesai, mengikut urutan itu:

netsh winhttp show proxy
Get-NetAdapter
route print -4
Get-DnsClientServerAddress

Linux dan macOS memerlukan arahan mereka sendiri, dan ia tidak boleh ditukar ganti. Pada Linux laluan datang daripada ip route dan penyelesai daripada resolvectl status di tempat systemd-resolved memilikinya, dengan kembali kepada cat /etc/resolv.conf. Pada macOS laluan datang daripada netstat -rn, penyelesai daripada scutil --dns, dan proksi sistem daripada scutil --proxy. Pembaca macOS yang menjalankan ip route mendapat command not found, dan /etc/resolv.conf di sana ialah kerangka terjana dan bukan konfigurasi berautoriti. Semak platform sebelum anda menyemak lapisan, atau arahan pertama menjadi penemuan.

Bagi setiap lapisan tanya satu soalan: adakah nilai ini masih menunjuk kepada sesuatu yang wujud semasa aplikasi ditutup? Proksi pada port mati, penyesuai tanpa terowong, laluan lalai melalui antara muka yang turun dan penyelesai di dalam terowong semuanya menjawab tidak. Satu jawapan tidak sudah cukup untuk menjelaskan gejala, sebab itulah satu perubahan bagi setiap ujian penting.

Proksi bukan terowong

Proksi menerima permintaan, mengambilnya di tempat lain dan mengembalikan respons, bermakna ia tahu destinasinya dan melihat apa sahaja yang tidak disulitkan oleh tapak itu sendiri. Ia tidak membawa protokol lain. Ia tidak melindungi laluan melainkan destinasi sudah menggunakan TLS. Dan ia boleh diubah oleh apa sahaja yang memasangnya, tanpa penglibatan anda.

Perbezaan itu mengubah soalan yang patut ditanya. Apabila proksi kekal di belakang, ketahui program mana yang masih mengemudi pelayar anda dan bukannya sama ada terowong hidup. Terowong mungkin sihat sepenuhnya dan sama sekali tidak berkaitan dengan kegagalan itu.

Jika anda ingin tahu apa yang sebenarnya dilakukan klien sedemikian, perhatikannya dan bukan membaca papan pemukanya. Process Monitor merekodkan kunci registri dan fail yang disentuhnya, manakala tangkapan paket mendedahkan ke mana trafiknya pergi. Kedua-duanya alat biasa, dan kedua-duanya menjawab soalan sisa itu lebih baik daripada mana-mana lampu status. Tiada satu pun memerlukan aplikasi masih berjalan.

Buang komponennya, bukan buktinya

Pembaikan yang tahan lama ialah membuang perkara yang menulis tetapan itu. Nyahpasang aplikasi, padam penyesuai maya yang ditambahnya, kosongkan proksi dan senarai penyelesai, kemudian but semula dan uji dengan aplikasi masih belum dipasang. Jika pelayaran berfungsi pada ketika itu, anda telah menemui puncanya dan bukan penyelesaian sementara. Catat lapisan mana yang lapuk, kerana vendor yang sama cenderung menghantar kesilapan yang sama dua kali.

Jika gejala kembali selepas anda memasang klien seterusnya, turuni keempat-empat lapisan sekali lagi sebelum memutuskan bahawa perkhidmatan itu merosakkan sesuatu. Bukti biasanya masih ada, di salah satu daripada empat tempat itu. Aplikasi kedua tidak mencipta lapisan kelima; ia menyunting salah satu daripada empat.

Memasang semula menetapkan semula proksi tetapi bukan penyesuai yang lapuk, dan ia mungkin meninggalkan dua penyelesai dalam senarai. Asimetri itulah sebabnya nyahpasang-dahulu-kemudian-uji mengalahkan butang tetapkan-semula-semua. Ia juga memberi anda garis dasar untuk dibandingkan pada kali seterusnya sambungan terputus.