İki VPN'i zincirlemek: neyi saklar, neye mal olur
İç içe tüneller kimin hangi uç noktaları gördüğünü değiştirir, sizi kimin gördüğünü değil. İç uç noktayı dış tünelden geçirin, sonra DNS, MTU ve hata anındaki davranışı kontrol edin.
İç içe iki tünel sizi anonim yapmaz. Gözlemleri iki sağlayıcı arasında bölerler, böylece hiçbiri ev adresinizi ve hedefinizi aynı anda görmez. Bu gerçek ama dar bir faydadır ve yönlendirme, DNS ve MTU sorunlarıyla birlikte gelir; bunlar ona ilk kez güvendiğinizde ortaya çıkar.
1. İkinci atlamanın ne için olduğuna karar verin
Herhangi bir şeyi yapılandırmadan önce hedefi tek bir cümleyle yazın. Amaç internet sağlayıcınızın hangi siteleri ziyaret ettiğinizi görmemesi ise tek tünel yeter. Amaç hiçbir sağlayıcının adresinizi trafiğinizle ilişkilendirememesi ise iki tünel gerekir. Amaç kimsenin sizi tanımlayamaması ise hiçbir atlama sayısı oraya varmaz.
Zincir, zayıf sağlayıcının günlüklemesi ve ikisinin de tuttuğu hesap kayıtları kadar güçlüdür. Ödemeler, kayıt e-postası ve uygulama telemetrisi tünelin tamamen dışındadır.
2. İç uç noktayı dış tünel üzerinden erişilebilir yapın
Olağan arıza, iç tünelin hiç kurulmamasıdır. Tam tünel modundaki dış bağlantı varsayılan rotaya sahiptir, bu yüzden iç istemcinin kendi uç noktasına ulaşma girişimi dış tünel tarafından yutulur ve düşürülür ya da döngüye girer. İç uç noktanın, iç istemci başlamadan önce kurulmuş, dış arayüzden geçen açık bir rotaya ihtiyacı vardır. Aksi halde el sıkışma rota ile yarışır ve kaybeder.
WireGuard aynı çatışmayı diğer yönden gösterir. Her peer'in AllowedIPs değeri hangi hedeflerin o tünele gireceğine karar verir, bu yüzden her adresi talep eden bir iç arayüz, daha belirgin bir rota kazanmadıkça dış uç noktayı da talep eder. İki arayüzde çakışan AllowedIPs değerleri, bir tarafın sessizce kaybettiği bir yapılandırmadır.
Konteyner zincirleme, ayrımı açık ve tuzağı belirgin hale getirir. Kendi ad alanı, kendi varsayılan rotası ve içinde bir istemci bulunan bir konteyner, ana makinenin ona gönderdiğini iletir; ana makine o yolu kendiliğinden kullanmaya başlamaz. Yönlendirmeyi açın, konteynerin tüneli için bir rota ekleyin ve hizmeti konteynerin adresine yönlendirin.
3. DNS'i aynı yolda tutun
DNS, trafiğin gittiği yere gitmelidir. İç sağlayıcı çözümleyicileri itiyor ve ana makine hâlâ yerel olanları sorguluyorsa, bu sorgular tünelin saklaması gereken siteleri tam olarak açığa çıkarır. İstemcinin durum paneline güvenmek yerine her tünel arayüzünde yakalama ile kontrol edin. Buradaki sızıntı normal gezinmede görünmez, yakalamada apaçık ortadadır.
Bölünmüş DNS tasarımları bunu zorlaştırır, çünkü yerel bir ad için sorgu meşru olarak tünelin dışına ait olabilir. İstisna listesini rastgele yanıt veren çözümleyiciden keşfetmek yerine bilerek yazın.
4. MTU'yu kullanıcılar sizin yerinize keşfetmeden ayarlayın
MTU öngörülebilir diğer kurban. İki kapsülleme iki başlık çıkarır ve yol MTU'sunu zaten düşürmüş bir dış tünel içeride daha az yer bırakır. Belirtiler tanıdıktır: küçük istekler geçer, büyük aktarımlar ve TLS el sıkışmaları takılır.
ip link set dev wg1 mtu 1280 kaba çözümdür, yönlendiricide MSS kısmak daha düzgünüdür. Bağlantıyı yeniden denemek hiçbir çözüm değildir.
5. Gerçekten alacağınız arızayı test edin
Dış tüneli kasten bozun ve ne olduğunu izleyin. Dış atlama öldüğünde sessizce doğrudan yola düşen bir zincir, zincir olmamasından daha kötüdür, çünkü tam da kendinizi korunmuş sandığınız anda sızdırır. Tüm trafiği durduran bir kill switch hedeflenmesi gereken davranıştır. Sonucu kaydedin, çünkü bir olayın ortasında onu yeniden keşfetmek istemezsiniz.
Gecikme ve ikinci arıza noktası kalıcı maliyetlerdir. İki atlama, uygunsuz bir saatte bir şey bozulduğunda iki destek kuyruğu anlamına da gelir.