İki DNS adı, bir OpenVPN portu: həqiqətdə nə seçir

İki A qeydi, bir ünvan, bir demon: istifadəçi hansı adı yazsa da, gələn paket eynidir və 1194 portuna bağlanmış prosesin ikisini ayırd etmək üçün heç bir vasitəsi yoxdur. Bu, düzəldilməyi gözləyən səhv konfiqurasiya deyil; ad axtarışının ifadə edə biləcəyi sərhəddir. İki OpenVPN instansiyası arasında seçim edən hər şey müştərinin bağlantıya qoyduğu və ön tərəfin geri oxuya bildiyi dəyər olmalıdır, standart OpenVPN müştərisi isə açıq formada belə bir dəyər qoymur. Bundan sonrası bunun sizi hansı vəziyyətdə qoyduğu və hansı quruluşların trafiki həqiqətən ayırdığıdır.

Resolverin qaytardığı ilə başlayın

Müştəri vpn-a.example üçün sorğu göndərir və bir ünvan alır; o ünvan üstəgəl port onun qoşulduğu hər şeydir. Ad axtarış zamanı yerli olaraq xərclənir və heç vaxt naqildə sahəyə çevrilmir, buna görə qarşı tərəfdəki dinləyici hansı etiketin istifadə edildiyini görə bilmir. vpn-a.example və vpn-b.example-i bir hosta yönəldin, hər iki axtarış eyni təyinatı verəcək, buna görə də demon heç bir fərq qeyd etmədən hər iki bağlantını bir instansiyaya qəbul edir. Ünvana əsaslanan profillər də eyni səbəbdən ada əsaslananlar kimi davranır.

Bu, həm də cəlbedici bir sıra həll yollarını bağlayır: əlavə ləqəblər, bir soketdə hər ad üçün sertifikat seçmək və ya sorğulanan ada bağlanmış firewall qaydası. Onların heç biri müştəridən ilk paket çıxmazdan əvvəl artıq atılmış məlumat üzərində işləyə bilməz. Əgər iki server ayrı qalmalıdırsa, ayırma bağlantının özü ilə birlikdə getməlidir, yəni ünvan, port və ya protokolun təyin etdiyi faydalı yük sahəsi.

Sayılan yeganə seçici paketin içində gedir

HTTP bunu Host başlığı ilə, TLS isə ClientHello daxilində server adı uzantısı ilə idarə edir; bir ünvanın bir dinləyici arxasında çoxlu saytı belə xidmət etməsi bundandır. Hər ikisi işləyir, çünki naqil protokolu konkret xidmət üçün sorğu daşıyır. OpenVPN ilə bağlı aktual fakt budur ki, aralıq qutu tərəfindən yoxlanılan qatda bu sahələrin heç biri yoxdur.

Standart quruluşda idarə kanalını qoruyan TLS əl sıxışması xarici sessiya qurulduqdan sonra baş verir və onun içində daşınır, buna görə həmin sessiyanı sonlandırmamış dinləyici qeyri-şəffaf bir axın görür. O, hələ də bunun OpenVPN olduğunu deyə bilər, çünki açılış baytlarındakı opkodu və çərçivələmə tanınır, lakin server adı, əgər varsa, şifrələnmiş hissədə oturur. Xarici paketdən virtual host oxumağı gözləyən dizayn protokolun heç vaxt ora yazmadığı sahəni oxuyur. Bu, tunelin necə qurulmasından irəli gəlir, daha ağıllı nümunə uyğunluğunun bağlaya biləcəyi boşluqdan deyil.

Protokol bölücüsünün çatmadığı yer

sslh layihəsinin sənədləşdirdiyi tipli multipleksor bir portda dinləyir, açılış baytlarını yoxlayır və bağlantını tanıdığı protokolu danışan hansı backend varsa ona verir. Bu, bir portun SSH, HTTPS və OpenVPN-ə birlikdə xidmət etməli olduğu halda real dəyərdir.

