Status VPN di macOS dari terminal: scutil, rute, atau ping

Di suatu tempat dalam skrip penerapan ada pemeriksaan apakah terowongan aktif sebelum penyalinan dimulai. Tersedia tiga jawaban, dan ketiganya tidak berarti sama: status layanan yang dilaporkan scutil, rute yang dipilih kernel, dan apakah ujung jauh benar-benar membalas. Membandingkannya adalah beda antara pemeriksaan yang memprediksi penyalinan dan yang hanya menghias log.

Tiga jawaban untuk pertanyaan apakah VPN aktif

Status layanan adalah fakta bidang kendali. macOS tahu sebuah konfigurasi terhubung karena proses kliennya mengatakan demikian. Rute adalah fakta bidang data: kernel akan mengirim tujuan ini melalui antarmuka itu. Keterjangkauan adalah fakta ujung ke ujung, dan bisa gagal karena alasan yang tidak dilihat kedua yang lain.

Pemeriksaan yang berguna menggabungkan dua yang pertama dan memakai yang ketiga sebagai konfirmasi bahwa dua lainnya tidak berbohong. Salah satu saja hanyalah tebakan dengan stempel waktu.

Baca pengenalnya, bukan nama tampilannya

scutil --nc list
scutil --nc status "Office"

Daftar mencetak satu baris per layanan, dan setiap baris memuat status dalam tanda kurung diikuti pengenal layanan, jenis, dan nama tampilan. Tulis skrip berdasarkan pengenal, karena nama tampilan adalah yang diketik seseorang di Pengaturan Sistem dan bisa berubah tanpa pemberitahuan. Perintah status mencetak satu kata diikuti statistik untuk beberapa jenis layanan; cocokkan kata pertama itu alih-alih mencari nama di seluruh keluaran, yang juga muncul di tempat lain.

Memulai layanan dapat memunculkan permintaan otorisasi atau ditolak mentah-mentah bila profil dikelola. Penolakan itu bukan kerusakan terowongan; itu pernyataan kebijakan tentang siapa yang boleh menyalakannya.

Klien pihak ketiga bersembunyi dari daftar

Daftar kosong tidak berarti tidak ada VPN. Konfigurasi yang dibuat di pengaturan jaringan sistem sendiri muncul di sini; klien vendor, profil manajemen, atau aplikasi pihak ketiga dapat memegang terowongan aktif yang tidak pernah dilihat perintah ini. Alatnya sendiri adalah otoritas untuk layanannya sendiri. Menanyakan scutil tentang klien yang tidak pernah mendaftar kepadanya mengembalikan kosong, dan kosong bukan jawaban yang sama dengan terputus.

Ketika daftar kosong tetapi lalu lintas jelas terenkripsi, cari antarmukanya: perangkat utun atau ppp dengan alamat dalam rentang yang diharapkan adalah bukti bahwa sesuatu membangun terowongan. Itu sinyal yang lebih lemah daripada status layanan, jadi pasangkan dengan pemeriksaan rute alih-alih memperlakukan antarmuka sebagai bukti identitas. Beberapa klien dapat membuat beberapa antarmuka semacam itu, dan hanya satu yang termasuk terowongan yang Anda maksud.

Status bukan perutean

Layanan yang terhubung mengatakan terowongan itu ada. Itu tidak mengatakan tujuan Anda memakainya. Baca alamatnya, lalu tanyakan langsung ke kernel:

ifconfig | grep -A4 utun
netstat -rn -f inet
route -n get 10.40.0.20

Klien terowongan penuh memasang rute default melalui terowongan; klien terowongan terpisah memasang prefiks privat tertentu. Keduanya melaporkan Connected, dan skrip yang hanya memeriksa status akan dengan senang hati berjalan di jalur yang salah. Menghentikan terowongan tidak selalu menghapus rute yang dipasang klien lain, dan itulah salah satu cara sebuah mesin berakhir dengan layanan terhubung dan rute basi pada saat yang sama. Lihat tujuan yang Anda pedulikan, bukan seluruh tabel rute.

Penamaan adalah masalah tersendiri

Mesin lain tidak dapat menjangkau Mac berdasarkan nama sementara alamatnya berfungsi, dan itu dilaporkan sebagai kerusakan VPN. Nama host lokal, nama host, dan catatan DNS adalah tiga hal berbeda. scutil --get LocalHostName menunjukkan nama Bonjour; sudo scutil --set HostName mac-office menetapkan nama yang dilaporkan sistem.

Tidak ada dari kedua pengaturan itu yang membuat catatan di zona kantor. Jika host lain harus menyelesaikan nama melalui DNS, pemilik zona harus menambahkannya, atau skrip sebaiknya memakai alamatnya. Menetapkan nama yang stabil membuat pengumuman konsisten; itu tidak membuat resolver menjawab.

Catat pengenal layanan dan bentuk rute yang diharapkan bersama-sama di skrip, dan periksa keduanya sebelum penyalinan. Terowongan yang aktif tetapi dirutekan ke arah yang salah gagal persis seperti tidak ada terowongan, dan baris log yang menyebut Connected akan mengirim orang berikutnya mencari di tempat yang salah.