NGINX stream ਸੰਦਰਭ ਵਿੱਚ TLS passthrough ਕਨੈਕਸ਼ਨ ਦੀ ਆਗਿਆ ਦਿਓ
NGINX TLS ਨੂੰ ਖ਼ਤਮ ਕੀਤੇ ਬਿਨਾਂ TCP TLS ਰੀਲੇ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ। ਆਗਿਆ ਨਿਯਮ HTTP location ਵਿੱਚ ਨਹੀਂ, stream ਵਿੱਚ ਰੱਖੋ, ਅਤੇ ਜਾਂਚੋ ਕਿ ਕਿਹੜਾ peer ਪਤਾ ਆਉਂਦਾ ਹੈ।
ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਕਦੇ ਵੀ ਨਾ ਰੱਖਦੇ ਹੋਏ ਐਨਕ੍ਰਿਪਟਿਡ ਬਾਈਟਾਂ ਅੱਗੇ ਭੇਜਣਾ ਉਹੀ ਹੈ ਜੋ TLS passthrough ਰੀਲੇ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਪ੍ਰਬੰਧ ਸੁਵਿਧਾਜਨਕ ਅਤੇ ਥੋੜ੍ਹਾ ਉਲਝਾਉਣ ਵਾਲਾ ਵੀ ਹੈ। ਕਿਉਂਕਿ ਕੁਝ ਵੀ ਡੀਕ੍ਰਿਪਟ ਨਹੀਂ ਹੁੰਦਾ, ਫਿਲਟਰ ਕਰਨ ਲਈ HTTP ਆਕਾਰ ਦਾ ਕੁਝ ਨਹੀਂ ਹੈ, ਇਸ ਲਈ ਆਮ location ਬਲਾਕ ਅਤੇ ਉਸ ਦੇ ਪਹੁੰਚ ਨਿਯਮ ਇੱਥੇ ਕੋਈ ਕੰਮ ਨਹੀਂ ਆਉਂਦੇ। NGINX ਕੋਲ ਜੋ ਫੈਸਲਾ ਹੈ ਉਹ ਕਨੈਕਸ਼ਨ ਬਾਰੇ ਹੈ: ਕਿਹੜੇ ਨੈੱਟਵਰਕ peer ਨੇ ਖੜਕਾਇਆ, ਅਤੇ ਕੀ ਉਸ peer ਨੂੰ ਬਿਲਕੁਲ ਅੱਗੇ ਭੇਜਣਾ ਚਾਹੀਦਾ ਹੈ।
ਫੈਸਲਾ HTTP ਵਿੱਚ ਨਹੀਂ, stream ਵਿੱਚ ਹੈ
stream ਸੰਦਰਭ ਵਿੱਚ NGINX TCP ਸੈਸ਼ਨਾਂ ਨਾਲ ਕੰਮ ਕਰਦਾ ਹੈ। ਇਹ ਕਨੈਕਸ਼ਨ ਦਾ peer ਪਤਾ ਦੇਖਦਾ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਬਾਈਟ ਦੇ backend ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਉੱਤੇ ਕ੍ਰਮਬੱਧ allow ਅਤੇ deny ਨਿਯਮ ਲਾਗੂ ਕਰ ਸਕਦਾ ਹੈ। ਇਹ ਪੂਰਾ ਦਾਖਲਾ ਫੈਸਲਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਨਿੱਜੀ ਕੁੰਜੀ, ਸਰਟੀਫਿਕੇਟ ਜਾਂ 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 |
ਉਹ ਤਿੰਨ ਲਾਈਨਾਂ ਕਦੇ ਵੀ ਇੱਕ ਦੂਜੇ ਦੀ ਥਾਂ ਨਹੀਂ ਲੈਂਦੀਆਂ। 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 ਨੂੰ ਜਵਾਬ ਦੇਣ ਲਈ ਮਜਬੂਰ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਅਤੇ ਤੁਹਾਡੇ ਸ਼ੁਰੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਗਾਇਬ ਵਾਪਸੀ ਰਸਤੇ ਨੂੰ ਠੀਕ ਨਹੀਂ ਕਰ ਸਕਦਾ।