OpenVPN UDP yanıtı neden yanlış adresten çıkıyor

Bir OpenVPN istemcisi bir adrese bağlanır, sunucu başka bir adresten yanıt verir ve tünel hiç açılmaz. Sunucu günlüğü paketin geldiğini, bir kayıt da yanıtın çıktığını gösterir, bu yüzden hata istemciye yüklenir. Birden çok arayüze veya tek arayüzde birden çok adrese sahip bir ana bilgisayarda iki taraf hangi adresin kullanıldığı konusunda anlaşamaz. Yanıt IP katmanında geçerlidir, ancak birçok istemci kaynağı bağlandıkları adres olmayan datagramı atar.

Kaynak değiştiğinde istemci ne görür

Belirli bir yerel adrese bağlanmamış bir UDP soketinin sabit kaynağı yoktur, bu yüzden çekirdek gönderim sırasında birini seçer. Bu seçim istemcinin adresine doğru yapılan bir yol aramasından gelir ve kaynak, aramanın seçtiği arayüzün adresi olur. Tek arayüzlü bir makinede seçim görünmez; yönetim adresi, genel adres ve aynı ağ kartındaki ikincil adres bulunan bir ana bilgisayarda ise yönlendirme metriklerine ve ilkesine bağlıdır. İlke tabanlı yönlendirme uyumsuzluğu azaltmak yerine daha olası hale getirir, çünkü bir kural istemcinin hiç ulaşmadığı bir üst bağlantıyı seçebilir. Bir sağlayıcıdan öğrenilen varsayılan yol ve başka birini gösteren bir kaynak kuralı bunu üretmeye yeter.

Yanıtları filtreleyen istemciler ve tam dörtlü ile kaynağı bekleyen bağlantı izleme, yanıtı yararlı bir ileti olmadan atar. Ardından tünel hiçbir şey gelmemiş gibi zaman aşımına uğrar ve bu yüzden bu durum yanlışlıkla istemci tarafında bir güvenlik duvarı sorunu sanılır. Yalnızca sunucuda alınan bir kayıt hatayı açıklamak yerine doğrular, çünkü yanıt gerçekten çıkar. Başka bir şeyi değiştirmeden önce yanıtın kaynağını istemcinin bağlandığı adresle karşılaştırın.

multihome seçeneği gerçekte ne yapar

Yönerge yapılandırma dosyasında multihome, komut satırında --multihome olarak yazılır ve UDP sunucusunun istemcinin paketinin ulaştığı adresten yanıt vermesini sağlar. Çekirdek alırken özgün hedef adresi ek veri olarak verir ve OpenVPN bu değeri yanıtın kaynağı olarak kullanır. Böylece genel bir adreste dinleyen bir sunucu, IPv4 için local 0.0.0.0 veya IPv6 eşdeğeri, her istemci ayrı bir dinleyiciye ulaşmış gibi davranır. Genel adres üzerinden gelen istemciler yanıtları genel adresten alır, iç adresteki istemciler ise o adresten alır. Paket yolunda başka hiçbir şey hareket etmez: yol, filtre kuralları ve tünel yapılandırması tam olarak olduğu gibi kalır.

Son özellik tam da bu yüzden seçeneği başka açılardan çalışan bir sunucuya eklemeyi güvenli kılar ve yalnızca tek bir adrese izin veren bir filtreyi onaramamasının nedeni de budur. Paket yine de izlediği yolda kabul edilmelidir, bu yüzden kaynak düzeltmesi yanıtın kökenini değiştirir ve başka bir şeyi değil. Yalnızca UDP içindir: bir TCP dinleyicisi bu sorunu aynı biçimde yaşamaz, çünkü bağlantı yanıtın kaynak adresiyle değil dörtlü ile tanımlanır.

Sabit yerel adres ne zaman yanlış varsayılandır

