NGINX-ийн stream контекст дахь TLS passthrough холболтыг зөвшөөрөх

NGINX нь TLS-ийг дуусгахгүйгээр TCP TLS релейг татгалзаж болно. Зөвшөөрлийн дүрмийг HTTP location-д биш, stream-д байрлуулж, ямар peer хаяг ирж байгааг шалгаарай.

Сертификатыг хэзээ ч эзэмшихгүйгээр шифрлэсэн байтуудыг дамжуулах нь TLS passthrough релейн ажил бөгөөд энэ зохион байгуулалт нь тохиромжтой бөгөөд бага зэрэг төөрөгдүүлдэг. Юу ч тайлагдахгүй тул шүүх HTTP хэлбэрийн зүйл байхгүй, тиймээс ердийн location блок болон түүний хандалтын дүрмүүд энд ямар ч ашиггүй. NGINX-ийн гарт байгаа шийдвэр нь холболтын тухай: аль сүлжээний peer тогшиж, түүнийг огт дамжуулах ёстой эсэх.

Шийдвэр нь HTTP-д биш, stream-д

stream контекстэд NGINX нь TCP сессүүдтэй ажилладаг. Холболтын peer хаягийг хардаг бөгөөд ямар ч байт backend-д хүрэхээс өмнө түүнд дараалсан allow болон deny дүрмийг хэрэглэж чадна. Энэ нь бүрэн хүлээн авах шийдвэр бөгөөд хувийн түлхүүр, сертификат эсвэл HTTP шинжилгээ шаарддаггүй.

MechanismWhat it decidesWhere it lives
stream allow/denyWhether this TCP peer is relayedstream server block
ssl_preread mapWhich backend a named connection goes tostream, with the preread module
HTTP location ruleWhether an HTTP request is servedhttp server block

Тэдгээр гурван мөр хэзээ ч бие биеийг орлуулдаггүй. 443 портыг дурдсан аль ч файлд HTTP хандалтын заавар хуулах нь юу ч өөрчлөхгүй, учир нь stream сервер http контекстийг хэзээ ч уншдаггүй.

Холболтыг дамжуулахаас өмнө хүлээн ав

stream болон stream-access модуль бүхий одоо байгаа суулгалт байна гэж үзье, VPN клиентүүд эх хаягуудыг 10.90.0.0/24 дотор хадгалдаг, 192.168.50.20:443 дээрх backend нь зорилтот HTTPS таних тэмдгийг аль хэдийн үзүүлж байна.

stream {
    server {
        listen 443;

        allow 10.90.0.0/24;
        deny all;

        proxy_pass 192.168.50.20:443;
    }
}

Үүнийг ажиллаж буй тохиргооны шууд орлуулалт биш, шинэ listener-ийн хэсэг гэж уншина уу. Эхлээд одоо байгаа listener болон include-уудыг хянаарай, учир нь аль хэдийн эзэлсэн порт дээрх хоёр дахь listener нь хүсэлтийн үед биш, reload үед бүтэлгүйтдэг.

Юу дутуу байгааг анзаараарай: listen ... ssl байхгүй, сертификатын заавар байхгүй. NGINX шифрлэсэн урсгалыг дамжуулж, backend нь TLS-ийг дуусгаад клиентийн баталгаажуулдаг сертификатыг үзүүлдэг. allowlist-д унасан клиентийн TCP сесс татгалзагдана, HTTP 403 хуудас биш, мөн статусын код хүлээж буй аливаа хэрэгсэл ашиггүй зүйл мэдээлнэ.

allowlist юуг хамарч, юуг хамахгүй

Хэрэв релей backend-үүдийг серверийн нэрээр сонгодог бол модуль боломжтой бол ssl_preread болон map тэр ажлыг үргэлжлүүлж чадна. Нэрийг клиент л өгдөг хэвээр, нэр үзүүлэх нь клиент VPN-д нэгдсэнийг нотлохгүй.

Жишээ дүрэм нь бүх stream listener-ийг хамардаг. Энэ нь нийтийн болон зөвхөн VPN сайтуудын холимог үйлчилдэг нэг орох цэгт тохиромжгүй болгодог, тэнд нэр тус бүрээр үл хамаарах зүйл хэрэгтэй болно; тусдаа listener-үүд нь хэн ч уншиж чадахгүй нэрээс хамааралтай бодлогоос илүү тодорхой байдаг.

Өөр хоёр цоорхойг нэрлэх нь зүйтэй. Prefix тааралт нь пакет аль интерфэйсээр ирснийг хэлэхгүй, өөр газар байгаа HTTP дүрэм энэ listener-ийг хязгаарлаж чадахгүй. Хоёулаа нэг allow мөрийг бүхэл хил гэж үзэхийн оронд хост түвшний ingress бодлогыг зурагт байлгах шалтгаан юм. Хил хязгаарыг тохирох ёстой хоёр хяналт гэж бичээрэй, ингэснээр аль нэгнийх нь өөрчлөлт хянагдана.

NGINX үнэндээ хэний хаягийг хардаг вэ?

Ачааллын тэнцвэржүүлэгч, өөр proxy эсвэл source NAT нь NGINX-ийн өмнө зуучлагч тавьж болох тул ажиглагдаж буй peer нь VPN клиентийн дотоод хаяг биш. Prefix сонгохын өмнө бодит замыг шалгаарай, учир нь буруу хаягт зориулж бичсэн allowlist нь орчуулагчийн ард байгаа бүгдийг оруулах эсвэл хэнийг ч оруулахгүй.

PROXY протокол ба бодит IP-ийн зохицуулалт нь хууль ёсны хариулт бөгөөд зөвхөн нийцтэй, тодорхой итгэмжлэгдсэн илгээгчдэд тохируулах ёстой. Хоёр механизм илгээгчийн хэлснийг итгэдэг, яг ийм учраас илгээгчдийн жагсаалт богино байх ёстой. Аливаа интернэт клиентээс ирсэн таних тэмдгийн толгойд итгэх нь эх сурвалжийн мэдээллийг дахин найдвартай болгодоггүй; энэ нь зөв татгалзалыг хуурамч хүлээн авалт болгон хувиргадаг.

reload-ийн өмнө хоёр үр дүнг шалга

Тохиргоог баталгаажуулж, reload хийгээд дараа нь хоёр удаа шалга: ажиллах ёстой шинэ зөвшөөрөгдсөн сесс, ажиллах ёсгүй татгалзагдсан сесс. Зөвшөөрөгдсөн туршилтад ердийн backend сертификатын баталгаажуулалтыг хадгал, учир нь холбогддог ч backend-ийг баталгаажуулж чадахгүй релей нэг асуудлыг шийдэж нөгөөг үүсгэсэн.

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

Backend-ийн зам болон хариултыг тусад нь шалгаарай. allowlist-ийг давах нь NGINX сессийг хүлээн авсныг л нотолно; энэ нь хүрэх боломжгүй backend-ийг хариулахад хүргэж чадахгүй бөгөөд эхлэхээс өмнө дутагдаж байсан буцах замыг засаж чадахгүй.

Холбоотой нийтлэлүүд