Tek bir Linux ağ geçidinde iki OpenVPN istemcisi: politikayı bölün

İki OpenVPN arka plan programı da başarılı bir tünel bildirebilirken ağ geçidi her istemciyi aynı tünelden gönderir. El sıkışmada hiçbir şey istemcinin hangi tüneli kullandığına karar vermez; bunu çekirdek karar verir, paket paket, politika kurallarını ve ardından her kuralın adlandırdığı tabloyu geçerek. Böyle bakınca yapılandırma artık OpenVPN seçenekleriyle ilgili olmaktan çıkar ve iki sahibi olan bir yönlendirme matrisine dönüşür.

Çekirdek karar verir, arka plan programı değil

İletilen bir paket LAN arayüzüne gelir ve yönlendirme kodu kural listesini öncelik sırasına göre değerlendirir. Seçicisi ilk eşleşen kural bir tabloyu adlandırır ve o tablonun yolları çıkış aygıtını seçer. Tabloda eşleşen bir yol yoksa arama bir sonraki kurala devam eder, ve yarım kalmış bir kurulumun yüksek sesle değil sessizce başarısız olmasına neden olan tam da bu ayrıntıdır.

Tünel sürecinin o geçişte söyleyecek sözü yoktur. Bir arayüz oluşturur ve yollar kurabilir, ancak belirli bir istemcinin paketinin o arayüze girip girmediği tamamen gönderildiği tabloya bağlıdır. Bu nedenle aynı içe aktarılmış yollara sahip iki tünel yarışır ve son yazan herkes için kazanır. Bu yüzden bir kurulum yapılandırma dosyalarında dengeli görünebilir ve yine de tüm istemcileri tek bir arka plan programından geçirebilir.

Her örneğe kendi kaynak kümesini verin

Adlarla başlayın, çünkü yeniden kullanılan adlar iki örneğin kazara durumu paylaşmaya başlamasının yoludur. Ayrı tünel aygıtları, ayrı yapılandırma dosyaları, ayrı kimlik bilgileri ve ayrı hizmet birimleri atayın. Her örneğin dış uç noktasını ve tünel adresini politika matrisiyle aynı tabloya kaydedin, böylece sonraki bir değişikliğin bakacağı tek bir yer olsun.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull sunucunun ittiği yolları yerel tablonun dışında tutar ve politika tablolarının açık olması gerektiğinde tam olarak istediğiniz şey budur. Belirli bir sunucunun redirect-gateway seçeneğini de itip itmediğini ve istemci sürümünüzün filtre biçimini destekleyip desteklemediğini varsaymak yerine kılavuzdan kontrol etmeye değer.

Matrisi yazın: kaynak, tablo, aygıt

Her istemci grubu için kaynak adrese göre tablo seçen bir kural ekleyin, sonra amaçlanan yolu o tabloya koyun:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

Tablonun grubun sahip olması gereken hedef yollara ve ağ geçidini kullanılabilir tutan yerel veya yönetim istisnalarına ihtiyacı vardır. Yalnızca varsayılan bir yol içeren tablo o grup için tam tünel politikasıdır, bu tam olarak doğru olabilir, ancak bir eksiklik değil karar olmalıdır.

Tünelin kendi taşıması bir istemci grubunda değildir

Her arka plan programının şifrelenmiş paketleri ağ geçidinin kendisinde doğar ve dış eşe adreslenir. Yalnızca istemci kaynak önekiyle eşleşen bir kural bu paketleri rahat bırakır, bu yüzden kaynakla sınırlı kurallar her şeyle eşleşen kurallardan daha güvenlidir. Seçicisi olmayan bir kural tünelin kendi taşımasını yakalayabilir ve onu bir tünelden geri gönderebilir, ve o zaman bağlantı sağlayıcı sorunu gibi görünen bir biçimde başarısız olur.

Yerel yönetim oturumunu ve alt katman yolunu politika tablolarının açıkça dışında tutun. Bu istisnaları matrisin yanına yazın; bunlar tasarımın parçasıdır, bir olay sırasında yeniden keşfedilmesi gereken bir geçici çözüm değildir.

Bir yolu seçmek ona izin vermez

İletme izni yolda daha sonra verilen ikinci bir karardır. İkinci tünelden çıkan paketleri kabul eden bir güvenlik duvarı kuralı yönlendirme kodunun onu seçmesini sağlamaz ve doğru bir tablo iletme izni vermez. İkisi de olmalıdır, ve yalnızca birini kanıtlayan bir test sizi diğeri konusunda yanıltır. Bir grup çalışıp diğeri çalışmadığında, tabloları yeniden yazmak yerine bu iki adımı ayrı ayrı kontrol edin.

Kaynak çevirisi üçüncü bir karardır ve kaynak grubuyla onu gerçekten taşıyan tünel aygıtıyla sınırlandırılmalıdır. İki örnek için ayrı bir zincir ekleyin, postrouting zincirini boşaltmak yerine, çünkü ilgisiz hizmetlerin orada girdileri olabilir ve boşaltmak onları sessizce kaldırır.

Bir tünel düştüğünde ne olur

Arıza davranışına önceden karar verin. Bir tünel tablosu rotasını kaybettiğinde arama bir sonraki kurala düşer ve grubun trafiği hiçbir hata olmadan diğer tünelden veya olağan üst bağlantıdan devam eder. Bu kabul edilebilir değilse, daha düşük öncelik numarasında o kaynak için ulaşılamaz sonuç döndüren bir sonlandırma kuralı ekleyin, böylece kayıp yutulmak yerine görünür olsun.

Her kaynak grubundan yeni bir istek gönderin ve dört gerçeği kaydedin: seçilen tablo, çıkış aygıtı, çevrilmiş kaynak ve yanıtın aynı yoldan dönüp dönmediği. Sonra bir tüneli indirin ve tekrarlayın. Arayüz listesinde iki TUN aygıtı olması her iki arka plan programının da başladığını kanıtlar; belirli bir istemcinin hangisini kullandığı hakkında hiçbir şey söylemez. Bir tünelin eksik olduğu ikinci çalıştırma, yedek kuralınızın amaçladığınızı yapıp yapmadığını gösteren çalıştırmadır.