Cara mendeteksi terowongan VPN aktif dari kode di platform apa pun
Apakah terowongannya ada, apakah tujuan ini melewatinya, atau ujung jauh yang menjawab? Itu tiga pemeriksaan berbeda dan tiga sinyal berbeda.
“Apakah VPN aktif?” sebenarnya tiga pertanyaan dalam satu kalimat. Mana yang dibutuhkan kode Anda adalah keputusan pertama, dan itulah yang dilewati sebagian besar implementasi. Apakah ada terowongan di perangkat ini, apakah lalu lintas ke tujuan ini keluar melaluinya, atau ujung jauh menjawab dengan identitas yang Anda harapkan. Pilih propertinya, lalu pilih sinyal yang mengukurnya, lalu tulis di log mana yang benar-benar Anda ukur.
Tiga properti, tiga sinyal
Dipadatkan jadi satu baris masing-masing, ketiga pertanyaan punya tiga jawaban berbeda. Tabel di bawah adalah keputusannya sendiri, bukan ringkasannya.
| Property | Signal that answers it | What it still leaves open |
|---|---|---|
| Existence | The platform's own connection state: RAS on Windows, NetworkManager on D-Bus on Linux, scutil on macOS | Tunnels of a type the platform does not manage, which includes most third-party clients |
| Path | A route lookup for the one destination, or a scoped proxy or interface key that names the tunnel | Whether the far end is the peer you trust |
| Identity | An authenticated response from the far end, or a source-address policy applied on the server | Which local interface carried the packets |
Baca baris terakhir perlahan. Host privat yang menjawab membuktikan ada sesuatu yang menjawab, bukan bahwa jawabannya datang lewat terowongan, dan itu tidak mengatakan apa pun tentang siapa di ujung sana. Jika properti yang Anda butuhkan adalah jalurnya, ukurlah jalurnya.
Keberadaan: status platform itu sendiri
Windows menjawab ini untuk profil asli melalui Remote Access Service API. RasEnumConnections mendaftar apa yang terhubung, RasGetConnectStatus melaporkan status satu entri, dan RasGetLinkStatistics menambahkan kecepatan, penghitung byte, dan usia koneksi. Batasannya adalah intinya: OpenVPN, WireGuard, dan klien vendor tidak pernah mendaftarkan koneksi RAS, jadi terowongan sehat jenis itu menampilkan daftar kosong dan kode naif melaporkannya sebagai mati.
Desktop Linux memaparkan properti yang sama melalui NetworkManager di D-Bus, tempat PropertiesChanged pada objek koneksi VPN mengubah pemeriksaan menjadi peristiwa dan properti State melaporkan kapan tautan mencapai status terhubung. Dari shell, nmcli connection show --active membaca informasi yang sama, dan itulah yang Anda inginkan saat men-debug. macOS menyimpan daftar itu di kerangka System Configuration, dengan scutil sebagai tampilan baris perintahnya. Ketiganya menggambarkan koneksi yang dikelola platform, dan ketiganya diam untuk terowongan yang tidak dikelolanya.
Jalur: ke mana paket sebenarnya pergi
Pencocokan nama adalah pintasan yang pertama diambil semua orang: sebutkan antarmuka, uji string terhadap tun, tap, ppp, atau ipsec, dan anggap kecocokan sebagai bukti. Itu heuristik, dan himpunan antarmuka bisa tampak sama entah ada yang bergerak melaluinya atau tidak. Build iOS lama menjawab dengan cara ini dan yang lebih baru berhenti, karena antarmuka yang terlihat tidak lagi membedakan kedua status itu.
Yang menggantikannya di sana adalah kamus proksi sistem. Selama VPN terhubung, pemanggilan pengaturan proksi mengembalikan kunci yang dibatasi pada antarmuka terkait terowongan, dan saat tidak ada yang terhubung kamus kembali kosong. Itu pernyataan yang lebih lemah daripada kedengarannya, karena mencatat keyakinan sistem bahwa terowongan ada, bukan tujuan mana yang memakainya.
Android punya versi jebakannya sendiri: siaran vpn.connectivity mencapai penerima yang dideklarasikan di manifes pada sebagian build dan penerima yang didaftarkan saat runtime pada build lain. Perlakukan sebagai upaya terbaik, dan pertahankan pemeriksaan langsung di belakangnya.
Ketika tujuannya yang penting, tanyakan tabel perutean alih-alih daftar adaptor. Heuristik gateway default rusak pada mesin multi-jaringan dan pada terowongan yang memasang gateway sendiri.
Identitas: uji ujung jauh
Loop yang mengirim gema ICMP ke ujung jauh setiap beberapa detik adalah pemeriksaan termurah jenis ini, dan ia gagal ke arah yang berguna. Arahkan ke alamat yang hanya ada di dalam jaringan privat, karena alamat publik menjawab lewat tautan atas mana pun yang berfungsi dan tidak membuktikan apa pun. Di tempat ICMP difilter, koneksi TCP singkat ke port layanan melakukan tugas yang sama.
Pemeriksaan sisi server hanya punya tepat satu sinyal: alamat sumber pada koneksi. Merawat inventaris rentang adalah pekerjaan pemeliharaan, dan itu tidak bisa memisahkan terowongan dari jaringan lain yang kebetulan memakai blok yang sama.
Kebijakan kasar bisa hidup dengan itu. Identitas tidak bisa, jadi autentikasi klien alih-alih memercayai dari mana paketnya tampak datang.
Catat kategorinya, bukan putusannya
Pisahkan kategori kegagalan di log: tidak ada antarmuka sama sekali, antarmuka ada tetapi tujuan tidak terjangkau, tujuan terjangkau tetapi autentikasi ditolak. Itu tiga pemilik berbeda, dan masing-masing membuka penyelidikan berbeda.
Menyatukannya menjadi satu “VPN mati” mengirim laporan ke tim yang tidak bisa memperbaikinya. Kategori adalah keluaran yang berguna; putusan itulah yang membuatnya salah.