Mac VPN bir kez bağlanıyor, sonra zaman aşımına uğruyor: IKE daemonunu temizleyin

Yeniden başlatmadan sonraki ilk bağlantı çalışır. Sonraki her deneme bağlanma aşamasında takılır ve sonunda zaman aşımına uğrar, tek güvenilir çözüm bir yeniden başlatma daha. Bu örüntü bir profil sorunu değil ve bir kimlik bilgisi sorunu da değil. Arka planda bir şey hâlâ önceki denemenin durumunu tutuyor ve sonraki deneme onunla çakışıyor.

macOS'ta o şey genellikle IKE daemonudur.

Örüntü: bir bağlantı, sonra zaman aşımı

Açılışta tam olarak bir kez çalışan bir bağlantı, bağlantı kesilmesini atlatan ama yeniden başlatmayı atlatmayan bir duruma işaret eder. Profiller ikisini de atlatır, yani profil değişken değildir. Kimlik bilgileri de ikisini atlatır, sunucu hesabı kilitlemedikçe. Yeniden başlatmada değişen şey çalışan daemonlar kümesi ve tuttukları soketlerdir.

Bu, tek bir günlük açmadan önce soruşturmayı daraltır. Soru, hangi sürecin IKE bağlantı noktasına sahip olduğu ve ne yaptığını sandığı olur.

İki daemon, tek bağlantı noktası

Sistem çalıştırır racoon bir bağlantı IKE sürüm 1 konuştuğunda. Güncel sürümler ayrıca getirir iked IKEv2 ve daha yeni IPsec yığını için. İkisi de UDP 500 ve UDP 4500'ü tutabilir ve ikisi de bağlantı denemesi parola isteminde iptal edildikten veya ağ değişikliğiyle kesildikten sonra yarı açık bir güvenlik ilişkisi tutabilir.

Bu olduğunda, sonraki deneme temiz başlamaz. Eski ilişki hâlâ eşin durumunu tutarken müzakere etmeye çalışır ve alışveriş açık bir hatayla başarısız olmak yerine takılır. Kullanıcı dönen bir gösterge görür, ardından zaman aşımı.

Bir şeyi öldürmeden önce sahibini bulun, çünkü cevap hangi hizmeti yeniden başlatacağınızı ve sonra hangi günlüğü okuyacağınızı belirler.

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

Çıktıyı iki olgu olarak okuyun: hangi sürecin bağlantı noktasını tuttuğu ve birden fazla olup olmadığı. Aynı soket için yarışan iki IKE daemonu, kararsız bir sunucu gibi görünen birçok kesintili davranışı açıklar.

Süreci değil işi yeniden başlatın

Eski sistemlerde süreci öldürüp sonraki bağlantının onu yeniden başlatmasına izin vermek yeterlidir. Güncel sürümlerde daemon launchd tarafından yönetilir ve yalnızca sürece sinyal göndermek işi ne çalıştığı ne de başlamak üzere planlandığı bir durumda bırakabilir. Bunun yerine işi durdurun ve başlatın.

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

launchd'de işin kaydı yoksa, süreci adıyla öldürmek yine de sonraki denemede yeni bir müzakereyi zorlar. Test her iki durumda da aynıdır: yeniden bağlanmayı denediğinizde hiçbir süreç bağlantı noktasını tutmamalıdır. Bunu aynı komutla doğrulayın lsof yeniden başlatmanın işe yaradığını varsaymak yerine.

Sonra bir kez bağlanın ve istemci günlüğünü baştan okuyun. 1. aşamayı geçip ardından iletim hatası bildiren bir müzakere, yerel soket sorununu yineliyordur; eşin reddettiği bir müzakere tamamen başka bir bilet.

Sunucu reddeden taraf olduğunda

Her ikinci bağlantı yerel olarak başarısız olmaz. Sunucu, bağlantı kesildikten sonra sabit bir pencere boyunca yeni oturum açmayı reddedebilir ve istemcinin zaman aşımı takılı bir daemonla aynı görünür. Ayrım ucuzdur: daemonu yeniden başlatmak yardımcı olmuyor ama başka bir hesap hemen bağlanıyorsa pencere sunucu tarafındadır ve Mac hiçbir zaman sorun olmamıştır.

Bölünmüş tünel ilkesi aynı biçimi diğer yönden üretir. Tüm trafiği tünelde isteyen bir sunucu, bölünmüş tünel için yapılandırılmış istemciyi müzakere sırasında düşürür ve istemci ilke reddi yerine zaman aşımı bildirir. Profili her şeyi tünelden gönderecek şekilde değiştirmek bağlantıyı kurabilir, ancak bu ağ sahibiyle birlikte alınacak bir ilke kararıdır, sessizce uygulanacak bir onarım değil.

İstemciyi yeniden değiştirmeden önce eşin günlüğünü okuyun. Red, ilke uyuşmazlığı ve sessiz düşürme, Mac ekranında hepsi “bağlanıyor” gibi görünen üç farklı nedendir.

Eski istemciler ve 64 bit çekirdek

Eski Cisco IPSec istemcisi 32 bit ve PowerPC sistemler için derlenmiş bir çekirdek uzantısı yükler. 64 bit çekirdeğe açılan bir Mac'te bu uzantı yüklenemez ve istemci VPN alt sistemine hiç ulaşamadığı için 51 hatasıyla erken başarısız olur. Yanlış mimariye sahip bir çekirdek uzantısını hiçbir daemon yeniden başlatması düzeltmez.

Uzantıyı yeniden yüklemek bir süre çalışabilir ve sonraki açılışta yeniden başarısız olabilir. Kalıcı yanıtlar, eski çekirdeği hâlâ desteklendiği yerde çalıştırmak veya sistemle gelen yerleşik istemciye geçmektir. Yüklenemeyen bir üçüncü taraf istemcisine bir akşam harcamadan önce mimariyi kontrol edin.

• Bir kez yeniden üretin, sonra profile dokunmadan önce hangi daemonun UDP 500'ü tuttuğunu kontrol edin.
• 1. aşamadan sonraki ilk başarısızlığı okuyun: iletim hatası yerel sokete işaret eder.
• Yalnızca süreci değil launchd işini yeniden başlatın ve bağlantı noktasının boş olduğunu doğrulayın.
• Sunucu tarafındaki yeniden kimlik doğrulama penceresini istemci arızasından ayırmak için ikinci bir hesap deneyin.
• İstemciyi suçlamadan önce çekirdek mimarisini not edin.

Tam olarak bir kez çalışan bir VPN, aksi kanıtlanana kadar bir durum sorunudur. Daemonu temizlemek yeniden başlatmaktan hızlıdır ve yeniden başlatmanın atacağı günlük kanıtlarını korur.