İki OpenVPN sunucusundaki istemciler birbirine erişebilir mi?

İkinci bir OpenVPN sunucu kurmak istemcilerin bağlanabileceği ikinci bir yer verir, o kadar. Bu istemcileri ilk sunucunun ağına koymaz ve client-to-client adlı seçenek yalnızca tek bir sunucu süreci içindeki iletmeyi değiştirir. İki havuz, aralarında bilinçli olarak yönlendirme yaptığınızda tek bir ağ olur; her yön için bir sahibi vardır. Aşağıdaki her şey, bu iç iletme kapalıyken kullanıcı alanı TUN modunu varsayar, böylece kararı çekirdek verir.

Efsane: tek hesap listesi, tek ağ

Kimlik doğrulama ve erişilebilirlik birbirine karıştırılır çünkü ikisi de sunucu yapılandırmasında yaşar. İki ağ geçidinden herhangi birine giriş yapabilen bir kullanıcı, dışarıdan iki kapısı olan tek bir sistemdeki kullanıcı gibi görünür. İçeride her sunucu kendi havuzundan adres dağıtır ve yalnızca sonlandırdığı istemciler için rota kurar. Bu yüzden A ağ geçidindeki bir istemci, B ağ geçidindeki bir istemciye paket gönderdiğinde kendi sunucusunun hiç duymadığı bir hedef ister. Paket A'nın varsayılan rotasına gider, tünelden çıkar ve izin vermesi hiç istenmemiş bir güvenlik duvarına varır.

Dolayısıyla ikinci bir sunucu eklemek yedeklilik, keşif veya paylaşılan bir yayın alanı eklemez. Bir plan gerektiren yönlendirilmiş bir ağ ekler ve plan adreslemeyle başlar.

Her ağ geçidine kendi havuzunu ve geçiş adresini verin

Başka hiçbir şeyle çakışamayacak iki aralık ve ana bilgisayarlar arasında küçük bir geçiş bağlantısı, tüm adres planıdır. Geçişi kontrol ettiğiniz özel bir segmentte tutun ve herhangi bir sunucu kiralama vermeden önce sayıları yazın.

Profiller aynı kalsın diye iki sunucuya aynı havuzu verme cazibesine direnin. Çekirdek rotası, paylaşılan bir aralıktaki herhangi bir adrese şu anda iki ana bilgisayardan hangisinin sahip olduğunu söyleyemez, bu yüzden yönlendirme tablosu bir ağ geçidini gösterir ve istemci diğerine bağlı olabilir. Arayüz adları yerel geleneklerdir, paylaşılan durum değil. Buradaki iki ana bilgisayar da tünel aygıtına tun0 ve geçiş bağlantısına transit0 diyor; bu sorun değil çünkü hiçbir paket bu adları taşımıyor.

Rotayı iki tarafa da kurun

Her ağ geçidi, geçiş adresi üzerinden diğerinin havuzuna bir rota gerektirir ve herhangi birinin atlama olarak çalışabilmesi için iletme açık olmalıdır. Önce geçerli tabloyu doğrulayın, sonra girdiyi ekleyin ve yeniden bağlanma kancası yerine ana bilgisayarın ağ yöneticisi üzerinden kalıcı hale getirin.

sysctl net.ipv4.ip_forward
ip route add 10.64.20.0/24 via 172.28.44.2 dev transit0
ip route get 10.64.20.37

Havuzları değiştirerek bunu diğer ana bilgisayarda yansıtın. Aynı rotayı ilgisiz bir betikten tekrar tekrar eklemek, bir ana bilgisayarın birkaç kopyayla ve bir sonraki tablo okumasında gizemli bir değişiklikle kalmasının yoludur. Geçiş bağlantısı kendisi bir tünelse, rota o tünelin topolojisine işaret eder ve atlama, yeniden bağlanmasından sağ çıkmalıdır. Otuz saniye boyunca kaybolan bir geçiş adresi havuzlar arası yolu da beraberinde götürür; bu, keşfedilmekten çok dile getirilmeye değer bir tasarım özelliğidir.

Sahiplik taslamadan istemci rotasını itin

İstemcilerin uzak havuza bir rotaya ihtiyacı vardır, aksi halde kendi işletim sistemleri paketi varsayılan ağ geçidine gönderir ve tünel onu asla görmez. Sunucu yapılandırması bunu iletmek için doğal yerdir.

push "route 10.64.20.0 255.255.255.0"

Ayna satırını diğer sunucunun yapılandırmasına koyun, ardından bir test istemcisini yeniden bağlayın ve tablosunu okuyun. İtilen rotaları yok sayan bir istemcinin kendi onaylı yapılandırması gerekir ve hiç gelmeyen bir rota erişim denetimi değildir. Bir istemciye diğer ağ geçidinin tüm havuzu için iroute vermeyin. Bu direktif, tek bir bağlı istemcinin arkasındaki alt ağ için vardır ve eksik bir ağ geçitleri arası rotayı örtmek için kullanılması erişemediği adreslere sahip olduğuna inanan bir sunucu üretir.

Bir isteği kanıtlayın ve diğerini reddedin

Gerçek bir işlem seçin, örneğin 10.64.10.21'deki bir istemciden 10.64.20.37'deki bir hizmete HTTPS ve iki ana bilgisayarda da tam olarak buna izin verin. Her güvenlik duvarı isteği gelen tarafında ve izlenen yanıtı dönüş tarafında kabul eder; hedefin kendi hizmet ilkesi yine de bunu kabul etmelidir.

iptables -A FORWARD -i tun0 -o transit0 -s 10.64.10.21 -d 10.64.20.37 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i transit0 -o tun0 -d 10.64.10.21 -s 10.64.20.37 -p tcp --sport 443 -m conntrack --ctstate ESTABLISHED -j ACCEPT

Karşılıklı rotalar varken kaynak NAT gereksizdir ve burada etkin biçimde zararlıdır: kaynağı çevirmek isteği hangi istemcinin yaptığını gizler ve hedef tarafındaki kaynak tabanlı ilkeyi bozar. İnternete çıkış için var olan masquerade kuralının bu yolu da yakalamadığını denetleyin. Sonra reddi test edin. B havuzunda yerel kalması gereken bir hizmet A havuzundan erişilemez kalmalıdır ve aynı ağ geçidindeki istemci çiftleri de test edilmelidir, çünkü az önce değiştirdiğiniz iletme ilkesi onlar için de geçerlidir.

Zihinsel modele bir düzeltme daha: geçiş bağlantısı şifresi çözülmüş iç paketleri taşır, yani özel bir garanti değil güven sınırıdır. Kontrol etmediğiniz bir ağı geçiyorsa o atlamayı onaylı şifreli bir tünelle koruyun ve gerçek topolojisi üzerinden yönlendirin. Uçtan uca TLS uygulamayı yine kendisi doğrular, bu yüzden iç hizmet onu kullanmaya devam etmelidir.