Arka Arkaya İki VPN Sıçraması: Trafiğinizi Gerçekte Kim Görüyor?

Her istemci profili tek bir sunucu adlandırır, bu yüzden kullanıcının yerinden tek bir tünel ve korumanın bittiği tek bir nokta vardır. O ilk ağ geçidinden sonra olanlar, istemcinin hiç görmediği bir tasarım kararıdır ve iki yaygın tasarım denetim altında çok farklı davranır. Seri zincirde ilk ağ geçidi şifreyi çözer ve yeniden şifreler. İç içe zincirde bir dış katmanı kaldırır ve açamadığı bir iç tüneli iletir. Sıçrama sayısı ikisinde de aynıdır, bu yüzden fark sayılmakla değil çizilmekle anlaşılır.

İstemciden başlayın ve iki ucu da adlandırın

Kullanıcının başladığı yerden, yani bağlantı profilinden başlayın. İçinde bir uzak adres, bir kimlik doğrulama yöntemi ve tasarım destekliyorsa bir yol listesi vardır. İstemciden A ağ geçidine giden o dış tüneli etiketleyin ve örnek adresler verin: istemcinin tünel adresi 10.77.0.2, A'nın 10.77.0.1 ve A'nın genel uç noktası 198.51.100.10, TEST-NET-2 belge aralığından alınmış, örnekte hiçbir şeyin gerçek bir ana bilgisayarla çakışmaması için.

O profilde B ağ geçidinden söz edilmez ve bu bir kusur değildir. İkinci sıçrama A'ya aittir ve istemcinin tek yükümlülüğü trafiği A'ya ulaştırmak ve geri geleni kabul etmektir. A'nın tüneli sonlandırması, iletmesi ya da yenisini açması, bu gezintinin geri kalanının yanıtladığı sorudur ve A'nın neyi okuyabileceğini belirler.

Seri: A şifreyi çözer, sonra yeniden şifreler

Seri tasarımda A trafiği iki kez sonlandırır. İstemciden korumayı kaldırır, uygulamanın IP paketini alır ve sonra bu paketi A'nın B'ye doğru kurduğu ikinci tünelden gönderir. Bu iki işlem arasında paket A'nın iletme yolunda özel bir hedefe adreslenmiş sıradan bir IP paketi olarak durur.

Bunun açıkça söylenmesi gereken iki sonucu vardır. A iç pakete politika uygulayabilir; yollar, filtre kuralları ve kaynak ile hedefin günlüklenmesi biçiminde, ve A iki kimlik bilgisi seti tutmalıdır: biri istemci için sunucu olarak, biri B'nin istemcisi olarak. Koruma her an vardır, ancak korunan nesne A'da kimlik değiştirir.

Bundan A'nın uygulamanın düz metnini okuduğu sonucu çıkmaz. İstemci ve hizmet TLS çalıştırıp birbirlerinin sertifikalarını doğruladığında, A okunabilir bir istek yerine TLS kayıt akışı görür. Bu korumanın nerede bittiğini doğrulamak tünel şemasına değil, hizmetin sertifika zincirine bakmayı gerektirir.

İç içe: A yalnızca dış katmanı kaldırır

İç içe tasarımda istemci önce B'ye bir iç tünel kurar ve sonra o tüneli dış tünelin içinde A'ya taşır. A dış başlığı sıyırır, bir iç tünel bulur ve anahtarlarını tutmadan onu iletir, bu yüzden iç koruma hâlâ B'de sona erer.

Sonra istemcinin yukarı bağlantısı iki katman taşır, A ile B arasındaki yol ise bir katman. A iç tünelin dış adreslerini görür; bu, trafiğin var olduğunu ve yaklaşık nereye gittiğini bilmeye yeter, yükü okumaya yetmez. Seri durumdan bütün fark budur ve hiçbir sıçrama sayacı bunu göstermez. A'nın hâlâ yapabileceği şey, okuyamadığını iletmeyi reddetmektir ve bu o ağ geçidinin operatörü için her zaman açıktır.

İç içelik bu özelliğin bedelini öder. Her katman başlık yükü ekler, bu yüzden MTU ve MSS planlaması düzenli olmaktan çok zorunlu hâle gelir ve tek katmanla çalışan bir yol iki katmanla büyük paketleri sessizce düşürebilir. Her katman kendi yeniden bağlanma ve canlı tutma davranışına da ihtiyaç duyar ve bir katmandaki arıza diğerinin üzerinden kısmi kesinti gibi görünür.

Yalnızca tünelleri değil, gözlemcileri de çizin

Tüneller çizimin kolay kısmıdır. Tasarımın konusu gözlemcilerdir, bu yüzden her bakış noktası için bir satır yazın ve her birinin gerçekte neyi okuyabildiğini doldurun.

İki satır sürekli karıştırılır: A'nın operatörü ve istemcinin tünelinin sağlayıcısı. Aynı varlık olabilirler ve ayrı ağ geçidi adları onları bağımsız yapmaz. Bağımsız sahiplik ayrı yönetsel denetim, ayrı kimlik bilgileri ve ayrı günlükleme gerektirir.

Üst veriler iki tasarımda da varlığını sürdürür. Zamanlama, paket boyutları ve bağlantı sayıları her sıçramada gözlenebilir kalır, bu yüzden iki sıçrama sinyali kaldırmak yerine bağıntı maliyetini yükseltir. Görünmezlik vaat eden bir tasarım, kimse ona güvenmeden önce bu listeyle karşılaştırılmalıdır.

Seçmeden önce arıza yollarını gezin

Kullanıcının karşılaşacağı sırayla istemciden bilerek bir şeyleri kırın. Arayüz ve MTU'suyla başlayın, çünkü iç içelik paket boyutunda kimlik doğrulamadan çok daha önce başarısız olur.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Sonra koruma uç noktalarını varsaymak yerine doğrulayın. Hizmetten hangi tünel açıksa onun içinden sertifikasını isteyin ve istemcinin gördüğü zinciri hizmetin gerçekte sunduğu zincirle karşılaştırın. Yeniden imzalayan veya araya giren bir ağ geçidi o sertifikayı değiştirir ve denetim tek bir komutla görünür hâle gelir.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Yeniden bağlanma matrisiyle bitirin: istemcinin tüneli düşer, B'nin tüneli düşer, A ile B arasındaki yol değişir. Neyin geri döndüğünü, neyin dönmediğini ve bir iç bağlantının hiç amaçlanan taşıyıcısının dışındaki bir yola düşüp düşmediğini not edin. Her testin kullandığı adresleri kaydedin, çünkü başka bir erişim ağında yinelemek başka bir soruyu yanıtlar. Her yeniden bağlanmadan sonra MTU sınamasını da yineleyin, çünkü değişen bir yol tek bir yapılandırma satırı kımıldamadan kullanılabilir boyutu düşürebilir.

A iç pakete politika uygulamak zorundaysa ya da istemci iki katmanlı tünel çalıştıramıyorsa seriyi seçin. İç yükün A'da okunamaz kalması gerekiyorsa iç içeliği seçin. Seçimi gözlemcileri ve MTU sayılarıyla yazın, bir sonraki kişi tek bir soruyu yanıtlamak için bütün resmi yeniden çizmek zorunda kalmasın.