VPN Mac bersambung sekali, kemudian tamat masa: bersihkan daemon IKE

Sambungan pertama selepas but semula berfungsi. Setiap percubaan selepas itu tergantung pada peringkat menyambung dan akhirnya tamat masa, dan satu-satunya ubat yang boleh dipercayai ialah but semula lagi. Corak itu bukan masalah profil dan bukan masalah kelayakan. Sesuatu di latar belakang masih memegang keadaan daripada percubaan sebelumnya, dan percubaan seterusnya berlanggar dengannya.

Pada macOS, sesuatu itu biasanya daemon IKE.

Coraknya: sambung sekali, kemudian tamat masa

Sambungan yang berfungsi tepat sekali setiap but menunjukkan keadaan yang bertahan selepas putus tetapi tidak selepas but semula. Profil bertahan kedua-duanya, jadi profil bukan pemboleh ubah. Kelayakan juga bertahan kedua-duanya, melainkan pelayan mengunci akaun. Apa yang berubah semasa but semula ialah set daemon yang berjalan dan soket yang dipegangnya.

Itu menyempitkan penyiasatan sebelum anda membuka satu log pun. Persoalannya menjadi proses mana yang memiliki port IKE dan apa yang disangkanya sedang dilakukan.

Dua daemon, satu port

Sistem menjalankan racoon apabila sambungan bercakap IKE versi 1. Keluaran semasa juga membawa iked untuk IKEv2 dan tindanan IPsec yang lebih baharu. Kedua-duanya boleh mengikat UDP 500 dan UDP 4500, dan kedua-duanya boleh menyimpan persatuan keselamatan separuh terbuka selepas percubaan sambungan dibatalkan pada gesaan kata laluan atau terganggu oleh perubahan rangkaian.

Apabila itu berlaku, percubaan seterusnya tidak bermula bersih. Ia cuba berunding sementara persatuan lama masih menduduki keadaan rakan, dan pertukaran terhenti dan bukannya gagal dengan ralat yang jelas. Pengguna melihat penunjuk berputar, kemudian tamat masa.

Cari pemiliknya sebelum membunuh apa-apa, kerana jawapannya menentukan perkhidmatan mana yang anda mulakan semula dan log mana yang anda baca seterusnya.

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

Baca output sebagai dua fakta: proses mana yang memegang port, dan sama ada terdapat lebih daripada satu. Dua daemon IKE yang bersaing untuk soket yang sama menjelaskan banyak tingkah laku berselang-seli yang kelihatan seperti pelayan tidak stabil.

Mulakan semula tugas, bukan proses

Pada sistem lama, membunuh proses dan membiarkan sambungan seterusnya memulakannya semula sudah memadai. Pada keluaran semasa daemon diurus oleh launchd, dan menghantar isyarat kepada proses sahaja boleh meninggalkan tugas dalam keadaan tidak berjalan dan tidak dijadualkan untuk bermula. Hentikan dan mulakan tugas itu.

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

Jika launchd tiada rekod tugas itu, membunuh proses mengikut nama masih memaksa rundingan baharu pada percubaan seterusnya. Ujiannya sama dalam kedua-dua kes: tiada proses sepatutnya memegang port apabila anda cuba menyambung semula. Sahkan perkara itu dengan arahan yang sama lsof bukannya menganggap but semula berjaya.

Kemudian sambung sekali dan baca log klien dari awal. Rundingan yang melepasi fasa 1 dan kemudian melaporkan kegagalan penghantaran mengulangi masalah soket setempat; rundingan yang ditolak oleh rakan ialah tiket yang sama sekali berbeza.

Apabila pelayan yang menolak

Bukan setiap sambungan kedua gagal secara setempat. Pelayan boleh menolak log masuk baharu untuk tetingkap tetap selepas putus, dan tamat masa klien kelihatan sama seperti daemon tersekat. Pembezanya murah: jika memulakan semula daemon tidak membantu tetapi akaun lain bersambung serta-merta, tetingkap itu di pihak pelayan dan Mac tidak pernah menjadi masalah.

Dasar terowong berpecah menghasilkan bentuk yang sama dari arah lain. Pelayan yang menuntut semua trafik dalam terowong akan menggugurkan klien yang dikonfigurasikan untuk terowong berpecah semasa rundingan, dan klien melaporkan tamat masa dan bukannya penolakan dasar. Menukar profil untuk menghantar semuanya melalui terowong mungkin membuatnya bersambung, tetapi itu keputusan dasar yang perlu dibuat dengan pemilik rangkaian, bukan pembaikan yang diterapkan secara senyap.

Baca log rakan sebelum menukar klien lagi. Penolakan, ketidakpadanan dasar dan pengguguran senyap ialah tiga sebab berbeza yang semuanya kelihatan seperti “menyambung” pada skrin Mac.

Klien lama dan kernel 64-bit

Klien Cisco IPSec lama memuatkan sambungan kernel yang dibina untuk sistem 32-bit dan PowerPC. Pada Mac yang but ke dalam kernel 64-bit, sambungan itu tidak dapat dimuatkan, dan klien gagal awal dengan ralat 51 kerana ia langsung tidak mencapai subsistem VPN. Berapa kali pun daemon dimulakan semula, sambungan kernel dengan seni bina yang salah tidak akan baik.

Memuat semula sambungan boleh berfungsi sebentar dan kemudian gagal lagi pada but seterusnya. Jawapan yang tahan lama ialah menjalankan kernel lama di tempat ia masih disokong, atau beralih kepada klien terbina dalam yang disertakan dengan sistem. Periksa seni bina sebelum menghabiskan satu malam pada klien pihak ketiga yang tidak dapat dimuatkan.

• Hasilkan semula sekali, kemudian periksa daemon mana yang memiliki UDP 500 sebelum menyentuh profil.
• Baca kegagalan pertama selepas fasa 1: ralat penghantaran menunjuk kepada soket setempat.
• Mulakan semula tugas launchd, bukan hanya proses, dan sahkan port itu bebas.
• Cuba akaun kedua untuk memisahkan tetingkap pengesahan semula di pihak pelayan daripada kerosakan klien.
• Catat seni bina kernel sebelum menyalahkan klien.

VPN yang berfungsi tepat sekali ialah masalah keadaan sehingga dibuktikan sebaliknya. Membersihkan daemon lebih pantas daripada but semula, dan ia mengekalkan bukti log yang akan dibuang oleh but semula.