Apple VPN On Demand alan adı kuralları bir tüneli nasıl başlatır

Bir iç ada istek yaptığınızda tünel açılır ve sonraki uygulama aynı derecede ihtiyaç duyduğunda kapalı kalır. Bu uygulamadaki bir hata değil; bir alan adı kuralının biçimidir. Apple’ın on-demand yapılandırması bir bağlantı kurma koşullarını tanımlar ve bu koşulların alan adı biçimi, tek bir paket hareket etmeden önce sistem çözümleyicisine bir soru sorar. İki soru sürekli karıştırılır: tünelin ne zaman kalkması gerektiği ve tünel var olduğunda ne taşıdığı. İlki bir tetikleyici, ikincisi bir rota ve çözümleyici politikasıdır ve bir profil genellikle ikisini de aynı payload’da ayarlar, bu yüzden doğru bir alan adı kuralı sizi yine de yanlış ağda bırakabilir.

Tetikleyici ve trafik seçimi farklı katmanlarda

on-demand kuralı bir VPN payload’ının on-demand sözlüğünde yaşar: her biri bir eylem ve bir eşleşme koşulları kümesi olan sıralı bir kural listesi. Sistem bunları bağlantı değiştiğinde veya bir şey ağa ulaşmaya çalıştığında değerlendirir ve eylem tünelin kaldırılacağına, değerlendirileceğine, bağlantısının kesileceğine veya yok sayılacağına karar verir. Bütün bunlar uygulamanız bir socket edinmeden önce platformun ağ katmanında gerçekleşir.

Ardından ayrı bir anahtar grubu gelir: tünelin IPv4 ve IPv6 ayarları, dahil edilen ve hariç tutulan rotaları, DNS sunucu adresleri ve iOS ile iPadOS’ta hangi uygulamaların tüneli kullanabileceğini belirleyen uygulama başına eşleme. Bir profil geniş bir tetikleyiciyi dar bir rotayla veya dar bir tetikleyiciyi varsayılan bir rotayla eşleştirebilir. Yalnızca bir yarısını okuyun, diğer yarısı arıza gibi görünür.

İç alan adı altında bir şey istendiğinde bağlanan ama tünele yalnızca bir /16 yönlendiren bir laboratuvar profilim var. Payload’ında yazanı tam olarak yapar ve aynı zamanda bilet üreten profil türüdür: insanlar bağlı bir tünelin trafiklerinin içinde olduğu anlamına geldiğini varsayar.

Bir alan adı kuralı çözümleyiciye gerçekte ne sorar

Genellikle connect-if-needed olarak adlandırılan kuralın alan adı biçimi paket payload’larını incelemez ve URL’leri izlemez. Bir ad çözüldüğünde sistem onu kuraldaki alan adlarıyla karşılaştırır ve eşleşme durumunda bu adın tünelin sağladığı DNS sunucuları üzerinden çözülüp çözülemeyeceğini sorar. Tünelin çözümleyicisi yanıtlarsa ad iç olarak sayılır ve bağlantı başlar. Bunun yerine yerel çözümleyici yanıtlarsa ad dış olarak ele alınır ve tünel görünmez. Apple’ın dağıtım genel bakışı bunu ağ algılama ve ardından bağlantı değerlendirmesi olarak açıklar.

Bundan iki sonuç çıkar. Profil tünelin içindeki DNS sunucularını adlandırmalıdır; tünel çözümleyicisi olmayan bir alan adı kuralının karşılaştıracağı bir şey yoktur, bu yüzden değerlendirme beklediğiniz eşleşmeyi veremez. Ve arama sistem çözümleyicisine ulaşmalıdır. Kendi şifreli DNS’ini çalıştıran bir uygulama veya tarayıcı, yerel olarak yanıt veren bir uzantı ya da gerçek bir adrese bağlantı, kuralın beklediği ad çözümlemesini asla üretmez. Geçirdiğim en uzun öğleden sonralardan biri, tünelin önündeki istemcinin DNS over HTTPS kullandığını keşfettiğimde sona erdi.

Önbellek de tetikleyiciyi ortadan kaldırır. Zaten önbellekte olan bir ada, tüneli başlatacak sonda olmadan yanıt verilebilir, bu yüzden dün çalışan bir kural yeniden başlatmadan sonra veya tünel bir süre ayakta kaldıktan sonra başarısız olur. macOS’ta sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder durumu sıfırlar; iOS’ta uçak modunu açıp kapatmak veya cihazı yeniden başlatmak karşılaştırılabilir temiz bir başlangıç verir.

Eşleşme kapsamı: adlar, uygulamalar ve ağlar

Alan adı eşleşmesi birkaç türden biridir. Bir kural arayüz türüyle (Wi-Fi, hücresel, Ethernet) ve belirli bir SSID ile de eşleşebilir ve uygulama veya Safari alan adı girdileri bir tüneli tek bir iş akışına bağlar. Bu bağ, yalnızca bir uygulamanın diğer her şeyden farklı davrandığı tuhaf deneyimi açıklar: diğer uygulamalar tünelin kapsamı dışındadır, bu yüzden tünel simgesi bağlı dese bile yerel yolu kullanmaya devam ederler.

