Antarmuka utun VPN di Mac aktif tetapi lalu lintas gagal? Periksa ifconfig

Anda menghubungkan VPN, menjalankan ifconfig, dan menemukan entri utun4 dengan alamat di atasnya. Situs yang Anda butuhkan masih kehabisan waktu. Celah itu normal: daftar membuktikan antarmuka virtual ada, bukan bahwa klien Anda memilikinya, bahwa rute yang Anda pedulikan memilihnya, atau bahwa paket melewatinya. Saya berhenti mempercayai nama antarmuka setelah menghabiskan satu sore menyalahkan terowongan yang salah di laptop yang sudah memiliki tiga entri utun sebelum saya memasang apa pun.

Apa yang sebenarnya dikandung satu baris utun

Jalankan ifconfig -a saat Anda menginginkan gambaran lengkap. Dipanggil tanpa argumen, ifconfig hanya mencetak antarmuka yang sedang aktif, sehingga terowongan yang gagal dimulai bisa hilang dari keluaran yang orang tempelkan ke tiket. ifconfig -l hanya mengembalikan namanya, dan itu cara tercepat untuk tahu apakah utun baru muncul setelah Anda terhubung.

Membaca satu antarmuka adalah tempat detail berguna berada. Terowongan yang terhubung biasanya terlihat seperti ini:

utun4: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1380
    inet 10.8.0.6 --> 10.8.0.5 netmask 0xffffffff
    inet6 fe80::ce81:b1c:bd2c:69e%utun4 prefixlen 64 scopeid 0x15

Tiga bidang membawa jawabannya. UP dan RUNNING mengatakan bahwa kernel bersedia memakai antarmuka itu. POINTOPOINT bersama alamat sejawat --> adalah tanda tangan terowongan, bukan tautan fisik. Nilai mtu menjelaskan satu kelas laporan «tersambung lalu macet», karena antarmuka utun biasanya naik dengan MTU yang diperkecil, 1380 pada beberapa build macOS, dan klien dapat menimpanya. Daftar bidangnya cukup singkat untuk dipindai sekali di manual ifconfig yang disediakan Apple.

Temukan proses di balik antarmuka

ifconfig tidak punya konsep aplikasi pemilik. Dua klien VPN, satu layanan sistem, dan terowongan sisa minggu lalu semuanya menghasilkan entri yang tampak identik pada tingkat ini. Di Mac saya sendiri, utun0 sampai utun3 sudah ada sebelum saya mengonfigurasi apa pun; Continuity dan iCloud Private Relay juga memakai terowongan, dan tidak satu pun dari itu adalah koneksi yang sedang Anda telusuri.

Untuk terowongan yang mendaftarkan konfigurasi ke sistem, scutil --nc list adalah korelasi tercepat. Ia mencetak setiap konfigurasi dengan status dan ID layanannya, dan yang terhubung ditandai seperti ini:

scutil --nc list
* (Connected)   5F2A9C10-...   VPN  Work IKEv2

Klien yang menjalankan proses terowongannya sendiri alih-alih mendaftarkan konfigurasi tidak pernah muncul di sana. Tunnelblick dan instans openvpn dari baris perintah termasuk kelompok itu, jadi periksa juga tabel proses: ps -Ao pid,comm | grep -i openvpn. Begitu sebuah proses memiliki terowongan, nomor utun menjadi milik proses itu dan bukan milik siapa pun lagi.

Uji alamatnya sebelum menguji rutenya

Antarmuka bisa aktif tanpa alamat yang bisa dipakai. Profil hanya-IPv6 menampilkan entri fe80:: lokal tautan dan tidak ada apa pun di baris inet, dan klien yang gagal menerapkan alamat yang didorong meninggalkan bentuk yang persis sama. Jika tujuan Anda IPv4 dan terowongan tidak punya alamat IPv4, pertanyaan perutean sudah selesai.

MTU layak diperiksa terpisah, karena kegagalannya tidak terlihat seperti masalah ukuran. Ia terlihat seperti koneksi yang mengautentikasi lalu diam begitu transfer besar dimulai. Kirim probe yang tidak boleh difragmentasi, berukuran sehingga paket cocok dengan MTU antarmuka; untuk MTU 1400 muatannya adalah 1372 bita:

ping -D -s 1372 10.8.0.5

Balasan berarti paket sebesar itu melewati terowongan. Diam sementara ping kecil berhasil menunjuk ke MTU atau ke sesuatu yang menjatuhkan ICMP di jalur, bukan ke autentikasi, yang sudah selesai sebelum Anda mendapat antarmuka.

Buktikan bahwa tujuan yang memilih terowongan

Pertanyaan pentingnya bukan apakah utun4 ada, melainkan apakah lalu lintas ke satu alamat tertentu keluar melaluinya. route -n get menjawabnya untuk satu tujuan dan mencetak gerbang serta antarmuka yang akan dipakai:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Jika perintah yang sama melaporkan en0, konfigurasi split-tunnel Anda melakukan apa yang diperintahkan dan tidak ada pemeriksaan antarmuka yang akan mengubahnya. Gunakan netstat -rn -f inet saat Anda memerlukan rute bawaan dan seluruh tabel dalam satu tampilan.

Penghitung yang memutuskan apakah paket benar-benar bergerak. netstat -ib melaporkan total paket dan bita per antarmuka, termasuk entri utun; angkanya kumulatif, jadi bacalah dua kali dengan jeda lalu bandingkan:

netstat -ib | grep utun4

Penghitung yang membeku sementara aplikasi terus mencoba berarti kernel tidak pernah menyerahkan paket ke antarmuka. Penghitung yang naik di kedua arah sementara aplikasi masih gagal memindahkan penyelidikan ke ujung jauh terowongan.

Ketika tidak ada utun yang muncul sama sekali

Daftar antarmuka yang kosong setelah login yang tampak berhasil biasanya berarti terowongannya tidak pernah dimulai, bukan bahwa ifconfig menyembunyikannya. Periksa status klien itu sendiri, lalu status sistem: ekstensi jaringan yang tidak pernah disetujui, atau yang dinonaktifkan macOS setelah pembaruan, tidak meninggalkan antarmuka di belakangnya. Persetujuan itu ada di Pengaturan Sistem di bawah Login Items & Extensions, dan entri usang di sana layak diaktifkan ulang sebelum Anda memasang ulang apa pun.

Penomoran utun tidak stabil antar penyambungan ulang. Anda bisa mendapat utun5 di tempat utun4 ada sepuluh menit lalu, karena antarmuka lama dibongkar dan kernel memberikan indeks bebas berikutnya. Skrip yang menanamkan nama secara keras rusak diam-diam pada saat itu; cocokkan dengan alamat atau dengan rutenya saja.

Jaga sisi pembacaan tetap hanya-baca. sudo ifconfig utun4 down memutus terowongan, dan pada profil terowongan penuh ia membawa serta sesi jarak jauh Anda, yang merupakan pertukaran buruk ketika Anda hanya berusaha mengumpulkan bukti. Tidak ada yang Anda butuhkan di sini memerlukan root: membaca bendera, alamat, dan penghitung semuanya bekerja sebagai pengguna biasa.

Kerjakan pemeriksaan itu secara berurutan saat terowongan Mac berikutnya berperilaku buruk: pastikan utun muncul dengan ifconfig -l, baca benderanya, alamatnya, dan MTU-nya, kaitkan ke sebuah proses, tanyakan kepada route -n get antarmuka mana yang dipakai tujuan, lalu amati netstat -ib bergerak. Setiap langkah menyingkirkan lapisan yang berbeda, dan langkah pertama yang kembali salah adalah tempat perbaikannya.