Tek bir Linux makinesinde iki VPN: sonuçları karıştırmadan her birini ayrı test edin
İki yeşil simge bir karşılaştırma değildir. Her tüneli kendi ad alanına koyun, beklentiyi önce yazın ve sonuca güvenmeden önce yolu kanıtlayın.
İki yeşil bağlantı simgesi bir karşılaştırma gibi görünür ve genellikle tesadüftür. Test isteği iki tünelden herhangi birini kullanabildiyse, sonuç en iyi ihtimalle bunlardan birini, en kötü ihtimalle hiçbirini tanımlar. Her gözleme bir ağ bağlamı, amaçlanan hedef ve test çalışmadan önce yazılmış bir beklenti verin. Kendi yönettiğiniz bir Linux makinesinde, adlandırılmış ağ ad alanları bu ayrımı satın almanın en ucuz yoludur.
İki yeşil ışık bir karşılaştırma değildir
Bir ad alanı yönlendirme tablolarını, arayüzleri ve ağ yığınının durumunu ayırır, bu yüzden birinin içinde başlayan bir istek diğerinin tünelini sessizce ödünç alamaz. Ayırmadığı şey bir işlemci, fiziksel bir yukarı bağlantı veya ana makinede çalışan çözümleyici servisidir. Bu son boşlukta, bu testlerin çoğu kimse fark etmeden başarısız olur. Ad alanından çıkıp ana makinenin çözümleyicisine soran bir arama, test edilen tünelle hiçbir ilgisi olmayan bir yanıt döndürür.
Bu yordam, önceden hazırlanmış ve onaylanmış iki test ad alanı, çalışan bir dış bağlantı ve desteklenen istemciler varsayar. Hiçbir şey oluşturmaz, hiçbir şey kaydetmez ve hiçbir yapılandırmayı değiştirmez. İstemci tam bir masaüstü oturumuna ihtiyaç duyduğunda veya bunun dışında çalışmayı reddettiğinde ayrı sanal makineler dürüst seçim olmaya devam eder.
Beklentiyi ilk çalıştırmadan önce sabitleyin
Her bağlam için başarının nasıl göründüğüne karar verin: çözümleyici, servis adı, beklenen adres ve tünel düştüğünde gereken davranış. Bu planlanan değerleri kendi sütunlarında tutun, çünkü plan ile gözlemi karıştıran bir kayıt zaman damgalı bir kurgudur. Aşağıdaki kontrol listesi kaydın ihtiyaç duyduğu biçimdir ve her satır ilk bağlantıdan önce doldurulabilmelidir.
| Tunnel | Owner | Client interface inside the namespace | Proof command | Required on disconnect |
|---|---|---|---|---|
| vpn-a | the identity that owns profile A, recorded by name | its own tun device, never the host's | ip -n vpn-a -4 route get 10.55.10.20 | traffic stops; no host-side fallback |
| vpn-b | a separate owner, even when both run on one box | its own tun device in its own namespace | ip -n vpn-b -4 route get 10.55.20.20 | verified separately, never inferred from A |
Çözümleyici kablolaması o kayıtta kendi satırını hak eder, çünkü yalan söyleme olasılığı en yüksek alan odur. Ad alanına bağlı dosyalar, örneğin /etc/netns/vpn-a/resolv.conf bir komut ad alanının içinde çalıştığında her zamanki yollarında görünür, tıpkı iproute2 ad alanları başvurusunun açıkladığı gibi, ancak ad servisi geçiş yapılandırması ve onun başlattığı herhangi bir yerel çözümleyici bir aramayı hâlâ ana makineye geri çekebilir.
Bir seferde bir tünel, diğeri bağlantısız
B kapalıyken A'yı mevcut sahibi üzerinden bağlayın, ardından yönetim bağlamından ilkeyi, yolları ve seçilen yolu inceleyin. Aşağıdaki komutlardan üçü durumu okur; yalnızca sonuncusu bir ad servisiyle iletişim kurar ve hiçbiri uygulama isteği göndermez.
sudo ip -n vpn-a -4 rule show
sudo ip -n vpn-a -4 route show table all
sudo ip -n vpn-a -4 route get 10.55.10.20
sudo ip netns exec vpn-a getent ahostsv4 svc-a.lab.internalYol araması bir hedef hakkındaki varsayımsal bir soruyu yanıtlar, bu yüzden servisin trafiği kabul ettiğini gösteremez. Bu iki kanıt türünü ayrı sütunlarda tutun, çünkü reddedilen bir bağlantının yanındaki sağlıklı bir yol gerçek ve yaygın bir sonuçtur. Ardından gerçek uygulamayla zararsız, yetkilendirilmiş tek bir istek gönderin; A'nın bağlamında olağan ayrıcalıksız kullanıcısı olarak başlasın, sertifika doğrulaması ve uygulama kimlik doğrulaması bozulmadan kalsın ve sonucu servisin gördüğü kaynak adresle birlikte kaydedin. A'yı sahibi üzerinden ayırın ve B için tüm temel çizgiyi yineleyin, yaptığınız her yapılandırma değişikliğini not edin, aksi halde iki temel çizgi karşılaştırılabilir olmaktan çıkar.
İkisi de açık, sonra birer birer kapatın
Kararlı durum kolay kısımdır. İki tünel de bağlıyken her bağlamın aramasını ve uygulama isteğini yineleyin, sonra bir tüneli koparıp diğerini denetleyin. Bağlantı sırasının kendisi soru olduğunda ters sırayla yeniden bağlanın.
sudo ip netns exec vpn-a tcpdump -ni any port 443 -c 5
sudo ip netns exec vpn-b getent ahostsv4 svc-b.lab.internal
sudo ip -n vpn-b -4 route get 10.55.20.20Yakalama, uygulama sonucunun çözemeyeceği tartışmaları çözer: isteğin beklediğiniz arayüzden mi yoksa tamamen başka bir şeyden mi çıktığını gösterir. Her geçiş için sahibin eylemini, zaman damgasını, yol sonucunu, ad sonucunu ve uygulama sonucunu kaydedin. Ardından etkilenen ad alanının içinde güvenli kapanma koşulunu denetleyin, çünkü yalıtım bir acil durdurma anahtarı değildir. Bir ad alanı iki tüneli ayrı tutar; profili trafiğin durması gerektiğini söylediğinde hiçbirinin trafik taşımasını engellemez.
Bu kayıt neyi iddia edebilir, neyi edemez
Bir geçiş, bu düzen için, bu ana makinede, o anda o gözlemleri kanıtlar. Tek bir masaüstü yönlendirme tablosunu paylaşan iki istemci hakkında hiçbir şey söylemez, iki tünel de yük taşırkenki verim hakkında da hiçbir şey söylemez. Bunlar ayrı testleri olan ayrı sorulardır ve bir karşılaştırma, her satıra eklenen bağlam kadar iyidir.
Başarısızlıkları kayıtta başarıların yanında tutun, o sırada hangi tünelin açık olduğunu işaretleyin. Ölçüm anındaki durumu saklayan temiz bir sayfa, onu gösteren çirkin bir sayfadan daha kötüdür. Kaydı sonradan yeniden kullanılabilir kılan şey bağlamdır, puan değil.
Bir makinedeki iki tünel dürüstçe karşılaştırılabilir, ama yalnızca gerçekten denetlediğiniz kadar bağlamın içinde. Bunun ötesi, yanında yeşil bir simge olan bir dilektir.