Benarkan sambungan TLS passthrough dalam konteks stream NGINX

Menghantar bait tersulit tanpa pernah memegang sijil ialah apa yang dilakukan oleh relay TLS passthrough, dan susunan ini mudah serta sedikit mengelirukan pada masa yang sama. Kerana tiada apa yang dinyahsulit, tiada apa-apa berbentuk HTTP untuk ditapis, jadi blok location biasa dan peraturan aksesnya tidak berguna di sini. Keputusan yang ada pada NGINX adalah tentang sambungan itu sendiri: peer rangkaian mana yang mengetuk, dan sama ada peer itu perlu dihantar terus.

Keputusan terletak dalam stream, bukan HTTP

Dalam konteks stream NGINX bekerja dengan sesi TCP. Ia melihat alamat peer sambungan dan boleh menggunakan peraturan allow dan deny yang tersusun padanya sebelum mana-mana bait sampai ke backend. Ini keputusan penerimaan yang lengkap dan tidak memerlukan kunci peribadi, sijil atau penghuraian HTTP.

Ketiga-tiga baris itu tidak pernah menggantikan satu sama lain. Menyalin arahan akses HTTP ke mana-mana fail yang menyebut port 443 tidak mengubah apa-apa, kerana pelayan stream tidak pernah membaca konteks http.

Terima sambungan sebelum menghantarnya

Andaikan terdapat pemasangan sedia ada dengan modul stream dan stream-access tersedia, klien VPN menyimpan alamat sumber dalam 10.90.0.0/24, dan backend di 192.168.50.20:443 yang sudah menyajikan identiti HTTPS yang dimaksudkan.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Bacalah ini sebagai serpihan listener baharu, bukan pengganti terus konfigurasi yang berjalan. Semak listener dan include sedia ada dahulu, kerana listener kedua pada port yang sudah terikat gagal semasa reload, bukan semasa permintaan.

Perhatikan apa yang tiada: tiada listen ... ssl, tiada arahan sijil. NGINX menghantar aliran tersulit, dan backend menamatkan TLS serta membentangkan sijil yang disahkan oleh klien. Klien yang gagal dalam allowlist akan ditolak sesi TCP-nya, bukan halaman HTTP 403, dan mana-mana alat yang menjangka kod status akan melaporkan sesuatu yang tidak berguna.

Apa yang diliputi allowlist dan apa yang tidak

Jika relay sudah memilih backend mengikut nama pelayan, ssl_preread dan map boleh meneruskan kerja itu, dengan syarat modul tersedia. Nama itu masih dibekalkan oleh klien, dan tiada apa dalam pembentangan nama membuktikan klien telah menyertai VPN.

Peraturan contoh meliputi keseluruhan listener stream. Itu menjadikannya tidak sesuai untuk satu titik masuk yang menyajikan campuran laman awam dan laman khusus VPN, di mana pengecualian setiap nama diperlukan; listener berasingan biasanya lebih jelas daripada dasar bergantung pada nama yang tiada siapa boleh baca.

Dua lagi jurang wajar dinamakan. Padanan awalan tidak mengatakan apa-apa tentang antara muka mana paket itu tiba, dan peraturan HTTP di tempat lain tidak boleh mengekang listener ini. Kedua-duanya adalah sebab untuk mengekalkan dasar ingress peringkat hos dalam gambaran dan bukannya menganggap satu baris allow sebagai keseluruhan sempadan. Tulis sempadan itu sebagai dua kawalan yang mesti bersetuju, supaya sebarang perubahan pada salah satu daripadanya disemak.

Alamat siapa yang NGINX sebenarnya lihat?

Penyeimbang beban, proksi lain atau source NAT boleh meletakkan perantara di hadapan NGINX, jadi peer yang diperhatikan bukan alamat dalaman klien VPN. Periksa laluan sebenar sebelum memilih awalan, kerana allowlist yang ditulis untuk alamat yang salah sama ada menerima semua orang di belakang penterjemah atau tiada sesiapa.

Protokol PROXY dan pengendalian IP sebenar ialah jawapan yang sah, dan ia hanya boleh dikonfigurasikan untuk penghantar yang serasi dan dipercayai secara eksplisit. Kedua-dua mekanisme percaya apa yang dikatakan penghantar, dan itulah sebabnya senarai penghantar mesti pendek. Mempercayai pengepala identiti daripada mana-mana klien internet tidak menjadikan maklumat sumber boleh dipercayai semula; ia mengubah penolakan yang betul menjadi penerimaan palsu.

Uji kedua-dua hasil sebelum reload

Sahkan konfigurasi, lakukan reload, kemudian uji dua kali: sesi baharu yang dibenarkan yang mesti berfungsi, dan satu yang ditolak yang tidak sepatutnya. Kekalkan pengesahan sijil backend biasa dalam ujian yang dibenarkan, kerana relay yang bersambung tetapi tidak dapat mengesahkan backend telah menyelesaikan satu masalah dan mencipta satu lagi.

nginx -t
ss -tnp | grep ':443'

Periksa laluan ke backend dan balasan secara berasingan juga. Lulus allowlist hanya membuktikan bahawa NGINX menerima sesi itu; ia tidak boleh memaksa backend yang tidak dapat dicapai untuk menjawab, dan ia tidak boleh membaiki laluan balik yang tiada sebelum anda bermula.