Internet Hanya Jalan Saat Aplikasi VPN Menyala? Periksa Empat Lapisan

Anda mencoba klien VPN gratis atau ekstensi peramban selama sepekan, mematikannya, lalu internet berhenti. Ikon Wi-Fi masih menunjukkan koneksi, perangkat lain di router yang sama baik-baik saja, dan satu-satunya yang memulihkan penjelajahan adalah menyalakan aplikasinya lagi atau menghapusnya. Pola itu bukan enkripsi yang menciptakan ketergantungan. Itu konfigurasi yang ditulis aplikasi di tempat yang bukan milik terowongan.

Klien mengubah pengaturan yang bukan milik terowongan

Klien privasi di Windows atau macOS biasanya menyentuh tiga tempat sekaligus. Ia mengatur proxy HTTP sistem, kolom yang sama yang ditampilkan Internet Options. Ia memasang adapter virtual, sering kali driver TAP, agar bisa menangkap paket. Dan ia menulis ulang daftar resolver, sementara saat Anda menekan tombol putus hanya terowongannya yang hilang.

Ekstensi peramban adalah hal yang lebih sempit. Biasanya ia mengubah profilnya sendiri atau proxy yang diikuti satu peramban. Karena itu satu peramban bisa gagal sementara alat baris perintah tetap berjalan, atau sebaliknya: ekstensi itu tidak pernah punya wewenang menyentuh lapisan lain. Lapisan mana yang ia ubah menentukan alat mana yang rusak.

Bagaimanapun, keputusan usang itu dibuat oleh perangkat lunak yang tidak punya alasan untuk membatalkannya. Terowongan adalah bagian yang terlihat, dan juga satu-satunya bagian dengan jalur penghentian yang bersih. Sisanya adalah pengaturan di penyimpanan yang hidup lebih lama dari prosesnya, jadi menghapus aplikasi adalah satu-satunya langkah yang membalik ketiganya sekaligus. Membaca penyimpanan itu sebelum memasang ulang adalah yang mengubah gejala menjadi diagnosis.

Tiga sisa, tiga kegagalan berbeda

Sisa pertama adalah proxy yang menunjuk ke ketiadaan: kotak proxy LAN masih tercentang, atau URL skrip konfigurasi mengarah ke porta localhost yang tidak lagi didengarkan proses apa pun. Peramban meneruskan setiap permintaan ke porta mati itu dan tersendat sampai batas waktu tampak seperti jaringan mati. Sisa kedua adalah adapter yang masih memegang rute default, karena perangkat TAP-Windows atau driver perutean vendor tetap menjadi antarmuka nyata setelah penghapusan. Ia mempertahankan rute yang diberikan padanya, dan lalu lintas menghilang ke terowongan yang tidak ada. Tak satu pun sisa itu mengumumkan dirinya; keduanya tampak persis seperti gangguan.

Yang ketiga adalah DNS, dan ia gagal lebih awal daripada dua lainnya. Jika daftar resolver hanya berisi server yang bisa dijangkau lewat terowongan, setiap pencarian habis waktu sebelum satu halaman pun diminta, sehingga peramban melaporkan situs tak terjangkau, bukan proxy mati. Mana pun yang Anda alami, tidak satu pun merupakan gangguan dalam arti jaringan. Masing-masing adalah sisa yang tidak dicabut siapa pun, dan masing-masing diperbaiki di tempat berbeda.

Telusuri keempat lapisan

Mulailah dari yang paling dekat dengan aplikasi lalu turun, karena lapisan gagal dalam urutan keterlihatan itu. Ubah satu lapisan per uji, dan uji ulang setelah tiap perubahan. Mengatur ulang semuanya sekaligus biasanya memulihkan penjelajahan, dan itu membuat Anda tak bisa mengatakan sisa mana penyebabnya, sehingga pemasangan berikutnya menciptakan teka-teki yang sama. Urutannya proxy, adapter, rute, resolver.

