iPhone'da WireGuard DNS: alan adı yalnızca bir arama soneki
DNS satırına bir alan adı eklemek bölünmüş DNS gibi görünür. Apple istemcilerinde yalnızca kısa adları tamamlar ve her sorgu yine de tünel çözücüsüne gider.
Bir çözücü adresi ve bir şirket alan adıyla tek satır yazarsınız ve yalnızca o alan adındaki adların tünel çözücüsünü kullanmasını beklersiniz. Apple istemcisinde artık tüm adlar oraya gider ve alan adındaki kısa adlar da çözülür. Satır iki ayrı iş yapar ve bunlardan yalnızca biri tünelin hangi sorguları ele aldığıyla ilgilidir. Diğeri, dilekçi bir okumayla politikaya yükseltilmiş bir yazma kolaylığıdır.
DNS satırı neye ayrıştırılır
İstemci girdiyi liste olarak okur ve her öğeyi biçimine göre sınıflandırır. Adrese benzeyen her şey bir DNS sunucusu olur; alan adına benzeyen her şey bir arama soneki olur. İkisi de tünel ayarlarına girer, ancak farklı alanlara. Özel bir çözücü ve bir iç alan adı taşıyan bir tünel için örnek satır şöyle görünür.
DNS = 10.24.8.53, lab.internal.exampleAdres çözücüyü sağlar. Alan adı, istemcinin kısa bir ad yazmasına ve sistemin sormadan önce geri kalanını eklemesine izin veren bir sonek sağlar. İkisi de çözücüyü o alan adıyla sınırlamak hakkında hiçbir şey söylemez ve insanların bekleyip alamadığı kısım tam olarak burasıdır. Platformdaki yalnızca bir alan bu kısıtlamayı ifade edebilir ve bu alan o değildir.
İki Apple alanı, iki farklı iş
Apple bu ayrımı DNS ayarları nesnesinde ortaya koyar. Arama alan adı listesi, tek etiketli ana bilgisayar adlarını nitelendirmek için kullanılan liste olarak belgelenmiştir: çıplak bir ana bilgisayar adı yazın ve sistem sırayla her soneki ekleyebilir. Bu bir tamamlama kuralıdır, yönlendirme kuralı değildir. O listedeki hiçbir şey hangi sunucuya sorulacağını belirlemez.
Eşleşme alan adı listesi başka bir özelliktir. Hangi ad alanlarının bu DNS ayarları kümesini kullandığını belirler ve boş girdi belirli bir sonek değil varsayılan alan adı anlamına gelir. paket tüneli ayarları üreteci Apple istemcisinde bu modeli izler. Ayrıştırılmış arama soneklerini arama listesine koyar ve sunucular varsa eşleşme listesini boş dizeye ayarlar. Sonuç, sistemin gönderdiği her şeye yanıt veren bir tünel çözücüsü ve kısa adlara yardımcı olan bir sonektir.
Yani o satırdaki alan adı bir ad alanı seçici değildir. Bir tane daha eklemek tünelin kullandığı sorguları daraltmaz, kaldırmak da genişletmez. Değişen tek şey kaç kısa adın tamamlandığıdır.
Her ad neden hâlâ tünel çözücüsüne ulaşır
Boş eşleşme girdisiyle tünel, yalnızca şirket alan adı için değil, sıradan adlar için de aday bir çözücüdür. Tam tünel yapılandırmasında bu genellikle pek önemli değildir, çünkü tüm trafik zaten tüneldedir. Bölünmüş tünelde bu çok önemlidir. Genel adlar artık yalnızca özel bir bölge tutan bir çözücü tarafından çözülebilir ve başarısızlık bozuk bir VPN gibi görünür, oysa aslında ad alanının yalnızca bir bölümüne yanıt veren bir çözücüdür. Tünel iyi, sorgular çıkıyor ve yanıtlar boş dönüyor.
İki onarım mevcut ve bunlar farklı kararlardır. Tünel çözücüsünü genel adları onaylanmış yoldan ileten tam bir çözücü yapın ya da alan adı listesi yerine istemci yapılandırmasını değiştirerek genel adları oraya göndermeyi bırakın. Birincisi her sorguyu tünelde tutar ve yukarı akışa güvenir. İkincisi bazı sorguları yerelde tutar ve tünel kapalıyken özel adların çözülmesinin durabileceğini kabul eder.
Bölünmüş DNS'in gerçekte neye ihtiyacı olurdu
Ad alanıyla sınırlı bir çözücü politikası, onu ifade etmenize izin veren bir istemci gerektirir: Apple platformlarında alan adlarını eşleştirin veya kullandığınız üründe eşdeğer bir ayar kullanın. Yalnızca sunucuları ve sonekleri kabul eden bir yapılandırma alanı, nasıl noktalanırsa noktalansın bunu ifade edemez. Bir profil politikayı taşıyabilir çünkü bağlanma anındaki bir ipucu değil, yönetilen bir yapılandırmayı tanımlar. Alan adını, sunucuları ve o alan adına ulaşılamadığında ne olması gerektiğini adlandırabilir. Ayar ile sözleşme arasındaki fark budur.
Yönetilen Apple cihazlarında bu genellikle alan adına özgü DNS ayarlarını taşıyan bir yapılandırma profili aracılığıyla sağlanır. Bu, WireGuard yapılandırma dosyasından farklı bir mekanizmadır ve ikisi ancak istemci profili onurlandırırsa bir arada var olabilir. İki ürünün aynı davrandığını varsaymadan önce istemcinizin o alanı gerçekte ne diye adlandırdığını kontrol edin. Mac'teki bir wg-quick betiği ve iPhone'daki WireGuard uygulaması benzer satırları okur ve bunları farklı katmanlar aracılığıyla kurar.
Kurulu ayarları okuyun, yapılandırmayı değil
Mac'te sistemin neyle sonuçlandığını inceleyebilirsiniz, bu da yazdığınız dosyayı yeniden okumaktan daha bilgilendiricidir. Çözücü listesi hangi sunucuların hangi alan adları için yapılandırıldığını, kapsamlı sorgular ise hangisinin kazandığını gösterir. Satırı bozan bir istemci bunu yazdığınız dosyada değil, burada gösterir. iOS'ta eşdeğer bir komut satırı yoktur, bu yüzden oradaki kanıt bir sonuçtur: tünel üzerinden çözülen özel bir ad ve yanıtı hangi çözücünün yanıtladığını ortaya koyan genel bir ad.
scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-FiBu iki komut geçerli çözücü yapılandırmasını ve etkin hizmetin DNS sunucularını yazdırır. Tünel çözücüsü alan adı kısıtlaması olmadan varsayılan çözücü olarak görünüyorsa, yapılandırma istemcinin istediğini tam olarak yapıyordur. Bunu mekanizmayı değiştirerek düzeltin, ikinci bir sonek ekleyip davranışın değişmesini umarak değil.