Payagan ang isang TLS passthrough na koneksyon sa kontekstong stream ng NGINX

Ang pagpapasa ng mga naka-encrypt na byte nang hindi kailanman hinahawakan ang sertipiko ay siyang ginagawa ng isang TLS passthrough relay, at ang kaayusang ito ay maginhawa at medyo nakakalito rin. Dahil wala namang nadidecrypt, walang anumang hugis-HTTP na maaaring salain, kaya ang karaniwang location block at ang mga tuntunin nito sa pag-access ay walang silbi dito. Ang desisyong nasa NGINX ay tungkol sa koneksyon mismo: aling peer ng network ang kumatok, at kung dapat bang ipasa ang peer na iyon.

Ang desisyon ay nasa stream, hindi sa HTTP

Sa kontekstong stream, gumagana ang NGINX sa mga session ng TCP. Nakikita nito ang peer address ng koneksyon at maaaring maglapat ng mga nakaayos na tuntuning allow at deny dito bago pa man makarating ang anumang byte sa backend. Ito ay isang kumpletong desisyon sa pagtanggap at hindi ito nangangailangan ng pribadong susi, sertipiko, o pag-parse ng HTTP.

Ang tatlong linyang iyon ay hindi kailanman nagpapalitan. Ang pagkopya ng direktiba sa pag-access ng HTTP sa alinmang file na nagbanggit ng port 443 ay walang binabago, dahil hindi kailanman binabasa ng server ng stream ang kontekstong http.

Tanggapin ang koneksyon bago ito ipasa

Ipagpalagay na may umiiral na pag-install na may mga module na stream at stream-access, ang mga kliyente ng VPN ay nag-iingat ng mga source address sa 10.90.0.0/24, at may backend sa 192.168.50.20:443 na naghahatid na ng inilaan na pagkakakilanlang HTTPS.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Basahin ito bilang isang bahagi ng bagong listener, hindi bilang direktang kapalit ng gumaganang configuration. Suriin muna ang mga umiiral na listener at include, dahil ang pangalawang listener sa isang port na okupado na ay nabigo sa reload, hindi sa oras ng kahilingan.

Pansinin ang nawawala: walang listen ... ssl, walang direktiba ng sertipiko. Ipinapasa ng NGINX ang naka-encrypt na stream, at tinatapos ng backend ang TLS at inihaharap ang sertipikong binabalido ng kliyente. Ang kliyenteng nabigo sa allowlist ay tatanggihan ang session ng TCP, hindi isang pahinang HTTP 403, at anumang tool na umaasa sa status code ay mag-uulat ng walang silbi.

Ano ang sakop ng allowlist at ano ang hindi

Kung ang relay ay pumipili na ng backend ayon sa pangalan ng server, ang ssl_preread at isang map ay maaaring magpatuloy sa gawaing iyon, basta’t available ang module. Ang pangalan ay ibinibigay pa rin ng kliyente, at walang anuman sa paghaharap ng pangalan ang nagpapatunay na sumali ang kliyente sa VPN.

Ang tuntunin sa halimbawa ay sumasaklaw sa buong stream listener. Ginagawa nitong hindi angkop para sa isang solong punto ng pagpasok na naghahatid ng pinaghalong pampublikong site at site para sa VPN lamang, kung saan kailangan ang pagbubukod sa bawat pangalan; ang magkakahiwalay na listener ay karaniwang mas malinaw kaysa sa patakarang nakadepende sa pangalan na walang sinumang makababasa.

Dalawa pang puwang ang dapat banggitin. Ang pagtutugma ng prefix ay walang sinasabi tungkol sa kung aling interface dumating ang packet, at ang isang tuntunin ng HTTP sa ibang lugar ay hindi maaaring magpataw ng limitasyon sa listener na ito. Pareho itong dahilan upang panatilihin ang patakaran ng ingress sa antas ng host sa larawan sa halip na ituring ang isang linyang allow bilang ang buong hangganan. Isulat ang hangganan bilang dalawang kontrol na dapat magkasundo, upang ang anumang pagbabago sa alinman sa mga ito ay masuri.

Kaninong address ang aktwal na nakikita ng NGINX?

Ang isang load balancer, isa pang proxy, o source NAT ay maaaring maglagay ng tagapamagitan sa harap ng NGINX, kaya ang peer na nakikita ay hindi ang panloob na address ng kliyente ng VPN. Suriin ang tunay na landas bago pumili ng prefix, dahil ang allowlist na isinulat para sa maling address ay alinman sa tinatanggap ang lahat ng nasa likod ng tagasalin o wala.

Ang protocol na PROXY at ang paghawak ng tunay na IP ay mga lehitimong sagot, at dapat lamang i-configure para sa mga katugmang, tahasang pinagkakatiwalaang nagpadala. Ang dalawang mekanismo ay naniniwala sa sinasabi ng nagpadala, at iyon ang dahilan kung bakit dapat maikli ang listahan ng nagpadala. Ang pagtitiwala sa header ng pagkakakilanlan mula sa anumang kliyente ng internet ay hindi ginagawang mapagkakatiwalaan muli ang impormasyon ng pinagmulan; ginagawa nitong isang pekeng pagtanggap ang isang tamang pagtanggi.

Subukan ang parehong resulta bago mag-reload

Balidahin ang configuration, mag-reload, pagkatapos ay subukan nang dalawang beses: isang bagong pinahintulutang session na dapat gumana, at isang tinanggihan na hindi dapat. Panatilihin ang normal na beripikasyon ng sertipiko ng backend sa pinahintulutang pagsubok, dahil ang relay na kumokonekta ngunit hindi maaaring magbalido ng backend ay nalutas ang isang problema at lumikha ng isa pa.

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

Suriin din nang hiwalay ang ruta patungo sa backend at ang tugon. Ang pagpasa sa allowlist ay nagpapatunay lamang na tinanggap ng NGINX ang session; hindi nito mapipilitang tumugon ang isang backend na hindi maabot, at hindi nito maaayos ang isang landas pabalik na kulang bago ka magsimula.