Tek bir ana bilgisayarda OpenVPN sunucusu ve istemcisi: istemciler neden düşer

Zaten bir VPN sunucusu çalışan makineye istemci profili ekleyin, ilk kurban özgün hizmet olur. Yeni tünel hiç kurulmayabilir ya da kurulup sunucunun mevcut istemcileri sessizce yanıt almayı bırakabilir. İki çakışma her iki sonucu da verir: hâlihazırda kullanılan bir tünel havuzu ve yeni istemci yarısının kurduğu, tüm tabloyu kapsayan varsayılan yol. Hiçbiri OpenVPN hata iletisi üretmez, bu yüzden arıza sunucu sorunu olarak okunur.

Tek makine, iki rol ve yanıtların nereye gitmesi gerektiği konusunda birbiriyle bağdaşmayan iki yanıt.

Aynı havuz, iki sunucu: hangisi kazanır

Her sunucu örneğinin kendi tünel alt ağına ihtiyacı vardır. server 10.8.0.0 255.255.255.0 gibi bir satırı ikinci yapılandırmaya kopyalamak iki örneğe aynı öneki verir ve sonuç ya başlamayı reddetmek ya da bir sunucunun istemcilerinin diğerinin de kendisine ait saydığı adresleri aldığı sessiz bir yarıştır. Farklı UDP bağlantı noktaları ve farklı aygıt adları yardımcı olmaz, çünkü ikisi de adres alanına dokunmaz. İkinci havuzu değiştirin ve yolların ondan söz ettiği her yerde değiştirin.

Düzenlemeden önce nelerin etkin olduğunu listeleyin: ip -4 addr show tünel aygıtlarını listeler, ss -lunp dinleyicileri listeler ve systemctl list-units birimleri adlandırır. Tünel adreslerine bir bakış havuzların çakışıp çakışmadığını belirler.

İstemci profilinin tabloya eklediği şey

İstemci yarısı bağlanır bağlanmaz yolları yazar. redirect-gateway def1 varsayılan yolu 0.0.0.0/1 artı 128.0.0.0/1 olarak böler, ikisi de yeni aygıt üzerinden yönlendirilir; ayrıca uzak sunucuya giden ve kasıtlı olarak fiziksel arayüze sabitlenmiş bir ana bilgisayar yolu eklenir. Bu sabitleme, tünelin kendi taşıması için bir yol tutması içindir. Geri kalan her şey, yerel sunucunun kendi istemcilerine borçlu olduğu yanıtlar dahil, artık yeni varsayılanı izler ve uzak bağlantıdan çıkar.

Yani ikinci çakışma bozuk bir tünel değil. Tablonun yanlış yerinde duran çalışan bir tünel.

Rolleri ayrı tutmanın üç yolu

En az müdahaleci düzeltme varsayılan yolu istemci profilinin dışında tutar: uzak önekler için route-nopull artı açık route satırları, böylece yerel tablo yalnızca istediğiniz yerde değişir. Sonraki adım, yerel tünel alt ağını muaf tutan bir ilke kuralıdır; varsayılan yol varken bile yerel istemcilere giden yanıtların geldikleri arayüzden çıkmasını sağlar. En kapsamlısı, istemci rolü için ayrı bir ağ ad alanıdır; paylaşılan tabloyu tamamen kaldırır ama bakımı için ikinci bir yönlendirme bağlamı gerektirir.

Hangi yolu seçerseniz seçin, istisna LAN'ı değil yerel tünel alt ağını adlandırmalıdır. Yerel sunucunun gönderdiği yanıtın hedefi bir tünel adresidir, bu yüzden LAN biçimli bir istisna ona hiçbir zaman uymaz.

İki örnekten hangisi suçlu

İstemci örneğini durdurun ve özgün istemcileri yeniden test edin. Anında düzelme yönlendirme demektir, sunucu değil. İstemciyi geri getirin ve hem kaynak hem hedef adresi verilen ip route get ile tek bir yanıtı izleyin; bu, çekirdeğin seçeceği yolu gösterir, ardından paketlerin gerçekte hangi arayüzü kullandığını tcpdump -ni any port 1194 ile izleyin. Sunucunun durum dosyası, birkaç saniyede bir status yönergesiyle yazılır ve bağlı istemci listesini iki yöndeki bayt sayaçlarını taşır.

Bu sayaçları birbirine karşı okuyun. Çıkıp bir daha dönmeyen trafik el sıkışma sorunu değil, yönlendirme yanıtıdır.