Թույլատրել TLS passthrough միացումը NGINX-ի stream համատեքստում
NGINX-ը կարող է մերժել TCP TLS ռելեը՝ առանց TLS-ը ավարտելու։ Թույլտվության կանոնը դրեք stream-ում, ոչ թե HTTP location-ում, և ստուգեք, թե որ peer հասցեն է գալիս։
Ծածկագրված բայթերը փոխանցելը՝ երբեք վկայականը չպահելով, այն է, ինչ անում է TLS passthrough ռելեն, և այս դասավորությունը հարմար է ու միաժամանակ մի փոքր շփոթեցնող։ Քանի որ ոչինչ չի ապակոդավորվում, HTTP-ի ձևով զտելու ոչինչ չկա, ուստի սովորական location բլոկը և դրա մուտքի կանոններն այստեղ ոչինչ չեն տալիս։ NGINX-ի տրամադրության տակ եղած որոշումը վերաբերում է հենց միացմանը՝ որ ցանցային peer-ը թակեց, և արդյոք այդ peer-ը պետք է փոխանցվի ընդհանրապես։
Որոշումը պատկանում է stream-ին, ոչ HTTP-ին
stream համատեքստում NGINX-ը աշխատում է TCP սեսիաներով։ Այն տեսնում է միացման peer հասցեն և կարող է դրա վրա կիրառել պատվիրված allow և deny կանոններ, նախքան որևէ բայթ backend կհասնի։ Սա լիարժեք ընդունման որոշում է և չի պահանջում մասնավոր բանալի, վկայական կամ HTTP վերլուծություն։
| 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 |
Այդ երեք տողերը երբեք չեն փոխարինում միմյանց։ HTTP մուտքի հրահանգը 443 պորտը հիշատակող ցանկացած ֆայլ պատճենելը ոչինչ չի փոխում, քանի որ stream սերվերը երբեք չի կարդում http համատեքստը։
Ընդունեք միացումը նախքան այն փոխանցելը
Ենթադրեք գոյություն ունեցող տեղադրում՝ stream և stream-access մոդուլներով, VPN հաճախորդներ, որոնք պահում են աղբյուրի հասցեները 10.90.0.0/24-ում, և backend 192.168.50.20:443-ում, որն արդեն մատուցում է նախատեսված 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-ները սովորաբար ավելի պարզ են, քան անունից կախված քաղաքականությունը, որը ոչ ոք չի կարող կարդալ։
Արժե անվանել ևս երկու բացթողում։ Նախածանցի համընկնումը ոչինչ չի ասում, թե որ ինտերֆեյսով է փաթեթը եկել, և այլ տեղի HTTP կանոնը չի կարող սահմանափակել այս listener-ը։ Երկուսն էլ պատճառ են հոսթի մակարդակի ingress քաղաքականությունը պատկերի մեջ պահելու, փոխարենը մեկ allow տողը որպես ամբողջ սահման համարելու։ Գրեք սահմանը որպես երկու վերահսկիչ, որոնք պետք է համաձայնեն, որպեսզի դրանցից որևէ մեկի փոփոխությունը վերանայվի։
Ում հասցեն է NGINX-ը իրականում տեսնում։
Բեռնվածության հավասարակշռիչը, մեկ այլ proxy կամ source NAT-ը կարող են միջնորդ դնել NGINX-ի առջև, ուստի դիտարկվող peer-ը VPN հաճախորդի ներքին հասցեն չէ։ Ուսումնասիրեք իրական ուղին նախքան նախածանց ընտրելը, որովհետև սխալ հասցեի համար գրված allowlist-ը կամ թույլ է տալիս բոլորին թարգմանչի հետևում, կամ ոչ մեկին։
PROXY արձանագրությունը և իրական IP-ի մշակումը օրինական պատասխաններ են, և դրանք պետք է կարգավորվեն միայն համատեղելի, բացահայտ վստահելի ուղարկողների համար։ Երկու մեխանիզմներն էլ հավատում են այն, ինչ ասում է ուղարկողը, և հենց դա է պատճառը, որ ուղարկողների ցանկը պետք է կարճ լինի։ Ցանկացած ինտերնետ հաճախորդի ինքնության վերնագրին վստահելը աղբյուրի տեղեկատվությունը կրկին վստահելի չի դարձնում. այն ճիշտ մերժումը վերածում է կեղծ ընդունման։
Ստուգեք երկու արդյունքները reload-ից առաջ
Վավերացրեք կոնֆիգուրացիան, կատարեք reload, ապա ստուգեք երկու անգամ՝ նոր թույլատրված սեսիա, որը պետք է աշխատի, և մերժված մեկը, որը չպետք է։ Պահեք սովորական backend վկայականի ստուգումը թույլատրված փորձարկման մեջ, որովհետև ռելեն, որը միանում է, բայց չի կարող ստուգել backend-ը, լուծել է մի խնդիր և ստեղծել մեկ այլ։
nginx -t
ss -tnp | grep ':443'Ստուգեք նաև backend-ի երթուղին և պատասխանը առանձին։ allowlist-ը անցնելը միայն ապացուցում է, որ NGINX-ը ընդունել է սեսիան. այն չի կարող ստիպել անհասանելի backend-ին պատասխանել, և չի կարող վերանորոգել վերադարձի ուղին, որը բացակայում էր նախքան սկսելը։