Di Windows setiap pemeriksaan adalah satu perintah yang sudah ada bersama sistem operasi, jadi tidak ada yang perlu dipasang. Jalankan berurutan dan simpan keluarannya bersama, karena keempat jawaban hanya bermakna bila berdampingan. Perintah itu melaporkan proxy, adapter, rute IPv4, dan daftar resolver, dalam urutan tersebut:

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

Linux dan macOS memerlukan perintahnya sendiri, dan keduanya tidak bisa saling menggantikan. Di Linux rute berasal dari ip route dan resolver dari resolvectl status bila systemd-resolved yang memilikinya, dengan cadangan cat /etc/resolv.conf. Di macOS rute berasal dari netstat -rn, resolver dari scutil --dns, dan proxy sistem dari scutil --proxy. Pembaca macOS yang menjalankan ip route mendapat command not found, dan /etc/resolv.conf di sana adalah kerangka hasil generate, bukan konfigurasi yang berwenang. Periksa platform sebelum memeriksa lapisannya, atau perintah pertama justru menjadi temuan.

Untuk setiap lapisan ajukan satu pertanyaan: apakah nilai ini masih menunjuk ke sesuatu yang ada saat aplikasi tertutup? Proxy pada porta mati, adapter tanpa terowongan, rute default lewat antarmuka yang mati, dan resolver di dalam terowongan semuanya menjawab tidak. Satu jawaban tidak sudah cukup menjelaskan gejalanya, itulah sebabnya satu perubahan per uji penting.

Proxy bukan terowongan

Proxy menerima permintaan, mengambilnya di tempat lain, dan mengembalikan responsnya, yang berarti ia tahu tujuannya dan melihat apa pun yang tidak dienkripsi situs itu sendiri. Ia tidak membawa protokol lain. Ia tidak melindungi jalur kecuali tujuan sudah memakai TLS. Dan ia bisa diubah oleh apa pun yang memasangnya, tanpa keterlibatan Anda.

Perbedaan itu mengubah pertanyaan yang layak diajukan. Ketika proxy tertinggal, cari tahu program mana yang masih mengarahkan peramban Anda, bukan apakah terowongannya menyala. Terowongan bisa sangat sehat dan sama sekali tidak relevan dengan kegagalannya.

Jika ingin tahu apa yang sebenarnya dilakukan klien semacam itu, amati ia alih-alih membaca dasbornya. Process Monitor mencatat kunci registri dan berkas mana yang disentuhnya, sedangkan penangkapan paket mengungkap ke mana lalu lintasnya pergi. Keduanya alat biasa, dan keduanya menjawab pertanyaan sisa itu lebih baik daripada lampu status mana pun. Tak satu pun menuntut aplikasinya masih berjalan.

Hapus komponennya, bukan buktinya

Perbaikan yang tahan lama adalah menghapus hal yang menulis pengaturan itu. Copot aplikasinya, hapus adapter virtual yang ditambahkannya, bersihkan proxy dan daftar resolver, lalu boot ulang dan uji dengan aplikasi tetap tercopot. Jika penjelajahan berjalan saat itu, Anda menemukan penyebabnya, bukan jalan pintas. Catat lapisan mana yang usang, karena vendor yang sama cenderung mengirim kesalahan yang sama dua kali.

Jika gejalanya kembali setelah Anda memasang klien berikutnya, telusuri lagi keempat lapisan sebelum memutuskan bahwa layanannya merusak sesuatu. Buktinya biasanya masih ada, di salah satu dari empat tempat itu. Aplikasi kedua tidak menciptakan lapisan kelima; ia menyunting salah satu dari keempatnya.

Memasang ulang mengatur ulang proxy tetapi tidak adapter yang usang, dan bisa menyisakan dua resolver di daftar. Asimetri itulah sebabnya mencopot lalu menguji mengalahkan tombol atur ulang semuanya. Itu juga memberi Anda garis dasar untuk dibandingkan saat koneksi putus lagi.