stunnel arkasında OpenVPN: 1194 portunu değil, sarmalayıcıyı iletin

Bir TLS sarmalayıcısını OpenVPN önüne koyun ve dağıtım ikinci bir dinleyici kazanır; bunlardan yalnızca biri internete bakmalıdır. Tünel aynı makineden çalışıp dışarıdan başarısız olduğunda iletim genellikle ikisinden yanlış olana yönelmiştir. Hizalanması gereken şey bir zincirdir: genel kural sarmalayıcıya ulaşır ve sarmalayıcının kendi arka uç bağlantısı gerçek VPN soketine ulaşır. Dört atlama bu zinciri taşır ve herhangi biri soruşturmayı erken bitirebilir.

İki soket, iki sahip, biri genel

Sarmalayıcı dış bağlantı için TLS'yi sonlandırır ve çözülmüş bayt akışını sıradan bir OpenVPN TCP dinleyicisine aktarır. Bunlar ayrı yapılandırma dosyalarına sahip ayrı soketlerdir, bu yüzden birini düzenlemek diğerini dokunulmamış ve hâlâ görünüşte sağlıklı bırakır. Bu ayrıca ikisinin, biri diğeri olmadan değiştirildiğinde birbirinden uzaklaşabileceği anlamına gelir.

Makinenin kendisinden çalışmak, genel yol hakkında çok az şey kanıtlar. Yerel porta doğrudan bağlantı sarmalayıcıyı atlar, sarmalayıcıya onun LAN adresinden bağlantı çeviriyi atlar ve yalnızca istemci tarafındaki eksiksiz düzen, dışarıdaki bir kullanıcının yaptığını çalıştırır. Adlar da dikkatle okunmalıdır, çünkü localhost o belirli bileşeni çalıştıran ana makine anlamına gelir, tesadüfen yazdığınız makine değil. Bu ayrımı notlarınızda tutun, çünkü kapsadığı atlama belirtilmeden kaydedilen bir test iki farklı şeyi karşılaştırmaya davet eder.

İletim gerçekte nereye iner

Zinciri üç port numarası olarak değil dört atlama olarak tutmak daha kolaydır, çünkü aynı numara her uçta farklı anlamlara gelebilir. Tabloyu satır satır okuyun: her satır bir bağlantıyı kabul edip sonra bir sonrakini açması gereken bir sokettir. Bir satır yanlış eşe yöneldiğinde, son sütundaki belirti kullanıcının bildirdiği şeydir.

Sarmalayıcı yerine yerel VPN portunu hedefleyen bir kural TLS sonlandırmasını tamamen atlar ve bu hatanın en yaygın biçimi budur: istemci, OpenVPN çerçevelemesi bekleyen bir dinleyiciyle el sıkışma açar, bu yüzden bağlantı açılıp sonra takılabilir. Çevrilmiş portu belleğe değil sarmalayıcının yapılandırma dosyasına karşı doğrulayın, çünkü o dosyayı bir sonraki düzenleyen kişi başka bir numara seçmiş olabilir. Aşağıdaki iki komut o sorunun iki yüzünü aynı anda gösterir.

grep -nE '^[[:space:]]*(accept|connect)' /etc/stunnel/stunnel.conf
ss -lntp | grep -E ':443|:8443|:1194'

Sizi reddeden bağlama adresi

127.0.0.1 adresine bağlanmış accept satırı yalnızca ana makinenin kendisine yanıt verir, bu yüzden LAN adresine gelen iletim bağlanamaz ve istemci paket filtresi sorunu gibi görünen bir ret görür. Güvenlik duvarına dokunmadan önce sokete bakın, çünkü soket daha ucuz yanıttır. Ya sarmalayıcıyı iletimin hedeflediği arayüze bağlayın ya da loopback üzerinde tutup iletimin gerçekten çalışan bir şey aracılığıyla loopback'e ulaşmasını sağlayın. Bunlar iki tasarımdır ve her biri kendi kuralına ihtiyaç duyar.

İkisini karıştırmak, çalışan bir sarmalayıcının dışarıdan erişilemez hale gelmesinin yoludur; oysa her dosya doğru görünür. Aşağıdaki kontrol tek bir komuttur ve güvenlik duvarı kurallarının gözden geçirilmesinin yanıtlayamadığı bir soruyu yanıtlar. Çıktı loopback adresi gösterirken iletim LAN adresini hedefliyorsa, düzeltme accept satırına aittir, paket filtresine değil.

ss -lntp '( sport = :8443 )'

Yerel test gerçekte neyi kanıtladı

Kapsadığı atlama belirtilmeden kaydedilen bir başarı, diğer atlamalar hakkında kanıt değildir. Testin hangi adresi kullandığını ve hangi sürecin yanıt verdiğini not edin. Sonra aynı Wi-Fi'daki bir telefondan değil, ağın dışından yineleyin, çünkü toka davranışı yönlendiriciler arasında değişir ve LAN'dan hiç çıkmamış bir bağlantı bile iletim hiç devrede olmadan istemciyi tatmin edebilir. Yalnızca o ikinci deneme, bir yabancının izlediği yolu çalıştırır.

Deneme başarısız olduğunda, tek bir bağlantıyı iki günlükte izleyin: sarmalayıcının kabul ve bağlantı satırları, ardından VPN daemonunun kendi oturum günlüğü. Hiçbir şey kaydetmeyen ilk sınır, bir sonraki değişikliğin yeridir. OpenVPN eş seçeneklerini karşılaştırmaya başladığında, bu mesajları o uygulamanın kurallarına göre değerlendirin. link-mtu tutarsızlığı uyarısı otomatik olarak ölümcül değildir, link-mtu'yu 1500'e sabitlemek parçalanmanın durduğunu kanıtlamaz ve şifre pazarlığı yönlendiricinin iletimine değil OpenVPN'in iç yapılandırmasına aittir.

nc -vz 127.0.0.1 1194
journalctl -u stunnel -n 50 --no-pager

Bu sondalar arka uç soketini ve sarmalayıcı günlüğünü kapsar, bu da reddedilen arka ucu reddedilen el sıkışmadan ayırır. Onları tek bir deneme sürerken çalıştırın, sonra değil. Tek bir denemenin zaman damgaları karşılaştırmayı güvenilir kılan şeydir.

İki kimlik, iki başarısızlık sırası

Dış sertifika sarmalayıcıya, iç kimlik ise OpenVPN'e aittir ve farklı otoritelerden gelebilirler. Bir yolu sağlıklı göstermek için iki kontrolden birini kapatmak, gerçek bir korumayı görsel bir sonuçla değiştirir. Her iki doğrulamayı da koruyun ve sırayla hata ayıklayın, çünkü mesajların sırası katmanı adlandırır: sarmalayıcı sertifikası sorunu herhangi bir VPN seçeneği pazarlık edilmeden önce ortaya çıkar, iç kimlik hatası ise ancak akış kurulduktan sonra görünür.

stunnel kılavuzu accept, connect ve istemci modunu kesin olarak tanımlar ve bu bölümler soket sorusunu tahmin etmekten daha hızlı yanıtlar. Hangi katmanın yanıt verdiğini hâlâ söyleyemiyorsanız, aşağıdaki komutla genel portun sunduğu sertifikayı okuyun. Çıktıda sarmalayıcı sertifikası olması iletimin sarmalayıcıya ulaştığı anlamına gelir, sessizlik veya protokol hatası ise ulaşmadığı anlamına gelir. Bu tek ayrım buradaki herhangi bir başka kontrolden daha fazla zaman kazandırır.

openssl s_client -connect vpn.example:443 -servername vpn.example </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer