NGINX stream kontekstində TLS passthrough bağlantısına icazə vermək
NGINX TLS-i sonlandırmadan TCP TLS ötürülməsini rədd edə bilər. İcazə qaydasını HTTP location-da deyil, stream-də yerləşdirin və hansı peer ünvanının gəldiyini yoxlayın.
Şifrələnmiş baytları sertifikatı heç vaxt saxlamadan ötürmək TLS passthrough relay-in işidir və bu quruluş həm rahat, həm də bir qədər qarışıqdır. Heç nə deşifrə olunmadığı üçün filtrləmək üçün HTTP formalı heç nə yoxdur, buna görə adi location bloku və onun giriş qaydaları burada heç bir işə yaramır. NGINX-in verə biləcəyi qərar bağlantının özünə aiddir: hansı şəbəkə peer-i qapını döydü və o peer ümumiyyətlə ötürülməlidirmi.
Qərar HTTP-də deyil, stream-dədir
stream kontekstində NGINX TCP sessiyaları ilə işləyir. Bağlantının peer ünvanını görür və hər hansı bayt backend-ə çatmazdan əvvəl ona sıralı allow və deny qaydaları tətbiq edə bilər. Bu tam qəbul qərarıdır və nə şəxsi açar, nə sertifikat, nə də HTTP təhlili tələb etmir.
| Mechanism | What it decides | Where it lives |
|---|---|---|
| stream allow/deny | Whether this TCP peer is relayed | stream server block |
| ssl_preread map | Which backend a named connection goes to | stream, with the preread module |
| HTTP location rule | Whether an HTTP request is served | http server block |
O üç sətir heç vaxt bir-birini əvəz etmir. HTTP giriş direktivini 443 portunu qeyd edən hansı fayla kopyalamaq heç nəyi dəyişmir, çünki stream serveri http kontekstini heç vaxt oxumur.
Bağlantını ötürməzdən əvvəl qəbul edin
stream və stream-access modullarının mövcud olduğu mövcud quraşdırmanı, mənbə ünvanlarını 10.90.0.0/24 daxilində saxlayan VPN müştərilərini və artıq nəzərdə tutulan HTTPS kimliyini təqdim edən 192.168.50.20:443 ünvanındakı backend-i fərz edin.
stream {
server {
listen 443;
allow 10.90.0.0/24;
deny all;
proxy_pass 192.168.50.20:443;
}
}
Bunu işlək konfiqurasiyanın birbaşa əvəzi kimi deyil, yeni listener fraqmenti kimi oxuyun. Əvvəlcə mövcud listener-ləri və include-ları nəzərdən keçirin, çünki artıq bağlanmış portda ikinci listener sorğu vaxtında deyil, reload zamanı uğursuz olur.
Nəyin olmadığına diqqət yetirin: listen ... ssl yoxdur, sertifikat direktivi yoxdur. NGINX şifrələnmiş axını ötürür, backend TLS-i sonlandırır və müştərinin yoxladığı sertifikatı təqdim edir. İcazə siyahısından keçməyən müştərinin TCP sessiyası rədd edilir, HTTP 403 səhifəsi deyil, və status kodu gözləyən hər hansı alət faydasız bir şey göstərəcək.
İcazə siyahısı nəyi əhatə edir və nəyi etmir
Əgər relay artıq backend-ləri server adına görə seçirsə, modul mövcud olduqda ssl_preread və map bu işi davam etdirə bilər. Adı hələ də müştəri təqdim edir və ad təqdim etmək müştərinin VPN-ə qoşulduğunu sübut etmir.
Nümunə qaydası bütün stream listener-i əhatə edir. Bu onu həm ictimai, həm də yalnız VPN saytlarının qarışığını təqdim edən bir giriş nöqtəsi üçün yararsız edir, orada hər ad üçün istisna lazım olardı; ayrı listener-lər heç kimin oxuya bilməyəcəyi addan asılı siyasətdən adətən daha aydındır.
Daha iki boşluğu qeyd etmək lazımdır. Prefiks uyğunluğu paketin hansı interfeysdən gəldiyi barədə heç nə demir və başqa yerdəki HTTP qaydası bu listener-i məhdudlaşdıra bilməz. Hər ikisi bir allow sətrini bütün sərhəd hesab etmək əvəzinə host səviyyəli ingress siyasətini işdə saxlamaq üçün səbəbdir. Sərhədi razılaşmalı olan iki nəzarət kimi yazın ki, hər hansı birinə edilən dəyişiklik nəzərdən keçirilsin.
NGINX əslində kimin ünvanını görür?
Yük balanslaşdırıcısı, başqa proxy və ya mənbə NAT NGINX-in qarşısında vasitəçi yerləşdirə bilər, buna görə gördüyü peer VPN müştərisinin daxili ünvanı deyil. Prefiks seçməzdən əvvəl real yolu yoxlayın, çünki səhv ünvan üçün yazılmış icazə siyahısı ya tərcüməçinin arxasındakı hamını qəbul edir, ya da heç kimi.
PROXY protokolu və real IP emalı qanuni cavablardır və yalnız uyğun, açıq şəkildə etibar edilən göndərənlər üçün konfiqurasiya edilməlidir. Hər iki mexanizm göndərənin dediyinə inanır və göndərən siyahısının qısa olmasının səbəbi də məhz budur. Hər hansı internet müştərisindən gələn kimlik başlığına etibar etmək mənbə məlumatını yenidən etibarlı etmir; düzgün imtinanı saxta qəbula çevirir.
Reload-dan əvvəl hər iki nəticəni yoxlayın
Konfiqurasiyanı yoxlayın, reload edin, sonra iki dəfə sınaqdan keçirin: işləməli olan yeni icazəli sessiya və işləməməli olan rədd edilmiş biri. İcazəli sınaqda normal backend sertifikat yoxlamasını saxlayın, çünki qoşulan amma backend-i yoxlaya bilməyən relay bir problemi həll edib başqasını yaratmışdır.
nginx -t
ss -tnp | grep ':443'
Backend marşrutunu və cavabı da ayrıca yoxlayın. İcazə siyahısından keçmək yalnız NGINX-in sessiyanı qəbul etdiyini sübut edir; o, əlçatmaz backend-i cavab verməyə məcbur edə bilməz və siz başlamazdan əvvəl çatışmayan dönüş yolunu bərpa edə bilməz.