OpenVPN UDP ਲਈ Nginx stream relay: ਕੀ ਬਦਲਦਾ ਹੈ

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;
    }
}

ਕੁਝ ਵੀ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ build ਵਿੱਚ stream ਮਾਡਿਊਲ ਹੈ; ਵੰਡ ਪੈਕੇਜ ਇਸਨੂੰ ਵੱਖਰੇ ਮਾਡਿਊਲ ਵਿੱਚ ਵੰਡ ਸਕਦਾ ਹੈ, ਅਤੇ ਮਾਡਿਊਲ ਨਾ ਹੋਣ ਤੇ ਟਨਲ ਦੀ ਥਾਂ ਸੰਰਚਨਾ ਗਲਤੀ ਆਉਂਦੀ ਹੈ। ਬਲਾਕ ਨੂੰ ਮੁੱਖ ਸੰਰਚਨਾ ਸੰਦਰਭ ਵਿੱਚ ਰੱਖੋ, http ਦੇ ਅੰਦਰ ਨਹੀਂ, ਅਤੇ ਦਸਤਾਵੇਜ਼ੀ ਪਤੇ ਨੂੰ ਅਸਲੀ ਬੈਕਐਂਡ ਨਾਲ ਬਦਲੋ।

ਦੋਵੇਂ ਮਾਰਗ ਅਤੇ ਦੋਵੇਂ ਫਾਇਰਵਾਲ ਡੇਟਾਗ੍ਰਾਮ ਦੀ ਆਗਿਆ ਦੇਣਗੇ: ਸਰੋਤੇ ਤੱਕ ਦਾ ਰਾਹ ਅਤੇ ਪ੍ਰੌਕਸੀ ਤੋਂ ਬੈਕਐਂਡ ਤੱਕ ਦਾ ਰਾਹ। IPv6 ਸਰੋਤਾ IPv4 ਰਾਹ ਵੀ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਇਸ ਲਈ ਜੇ ਕੁਝ ਕਲਾਇੰਟ ਅਜੇ ਵੀ IPv4 ਵਰਤਦੇ ਹਨ, ਤਾਂ ਉਹ ਸਰੋਤਾ ਆਪਣੀ ਜਾਂਚ ਵਾਲੀ ਵੱਖਰੀ ਐਂਟਰੀ ਹੈ। ਬੈਕਐਂਡ ਦੀ ਆਪਣੀ ਫਾਇਰਵਾਲ ਪ੍ਰੌਕਸੀ ਦੇ ਪਤੇ ਤੋਂ ਜਾਂਚੋ, ਆਪਣੇ ਲੈਪਟਾਪ ਤੋਂ ਨਹੀਂ।

ਸੈਸ਼ਨ ਦੀਆਂ ਸਮਾਂ-ਸੀਮਾਵਾਂ ਬੇਨਤੀ ਦੀਆਂ ਸਮਾਂ-ਸੀਮਾਵਾਂ ਨਹੀਂ ਹਨ

stream ਪ੍ਰੌਕਸੀ UDP ਸੈਸ਼ਨ ਲਈ ਸਥਿਤੀ ਰੱਖਦੀ ਹੈ ਅਤੇ ਆਪਣੀ ਸਮਾਂ-ਸੀਮਾ ਤੇ ਜਵਾਬ ਸੈਟਿੰਗਾਂ ਅਨੁਸਾਰ ਉਸਨੂੰ ਸੁੱਟ ਦਿੰਦੀ ਹੈ। DNS relay ਤੋਂ ਨਕਲ ਕੀਤੀ ਛੋਟੀ ਸਮਾਂ-ਸੀਮਾ ਘੰਟਿਆਂ ਤੱਕ ਡੇਟਾਗ੍ਰਾਮ ਬਦਲਣ ਦੀ ਆਸ ਰੱਖਣ ਵਾਲੇ VPN ਲਈ ਠੀਕ ਨਹੀਂ ਬੈਠਦੀ, ਅਤੇ ਨਾਕਾਮੀ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਇਨਕਾਰ ਕਰਨ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਦੀ ਥਾਂ ਚੁੱਪਚਾਪ ਮਰਨ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਵਜੋਂ ਦਿਸਦੀ ਹੈ।

ਤੈਨਾਤੀ ਦਾ ਪ੍ਰਭਾਵੀ proxy_timeout ਅਤੇ ਜਵਾਬ ਗਿਣਤੀ ਦੀ ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਪੜ੍ਹੋ, ਫਿਰ ਉਨ੍ਹਾਂ ਦੀ VPN ਦੇ ਅਸਲ keepalive ਵਿਵਹਾਰ ਨਾਲ ਤੁਲਨਾ ਕਰੋ। ਵੱਖ-ਵੱਖ ਲੋਕਾਂ ਵੱਲੋਂ ਵੱਖ-ਵੱਖ ਫਾਈਲਾਂ ਵਿੱਚ ਲਿਖੇ ਦੋ ਨੰਬਰ ਚੱਲ ਰਹੇ ਸਿਸਟਮ ਦੀ ਆਮ ਹਾਲਤ ਹਨ। ਕਦੇ ਤੁਲਨਾ ਨਾ ਕੀਤੇ ਦੋ ਨੰਬਰ ਰੁਕ-ਰੁਕ ਕੇ ਚੱਲਣ ਵਾਲੇ ਸਿਸਟਮ ਦੀ ਆਮ ਹਾਲਤ ਹਨ। ਤੁਲਨਾ ਇੱਕ ਵਾਰ, ਦਿਨ ਦੀ ਰੌਸ਼ਨੀ ਵਿੱਚ ਹੋਵੇ ਇਸ ਲਈ ਦੋਵੇਂ ਸੇਵਾ ਰਿਕਾਰਡ ਵਿੱਚ ਲਿਖੋ।

