OpenVPN istemcisi sunucusu aynı ana bilgisayarda çalışırken takılıyor

Uzak bir siteden tünel kabul eden ve aynı zamanda bir sağlayıcı ağına bağlanan bir laboratuvar makinem vardı. Giden profil haftalarca çalışmıştı. Gelen sunucu eklendikten sonra giden olan bağlandı ve ardından saniyeler içinde trafik geçirmeyi durdurdu ya da adres zaten kullanımda hatasıyla başlamayı reddetti. Yapılandırma dosyaları değişmemişti; ana bilgisayar yalnızca bağlantı noktaları ve yollar hakkında kendi görüşüne sahip ikinci bir OpenVPN süreci edinmişti.

Arıza rastgele değil ve bir kimlik doğrulama sorunu değil. Tek makinedeki iki daemon aynı yerel soket ve aynı yönlendirme tablosu için yarışır ve en son başlayan ya da yeniden bağlanan genellikle kazanır. Bu iki çakışmadan hangisine sahip olduğunuzu bilmek önce nereye bakacağınızı belirler.

Belirtiyi tersten okuyun

Tünelin ne zaman öldüğüyle başlayın. Başlangıçta bir bind hatası dinleme tarafını işaret eder: bir şey o bağlantı noktasına zaten sahiptir ve OpenVPN onu paylaşmak yerine başlamayı reddeder. Yükselip sonra susan bir tünel yönlendirmeyi işaret eder, çünkü diğer örneğin kurduğu bir yol, dış bağlantının paketlerini yollarından çekebilir.

Her iki durum da aynı kullanıcı şikâyetini üretir, bu yüzden yeniden deneme döngüleri ve bekçi betikleri hiçbir şeyi düzeltmez. İstemciyi aynı çatışmaya yeniden bağlarlar. Yararlı ilk soru, trafik durduğunda sürecin hâlâ çalışıp çalışmadığıdır.

Örnek başına bir soket ve bir aygıt

Dinleyen bir sunucu bağlantı noktasını bağlar; giden bir istemci de kapsüllenmiş trafiği için yerel bir bağlantı noktasına ihtiyaç duyar. İkisi aynı ana bilgisayarda yaşadığında, istemcinin varsayılan davranışı sunucunun bağlantı noktasıyla çakışabilir. İstemcinin yerel bağlantı noktası sabitlenebilir ve eş sabit bir kaynak bağlantı noktasına ihtiyaç duymadığında bağlama atlanabilir:

lport 1195
nobind
dev tun1

Bu sayılar örnektir, gereklilik değil. Önemli olan istemcinin sunucunun bağlantı noktası için yarışmayı bırakması ve her örneğin ayrı bir tünel aygıtı almasıdır. tun0 aygıtını paylaşan iki daemon, bağlantı noktaları farklı olsa bile birbirlerinin aygıt durumunun üzerine yazar, bu yüzden tünel başına bir aygıt isteğe bağlı değildir.

nobind istemci tarafına aittir. Bir sunucu yine de bağlamalı ve dinlemelidir, bu yüzden satırı sunucu yapılandırmasına kopyalamayın ve eşi sabit kaynak bağlantı noktasına göre filtreleyen bir istemcide bağlamayı devre dışı bırakmayın.

Varsayılan yol için tek bir sahip seçin

Varsayılan yolu yalnızca bir bağlantı kurabilir. Her iki profil de tüm trafiği yeniden yönlendirirse, ikinci bağlantı birincinin yerini sessizce alır ve birinci bozulmuş görünür. Ya giden tüneli bölünmüş tutup yalnızca sağlayıcı öneklerini itin ya da ona ayrı bir yönlendirme tablosu verin.

ip rule add from 10.9.0.2 table 120
ip route add default dev tun1 table 120
ip route get 10.9.0.2

Yukarıdaki adresler ve tablo numarası yer tutuculardır. Kuralı ekledikten hemen sonra VPN sunucusunun kendi adresinin hâlâ normal tablo üzerinden çözüldüğünü doğrulayın; dış taşımayı yakalayan bir tablo, koruması gereken tüneli bozar ve ardından gelen yeniden bağlanma döngüsü güvenilmez bir sağlayıcı gibi görünür.

Yeniden bağlanmalara ve yeniden başlatmalara dayanması gereken bir kurulum için ağ ad alanı daha sağlam sınırdır. İkinci istemci kendi arabirimleri ve yollarıyla kendi ad alanında çalışır ve yalnızca sınırı geçmesi gereken hizmetler açığa çıkar. Ana bilgisayar tek bir varsayılan yolu korur ve bir ad alanı yeniden bağlanması onu yeniden yazamaz.

Durum satırıyla değil, tabloyla doğrulayın

Bağlandığını bildiren bir istemci yalnızca kontrol kanalını kanıtlar. Her bağlantıdan önce ve sonra yönlendirme durumunu yakalayın, ardından çekirdeğe gerçek bir hedefin hangi aygıtı kullanacağını sorun:

ip route show
ip route get 10.40.0.20
ss -lunp | grep 1194

İkinci tünel başladığında sağlayıcı adresi için seçilen aygıt değişirse yol çakışmanız var. Her iki süreç de aynı yerel bağlantı noktasında görünürse soket çakışmanız var. Birinciyi ikincisi olmadan düzeltmek yalnızca arızayı bir sonraki yeniden bağlanmaya taşır.

Bağlantı noktalarını, aygıtları, tabloları ve yol sahibini ana bilgisayarın runbook'una yazın. Aksi halde üçüncü bir tünel ekleyen sonraki kişi aynı çakışmayı yeniden keşfedecek ve görünen tek kanıt, başka birinin daemon'u yeniden başlayana kadar çalışan bir bağlantı olacaktır.