Cara memeriksa status VPN tanpa ping di Android, iOS, dan Windows

Ping hanya membuktikan bahwa satu host menjawab, bukan bahwa terowongan aktif. Tanyakan API status Android, iOS, dan Windows, lalu verifikasi rute yang benar-benar dibutuhkan aplikasi Anda.

Melakukan ping ke 192.0.2.10 hanya memberi tahu Anda bahwa satu alamat menjawab gema ICMP, dan hanya itu. Pada jaringan tanpa terowongan, ping tetap bisa berhasil karena alamat itu mungkin berada di subnet lokal; dengan terowongan yang sehat, ping bisa gagal karena server membuang ICMP saat melayani HTTPS. Pemeriksaan yang dibutuhkan skrip Anda adalah kueri status platform ditambah uji rute ke tujuan yang dipakai aplikasi. Perlakukan keduanya sebagai dua bidang terpisah, jangan pernah sebagai satu boolean.

Apa yang sebenarnya dibuktikan balasan gema

ICMP adalah protokol keterjangkauan yang tidak mengenal antarmuka atau terowongan. Saat balasan tiba, kernel melaporkan bahwa sebuah host merespons; ia tidak melaporkan rute yang membawa permintaan atau yang membawa jawaban. Penyaringan membuat sinyal makin berisik, karena firewall yang memblokir permintaan gema tidak mengatakan apa pun tentang porta di belakangnya. Dan profil terowongan terpisah dapat dengan sengaja mengecualikan alamat yang diuji sementara semua tujuan lain berfungsi.

Yang sebenarnya ingin Anda ketahui adalah apakah layanan tertentu dapat dipakai melalui jalur yang ditempuh aplikasi. Pilih host dan porta yang dipanggil aplikasi, lalu tuntut jawaban di lapisan aplikasi.

Keterjangkauan dan status terowongan adalah dua fakta berbeda, dan salah satunya bisa benar sementara yang lain salah. Memisahkannya memberi tahu Anda siapa pemilik kegagalan. Menggabungkannya menjadi satu pemeriksaan menghasilkan tiket yang tidak bisa dirutekan siapa pun.

Mintalah transport ke Android, bukan ping

Android menjawab pertanyaan status secara langsung melalui ConnectivityManager. Kemampuan jaringan aktif membawa bendera transport VPN, yang disetel saat lalu lintas dirutekan melalui antarmuka VPN. Panggilan ini lokal, murah, dan tidak bergantung pada apakah ada host jarak jauh yang menjawab.

Versi Java ini mengembalikan false alih-alih melempar pengecualian saat tidak ada jaringan aktif. Karena membaca jaringan aktif, ia mencerminkan profil yang dipilih pengguna di Setelan.

ConnectivityManager cm = (ConnectivityManager) getSystemService(CONNECTIVITY_SERVICE);
NetworkCapabilities caps = cm.getNetworkCapabilities(cm.getActiveNetwork());
boolean tunnel = caps != null && caps.hasTransport(NetworkCapabilities.TRANSPORT_VPN);

Untuk notifikasi perubahan, daftarkan NetworkCallback alih-alih melakukan polling dengan timer. Jangan mencampurnya dengan VpnService.prepare, yang hanya melaporkan apakah pengguna memberi izin untuk VPN, bukan apakah paket mengalir. Pencabutan datang melalui VpnService.onRevoke, namun melupakan profil di Setelan tidak menghasilkan siaran apa pun.

iOS: nama antarmuka adalah heuristik, bukan kontrak

Banyak cuplikan iOS memeriksa pengaturan proxy, menemukan kamus __SCOPED__, dan mencari kunci antarmuka seperti tap, tun, utun2, ppp, atau ipsec. Pendekatan itu adalah konvensi penamaan, bukan jaminan terdokumentasi, sehingga pembaruan OS yang mengganti nama antarmuka dapat merusaknya. Ia juga cenderung melaporkan true untuk entri usang yang bertahan lebih lama daripada terowongan.