relay ਕੀ ਬਦਲਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

stream ਪ੍ਰੌਕਸੀ OpenVPN ਦਾ TLS ਕੰਟਰੋਲ ਚੈਨਲ ਖਤਮ ਨਹੀਂ ਕਰਦੀ ਅਤੇ ਨਾ ਹੀ ਇਸਨੂੰ HTTPS ਵਿੱਚ ਬਦਲਦੀ ਹੈ। ਬੈਕਐਂਡ ਹੀ VPN ਸੇਵਾ ਰਹਿੰਦੀ ਹੈ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਦਾ ਸੰਬੰਧ ਕਲਾਇੰਟ ਅਤੇ ਉਸ ਸੇਵਾ ਵਿਚਕਾਰ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਇੱਛਤ ਬੈਕਐਂਡ ਪਛਾਣ ਬਚਾਉਣਾ ਅਜੇ ਵੀ ਕਲਾਇੰਟ ਅਤੇ ਸਰਵਰ ਦਾ ਕੰਮ ਹੈ।

ਆਮ ਪ੍ਰੌਕਸੀਿੰਗ ਬੈਕਐਂਡ ਵੱਲੋਂ ਦੇਖਿਆ ਜਾਣ ਵਾਲਾ ਸਰੋਤ ਪਤਾ ਵੀ ਬਦਲਦੀ ਹੈ। ਲੌਗ ਪ੍ਰੌਕਸੀ ਦਿਖਾਉਣਗੇ, ਅਤੇ VPN ਸਰਵਰ ਤੇ IP-ਅਧਾਰਿਤ ਕੋਈ ਵੀ ਪਹੁੰਚ ਨਿਯਮ ਕਲਾਇੰਟ ਦੀ ਥਾਂ ਉਸ ਪਤੇ ਦਾ ਮੁਲਾਂਕਣ ਕਰੇਗਾ। ਪਾਰਦਰਸ਼ੀ ਸਰੋਤ ਸੁਰੱਖਿਆ ਵੱਖਰੀ ਰੂਟਿੰਗ ਅਤੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਡਿਜ਼ਾਈਨ ਹੈ, ਸਰੋਤੇ ਵਿੱਚ udp ਜੋੜਨ ਨਾਲ ਆਉਣ ਵਾਲੀ ਚੀਜ਼ ਨਹੀਂ। ਕਲਾਇੰਟ ਪਤੇ ਤੇ ਨਿਰਭਰ ਨੀਤੀ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇਸਦੀ ਯੋਜਨਾ ਬਣਾਓ।

ਪੋਰਟ ਤੋਂ ਨਹੀਂ, ਕਲਾਇੰਟ ਤੋਂ ਪੁਸ਼ਟੀ ਕਰੋ

UDP ਪੋਰਟ ਖੁੱਲ੍ਹਾ ਹੈ ਦੀ ਸਥਾਨਕ ਜਾਂਚ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਸਰੋਤਾ ਮੌਜੂਦ ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਕੋਈ ਕਲਾਇੰਟ ਇਸ ਰਾਹੀਂ ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ ਜਾਂ ਟ੍ਰੈਫਿਕ ਬਦਲਣਾ ਜਾਰੀ ਰੱਖ ਸਕਦਾ ਹੈ। ਮਨਜ਼ੂਰ ਕਲਾਇੰਟ ਤੋਂ ਅਸਲੀ ਕਨੈਕਸ਼ਨ ਪੂਰਾ ਕਰੋ, ਫਿਰ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸੈਸ਼ਨ ਲੋੜੀਂਦੀ ਦੇਰ ਤੱਕ ਟਿਕਦਾ ਹੈ।

ਜਦੋਂ ਕੋਈ ਦੱਸਦਾ ਹੈ ਕਿ Nginx UDP ਨਹੀਂ ਕਰ ਸਕਦਾ ਕਿਉਂਕਿ ਇਸਦੀ ਥਾਂ ਇੱਕ ਸਾਧਾਰਨ relay ਟੂਲ ਕੰਮ ਕਰ ਗਿਆ, ਤਾਂ ਉਹ ਦੋ ਤੱਥ ਸੰਬੰਧਿਤ ਨਹੀਂ। ਟੂਲ ਨੇ ਸਾਬਤ ਕੀਤਾ ਕਿ ਬੈਕਐਂਡ ਜਵਾਬ ਦਿੰਦੀ ਹੈ; ਇਸਨੇ ਇਸ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਿਹਾ ਕਿ ਅਗਲਾ ਹਿੱਸਾ ਕੀ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ। ਦੋਵੇਂ ਸੱਚ ਹੋ ਸਕਦੇ ਹਨ, ਅਤੇ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਇਸ ਤੈਨਾਤੀ ਦੀ ਸੰਰਚਨਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