sslh hər protokol üçün ayrı prob saxlayır və onun TLS probu əsl ClientHello-dan server adı və ya ALPN dəyəri çıxara bilir. Native OpenVPN-i tanımaq TLS uzantısını oxumaqdan fərqli təsnifatdır və ikisi birləşmir, çünki dinləyici soketine heç vaxt ClientHello göndərməyən müştəri probu oxuyacaq bir şey olmadan qoyur. Buna görə OpenVPN-ə uyğunlaşan qayda “bu OpenVPN müştərisidir” cavabını verir və daha irəli getmir. Həmin qaydanın arxasındakı iki OpenVPN backend-i ayırd edilə bilməz, ön tərəfin seçim üçün heç bir əsası yoxdur və hər sessiya eyni yerə düşür. Multipleksləmə bir portu müxtəlif xidmətlər arasında paylaşır; bir xidmətin daxilində virtual hostinq etmir.

İki serveri həqiqətən ayıran quruluşlar

Ən ucuz vicdani ayırma ikinci ictimai ünvandır, hər instansiya üçün bir ədəd, və mövcud profillər lazım olanı artıq daşıyır, çünki fərqli ünvanlara baxırlar. Növbəti yol eyni ünvanda fərqli portdur və bu, hər profildə bir rəqəmdən başqa heç nəyə başa gəlmir. TCP və UDP ayrı port cədvəlləri saxlayır, buna görə 1194/tcp və 1194/udp əlaqəsiz soketlərdir və hər birindən biri bir hostda birlikdə mövcud ola bilər; bu ada görə marşrutlaşdırma deyil, nəqliyyat ayrımıdır və tez-tez onunla səhv salınır. Hər iki variant firewall baxışından keçir, çünki qayda paketin həqiqətən saxladığı bir şeyə uyğunlaşır.

Lazım olan sərhəd iki tətbiq arasında deyil, istifadəçi qrupları arasında keçirsə, fərqli müştəri konfiqurasiyaları, öz sertifikat idarəetməsi və açıq giriş siyasəti olan bir instansiya bunu örtə bilər. Bunun verdiyi şey server daxilində siyasətdir, serverlər arasında izolyasiya deyil, və bu ikisi fərqli tələblərdir. Kompromis altında davam etməli olan izolyasiya hələ də ünvana və ya firewall kənarına ehtiyac duyur.

OpenVPN-in qarşısına qoyulan TLS sonlandırıcısı qabiliyyətli ön tərəfə əsl server adını göstərə bilər, lakin yalnız müştəri tərəfi də həmin əlavə qat üçün konfiqurasiya edildikdə. Mövcud profillər eyni ünvana yönəldilməklə bu davranışı qazanmır.

Qurmadan əvvəl seçicini sübut edin

Backend-i müəyyən edəcək sahəni adlandırın, sonra müştərinin onu həqiqətən göndərdiyini təsdiqləyin; cavab ünvandırsa plan dayanır, əgər dinləyiciyə heç vaxt çatmayan əl sıxışması daxilində server adıdırsa, heç bir DNS işi onu xilas etməyəcək. Üç əmr dinləyici tərəfi tez həll edir.

ss -lntup | grep -E ':443|:1194'
openssl s_client -connect vpn-a.example:443 -servername vpn-a.example </dev/null | head -n 20
journalctl -u openvpn-server@server-a -n 20 --no-pager

openssl sətri yalnız o ünvanda nə isə TLS-i sonlandırdıqda sertifikat verir; native OpenVPN dinləyicisinə qarşı isə dayanır və ya uğursuz olur, bu da xarici qatın nə açdığına dair cavabın özüdür. journal sətri hər backend-də oxunduqda hansı instansiyanın sessiyanı qəbul etdiyini göstərir. Ön tərəf qeydləri təsnif ediləni yazır, nəzərdə tutulanı heç vaxt yazmır, buna görə istifadəçinin hara düşdüyü barədə yeganə səlahiyyət backend olaraq qalır.

Fərqli serverlərə çatmaq üçün nəzərdə tutulmuş iki profillə bitirin, onları bir-bir qoşun və hər biri üçün backend qeydini yazın. Əgər hər iki sessiya eyni jurnalda görünürsə, seçici səhv konfiqurasiya edilməyib, sadəcə yoxdur, və düzəliş müştərinin hədəfləyə biləcəyi ünvan və ya portdur. Marşrutlaşdırma qaydasını redaktə etmək kömək etməyəcək, çünki qaydaya heç vaxt marşrutlaşdıracaq bir şey verilməyib. Ayırma real olduqdan sonra onu profillərin yanında yazın ki, növbəti adam ikinci ləqəb əlavə edib ondan iş görməsini gözləməsin.