OpenVPN UDP üçün Nginx axın ötürücüsü: nəyi dəyişir
UDP HTTP location-a aid deyil. Onu stream qatına köçürün, sessiya taym-autunu VPN üçün ölçün və mənbə kimi proksini gözləyin.
Müştəriniz UDP-yə qurulub, Nginx serverində VPN portuna baxan location bloku var, amma heç nə gəlmir. Bu gözləniləndir: HTTP location UDP verinqramını daşıya bilməz, ön hissə necə adlandırılsa da. Nginx bunun üçün stream dinləyicisi tələb edir və konfiqurasiyanı ora köçürdükdən sonra sessiyanın davam edib-etmədiyini ikinci detallar toplusu həll edir.
Proksi qatı ünvandan əvvəl gəlir
Nginx-in stream modulu HTTP-ni təhlil etmədən TCP və UDP-ni proksiləyir. HTTP modulu sorğu sətri, başlıqlar və cavab gözləyir ki, bunların heç biri OpenVPN verinqramında yoxdur. Qatı seçmək buna görə ilk qərardır və dinləyicinin IPv4 yoxsa IPv6 olmasından asılı deyil.
TCP OpenVPN ilə işlədiyi görünən konfiqurasiya UDP halı haqqında heç nə demir. Burada nəqliyyat protokolun bir hissəsidir, yerləşdirmənin detalı deyil.
Dinləyici və backend
nginx -V 2>&1 | tr ' ' '\n' | grep stream
stream {
server {
listen [::]:1194 udp reuseport;
proxy_pass [2001:db8::20]:1194;
}
}
Nəyisə redaktə etməzdən əvvəl build-in stream modulunu ehtiva etdiyini yoxlayın; distributiv paketi onu ayrı modula bölə bilər və modulun olmaması tunel deyil, konfiqurasiya xətası verir. Bloku əsas konfiqurasiya kontekstinə qoyun, http içərisinə yox, və sənədləşdirmə ünvanını real backend ilə əvəz edin.
Hər iki marşrut və hər iki firewall verinqramlara icazə verməlidir: dinləyiciyə gedən yol və proksidən backendə gedən yol. IPv6 dinləyicisi IPv4 yolu da yaratmır, ona görə bəzi müştərilər hələ də IPv4 istifadə edirsə, o dinləyici öz testi ilə ayrıca girişdir. Backendin öz firewallunu proksin ünvanından yoxlayın, noutbukdan yox.
Sessiya taym-autları sorğu taym-autları deyil
stream proksisi UDP sessiyası üçün vəziyyət saxlayır və onu öz taym-aut və cavab parametrlərinə uyğun atır. DNS relay-dən köçürülmüş qısa taym-aut saatlarla verinqram mübadiləsi gözləyən VPN üçün yaramazdır və nasazlıq başlamaqdan imtina edən deyil, səssizcə ölən bağlantı kimi görünür.
Yerləşdirmənin faktiki proxy_timeout dəyərini və hər hansı cavab sayı parametrini oxuyun, sonra onları VPN-in həqiqətən istifadə etdiyi keepalive davranışı ilə müqayisə edin. Fərqli insanların fərqli fayllarda yazdığı iki rəqəm işlək sistemin normal vəziyyətidir. Heç vaxt müqayisə olunmamış iki rəqəm isə fasilələrlə işləyən sistemin normal vəziyyətidir. Hər ikisini xidmət qeydinə yazın ki, müqayisə bir dəfə, gün işığında baş versin.
Relay nəyi dəyişir və nəyi dəyişmir
stream proksisi OpenVPN-in TLS idarəetmə kanalını sonlandırmır və onu HTTPS-ə çevirmir. Backend VPN xidməti olaraq qalır və sertifikat əlaqəsi müştəri ilə həmin xidmət arasında qalır. Nəzərdə tutulan backend kimliyinin qorunması yenə də müştərinin və serverin işidir.
Adi proksiləmə backendin gördüyü mənbə ünvanını da dəyişir. Qeydlərdə proksi görünəcək və VPN serverindəki hər hansı IP-əsaslı giriş qaydası müştərinin ünvanını deyil, həmin ünvanı qiymətləndirəcək. Şəffaf mənbə qorunması ayrı marşrutlaşdırma və imtiyaz dizaynıdır, dinləyiciyə udp əlavə etməkdən irəli gələn bir şey deyil. Müştəri ünvanından asılı siyasət yazılmazdan əvvəl bunu planlaşdırın.
Portdan deyil, müştəridən yoxlayın
UDP portunun açıq olmasının yerli yoxlaması dinləyicinin mövcudluğunu sübut edir. Müştərinin ondan keçərək autentifikasiya edə bildiyini və ya trafik mübadiləsini davam etdirə bildiyini sübut etmir. Təsdiqlənmiş müştəridən real bağlantı qurun, sonra sessiyanın kifayət qədər uzun müddət davam etdiyini yoxlayın.
Kimsə Nginx-in UDP edə bilmədiyini, sadə relay alətinin əvəzində işlədiyini deyəndə, bu iki fakt əlaqəsizdir. Alət backendin cavab verdiyini sübut etdi; ön hissənin nəyi dəstəklədiyi barədə heç nə demədi. Hər ikisi doğru ola bilər və yalnız biri bu yerləşdirmə üçün konfiqurasiyadır.