OpenVPN ve HTTPS 443 numaralı bağlantı noktasında: dinleyici kimin?
TCP ve UDP 443 ayrı soketlerdir. Tek bir TCP dinleyicisini paylaşmak bir sahip gerektirir ve OpenVPN'in bağlantı noktası paylaşımı dar bir düzenlemedir, proxy hilesi değil.
İki hizmet, hiç rekabet etmeden 443 numaralı bağlantı noktasında birlikte yanıt verebilir, çünkü bir dinleyici yalnızca numarayla değil taşıma, adres ve bağlantı noktasıyla birlikte belirlenir. Bir web sunucusu ile OpenVPN'i aynı makineye koyun; ilk yanıtlanmaya değer tek soru her sürecin çekirdekten hangi soketi istediğidir. Yapılandırmayı düzenlemeden önce bu listeyi yazın; «adres zaten kullanımda» hatalarının çoğu kendini açıklar. Listenin ardından her şey UDP dinleyicisi, paylaşılan TCP soketi veya protokole göre yönlendiren bir ön uç arasında seçimdir.
Her sürecin istediği soketle başlayın
Bind bu üçlüye göre başarılı olur ya da başarısız olur, dolayısıyla iki daemon yalnızca üç parça da çakıştığında çarpışır. Bu yüzden TCP 443'teki bir web sitesi UDP 443'teki bir OpenVPN dinleyicisiyle sınırsız süre bir arada yaşar ve bu yüzden ikisinden birini aynı ana makinedeki ikinci yerel adrese taşımak da tartışmayı bitirir. Canlı dinleyicileri okuyun, onları oluşturması gereken dosyaları değil, çünkü eski bir include ya da unutulmuş bir unit dosyası hatırladığınız düzenlemeden daha uzun yaşar.
| Line in the listener list | What it establishes | What to do next |
|---|---|---|
| One udp row and one tcp row, each on 443 | Separate transport sockets, nothing contested | Point the VPN profile at udp and stop editing |
| A single tcp address and port listed by two processes | A real bind collision between two daemons | Move one service, or put a dispatcher in front of both |
| A proxy process owns the socket, no vpn process | The proxy accepts and has to hand off correctly | Check that its backend speaks the protocol it forwards |
root olarak ss -lntup çalıştırın ve 443'ten söz eden her satırı, IPv6 girdileri dahil okuyun. Genellikle joker v6 dinleyicisi v4 trafiğini de kabul eder ve sizin sorumlu sandığınız dosyayı değiştirdikten sonra unuttuğunuz dinleyicinin bağlantı noktasını meşgul tutması böyle olur. Bir süreç adı sizi şaşırtırsa, herhangi bir şeye dokunmadan önce çıktıyı ss -lntup 'sport = :443' ile daraltın.
Ağ izin verdiğinde tüneli UDP'ye geçirin
UDP dinleyicisi çakışmayı tamamen atlar ve genellikle en kısa onarımdır, çünkü hiçbir soket paylaşılmaz ve yola ek bir ürün girmez. Ama bu bedava değildir. Bazı istemci ağları UDP 443'ü reset göndermeden düşürür, bu yüzden tünel bind'de başarısız olmak yerine kurulmayı durdurur ve kullanıcı okunacak bir hata olmadan VPN'in kapandığını bildirir. UDP dinleyicisi ayrıca web katmanının yeniden başlatılmasına dayanır, bu da sitesi sık sık yeniden dağıtılan bir makinede önemlidir. Kullanıcıların oturduğu ağdan test edin, çünkü sunucudaki bir shell yalnızca sunucunun kendine ulaşabildiğini kanıtlar.
Taşımayı sunucu yapılandırmasında ve istemci profilinde birlikte değiştirin. Hâlâ TCP isteyen bir profil yalnızca UDP dinleyicisine karşı yeniden bağlanma döngülerinde döner ve iki dosyayı karşılaştırana kadar bu bir ağ arızası gibi görünür.
VPN sürecinin TCP 443'e sahip olmasına izin verin, gerisini iletin
TCP sunucu modundaki Community OpenVPN, gelen bir bağlantının ilk baytlarını okur ve kendi protokolü olmayan her şeyi bir HTTPS arka ucuna iletir; port-share yönergesi bunun içindir. Arka uç, TLS etkin sıradan bir web sunucusudur ve o yönergede URL ile değil ana makine ve bağlantı noktasıyla adlandırılır.
port-share 10.0.0.5 8080
Sitenin ikinci özel adrese sahip olduğu bir makinede o satır VPN dışı trafiği 10.0.0.5:8080'e gönderir, bu yüzden HTTPS sanal ana makinesi oraya bağlanmalı ve güvenlik duvarı yerel sıçramaya izin vermelidir. Web sunucusu TLS'i kendisi sonlandırmalıdır, çünkü gelen baytlar tarayıcının özgün el sıkışmasıdır ve arada hiçbir şey onların şifresini çözmemiştir. Yönergeyi düz bir HTTP dinleyicisine yöneltin ve tarayıcı geçersiz yöntem hatası alır; bu, arka ucun yanlış yere konmasından çok bozuk bir site gibi okunur. Yönerge yalnızca TCP sunucu modunda vardır ve UDP dinleyicisinin inceleyecek bir akışı yoktur.
VPN süreci her bağlantıyı kabul ettiği için web uygulaması iletilen isteğin ziyaretçiden değil ana makinenin kendi adreslerinden birinden geldiğini görür. Gerçek istemci adresine ihtiyaç duyan her şey arka uçtaki PROXY protokol desteğine ya da onu ekleyen bir ön uca bağlıdır. Arka ucu başka bir yerel adrese taşımak ziyaretçinin adresini geri getirmez; yalnızca sitenin ana makinenin hangi adreslerini kaydettiğini değiştirir. Bir analiz raporu soruyu gündeme getirmeden önce bu sınırlamayı dağıtım notlarına yazın.
Ters proxy yanlış araçtır; dördüncü katman yönlendiricisi değildir
HTTP ters proxy, istekleri okuyabilmek için TLS'i sonlandırır; bu da bir OpenVPN akışını dokunulmadan geçiremeyeceği anlamına gelir. SNI'ye veya ilk paketin incelenmesine göre ileten dördüncü katman yönlendiricisi, VPN'in bağlı olduğu oturumu sonlandırmadığı sürece ikisinin de önünde durabilir. İki cihaz bir şemada benzer görünür ve sokette tamamen farklı davranır.
Ticari Access Server kendi bağlantı noktası paylaşım ayarlarıyla gelir ve bunlar topluluk yönergesiyle bire bir eşleşmez. Diğeri için yazılmış bir kılavuzu uyarlamadan önce ürünü ve sürümü belirleyin. Sessizce yok sayılan kopyalanmış bir ayar hiç ayar olmamasından daha kötüdür, çünkü dinleyici listesi sonrasında hâlâ inandırıcı görünür.
Web sitesini ve tüneli iki ayrı yol olarak test edin
Siteyi yükleyin ve tüneli bağlayın, ardından 443'e şu anda hangi sürecin sahip olduğunu görmek için dinleyici listesini yeniden okuyun. Yüklenen bir sayfa VPN hakkında hiçbir şey kanıtlamaz ve bağlanan bir tünel site hakkında hiçbir şey kanıtlamaz, ikisi de aynı numarayı kullansa bile. Aşağıdaki üç komut paylaşılan soketi, web yolunu ve VPN hizmetini bu sırayla denetler.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Arka ucun erişim günlüğündeki istemci adresini aynı an için VPN günlüğündekiyle karşılaştırın. Site her ziyaretçiyi ana makinenin kendisi olarak kaydediyorsa iletme çalışır ve adres işleme çalışmaz. İki günlük de sessizse ön uç bağlantıyı hiç teslim etmemiştir. Her iki durumda da soketi kimin kabul ettiğini dinleyici listesi belirler ve başka bir dosyayı değiştirmeden önce doğrulanması gereken gerçek budur.
Bu dinleyici haritasını yapılandırmanın yanında bırakın; 443'e dokunan bir sonraki kişi hangi sürecin kabul ettiğini ve diğer protokolün nereye gittiğini bilsin. Düzenlemenin ne yapması gerektiğine güvenmek yerine değişiklikten sonra sahipliği doğrulayın.