Sıra insanların beklediğinden daha önemlidir. Kurallar sırayla değerlendirilir ve ilk eşleşen eylemi verir, bu yüzden dar bir alan adı kuralının üstüne yerleştirilen geniş bir her-Wi-Fi’ye-bağlan kuralı sessizce kazanır ve alan adı kuralını test edilemez hale getirir. Alan adı listesini yeniden yazmadan önce daha önceki hiçbir kuralın zaten eşleşmediğini doğrulayın.

Bu yüzden always-on yalnızca daha katı bir on-demand kuralı değildir. always-on’ın uygulanması ayrı bir dağıtım modudur ve kendi gözetim ve yönetim gereksinimleri vardır; bir ada tepki vermek yerine tüneli açık tutar. İhtiyacınız olan şey asla düşmeyen bir tünelse, alan adı kuralı yanlış araçtır.

Bozuk kuralı taklit eden arıza modları

Bir alan adı kuralının çalışmadığına dair raporların çoğu beş yerden birine düşer ve bunlardan yalnızca sonuncusu kuralın metnidir.

Captive portallar kendi satırını hak eder, çünkü otel ve havalimanı Wi-Fi’ı kuralın bağlı olduğu aramayı tam olarak yakalar. Portal cihazı içeri alana kadar tünelin DNS sunucusuna ulaşılamaz, sonda başarısız olur ve arıza yanlış yazılmış bir alan adı gibi görünür. Kimlik doğrulama diğer sessiz durumdur: kural tetiklenebilir, tünel bağlanmaya başlayabilir ve bağlantı süresi dolmuş bir sertifikada veya başka bir ekranda beliren bir istemde ölür.

IPv6 yanlış teşhis edilmesi kolay bir varyant yaratır. Her iki adres ailesine sahip bir ada önce bir AAAA kaydından yanıt verilebilir, oysa tünelin rota listesi yalnızca IPv4 taşır. Bir tarayıcı başarır, diğeri başarısız olur ve alan adı listesi tamamen masumdur.

Gerçek bir istekle, bu sırayla test edin

Tahmin etmeden önce politikayı okuyun. macOS’ta sudo profiles show -type configuration VPN payload’ı dahil kurulu profilleri yazdırır, scutil --nc list hizmet durumunu gösterir ve scutil --nc show <service> sistemin kullandığı on-demand sözlüğünü yazdırır. Yönetilen bir iPhone veya iPad’de aynı payload yönetim konsolundan veya bir MDM raporundan gelir. Ağ günlükleri macOS’ta log stream --predicate 'subsystem == "com.apple.networkextension"' ile ve telefon bağlıyken cihaz konsolu aracılığıyla kullanılabilir.

Ardından oturumda daha önce sorgulanmamış bir ana bilgisayar adıyla test edin. Tünelin DNS bölgesinde içeriden çözüldüğünü bildiğiniz bir ad seçin, bir kez isteyin ve tünelin görünüp görünmediğini izleyin. Aynı aramayı iki kez çalıştırın: ikinci deneme önbellek yolunu çalıştırır ve ikisi arasındaki fark tetikleyicinin çözümleme mi yoksa yönlendirme mi olduğunu söyler.

Tünel kalktıktan sonra iki katmanı ayrı ayrı doğrulayın. netstat -rn -f inet ve netstat -rn -f inet6 her önekin nereye işaret ettiğini gösterir, scutil --dns çözümleyici sırasını ve her çözümleyicinin hangi arayüze ait olduğunu gösterir ve nettop -m route baytları hangi arayüzün taşıdığını gösterir. Tünel ayaktaysa ve çözümleyici doğruysa ama kaynak hâlâ başarısız oluyorsa kuralı düzenlemeyi bırakın; sunucu tarafı yetkilendirmeyi ve dönüş rotasını kontrol edin.

Kural başkasına ait olduğunda

Bağlantıyı kestikten sonra tünel yeniden ortaya çıkarsa kural genellikle bir uygulamaya değil bir profile aittir: MDM ile gönderilmiş bir yapılandırma, kalan kişisel bir profil veya başka bir istemci tarafından yüklenmiş bir profil. sudo profiles show -type configuration ve on-demand anahtarları için bir arama bunu daraltır ve kaldırma yolu profildir, menü çubuğundaki anahtar değil. Hizmet girdisini veya uygulamayı silmek kuralı geride bırakır ve sonraki kurulum onu yeniden devralır.

Tek bir test sahipliği çözer: bağlantıyı kesin, bekleyin, iç adı yeniden isteyin. Tünel geri dönerse tetikleyici tasarlandığı gibi çalışıyor demektir ve açık soru onu kimin yönettiği ve o kapsamın istediğiniz şey olup olmadığıdır.

Bunu hata olarak bildirmeden önce aynı beş kontrolü yapın: payload’da tünel çözümleyici adresleri var, önbelleğe alınmamış bir ad, daha önce eşleşmemiş bir kural, rota listesinin kapsadığı bir AAAA yolu ve uygulama tünelin kapsamı içinde. Beşi de geçerliyse kural işini yapıyor ve arıza yolun daha ilerisinde.