Saat aplikasi Anda memiliki konfigurasi, NEVPNManager memberi status sungguhan. Ia menjelaskan terowongan yang dijalankan aplikasi Anda; dengan VPN per aplikasi, aplikasi lain bisa berada sepenuhnya di luar terowongan itu.

Muat ulang preferensi sebelum membaca status, karena nilainya berubah saat terowongan naik dan turun:

let manager = NEVPNManager.shared()
manager.loadFromPreferences { error in
    let up = manager.connection.status == .connected
    print(up)
}

Bendera status platform tetap tidak membuktikan bahwa lalu lintas mencapai peer. Celah itulah yang ditutup uji rute, dan itulah sebabnya satu boolean tidak cukup untuk dukungan.

Profil Windows mengekspos bidang status sungguhan

Windows melacak profil VPN secara terpisah dari adaptor, dan Get-VpnConnection mengekspos ConnectionStatus untuk setiap profil yang dikenalnya. Profil yang dibuat melalui klien Windows atau paket provisi muncul di sini. Cmdlet ini bukan pendeteksi terowongan umum.

Baca bidang itu untuk profil bernama, tambahkan -AllUserConnection bila profil milik semua pengguna:

Get-VpnConnection -Name "Fabrikam" | Select-Object Name, ConnectionStatus, ServerAddress

Klien pihak ketiga sering tetap tak terlihat oleh cmdlet ini bahkan saat terowongannya aktif, jadi hasil kosong berarti tidak diketahui, bukan terputus. Daftar adaptor sama menyesatkannya: adaptor vendor dapat bertahan saat menganggur, dan sebagian adaptor hanya ada selama sesi. Untuk profil milik Windows, rasdial melaporkan kode keluar yang bisa Anda percabangkan. Semua ini menggambarkan keyakinan lokal, bukan keterjangkauan peer.

Status plus rute: pemeriksaan dua bagian

Profil yang terhubung tidak mengatakan apa pun tentang ke mana paket pergi. Terowongan terpisah dapat menjaga terowongan tetap aktif sambil mengecualikan tujuan yang Anda pedulikan. Profil always-on tetap terhubung dengan server mati, dan kill switch sengaja memblokir lalu lintas saat terowongan putus.

Uji kedua lapisan: pastikan transport VPN atau profil aktif, lalu pastikan tujuan berhasil diresolusi dan menjawab melalui jalur itu. Di Linux, tanyakan ke kernel antarmuka mana yang akan dipakai:

ip route get 192.0.2.10
resolvectl query intranet.example.test

Saat klien di luar kendali Anda, catat kedua hasil dan biarkan pola menunjuk lapisannya. Terhubung plus uji rute gagal mengisyaratkan terowongan terpisah, DNS, atau kebijakan. Terputus plus uji rute berhasil berarti jalur lain yang membawa lalu lintas.

Uji yang dapat Anda jalankan secara berurutan

Catat status platform lebih dulu, sebelum Anda mengubah keadaan jaringan apa pun. Resolusikan nama host dan catat keluarga alamat, karena catatan AAAA dapat menempuh jalur berbeda dari catatan A. Buka porta layanan dan tuntut jawaban aplikasi, bukan sekadar jabat tangan. Simpan setiap pengamatan di bidang lognya sendiri.

Pada mesin Linux dengan dig dan curl, tiga perintah mencakup resolusi, rute, dan layanan itu sendiri. Jalankan saat terowongan aktif dan lagi saat mati:

dig +short intranet.example.test
ip route get 198.51.100.20
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 https://intranet.example.test/health

Empat bidang terpisah mengalahkan satu boolean, karena status, DNS, rute, dan kebijakan gagal secara independen dan berakhir di tim berbeda. Ping di terminal tetap menjadi pemeriksaan kewajaran manual yang baik. Ia definisi konektivitas yang buruk untuk otomasi, di mana API platform dan uji rute menjawab pertanyaan sebenarnya.

Artikel terkait