VPN bağlantısı kesildikten sonra Mac'in IPv6 durumu nasıl kontrol edilir

Tünel çöktükten sonra bir siteye IPv4 üzerinden ulaşmanız IPv6 hakkında hiçbir şey kanıtlamaz. macOS iki aileyi her ağ hizmeti için ayrı ayrı yapılandırır ve bir VPN istemcisi birini diğerine dokunmadan değiştirebilir. Üç katmanı sırayla inceleyin: adres yapılandırması, yol seçimi ve ardından istemcinin bağlantı kesikken kurduğu herhangi bir ilke. Bu sırada erişim ağını değiştirmeyin, yoksa iki farklı sorunu karşılaştırırsınız.

Gerçekten bozulan aileyle başlayın

IPv4 üzerinden yüklenen bir sayfa size fiziksel ağın yaşadığını söyler. Hizmetin genel bir IPv6 adresi olup olmadığını, önekin hâlâ duyurulup duyurulmadığını veya bir şeyin aileyi filtreleyip filtrelemediğini söylemez. Aracı seçmeden önce neyin başarısız olduğunu doğrulayın, çünkü ulaşılamaz bir adrese çözülen bir ad, hiç çözülmeyen bir adla tamamen aynı görünür. Hangi katmanın yanlış yanıt verdiğini sorun ve yanıtı yazın. Bu olmadan sonraki her adım prosedür kılığına girmiş bir tahmindir.

Karşılaştırma boyunca aynı Wi-Fi ağını ve aynı erişim noktasını koruyun. Dün IPv6 sunan bir kafe ağı, şu an bulunduğunuz ağ hakkında hiçbir şey söylemez.

Adresi yoldan önce okuyun

Sistem Ayarları'nda etkin hizmetin TCP/IP paneli IPv6'nın otomatik, elle veya yalnızca bağlantı yerel olup olmadığını gösterir. Bunu beklediğinizle karşılaştırın; bir kuruluşun elle yapılandırmayı bilinçli olarak seçmiş olabileceğini unutmayın. Ardından ifconfig komutunu çalıştırın ve söz konusu arayüzü okuyun. Tek başına bir fe80:: adresi, arayüzün komşularıyla konuşabildiğini ve daha fazlasını değil, dolayısıyla bağlantı yerel varlığın kullanılabilir bir yolun kanıtı olmadığını gösterir.

İstemcinin geride bıraktığı utun arayüzlerini de arayın. Eski bir tünel aygıtı, istemci kullanmayı bıraktıktan çok sonra bile bir adres ve yol tutabilir. Böyle biri varsa, bu istemcinin sahibi için bir yaşam döngüsü bulgusudur, hemen silinecek bir şey değildir.

Başarısız hedef için yönlendirme tablosunu okuyun

Çekirdeğe başarısız olan hedefi sorun, varsayılan yolu değil. route -n get 2001:db8::25 o adres için seçilen arayüzü ve ağ geçidini yazdırır, netstat -rn -f inet6 ise karşılaştırma için tüm tabloyu gösterir. Varsayılan yol, bir varsayılanın var olduğunu söyler; bu hedefin onu kullandığını söylemez.

DNS'i kendi bölmesinde tutun. IPv4 üzerinden erişilebilen bir çözümleyici yine de AAAA kayıtları döndürebilir, bu yüzden arama hatası ile yönlendirme hatası tarayıcıda aynı belirtiyi üretir.

İstemcinin engelleme ilkesini kalandan ayırın

Bazı istemciler bağlantı kesikken trafiği engellemek üzere tasarlanmıştır, diğer adres ailesi de dahil, ve bu davranış bir kusur değil özelliktir.

Bir engellemeyi hasar olarak ele almadan önce istemcinizin hangi davranışı belgelediğini öğrenin. scutil --dns her hizmet için yürürlükteki çözümleyicileri gösterir ve istemcinin kurduğu çözümleyici ya da kapsamlı DNS ayarı tam orada görünür olur. Ardından paket filtresi kurallarının kurulup geride bırakılıp bırakılmadığını kontrol edin. Beklenen engelleme ile kalan kural birbirine zıt tepkiler gerektirir ve bunları yalnızca sahibin belgeleri ayırır.

Kanıt toplayın, sonra tek bir şeyi değiştirin

İstemci sürümünü, macOS sürümünü, ağ hizmetini, amaçlanan bağlantı kesik ilkesini ve bir bağlan-kes döngüsünün iki tarafındaki adres ve yol çıktısını kaydedin. O kayıt, bir şikâyeti birinin inceleyebileceği bir yaşam döngüsü sorununa dönüştürür. Ardından tek bir değişiklik yapın ve yeniden ölçün.

Sıfırlamaya direnin. Sanal arayüzleri silmek, yönlendirme tablosunu temizlemek ve IPv6'yı tüm makinede devre dışı bırakmak, yakalamanız gereken durumu yok eder ve ilgisiz yapılandırmayı da beraberinde götürebilir. İstemcinin desteklenen bir duraklatma, onarma veya kaldırma akışı varsa onu kullanın ve ağın yönetildiği yerde yöneticinin prosedürünü izleyin. Zaten sıfırlanmış bir makine sahibine çalışacak bir şey bırakmaz ve hatayı genellikle bir sonraki bağlantıda yeniden üretir.