Nginx-ի stream ռելեյը OpenVPN UDP-ի համար. ինչ է փոխում

Ձեր հաճախորդը դրված է UDP-ի վրա, Nginx սերվերն ունի location բլոկ, որը ցույց է տալիս VPN-ի պորտին, և ոչինչ չի հասնում։ Դա սպասելի է՝ HTTP-ի location-ը չի կարող տեղափոխել UDP դատագրամ՝ ինչ անուն էլ ունենա առջևի մասը։ Դրա համար Nginx-ին պետք է stream լսող, և երբ կազմաձևը տեղափոխեք այնտեղ, մանրամասների երկրորդ խումբն է որոշում՝ սեսիան կշարունակվի՞ արդյոք։

Վստահված շերտը գալիս է հասցեից առաջ

Nginx-ի stream մոդուլը վստահվածում է TCP-ն և UDP-ն՝ առանց HTTP վերլուծելու։ Նրա HTTP մոդուլը սպասում է հարցման տող, վերնագրեր և պատասխան, և դրանցից ոչ մեկը չկա բնիկ OpenVPN դատագրամում։ Շերտի ընտրությունը դրա համար առաջին որոշումն է, և այն կախված չէ նրանից՝ լսողը IPv4 է, թե IPv6։

Կազմաձևը, որը կարծես աշխատում է TCP OpenVPN-ի հետ, ոչինչ չի ասում UDP դեպքի մասին։ Տրանսպորտն այստեղ արձանագրության մասն է, ոչ թե տեղակայման մանրամասնություն։

Լսողը և backend-ը

nginx -V 2>&1 | tr ' ' '\n' | grep stream

stream {
    server {
        listen [::]:1194 udp reuseport;
        proxy_pass [2001:db8::20]:1194;
    }
}

Նախքան որևէ բան խմբագրելը համոզվեք, որ build-ը ներառում է stream մոդուլը, քանի որ բաշխման փաթեթը կարող է այն առանձնացնել որպես առանձին մոդուլ, և բացակայող մոդուլը տալիս է կազմաձևի սխալ, ոչ թե թունել։ Տեղադրեք բլոկը հիմնական կազմաձևի համատեքստում, ոչ թե http-ի ներսում, և փոխարինեք փաստաթղթերի հասցեն իրական backend-ով։

Ե՛վ երկու երթուղիները, և՛ երկու հրապարակախցիկները պետք է թույլ տան դատագրամները՝ ուղին դեպի լսող և ուղին վստահվածից դեպի backend։ IPv6 լսողը նույնպես IPv4 ուղի չի ստեղծում, այնպես որ եթե որոշ հաճախորդներ դեռ օգտագործում են IPv4, այդ լսողը առանձին գրառում է իր սեփական փորձարկմամբ։ Ստուգեք backend-ի սեփական հրապարակախցիկը վստահվածի հասցեից, ոչ թե ձեր նոթբուքից։

Սեսիայի ժամանակային սահմանները հարցման սահմաններ չեն

stream վստահվածը պահում է վիճակ UDP սեսիայի համար և դեն է նետում այն իր ժամանակային սահմանի և պատասխանի կարգավորումների համաձայն։ DNS ռելեից պատճենված կարճ սահմանը վատ է համապատասխանում VPN-ին, որը սպասում է ժամերով դատագրամներ փոխանակել, և խափանումը երևում է որպես լուռ մահացող կապ, այլ ոչ թե մեկը, որը հրաժարվում է սկսել։

Կարդացեք տեղակայման գործող proxy_timeout-ը և պատասխանների հաշվարկի ցանկացած կարգավորում, ապա համեմատեք դրանք keepalive վարքագծի հետ, որն իրականում օգտագործում է VPN-ը։ Երկու թիվ, որ տարբեր մարդիկ գրել են տարբեր ֆայլերում, աշխատող համակարգի նորմալ վիճակն է։ Երկու թիվ, որոնք երբեք չեն համեմատվել, ընդհատումներով աշխատող համակարգի նորմալ վիճակն է։ Գրեք երկուսն էլ ծառայության գրառման մեջ, որպեսզի համեմատությունը կատարվի մեկ անգամ՝ ցերեկային լույսի ներքո։

Ինչ է փոխում ռելեն և ինչ ոչ

stream վստահվածը չի ավարտում OpenVPN-ի TLS կառավարման ալիքը և չի փոխարկում այն HTTPS-ի։ Backend-ը մնում է VPN ծառայությունը, և վկայագրի հարաբերությունը մնում է հաճախորդի ու այդ ծառայության միջև։ Նախատեսված backend ինքնությունը պահպանելը դեռ հաճախորդի ու սերվերի գործն է։

Սովորական վստահվածումը փոխում է նաև այն աղբյուրի հասցեն, որը տեսնում է backend-ը։ Մատյանները ցույց կտան վստահվածին, և VPN սերվերի վրա IP-ի վրա հիմնված ցանկացած մուտքի կանոն կգնահատի այդ հասցեն, ոչ թե հաճախորդի։ Թափանցիկ աղբյուրի պահպանումը առանձին երթուղային և արտոնությունների ձևավորում է, ոչ այն, ինչ բխում է լսողին udp ավելացնելուց։ Պլանավորեք դա նախքան հաճախորդի հասցեից կախված քաղաքականություն գրելը։

Ստուգեք հաճախորդից, ոչ թե պորտից

Տեղական ստուգումը, որ UDP պորտը բաց է, ապացուցում է լսողի գոյությունը։ Այն չի ապացուցում, որ հաճախորդը կարող է դրա միջով նույնականանալ կամ շարունակել երթևեկություն փոխանակել։ Կատարեք իրական կապ թույլատրված հաճախորդից, ապա հաստատեք, որ սեսիան բավական երկար է մնում, որ նշանակություն ունենա։

Երբ ինչ-որ մեկը հայտնում է, որ Nginx-ը չի կարող UDP անել, որովհետև փոխարենը պարզ ռելե գործիք աշխատեց, այդ երկու փաստերը կապ չունեն։ Գործիքն ապացուցեց, որ backend-ը պատասխանում է, և ոչինչ չասաց այն մասին, թե ինչ է աջակցում առջևի մասը։ Երկուսն էլ կարող են ճիշտ լինել, և դրանցից միայն մեկն է կազմաձև այս տեղակայման համար։