Yakındaki bir DNS yanıtı, bağlantı başka bir yere inene kadar çözülmüş bir sorun gibi görünür. Coğrafi DNS ve anycast ikisi de yolu kısaltmaya çalışır ve bu kararı farklı bilgilerden alır. Hiçbiri ulaştığınız ağ geçidinin erişilebilir olduğunu, istemcinizin beklediği kimliği sunduğunu veya oturumunuzun bir düğüm değişikliğinden sağ çıktığını garanti etmez. Aşağıdaki kontroller bu dört soruyu ayırır.

Çözümleyicinin gerçekte kimin konumunu bildirdiğini kontrol edin

Topolojiye duyarlı bir sorguyu yanıtlayan yetkili bir sunucu genellikle soran özyinelemeli çözümleyicinin adresini görür, adı yazan kişinin adresini değil. Merkezi bir çözümleyici hizmet verdiği istemcilerden uzakta olabilir ve yanıt onları değil çözümleyiciyi yansıtır. Bu bir kusur değildir; ek bilgi sağlanmadıkça protokol böyle davranır. EDNS Client Subnet belirtimi hem sınırlamayı hem de isteğe bağlı çareyi açıklar.

EDNS Client Subnet, her katılımcı destekleyip etkinleştirdiğinde kaynak ağ bilgisini taşıyabilir. İsteğe bağlıdır, gizlilik ve önbelleğe alma sonuçları vardır ve herhangi bir genel çözümleyicinin kesin bir kullanıcı konumu bildirdiğini varsayma izni değildir. Buna göre tasarlamadan önce çözümleyici operatörlerine sorun.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

anycast yönlendirmesinin ne karar verdiğini kontrol edin

anycast ile birkaç konum tek bir hizmet adresi için erişilebilirlik duyurur ve ağ her istemciyi yönlendirmesinin tercih ettiği düğüme teslim eder. Bu seçim haritadaki mesafeyle değil, BGP ve çevresindeki politikayla yapılır. Topolojik yakınlık da genellikle daha iyi gidiş-dönüş performansı anlamına gelmez, çünkü kısa görünen yol tıkanık veya asimetrik olabilir. Size verilen adres hangi düğümün yanıt verdiği hakkında hiçbir şey söylemez.

Hizmet veren konumu yalnızca DNS yanıtından değil, hizmet tarafından veya onu adlandıran bir yanıttan doğrulayın. traceroute -n 198.51.100.20 izlediğiniz yolu gösterir ve yine de sonundaki ana bilgisayarı adlandırmaz, bu yüzden onu yanıt olarak değil yol olarak okuyun.

Oturumun bir düğüm değişikliğinden sağ çıktığını kontrol edin

DNS sorgusu kısadır ve VPN oturumu uzundur ve ikisinin durum gereksinimleri tamamen farklıdır. Yönlendirme oturumun ortasında kayabilir ve bu olduğunda sonraki paketler tünelinizi hiç görmemiş bir düğüme varabilir. Bunun atlatılabilir olup olmadığı uygulamaya bağlıdır: paylaşılan durum, bilinçli yeniden bağlanma veya belgelenmiş bir arıza. Yalnızca adres bunların hiçbirini sağlamaz.

Kaymayı varsaymak yerine gözlemleyin. Yol değişirken sudo tcpdump -ni any -c 20 esp dış paketleri gösterir ve eş adresindeki ani bir değişiklik, gerçekleşen kaymadır. Çalıştırdığınız uygulama için amaçlanan davranışı açıkça tanımlayın, ardından yol değişikliğini zorlayarak test edin. Tasarım oturum çoğaltmayı varsayıyorsa mekanizmayı adlandırın ve kapsamadığı arızayı adlandırın.

Kimliğin hâlâ eşleştiğini kontrol edin

Her giriş noktası, istemci profilinizin beklediği kimliği sunmalıdır. Hizmet adı için verilen bir sertifika düğümler arasında çalışırken, düğüm başına sertifikalar istemciyi yeni bir şeyi kabul etmeye zorlar ve kullanıcıların uyarıları tıklayıp geçmeyi öğrendiği yer burasıdır. Beklenen kimliği ve profili giriş modeliyle tutarlı tutun.

Bunu sıra dışı bir düğüme ulaşan bir istemciden kontrol edin, çünkü düğüm başına sertifikanın görünür hale geldiği durum budur. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com zinciri ve adları yazdırır, istemcinin karşılaştırdığı şey tam olarak budur. Ardından profilin daraltılması mı yoksa sertifika modelinin değiştirilmesi mi gerektiğine karar verin.

Yalnızca ilk yanıtı değil, kaydı kontrol edin

Üç senaryoyu değerlendirin ve her biri için dört olgu yazın: normal giriş, kullanılamayan bir konum ve kararlaştırılan kurtarma durumu. Dört olgu kullanılan çözümleyici, döndürülen adres, hizmet veren konum ve yeni bir uygulama sonucudur. Bu kayıt, DNS seçimi sorununu ağ geçidi sorunundan, yönlendirme sorunundan veya oturum durumu sorunundan ayırır. O olmadan dördü de istemciden aynı görünür.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Senaryoları yalnızca ofisten değil, temsili erişim ağlarından çalıştırın, çünkü bütün soru farklı istemcilerin gerçekte hangi giriş noktasına ulaştığıdır. Tek bir ağ, birin örneğidir.

İlgili makaleler