Tek bir Linux ana bilgisayarda iki OpenVPN istemcisini fwmark ile zincirleyin

Tek bir Linux ana bilgisayarda ikinci bir OpenVPN istemcisi yığmak iki yerden birinde başarısız olur. Ya dış tünel bu taşımayı yakaladığı için iç istemci kendi sunucusuna ulaşamaz, ya da ikinci istemci yönlendirme tablosunu yeniden yazar ve birinci tünel çalışmayı bırakır. Her iki sorun da yönlendirmede, şifrelemede değil, ve her ikisi de yeni tünel herhangi bir uygulama trafiği taşımadan önce çözülür. Buradaki adresler örnektir: tun0 dış tünel, 203.0.113.9 iç sunucu ve TCP 9999 iç yolu kullanması gereken akıştır.

İki arıza kipi, tek yönlendirme tablosu

İç istemci sunucusuna bir UDP soketi açar ve bu soket herhangi bir soket gibi geçerli yönlendirme tablosunu izler. Dış tünel zaten varsayılanı elinde tutuyorsa el sıkışma paketleri dış tünele gider. Bu yalnızca dış sunucu iç sunucuya ulaşabildiğinde ve karşı taraf akışı taşımayı kabul ettiğinde çalışır; aksi hâlde el sıkışma durur ve istemci yeniden dener.

İkinci arıza sunucunun push mesajından gelir. Olağan push redirect-gateway def1'dir ve varsayılan yolu değiştirmek yerine 0.0.0.0/1 ile 128.0.0.0/1'i kurar. Bu yüzden kendi /1 çiftini kuran iki istemci çakışır ve en yeni çift neredeyse her hedef için kazanır. İkincisi bağlandıktan sonra tünel ölürse tabloda bu iki öneki arayın, çünkü varsayılan yolun kendisi hiç değişmemiş olabilir.

Akışı işaretleyin ve ona bir tablo verin

Seçilen trafiği mangle tablosunda işaretleyip işareti bir politika kuralında eşleştirerek yönlendirin. Kural, varsayılan yolu iç aygıt olan özel bir tabloya işaret eder, böylece yalnızca işaretli paketler iç yolu izler.

iptables -t mangle -A PREROUTING -p tcp -m multiport --dport 9999 -j MARK --set-mark 0x9999
ip rule add fwmark 0x9999 table 200 pref 1000
ip route add default dev tun1 table 200

Bu kural kümesindeki arızaların çoğu iki hatadan kaynaklanır. Güvenlik duvarının ayarladığı işaret değeri ile kuralın eşleştirdiği değer aynı olmalıdır, çünkü uyumsuzluk ne hata ne de etki üretir. Ayrıca PREROUTING yalnızca dışarıdan gelen paketleri görür, bu yüzden bu ana bilgisayarda başlayan bir bağlantı işaretlenmeden önce aynı eşleşmeye sahip bir OUTPUT kuralına gerek duyar.

Yol sahipliğini ikinci istemciden alın

İki seçenek ikinci istemcinin tabloyu düzenlemesini engeller ve farklı noktalarda etki eder. route-nopull push ile gönderilen yol seçeneklerini yok sayar, bu yüzden hiçbir şey kurulmaz. route-noexec push ile gönderilen seçenekleri istemcinin ortamına kabul eder ama tablo değişikliğini bir hook'a bırakır, sunucunun ne önerdiğini görmeniz gerektiğinde istediğiniz tam olarak budur.

Hook push ile gönderilen değerlerle kendi ortamında çalışır ve yalnızca onayladığınız girdileri eklemelidir. Onu idempotent yapın: yeniden oluşturmadan önce sahip olduğu tabloyu boşaltın ve önceki çalıştırmanın temiz bir durum bıraktığını varsaymayın. Yeniden bağlanma hook'u tekrar çağırır ve temizlemeden ekleyen bir hook yinelenen yollar biriktirir.

Tek bir sahip seçin ve yazın. İki seçeneği de ayarlayan bir profil ya da elle yazılmış bir betikle yarışan bir hook, sonradan kimsenin açıklayamayacağı bir tablo üretir.

Her iki sunucu adresini sabitleyin

İç istemci bağlanmadan önce iç sunucunun dış aygıt üzerinden bir ana bilgisayar yoluna ihtiyacı vardır. İç taşımayı varsayılanı izlemeye bırakmak yerine dış tünelin içinde tutan girdi tam olarak budur.

ip route add 203.0.113.9/32 dev tun0
ip route get 203.0.113.9

Ana tabloya dış sunucu için de eşleşen bir ana bilgisayar yolu ekleyin, yoksa yeniden bağlanma dış istemcinin kendi taşımasını kendi tünelinin içine yönlendirebilir. Sıra isteğe bağlı değildir: bu girdileri ilgili arayüz var olduktan sonra ekleyin, yani bağlantı sonrası çalışan bir hook ya da betik. Kapalı bir aygıta işaret eden yol kaldırılır veya yok sayılır, bu yüzden açılışta yazılan bir girdi varsaydığınız sırayı atlatamaz.

Tüm tabloyu okumak yerine aramayı kontrol edin. Yol aramasının çıktısı çekirdeğin kullanacağı aygıtı ve kaynak adresi belirtir ve istemci soketini açtığında tam olarak bunu alır.

Zinciri test edin ve arızayı görünür kılın

İç istemci bağlanırken dış arayüzde yakalayın. İç el sıkışma dış tünelin içinde şifrelenmiş yük olarak görünmelidir; 203.0.113.9'a düz UDP olarak görünüyorsa ana bilgisayar yolu eksiktir ve zincir hiç kurulmamıştır.

Sessizce fiziksel uplink'e geri dönen bir zincir en kötü sonuçtur, çünkü arayüz durumu hiçbir şey bildirmez ve iç trafik yanlış kaynak adresinden çıkar. Dış tünel düştüğünde ikinci istemci doğrudan yeniden bağlanabiliyorsa o yolu devre dışı bırakın ya da arıza görünür olsun diye onu dış arayüze bağlayın.

İki akış ve tek bir kural dökümüyle bitirin: işaretli ve işaretsiz bağlantı farklı yollar izlemeli ve ip rule show amaçladığınız önceliği listelemelidir. İki akış aynı yolu izliyorsa işaret, düşündüğünüz yerde uygulanmıyor demektir.