Split-tunnel belgelerinin her rotanın yanında bir DNS kuralına ihtiyacı var
Rota adrese göre karar verir, çözümleyici ada göre karar verir. Her akış için iki seçiciyi de belgeleyin, her birini bir testle, yoksa DNS kaydığında not başarısız olur.
"Ofis trafiği VPN üzerinden gider" diyen bir split-tunnel notu bir kararı belgelemiş ve üç kararı ima etmiştir. Paket katmanında bir yönlendirme tablosu arayüzü hedef adrese göre seçer; ad katmanında bir çözümleyici sunucuyu sorguya göre seçer ve bu iki seçim birbirinden bağımsız yapılır. Bu yüzden doğru belgelenmiş bir önek yine de dahili bir adı genel bir adrese çözen ya da rota kusursuz görünürken hiçbir şeyi çözmeyen bir makine üretebilir.
İki seçici, bir bağlantı denemesi
Bir uygulama files.corp.example adresine bağlandığında, paket oluşmadan önce iki arama gerçekleşir. Çözümleyici, sorguyu hangi sunucunun alacağına arama alan adları, bağlantı başına yönlendirme alan adları veya açık bir profil kuralı kullanarak karar verir. Ardından yönlendirme tablosu, ortaya çıkan adresin nereye gideceğine hedefle en uzun önek eşleşmesini kullanarak karar verir.
Bu iki kararı hiçbir şey birbirine bağlamaz. Özel bir bölge 10.20.4.11 ile yanıt verebilir, yönlendirme tablosu ise 10.20.0.0/16 aralığını tünele gönderir ve bağlantı çalışır. Herhangi birini ters çevirin, diğerine benzeyen bir şekilde başarısız olur: doğru DNS politikası artı eksik rota, çözülmüş bir ad ve zaman aşımı verir; doğru rota artı genel bir çözümleyici ise temiz bir şekilde yanlış yere yönlendirilen bir adres verir.
Bölünmüş ufuklu DNS bunu daha keskin hale getirir. Aynı ad, dahili çözümleyiciden özel bir adres ve internete bakan çözümleyiciden genel bir adres döndürebilir, bu nedenle yalnızca öneki kaydeden bir not, istemcinin gerçekte hangi adresi kullanacağını öngöremez. Çözümleyici yolunu yazın, yoksa adres bir tahmindir.
Yalnızca rota notunun atladığı şey
Yalnızca rota içeren bir kayıt, split-tunnel'ın en yaygın arızası için kullanılamaz: adlar. Kullanıcı intranet yüklenmiyor diye bildirir, tünel açıktır ve önek vardır. Talebi devralan kişinin hangi çözümleyicinin yanıt vermesi gerektiğine dair kaydı yoktur, yanlış arama sonekini engellenmiş bir sunucudan ayırmanın yolu yoktur ve karşılaştıracak bir temel çizgisi yoktur.
İkinci eksik, istisna listesidir. Bir split-tunnel tasarımı, tünelin içine giren kadar dışında kalanla da tanımlanır ve hariç tutulan aralıklar genellikle ilk bozulanlardır, çünkü daha belirgin bir yerel rota veya istemci tarafı filtre, profile dokunmadan amacı geçersiz kılabilir.
Üçüncüsü tünelin uzak tarafıdır. İstemci rotası paketi yalnızca kabloya koyar; ağ geçidinin onu hâlâ iletmesi ve bir dönüş yolu olması gerekir. strongSwan'ın iletme kılavuzu ağ geçidindeki iletme ve güvenlik duvarı kurallarının özelliğin parçası olduğunu, varsayabileceğiniz tesisatın parçası olmadığını hatırlatır.
Notu yürütülebilir kılan alanlar
Her akış için bir satır ve akış bir hedef artı bir ad artı bir sahiptir. Gerçek bir olayla temas ettiğinde ayakta kalan alanlar şunlardır:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
"Nerede yaşadığı" satırı insanların atladığı satırdır. Sunucunun ittiği bir önek, istemci profilinin eklediği bir rota ve kabuğa yazılan bir rota, kimin değiştirebileceği ve yeniden bağlanmada kalıp kalmadıkları bakımından farklıdır. Bu alan olmadan bir sonraki mühendis üçünden hangisine baktığını söyleyemez.
Kural başına bir test, tünel başına değil
Her satır iki zararsız kontrol gerektirir: biri rotayı çalıştırır, diğeri adı. Rota için tüneli geçmesi gereken bir şey isteyin ve erişilebilirlik yerine yolu doğrulayın, örneğin tracert -d 10.20.4.11 Windows'ta veya ip route get 10.20.4.11 Linux'ta. Ad için özel adı sorgulayın ve hangi sunucunun yanıt verdiğini kaydedin, notun belirttiği çözümleyiciye karşı resolvectl query files.corp.example veya dig files.corp.example kullanarak.
Olumsuz bir beklenti de ekleyin: tünel kapalıyken ne olmalıdır. VPN olmadan engelleme açık olan bir Android veya iOS cihazındaki hariç tutulan uygulamanın hiç bağlantısı olmayabilir ve masaüstü istemcisi tünel yeniden bağlanırken aynı uygulamayı çalışır bırakabilir. Amaçlanan yanıtı kaydetmek "VPN uygulamamı bozdu" ifadesini doğrulanabilir bir iddiaya dönüştürür.
Kaydı yapılandırmayla birlikte tutun
Notu tanımladığı profilin yanında saklayın ve o profille sürümleyin. Kimsenin güncellemediği bir wiki belgesi söylentidir; itilen rotalar ve çözümleyici politikasıyla aynı depodaki bir tablo aynı değişiklikte gözden geçirilebilir.
Bir şey bozulduğunda, başka bir istisna eklemeden önce uygulanan rotayı ve etkin çözümleyiciyi kayıtla karşılaştırın. Yaygın üç nedenin ikisi — eski bir ad alanı kuralı ve uygulama politikası dışındaki bir yardımcı süreç — tam olarak bir VPN arızası gibi görünür ve not yalnızca önekleri listeliyorsa görünmez olur.
Notu tamamlandı ilan etmeden önce şunları yazılı olarak yanıtladığını doğrulayın: hangi önek, hangi adres ailesi için; hangi özel ad alanı, hangi çözümleyici tarafından yanıtlanıyor; hangi adlar kasıtlı olarak genel kalıyor; her kural nerede yapılandırılmış ve kime ait; ve rotayı kanıtlayan tek komut ile adı kanıtlayan komut. Bunlardan herhangi biri eksikse bir sonraki olay sıfırdan teşhis edilecektir.