OpenVPN UDP માટે Nginx stream રિલે: શું બદલાય છે

UDP HTTP location માં ન આવે. તેને stream સ્તરે ખસેડો, VPN માટે સેશનનો સમય મર્યાદા ગોઠવો, અને સ્રોત તરીકે પ્રોક્સીની અપેક્ષા રાખો.

તમારો ક્લાયન્ટ UDP પર સેટ છે, Nginx સર્વર પાસે VPN પોર્ટ તરફ દોરતો location બ્લોક છે, અને કંઈ પણ આવતું નથી. આ અપેક્ષિત છે: HTTP location UDP ડેટાગ્રામ વહન કરી શકતું નથી, આગળના ભાગને ભલે ગમે તે નામ આપો. આ માટે Nginx ને stream શ્રોતા જોઈએ છે, અને રૂપરેખાંકન ત્યાં ખસેડ્યા પછી, બીજો વિગતોનો સમૂહ નક્કી કરે છે કે સેશન ટકશે કે નહીં.

પ્રોક્સી સ્તર સરનામાં પહેલાં આવે છે

Nginx નું stream મોડ્યુલ HTTP પાર્સ કર્યા વિના TCP અને UDP પ્રોક્સી કરે છે. તેનું HTTP મોડ્યુલ વિનંતી લાઇન, હેડર અને પ્રતિભાવની અપેક્ષા રાખે છે, જેમાંથી કંઈ પણ મૂળ OpenVPN ડેટાગ્રામમાં હોતું નથી. તેથી સ્તર પસંદ કરવો એ પ્રથમ નિર્ણય છે, અને શ્રોતા IPv4 છે કે IPv6 તેના પર તે આધાર રાખતું નથી.

TCP OpenVPN સાથે કામ કરતું લાગતું રૂપરેખાંકન UDP કિસ્સા વિશે કંઈ કહેતું નથી. અહીં પરિવહન પ્રોટોકોલનો ભાગ છે, જમાવટની વિગત નથી.

શ્રોતા અને બેકએન્ડ

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

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

કંઈ પણ સંપાદિત કરતાં પહેલાં ખાતરી કરો કે બિલ્ડમાં stream મોડ્યુલ છે; વિતરણ પેકેજ તેને અલગ મોડ્યુલમાં વિભાજિત કરી શકે છે, અને ગેરહાજર મોડ્યુલ ટનલને બદલે રૂપરેખાંકન ભૂલ આપે છે. બ્લોકને મુખ્ય રૂપરેખાંકન સંદર્ભમાં મૂકો, http ની અંદર નહીં, અને દસ્તાવેજીકરણનું સરનામું વાસ્તવિક બેકએન્ડથી બદલો.

બંને માર્ગો અને બંને ફાયરવોલને ડેટાગ્રામની પરવાનગી આપવી પડશે: શ્રોતા સુધીનો માર્ગ અને પ્રોક્સીથી બેકએન્ડ સુધીનો માર્ગ. IPv6 શ્રોતા IPv4 માર્ગ પણ બનાવતું નથી, તેથી જો કેટલાક ક્લાયન્ટ હજી IPv4 વાપરે છે, તો તે શ્રોતા પોતાની કસોટી સાથે અલગ એન્ટ્રી છે. બેકએન્ડની પોતાની ફાયરવોલ પ્રોક્સીના સરનામેથી તપાસો, લેપટોપથી નહીં.

સેશન સમય મર્યાદા એ વિનંતી સમય મર્યાદા નથી

stream પ્રોક્સી UDP સેશન માટે સ્થિતિ રાખે છે અને તેની સમય મર્યાદા તથા પ્રતિભાવ સેટિંગ્સ અનુસાર તેને કાઢી નાખે છે. DNS રિલેમાંથી નકલ કરેલી ટૂંકી સમય મર્યાદા કલાકો સુધી ડેટાગ્રામની અદલાબદલીની અપેક્ષા રાખતા VPN માટે યોગ્ય નથી, અને નિષ્ફળતા શરૂ થવાનો ઇનકાર કરતા જોડાણને બદલે શાંતિથી મરતા જોડાણ તરીકે દેખાય છે.

જમાવટનું અસરકારક proxy_timeout અને પ્રતિભાવ-ગણતરીનું કોઈ પણ સેટિંગ વાંચો, પછી તેમને VPN ખરેખર વાપરતા keepalive વર્તન સાથે સરખાવો. જુદા જુદા લોકોએ જુદી જુદી ફાઇલોમાં લખેલી બે સંખ્યાઓ કાર્યરત સિસ્ટમની સામાન્ય સ્થિતિ છે. ક્યારેય સરખાવવામાં ન આવેલી બે સંખ્યાઓ વારંવાર અટકતી સિસ્ટમની સામાન્ય સ્થિતિ છે. બંનેને સેવા રેકોર્ડમાં લખો જેથી સરખામણી એક વાર, દિવસના અજવાળામાં થાય.

રિલે શું બદલે છે અને શું નહીં

stream પ્રોક્સી OpenVPN ની TLS નિયંત્રણ ચેનલને સમાપ્ત કરતું નથી કે તેને HTTPS માં ફેરવતું નથી. બેકએન્ડ જ VPN સેવા રહે છે, અને પ્રમાણપત્રનો સંબંધ ક્લાયન્ટ અને તે સેવા વચ્ચે જ રહે છે. ઇચ્છિત બેકએન્ડ ઓળખ જાળવવી હજી ક્લાયન્ટ અને સર્વરનું કામ છે.

સામાન્ય પ્રોક્સીંગ બેકએન્ડ જે સ્રોત સરનામું જુએ છે તે પણ બદલે છે. લોગ પ્રોક્સી બતાવશે, અને VPN સર્વર પર IP-આધારિત કોઈ પણ પ્રવેશ નિયમ ક્લાયન્ટના સરનામાને બદલે તે સરનામાનું મૂલ્યાંકન કરશે. પારદર્શક સ્રોત સંરક્ષણ અલગ રૂટિંગ અને વિશેષાધિકાર રચના છે, શ્રોતામાં udp ઉમેરવાથી મળતી વસ્તુ નથી. ક્લાયન્ટ સરનામા પર આધારિત નીતિ લખાય તે પહેલાં તેનું આયોજન કરો.

ક્લાયન્ટથી ચકાસો, પોર્ટથી નહીં

UDP પોર્ટ ખુલ્લો છે એ સ્થાનિક તપાસ સાબિત કરે છે કે શ્રોતા અસ્તિત્વમાં છે. તે સાબિત કરતી નથી કે ક્લાયન્ટ તેમાંથી પ્રમાણીકરણ કરી શકે છે અથવા ટ્રાફિકની અદલાબદલી ચાલુ રાખી શકે છે. મંજૂર ક્લાયન્ટથી વાસ્તવિક જોડાણ પૂર્ણ કરો, પછી ખાતરી કરો કે સેશન પૂરતા સમય સુધી ટકે છે.

જ્યારે કોઈ કહે કે Nginx UDP કરી શકતું નથી કારણ કે સાદું રિલે સાધન તેની જગ્યાએ કામ કરી ગયું, ત્યારે બંને તથ્યો સંબંધિત નથી. સાધને સાબિત કર્યું કે બેકએન્ડ જવાબ આપે છે; આગળનો ભાગ શું ટેકો આપે છે તે વિશે તેણે કંઈ કહ્યું નથી. બંને સાચા હોઈ શકે છે, અને તેમાંથી ફક્ત એક જ આ જમાવટ માટેનું રૂપરેખાંકન છે.

સંબંધિત લેખો