Antara muka utun VPN Mac aktif tetapi trafik gagal? Semak ifconfig

Anda menyambung VPN, menjalankan ifconfig, dan menemui entri utun4 dengan alamat padanya. Laman yang anda perlukan masih tamat masa. Jurang ini normal: penyenaraian membuktikan antara muka maya wujud, bukan bahawa klien anda memilikinya, bahawa laluan yang anda pentingkan memilihnya, atau bahawa paket melaluinya. Saya berhenti mempercayai nama antara muka selepas menghabiskan satu petang menyalahkan terowong yang salah pada komputer riba yang sudah mempunyai tiga entri utun sebelum saya memasang apa-apa.

Apa sebenarnya yang terkandung dalam baris utun

Jalankan ifconfig -a apabila anda mahu gambaran penuh. Dipanggil tanpa argumen, ifconfig mencetak hanya antara muka yang sedang aktif, sebab itu terowong yang gagal bermula boleh hilang daripada output yang orang tampal dalam tiket. ifconfig -l mengembalikan hanya nama, dan itulah cara terpantas untuk tahu sama ada utun baharu muncul selepas anda menyambung.

Membaca satu antara muka ialah tempat butiran berguna berada, dan terowong yang bersambung biasanya kelihatan 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 medan membawa jawapannya. UP dan RUNNING mengatakan kernel bersedia menggunakan antara muka itu. POINTOPOINT serta --> alamat rakan ialah tandatangan terowong dan bukan pautan fizikal. mtu nilai menerangkan seluruh kelas laporan "bersambung, kemudian tersekat", kerana antara muka utun biasanya naik dengan MTU yang dikurangkan, 1380 dalam beberapa binaan macOS, dan klien boleh mengatasinya. Senarai medan cukup pendek untuk diimbas sekali dalam manual ifconfig yang dihantar Apple.

Cari proses di sebalik antara muka

ifconfig tiada konsep aplikasi pemilik. Dua klien VPN, satu perkhidmatan sistem dan terowong tinggalan minggu lepas semuanya menghasilkan entri yang kelihatan serupa pada tahap ini. Pada Mac saya sendiri, utun0 hingga utun3 sudah wujud sebelum saya mengkonfigurasi apa-apa; Continuity dan iCloud Private Relay juga menggunakan terowong, dan tiada satu pun daripadanya ialah sambungan yang anda sedang nyahpepijat.

Untuk terowong yang mendaftarkan konfigurasi dengan sistem, scutil --nc list ialah korelasi terpantas, ia mencetak setiap konfigurasi dengan status dan ID perkhidmatannya, dan yang bersambung ditanda seperti itu.

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

Klien yang menjalankan proses terowong sendiri dan tidak mendaftarkan konfigurasi tidak pernah muncul di sana. Tunnelblick dan openvpn baris arahan termasuk dalam kumpulan itu, jadi semak jadual proses juga: ps -Ao pid,comm | grep -i openvpn. Sebaik proses memiliki terowong, nombor utun milik proses itu dan tiada yang lain.

Uji alamat sebelum anda uji laluan

Antara muka boleh aktif tanpa alamat yang boleh digunakan. Profil IPv6 sahaja menunjukkan entri fe80:: pautan setempat dan tiada apa dalam baris inet, dan klien yang gagal menggunakan alamat yang ditolak meninggalkan bentuk yang sama. Jika destinasi anda IPv4 dan terowong tiada alamat IPv4, soalan penghalaan sudah selesai.

MTU patut diberi semakan berasingan, kerana kegagalan ini tidak kelihatan seperti masalah saiz. Ia kelihatan seperti sambungan yang mengesahkan identiti dan kemudian senyap sebaik pemindahan besar bermula. Hantar prob yang tidak boleh difragmentasikan, bersaiz supaya paket sepadan dengan MTU antara muka; untuk MTU 1400 muatan ialah 1372 bait:

ping -D -s 1372 10.8.0.5

Balasan bermakna paket sebesar itu melintasi terowong. Kesenyapan semasa ping kecil berjaya menunjuk kepada MTU atau kepada sesuatu yang menggugurkan ICMP di laluan, bukan kepada pengesahan identiti, yang sudah selesai sebelum anda mendapat antara muka.

Buktikan destinasi memilih terowong

Soalan yang penting bukan sama ada utun4 wujud tetapi sama ada trafik ke satu alamat tertentu keluar melaluinya. route -n get menjawabnya untuk satu destinasi dan mencetak gerbang dan antara muka yang akan digunakan:

route -n get 203.0.113.20
  gateway: 10.8.0.5
  interface: utun4

Jika arahan yang sama melaporkan en0, konfigurasi split tunneling anda melakukan apa yang diberitahu dan tiada pemeriksaan antara muka akan mengubahnya. Gunakan netstat -rn -f inet apabila anda memerlukan laluan lalai dan seluruh jadual dalam satu paparan.

Kaunter menentukan sama ada paket benar-benar bergerak. netstat -ib melaporkan jumlah paket dan bait setiap antara muka, termasuk entri utun; nombornya terkumpul, jadi baca dua kali dengan jarak dan bandingkan:

netstat -ib | grep utun4

Kaunter beku sementara aplikasi terus mencuba bermakna kernel tidak pernah menyerahkan paket kepada antara muka. Kaunter menaik dalam kedua-dua arah sementara aplikasi masih gagal memindahkan siasatan ke hujung terowong yang jauh.

Apabila utun tidak muncul langsung

Senarai antara muka kosong selepas log masuk yang kelihatan berjaya biasanya bermakna terowong tidak pernah bermula, bukan kerana ifconfig menyembunyikannya. Semak status klien itu sendiri, kemudian status sistem: Network Extension yang tidak pernah diluluskan, atau yang dilumpuhkan macOS selepas kemas kini, tidak meninggalkan antara muka. Kelulusan itu berada dalam System Settings di bawah Login Items & Extensions, dan entri lama di situ wajar ditogol semula sebelum anda memasang semula apa-apa.

Penomboran utun tidak stabil merentasi sambungan semula. Anda boleh mendapat utun5 di mana utun4 wujud sepuluh minit lalu, kerana antara muka lama diruntuhkan dan kernel memberikan indeks bebas seterusnya. Skrip yang mengekod nama secara keras rosak secara senyap pada saat itu; padankan pada alamat atau pada laluan sebaliknya.

Kekalkan bahagian bacaan sebagai baca-sahaja. sudo ifconfig utun4 down mengganggu terowong, dan pada profil terowong penuh ia membawa sesi jauh anda bersamanya, yang merupakan pertukaran buruk apabila anda hanya cuba mengumpul bukti. Tiada apa yang anda perlukan di sini memerlukan root: membaca bendera, alamat dan kaunter semuanya berfungsi sebagai pengguna biasa anda.

Lakukan semakan mengikut urutan lain kali terowong Mac berkelakuan buruk: sahkan utun muncul dengan ifconfig -l, baca bendera, alamat dan MTU-nya, kaitkan dengan proses, tanya route -n get antara muka mana yang digunakan destinasi, kemudian perhatikan netstat -ib bergerak. Setiap langkah menolak lapisan yang berbeza, dan yang pertama kembali salah ialah tempat pembaikan sepatutnya.