VPN Mac terhubung sekali, lalu waktu habis: bersihkan daemon IKE

Koneksi pertama setelah boot ulang berfungsi. Setiap percobaan sesudahnya menggantung di tahap koneksi dan akhirnya waktu habis, dan satu-satunya obat yang andal adalah boot ulang lagi. Pola itu bukan masalah profil dan bukan masalah kredensial. Sesuatu di latar belakang masih memegang status dari percobaan sebelumnya, dan percobaan berikutnya bertabrakan dengannya.

Di macOS, sesuatu itu biasanya daemon IKE.

Polanya: koneksi sekali, lalu waktu habis

Koneksi yang berfungsi tepat sekali per boot menunjuk ke status yang bertahan dari pemutusan tetapi tidak dari boot ulang. Profil bertahan dari keduanya, jadi profil bukan variabelnya. Kredensial juga bertahan dari keduanya, kecuali server mengunci akun. Yang berubah saat boot ulang adalah kumpulan daemon yang berjalan dan soket yang mereka pegang.

Itu mempersempit penyelidikan sebelum Anda membuka satu log pun. Pertanyaannya menjadi proses mana yang memiliki port IKE dan apa yang ia kira sedang dilakukannya.

Dua daemon, satu port

Sistem menjalankan racoon ketika koneksi berbicara IKE versi 1. Rilis saat ini juga membawa iked untuk IKEv2 dan tumpukan IPsec yang lebih baru. Keduanya dapat memakai UDP 500 dan UDP 4500, dan keduanya dapat menyimpan asosiasi keamanan setengah terbuka setelah percobaan koneksi dibatalkan di prompt kata sandi atau terganggu oleh perubahan jaringan.

Ketika itu terjadi, percobaan berikutnya tidak mulai bersih. Ia mencoba bernegosiasi sementara asosiasi lama masih menempati status peer, dan pertukaran itu mandek alih-alih gagal dengan kesalahan yang jelas. Pengguna melihat indikator berputar, lalu waktu habis.

Temukan pemiliknya sebelum membunuh apa pun, karena jawabannya menentukan layanan mana yang Anda mulai ulang dan log mana yang Anda baca berikutnya.

sudo lsof -i :500 -i :4500
ps -ef | grep -E "racoon|iked"

Baca outputnya sebagai dua fakta: proses mana yang memegang port, dan apakah ada lebih dari satu. Dua daemon IKE yang bersaing untuk soket yang sama menjelaskan banyak perilaku intermiten yang tampak seperti server yang tidak stabil.

Mulai ulang tugasnya, bukan prosesnya

Pada sistem lama, membunuh proses dan membiarkan koneksi berikutnya memulainya lagi sudah cukup. Pada rilis saat ini daemon dikelola oleh launchd, dan mengirim sinyal hanya ke proses dapat meninggalkan tugas dalam keadaan tidak berjalan dan tidak terjadwal untuk mulai. Hentikan dan jalankan tugasnya.

sudo launchctl stop com.apple.racoon
sudo launchctl start com.apple.racoon

Jika launchd tidak punya catatan tugas itu, membunuh proses berdasarkan nama tetap memaksa negosiasi baru pada percobaan berikutnya. Ujinya sama saja: tidak boleh ada proses yang memegang port saat Anda mencoba terhubung lagi. Pastikan itu dengan perintah yang sama lsof alih-alih menganggap boot ulang berhasil.

Lalu hubungkan sekali dan baca log klien dari awal. Negosiasi yang melewati fase 1 lalu melaporkan kegagalan transmisi mengulangi masalah soket lokal; negosiasi yang ditolak oleh peer adalah tiket yang sama sekali berbeda.

Ketika serverlah yang menolak

Tidak setiap koneksi kedua gagal secara lokal. Server dapat menolak login baru untuk jendela tetap setelah pemutusan, dan waktu habis di klien terlihat identik dengan daemon yang macet. Pembedanya murah: jika memulai ulang daemon tidak membantu tetapi akun lain langsung terhubung, jendelanya ada di sisi server dan Mac tidak pernah menjadi masalah.

Kebijakan tunnel terpisah menghasilkan bentuk yang sama dari arah lain. Server yang menuntut semua lalu lintas di tunnel akan menjatuhkan klien yang dikonfigurasi untuk tunnel terpisah selama negosiasi, dan klien melaporkan waktu habis alih-alih penolakan kebijakan. Mengubah profil untuk mengirim semuanya lewat tunnel mungkin membuatnya terhubung, tetapi itu keputusan kebijakan yang harus diambil bersama pemilik jaringan, bukan perbaikan yang diterapkan diam-diam.

Baca log peer sebelum mengubah klien lagi. Penolakan, ketidakcocokan kebijakan, dan penjatuhan senyap adalah tiga penyebab berbeda yang semuanya tampak “menghubungkan” di layar Mac.

Klien lama dan kernel 64-bit

Klien Cisco IPSec lama memuat ekstensi kernel yang dibangun untuk sistem 32-bit dan PowerPC. Pada Mac yang boot ke kernel 64-bit, ekstensi itu tidak dapat dimuat, dan klien gagal lebih awal dengan kesalahan 51 karena sama sekali tidak mencapai subsistem VPN. Berapa kali pun daemon dimulai ulang, ekstensi kernel dengan arsitektur yang salah tidak akan terbentuk.

Memuat ulang ekstensi bisa berhasil untuk sementara lalu gagal lagi pada boot berikutnya. Jawaban yang tahan lama adalah menjalankan kernel lama di tempat yang masih didukung, atau pindah ke klien bawaan yang disertakan sistem. Periksa arsitekturnya sebelum menghabiskan satu malam untuk klien pihak ketiga yang tidak dapat dimuat.

• Reproduksi sekali, lalu periksa daemon mana yang memiliki UDP 500 sebelum menyentuh profil.
• Baca kegagalan pertama setelah fase 1: kesalahan transmisi menunjuk ke soket lokal.
• Mulai ulang tugas launchd, bukan hanya prosesnya, dan pastikan port-nya bebas.
• Coba akun kedua untuk memisahkan jendela autentikasi ulang di sisi server dari kerusakan klien.
• Catat arsitektur kernel sebelum menyalahkan klien.

VPN yang berfungsi tepat sekali adalah masalah status sampai terbukti sebaliknya. Membersihkan daemon lebih cepat daripada boot ulang, dan itu menyimpan bukti log yang akan dibuang oleh boot ulang.