Bölünmüş tünelin çalıştığını doğrulayın: tek IP sonucu test değildir

Bir IP adresi gösteren tek bir tarayıcı sayfası, bölünmüş tünel hakkında neredeyse hiçbir şey kanıtlamaz. Görünen adres yanlış nedenle doğru olabilir ve hariç tutulan bir akış onunla hiç denenmez. Test etmeden önce beklenen sonucu yazın: hangi uygulama veya hedef tüneli kullanmalı, hangisi doğrudan kalmalı ve tünel başarısız olduğunda ne durmalı. Bu plan olmadan her makul sayı başarı gibi görünür.

Efsane: bir adres sorgusu kapsamı kanıtlar

IP kontrolü tek bir soruyu yanıtlar: dış dünya bir anda bir uygulamadan ne görür. İç önek, ikinci bir tarayıcı profili veya özel olarak çözülmesi gereken bir ad hakkında hiçbir şey söylemez. Hata hakkında da hiçbir şey söylemez ve bu, üretimde bozulan bölünmüş tünel tasarımının yarısıdır.

Bir adres sayfası rotayı, çözümleyiciyi veya hata ilkesini de gösteremez. Ona bir gözlem olarak davranın, bir hüküm olarak değil.

Dahil edilen ve hariç tutulan bir akışı deneyin

Dahil edilmesi gereken uygulamadan veya tünelden geçmesini beklediğiniz öneğe zararsız bir istek gönderin ve kaynağı, hedefi, adres ailesini ve gözlenen yolu kaydedin. Doğrudan kalması gereken bir akış için de aynısını yapın. Hariç tutulan taraf, insanların atladığı taraftır ve bölünmenin kazara değil bilerek yapıldığının tek kanıtı budur. Yardımcı bir süreç ayrı bir ilke kimliği taşıyabilir, bu yüzden soketi sahiplenen süreçte test edin.

flow: Firefox to intranet.example:443, IPv4, source 10.8.0.6, tunneled
flow: Firefox to 1.1.1.1, IPv4, source 192.0.2.20, direct

Bu yüzden yanlış uygulamada yapılan bir test, tasarımın amaçladığının tersini gösterebilir. Herhangi bir sonuca varmadan önce dört alanı iki taraf için de yazın.

DNS'i ve hata durumunu ekleyin

Sistem çözümleyicisine ve uygulamanın kullandığı çözümleyiciye sorun, ardından bu yanıtları sitenin bildirdiği çıkış adresiyle karşılaştırın. İki katman tasarım gereği ayrışabilir ve tek bir tarayıcı sorgusu işletim sisteminin ilkesini denemez. Bir kabuk karşılaştırmayı yinelenebilir kılar: Tüneli bilerek kırın, ardından tarayıcının önbelleğe almadığı bir istek yapın; önbellekten sunulan bir sayfa yedek yolun hangi yöne gittiği hakkında hiçbir şey söylemez. Tasarımın öngördüğünü değil, gerçekte olanı kaydedin.

curl -s https://ifconfig.me
nslookup intranet.example

Kapalı biçimde başarısız olan bölünmüş tünel ile açık biçimde başarısız olan tünel, tüneli bilerek kırana kadar aynı görünür. Hangi davranışı gözlediğinizi kaydedin, hangisini beklediğinizi değil.

Durum değiştikten sonra yineleyin

Aynı gözlemleri yeniden bağlanma, ağ değişimi ve ilgili bir uygulama güncellemesinden sonra yineleyin. Saklanan bir hariç tutma, artık var olmayan bir yola veya uygulama kimliğine işaret etmeye devam edebilir ve tasarım sessizce belgeleriyle eşleşmeyi bırakır. Bu üç olay, bölünmüş tünellerin kaydığı yerlerdir ve her birini yeniden test etmek ucuzdur. Yalnızca bir kez kurulum sırasında çalışan bir test, artık var olmayan bir yapılandırmayı tanımlar.

Bir sonuç farklıysa, birkaç ayarı aynı anda değiştirmeden önce kuralın sahibini ve işleme aşamasını bulun. Beş şeyi değiştirip tek bir sonucu gözlemlemek bir tanı değil, yeni bir yapılandırmadır.

Sonucun neyi ortaya koyması gerekir

Gözlemleri gerçekten test ettiğiniz ilke ve istemci sürümüne bağlayın. Amaç, bu kurulumun iddia ettiği kapsama uyduğunu göstermektir, gelecekteki her uygulamanın özel olacağını değil. Bu daha dar bir iddiadır ve gerçekten kanıtlarla destekleyebileceğiniz iddia da budur. İddiayı, sürümü ve dört alanlı sonuçları değişiklik kaydına yazın.

O zaman bir sonraki gözden geçiren, tasarımın mı yoksa testin mi değiştiğini söyleyebilir. Bölünmüş tünel, her iki taraf, çözümleyici bölünmesi ve hata davranışı başta yazdıklarınızla eşleştiğinde doğrulanmış olur. Tek bir IP sonucu bunların hiçbirini doğrulamaz.