Seçeneğe başvurmadan önce sunucunun belirli bir yerel adresi bağlayıp bağlamadığını denetleyin, çünkü bağlı bir dinleyici her zaman o adresten yanıt verir. Bu, tek arayüzlü bir kurulum için doğrudur ve istemciler yasal olarak birden çok adres kullanmaya başladığı anda yanlıştır. Bağlama bilinçli yapıldıysa sunucunun ek adreslerde trafik kabul edip etmemesi gerektiğine karar verin. Bağlamayı kaldırmak maruziyeti artırır, bu yüzden izin verilen arayüzleri ve kaynak ağları yalnızca bağlama adresi değil, hizmet ve filtre uygulamalıdır.

OpenVPN başvurusu seçeneği UDP sunucularıyla sınırlar, paket yolundaki ek işlemeye dikkat çeker ve hangi platformların desteklediğini kaydeder. Buna dayanarak plan yapmadan önce kurulu sürümde bunu doğrulayın. Desteklenmediği yerlerde belirli adresi bağlamak veya dönüş yolunu düzeltmek alternatiftir ve ikisi de ilk bakışta göründüğünden daha dar değişikliklerdir. Genel adreste dinlemek yanıtların ötesinde de sonuçlar doğurur: tüm adreslerdeki bir sunucu ana bilgisayarın bağlı olduğu her ağdan erişilebilir ve bu kimsenin amaçladığı maruziyet olmayabilir.

Yanıtın kaynağını dışarıdan kanıtlayın

Sunucunun dışından test edin ve herhangi bir şeyi yakalamadan önce istemcinin kullandığı tam adresi ve taşımayı kaydedin. Aşağıdaki üç denetim üç farklı soruya yanıt verir ve sıra önemlidir.

tcpdump -ni any udp port 1194
ss -lunp 'sport = :1194'
ip route get 203.0.113.10 from 198.51.100.20

Kayıt yanıttaki kaynak adresini gösterir ve tüm yazı bu olguya dayanır. Soket listesi sunucunun gerçekte neyi bağladığını gösterir, çünkü genel ve belirli dinleyici bir yapılandırma dosyasında aynı görünür ve ağda farklı davranır. Yol araması çekirdeğin o akış için seçeceği kaynağı gösterir ve bu, herhangi bir şeyi değiştirmeden önce kaydı açıklar. Üçünü de IPv4 ve IPv6 için ayrı ayrı yineleyin, çünkü bunlar ayrı dinleyiciler ve ayrı aramalardır ve bir aile için genel bir girdi diğeri hakkında hiçbir şey söylemez.

Yönlendirme, keşif ve filtreleme ayrı kalır

Yanıtın kaynağını korumak giden bir yol kurmaz, dinamik DNS'i güncellemez ve bir adres ailesinin diğerini kabul etmesini sağlamaz. Birden çok üst bağlantısı olan bir sunucuda her kaynak için dönüş yolu bilinçli olarak kararlaştırılmalıdır, yoksa yanıtlar istemcinin filtresinin hiç izin vermediği bir arayüzden çıkar. Aynı şekilde, önek değişikliğinden sonra yeni adres istemcilere ulaşmalıdır keşif ve desteklenen yeniden bağlanma akışı üzerinden, eski kayıt üzerinden değil.

Sunucu kimlik denetimlerini ve sertifika doğrulamasını tam olarak olduğu gibi bırakın, çünkü değişen bir adres doğrulanmamış bir eşin kabul edilmesini haklı çıkarmaz. Yanıt artık amaçlanan kaynaktan çıkıyor ve tünel hâlâ başarısız oluyorsa kaynak sorununu çözülmüş sayın ve ilerleyin. Bir sonraki gözlenen hata yönlendirmeye, filtrelemeye veya kimlik doğrulamaya aittir ve dinleyiciyi yeniden değiştirmek ona ulaşmaz. Yanıtın kaynağını, istemcinin bağlandığı adresin yanına bilete yazın, böylece sonraki kişi aynı olguyu tek bir komutla denetleyebilsin.