Tam tünelleme uzun bir bölünmüş tünel listesinden daha mı basit?
Uygulamaların çoğunu kapsayan bir istisna listesi, kılık değiştirmiş bir varsayılandır. Kuralları sayın, ağ geçidini kontrol edin, sonra tek bir profili taşıyın ve iki kenarı da doğrulayın.
Bölünmüş tünel listesi üç uygulamayla başlar ve makinenin çoğunu kapsayacak şekilde biter, her yeni satır birinin istisnasıdır. O noktada liste sessizce fazladan adımları olan bir varsayılana dönüşmüştür. Tam tünelleme düzeni tersine çevirir: belgelenmiş bir istisna aksini söylemedikçe her şey tünele girer. Bunun daha basit olup olmadığı ağ geçidine ve bozacağınız yerel hizmetlere bağlıdır.
Sürdürdüğünüz kuralları sayarak başlayın
Girdileri sayın, ardından kaçının adlandırılmış bir sahibi ve son doğrulama tarihi olduğunu sayın. Önemli olan ikinci sayıdır, çünkü sahibi olmayan bir istisna, işaret ettiği yazılımın adı değiştiğinde veya yerine yenisi konduğunda değerlendirilemez. Çalıştırılabilir bir yola bağlı kurallar güncellemeden sonra sessizce başarısız olur ve hata eski bir kuraldan çok kararsız bir VPN gibi görünür. Liste hakkında bir fikir edinmeden önce onu yazın.
Her girdi üç soruyu yanıtlamalıdır: o olmadan ne bozulur, buna kim karar verdi ve nedenin süresi dolduğunda bunu nasıl fark edersiniz. Üçünü de yanıtlayamayan girdiler taşınmak yerine silinmeye adaydır ve onları önce silmek sonraki karşılaştırmayı dürüst kılar.
Girdilerin çoğu trafiğin büyük bir bölümünü yönlendiriyorsa, zaten bakım yükü eklenmiş bir tam tünel işletiyorsunuz. Karar o zaman varsayılanın nerede yaşadığıyla ilgilidir, bir varsayılana sahip olup olmamakla değil.
Ağ geçidinin varsayılanı taşıyıp taşıyamayacağını kontrol edin
Tam tünelleme her paketi tek bir cihaza taşır; bu da o cihazın CPU yükünü, conntrack tablosunu, adres çevirisini ve yukarı akış bant genişliği gereksinimini aynı anda değiştirir. Birkaç iç alt ağa rahatça hizmet veren bir ağ geçidi, bir kullanıcının tüm gezinmesi için boyutlandırılmamış olabilir. Ortalamaya değil, beklediğiniz en büyük eşzamanlı oturum sayısına bakın, çünkü önce zirve kırılır.
ip -s link show dev tun0
conntrack -C
ss -sDeğişiklikten önce ve sonra aynı iş yükünü ölçün, spesifikasyonlardan akıl yürütmeyin. Tek bir makinede sıradan kullanımın bir öğleden sonrası ağ geçidinin bir sınıra yakın olup olmadığını gösterecektir ve bunu bir pazartesi sabahı keşfetmeye kıyasla hiçbir maliyeti yoktur.
Yol MTU'sunu da uçtan uca kontrol edin, çünkü tam bir varsayılan her uygulamayı tünelin en büyük paket boyutuna maruz bırakır. Tünelin dışında çalışan uygulamalar artık hiç düşünmeniz gerekmeyen parçalanma davranışına bağımlı olabilir.
Yerel hizmetlerin ve özel DNS'in hâlâ çalıştığını doğrulayın
Yerel kalması gerekenleri uygulama adına göre değil protokole göre listeleyin: yazıcılar ve ekranlar için keşif protokolleri, bir akıllı ev köprüsü, bir yönlendiricinin yönetim sayfası, yalnızca LAN'da çözülen bir adla ulaşılan yerel bir geliştirme sunucusu. Bunlar varsayılan yol tünele işaret etmeye başladığında bozulur ve istemcide hiçbir şey hata kaydetmediği için sessizce bozulur.
Özel DNS diğer bağımlılıktır. İç adlar daha önce tünelin çözümleyicisi tarafından çözülüyorsa hiçbir şey değişmez; yerel olarak çözülüyorduysa, tam bir varsayılan onları bölgeleri bilen bir çözümleyiciye taşımalıdır. Değişiklikten sonra bir iç ve bir genel ad test edin, çözümleyici listesinin hayatta kaldığını varsaymak yerine.
Yerel istisnaları onlara sahip olan profile yazın. Yalnızca birinin belleğinde tutulan istisna, bir sonraki taşımanın kaybettiği ilk şeydir.
Tek bir profili taşıyın ve sınırları doğrulayın
Profili, önceki deneylerden kalan elle girilmiş yolların üzerine yeni bir varsayılan katmak yerine, ona sahip olan yapılandırma üzerinden değiştirin. O kalan yollar, çalışıyor gibi görünen ve bir gün sonra tutarsız davranan bir taşımanın olağan nedenidir. Eski profili kullanılabilir tutun ki geri alma bir yeniden inşa değil, bir seçim olsun.
Ardından iki sınırı ayrı ayrı doğrulayın: genel ve özel hedeflerin ikisinin de çalıştığını ve istenmeyen trafiğin tünelin dışına çıkmadığını. Başarılı bir sayfa yüklemesi birinciyi kanıtlar ve ikincisi hakkında hiçbir şey söylemez.
ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.comKontrolü yeniden bağlantıdan sonra ve bir kesintiden sonra tekrarlayın, çünkü düşüş sırasında trafiği engelleyen bir kill switch, sonradan doğru şekilde geri gelen bir yoldan farklı bir özelliktir. Daha basit tasarım, bir uygulama veya ağ değiştikten sonra gerçek kapsamını hâlâ açıklayabildiğiniz tasarımdır.