OpenVPN və HTTPS 443 portunda: dinləyicinin sahibi kimdir?
TCP və UDP 443 ayrı soketlərdir. Bir TCP dinləyicisini paylaşmaq sahib tələb edir və OpenVPN port paylaşımı dar bir düzənişdir, proxy hiyləsi deyil.
İki xidmət heç vaxt yarışmadan 443 portunda cavab verə bilər, çünki dinləyici yalnız nömrəyə deyil, nəqliyyat, ünvan və porta birlikdə görə açarlanır. Bir maşına veb server və OpenVPN qoyun; ilk cavablandırılmalı sual hər prosesin nüvədən hansı soketi istəməsidir. Konfiqurasiyanı redaktə etməzdən əvvəl bu siyahını yazın, və «ünvan artıq istifadə olunur» xətalarının çoxu özünü izah edəcək. Siyahıdan sonrakı hər şey UDP dinləyicisi, ortaq TCP soketi və ya protokola görə marşrutlaşdıran ön hissə arasında seçimdir.
Hər prosesin istədiyi soketlə başlayın
Bind bu üçlüyə görə uğurlu və ya uğursuz olur, ona görə iki demon yalnız hər üç hissə üst-üstə düşəndə toqquşur. Buna görə TCP 443-də veb sayt UDP 443-dəki OpenVPN dinləyicisi ilə qeyri-müəyyən müddət yanaşı yaşayır və buna görə onlardan birini eyni hostda ikinci yerli ünvana köçürmək də mübahisəni bitirir. Canlı dinləyiciləri oxuyun, onları yaratmalı olan faylları deyil, çünki köhnə include və ya unudulmuş unit faylı xatırladığınız redaktədən uzun yaşayır.
| 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 kimi ss -lntup işə salın və 443-ü xatırladan hər sətri, IPv6 girişləri də daxil olmaqla, oxuyun. Ümumi v6 dinləyicisi adətən v4 trafikini də qəbul edir; buna görə unutduğunuz dinləyici məsul bildiyiniz faylı dəyişdikdən sonra da portu tutur. Proses adı sizi təəccübləndirirsə, hər hansı bir şeyə toxunmadan çıxışı ss -lntup 'sport = :443' ilə daraldın.
Şəbəkə imkan verdikdə tuneli UDP-yə keçirin
UDP dinləyicisi toqquşmanı tamamilə yan keçir və adətən ən qısa düzəlişdir, çünki heç bir soket paylaşılmır və yola əlavə məhsul qoşulmur. Ancaq bu pulsuz deyil. Bəzi müştəri şəbəkələri UDP 443-ü reset göndərmədən atır, nəticədə tunel bind uğursuzluğu yerinə qurulmağı dayandırır və istifadəçi oxunacaq xəta olmadan VPN-in söndüyünü bildirir. UDP dinləyicisi həm də veb təbəqəsinin yenidən başlamasından uzun yaşayır, bu isə saytı tez-tez yenidən yerləşdirilən maşında önəmlidir. İstifadəçilərin olduğu şəbəkədən sınaq keçirin, çünki serverdəki shell yalnız serverin özünə çata bildiyini sübut edir.
Nəqliyyatı server konfiqurasiyasında və müştəri profilində birlikdə dəyişin. Hələ də TCP istəyən profil yalnız UDP dinləyicisi qarşısında yenidən qoşulma dövrünə girəcək və bu, iki faylı müqayisə edənə qədər şəbəkə nasazlığı kimi görünür.
Qoy VPN prosesi TCP 443-ə sahib olsun, qalanı yönləndirsin
TCP server rejimində Community OpenVPN gələn bağlantının ilk baytlarını oxuyur və öz protokolu olmayan hər şeyi HTTPS arxa hissəsinə yönləndirir; port-share direktivi buna görədir. Arxa hissə TLS aktivləşdirilmiş adi veb serverdir və bu direktivdə URL ilə deyil, host və portla adlandırılır.
port-share 10.0.0.5 8080
Saytın ikinci özəl ünvanı saxladığı maşında bu sətir VPN olmayan trafiki 10.0.0.5:8080-ə göndərir, ona görə HTTPS virtual host orada bind olunmalı və firewall yerli keçidə icazə verməlidir. Veb server TLS-i özü sonlandırmalıdır, çünki gələn baytlar brauzerin orijinal handshake-idir və arada heç nə onları deşifrə etməyib. Direktivi adi HTTP dinləyicisinə yönəldin və brauzer etibarsız metod xətası alacaq; bu, yanlış yerləşdirilmiş arxa hissə deyil, xarab sayt kimi oxunur. Direktiv yalnız TCP server rejimində mövcuddur və UDP dinləyicisinin yoxlanacaq axını yoxdur.
VPN prosesi hər bağlantını qəbul etdiyi üçün veb tətbiqi yönləndirilmiş sorğunun ziyarətçidən deyil, hostun öz ünvanlarından birindən gəldiyini görür. Həqiqi müştəri ünvanına ehtiyac duyan hər şey arxa hissədə PROXY protokol dəstəyindən və ya onu əlavə edən ön hissədən asılıdır. Arxa hissəni başqa yerli ünvana köçürmək ziyarətçinin ünvanını qaytarmır; yalnız saytın hostun hansı ünvanını qeyd etdiyini dəyişir. Analitika hesabatı sual qaldırmazdan əvvəl bu məhdudiyyəti yerləşdirmə qeydlərinə yazın.
Əks proxy yanlış alətdir; dördüncü qat marşrutlaşdırıcısı deyil
HTTP əks proxy TLS-i sonlandırır ki sorğuları oxuya bilsin, yəni OpenVPN axınını toxunmadan keçirə bilməz. SNI və ya ilk paket yoxlaması ilə yönləndirən dördüncü qat marşrutlaşdırıcısı VPN-in asılı olduğu sessiyanı bitirməmək şərti ilə hər ikisinin önünə keçə bilər. İki cihaz diaqramda oxşar görünür və soketdə tamamilə fərqli davranır.
Kommersiya Access Server öz port paylaşımı ayarları ilə gəlir və onlar community direktivi ilə birə-bir uyğun gəlmir. Digəri üçün yazılmış bələdçini uyğunlaşdırmazdan əvvəl məhsulu və versiyanı müəyyən edin. Səssizcə nəzərə alınmayan köçürülmüş ayar ayarsızlıqdan pisdir, çünki sonra dinləyici siyahısı hələ də inandırıcı görünür.
Saytı və tuneli iki ayrı yol kimi sınayın
Saytı yükləyin və tuneli qoşun, sonra 443-ə indi hansı prosesin sahib olduğunu görmək üçün dinləyici siyahısını yenidən oxuyun. Yüklənən səhifə VPN haqqında heç nə sübut etmir, qoşulan tunel sayt haqqında heç nə sübut etmir, baxmayaraq ki hər ikisi eyni nömrədən istifadə edir. Aşağıdakı üç əmr ortaq soketi, veb yolunu və VPN xidmətini bu sıra ilə yoxlayır.
ss -lntup 'sport = :443' curl -sI https://vpn.example.com/ | head -n 1 journalctl -u openvpn-server@server -n 20
Eyni anda arxa hissənin giriş jurnalındakı müştəri ünvanını VPN jurnalındakı ilə müqayisə edin. Sayt hər ziyarətçini hostun özü kimi qeyd edirsə, yönləndirmə işləyir, ünvan emalı isə işləmir. Hər iki jurnal sussursa, ön hissə bağlantını heç vaxt təhvil verməyib. Hər halda dinləyici siyahısı soketi kimin qəbul etdiyini həll edir və başqa faylı dəyişməzdən əvvəl təsdiqlənməli fakt budur.
Bu dinləyici xəritəsini konfiqurasiyanın yanında saxlayın ki, 443-ə toxunan növbəti şəxs hansı prosesin qəbul etdiyini və digər protokolun hara getdiyini bilsin. Dəyişiklikdən sonra sahibliyi təsdiqləyin, redaktənin nə etmək istədiyinə güvənməyin.