ਸਾਕਟ ਪੀਅਰ ਬਨਾਮ ਫਾਰਵਰਡ ਕੀਤਾ ਹੈਡਰ: ਕਿਸ ਪਤੇ 'ਤੇ ਭਰੋਸਾ ਕਰੀਏ?

ਤੁਹਾਡੇ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਆਉਣ ਵਾਲੀ ਬੇਨਤੀ ਦੋ ਕਿਸਮ ਦੇ ਪਤੇ-ਸਬੂਤ ਲੈ ਕੇ ਆਉਂਦੀ ਹੈ: ਨੈੱਟਵਰਕ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਣ ਵਾਲਾ ਪੀਅਰ, ਅਤੇ ਪਿਛਲੇ ਕਲਾਇੰਟ ਦਾ ਪਤਾ ਦਾਅਵਾ ਕਰਨ ਵਾਲਾ HTTP ਖੇਤਰ। ਉਹ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ। ਸਾਕਟ ਪੀਅਰ ਦਾ ਨਿਰੀਖਣ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਜਦਕਿ ਹੈਡਰ ਦਾ ਦਾਅਵਾ ਉਹ ਕਰਦਾ ਹੈ ਜਿਸ ਨੇ ਇਹ ਲਿਖਿਆ, ਅਤੇ ਕਿਸੇ ਨੂੰ ਵੀ ਲੌਗ ਜਾਂ ਪਹੁੰਚ ਨਿਯਮ ਵਿੱਚ ਦੂਜੇ ਨੂੰ ਚੁੱਪਚਾਪ ਨਹੀਂ ਬਦਲਣਾ ਚਾਹੀਦਾ। ਹੇਠਾਂ ਦਿੱਤੀ ਤੁਲਨਾ ਦੋਵਾਂ ਨੂੰ ਵੱਖ ਰੱਖਦੀ ਹੈ ਅਤੇ ਫਿਰ ਉਹ ਇੱਕੋ ਵਿਵਸਥਾ ਦਿਖਾਉਂਦੀ ਹੈ ਜਿਸ ਵਿੱਚ ਹੈਡਰ ਲਾਭਕਾਰੀ ਬਣਦਾ ਹੈ।

ਕੁਝ ਵੀ ਤੁਲਨਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਰਸਤੇ ਦਾ ਵਰਣਨ ਕਰੋ:

Client -> approved reverse proxy -> application origin

ਉਸ ਵਿਵਸਥਾ ਵਿੱਚ ਮੂਲ ਦਾ ਸਾਕਟ ਪੀਅਰ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੌਕਸੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਫਾਰਵਰਡਿੰਗ ਹੈਡਰ ਪ੍ਰੌਕਸੀ ਦਾ ਕਲਾਇੰਟ ਬਾਰੇ ਦਾਅਵਾ ਲੈ ਕੇ ਜਾ ਸਕਦਾ ਹੈ। ਇਸਦਾ ਮੁੱਲ ਉਸ ਪ੍ਰੌਕਸੀ ਨਾਲ ਨਿਯੰਤਰਿਤ ਸੰਬੰਧ ਤੋਂ ਆਉਂਦਾ ਹੈ, ਹੈਡਰ ਦੇ ਨਾਮ ਤੋਂ ਨਹੀਂ।

ਪਤੇ ਦੇ ਦੋ ਕਿਸਮ ਦੇ ਸਬੂਤ

ਸਾਕਟ ਪੀਅਰ ਇੱਕ TCP ਕਨੈਕਸ਼ਨ ਬਾਰੇ ਤੱਥ ਹੈ: ਕਿਸੇ ਚੀਜ਼ ਨੇ ਉਸ ਪਤੇ ਤੋਂ ਹੈਂਡਸ਼ੇਕ ਪੂਰਾ ਕੀਤਾ। ਇਹ ਜ਼ਰੂਰੀ ਨਹੀਂ ਕਿ ਉਹ ਉਹੀ ਵਿਅਕਤੀ, ਡਿਵਾਈਸ ਜਾਂ ਖਾਤਾ ਹੋਵੇ ਜੋ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੈ, ਕਿਉਂਕਿ VPN ਜਾਂ Tor ਨਿਕਾਸ ਕਾਨੂੰਨੀ ਤੌਰ 'ਤੇ ਉਹ ਸਰੋਤ ਹੋ ਸਕਦਾ ਹੈ ਜਿਸਦਾ ਕੋਈ ਸੇਵਾ ਨਿਰੀਖਣ ਕਰਦੀ ਹੈ। ਫਿਰ ਵੀ ਇਹ ਉਹ ਇੱਕੋ ਪਤਾ ਹੈ ਜੋ ਹੋਸਟ ਨੇ ਆਪਣੇ ਆਪ ਤਸਦੀਕ ਕੀਤਾ, ਅਤੇ ਇਸਦਾ ਪੂਰਾ ਮੁੱਲ ਇਸੇ ਵਿੱਚ ਹੈ।

ਫਾਰਵਰਡਿੰਗ ਖੇਤਰ ਇੱਕ ਲੜੀ ਬਾਰੇ ਮੈਟਾਡੇਟਾ ਹੈ। X-Forwarded-For, X-Real-IP ਅਤੇ ਮਿਆਰੀ ਖੇਤਰ Forwarded ਨੂੰ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਗੂੰਜਣ ਵਾਲੇ ਅੰਤ ਬਿੰਦੂ ਤੱਕ ਪਹੁੰਚਣ ਵਾਲਾ ਕੋਈ ਵੀ ਕਲਾਇੰਟ ਲਿਖ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਉਹਨਾਂ ਦੀ ਭਰੋਸੇਯੋਗਤਾ ਪੂਰੀ ਤਰ੍ਹਾਂ ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਕਿਸ ਨੂੰ ਸੀ।

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

ਹੈਡਰ ਕਦੇ ਵੀ ਕਨੈਕਸ਼ਨ ਦਾ ਰਸਤਾ ਨਹੀਂ ਬਦਲਦਾ

ਫਾਰਵਰਡਿੰਗ ਖੇਤਰ ਵਿੱਚ ਪਤਾ ਲਿਖਣਾ ਸਰਵਰ 'ਤੇ ਆਉਣ ਵਾਲੇ TCP ਕਨੈਕਸ਼ਨ ਦਾ ਸਰੋਤ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਰਸਤੇ ਵਿੱਚ ਕਿਤੇ ਵੀ ਰੂਟਿੰਗ ਨਹੀਂ ਬਦਲਦਾ। ਆਮ VPN ਰੂਟਿੰਗ ਜਾਂ ਸਰੋਤ NAT ਕਿਸੇ ਵੀ HTTP ਹੈਡਰ ਤੋਂ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਪਹੁੰਚਾਉਂਦੀ ਹੈ। ਇਸੇ ਤਰ੍ਹਾਂ, ਟ੍ਰਾਂਜ਼ਿਟ ਗੇਟਵੇ TLS ਅੰਤ ਬਿੰਦੂ ਦੀ ਵਿਵਸਥਾ ਬਦਲੇ ਬਿਨਾਂ ਸਹੀ ਢੰਗ ਨਾਲ ਸੁਰੱਖਿਅਤ HTTPS ਅਦਾਨ-ਪ੍ਰਦਾਨ ਮੁੜ ਨਹੀਂ ਲਿਖਦਾ।

ਉਲਟੀ ਗਲਤੀ ਵੀ ਓਨੀ ਹੀ ਆਮ ਹੈ: HTTPS ਕਲਾਇੰਟ ਵੱਲੋਂ ਦਿੱਤੇ ਫਾਰਵਰਡਿੰਗ ਹੈਡਰ ਨੂੰ ਸੱਚ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਇਹ ਝੂਠੇ ਦਾਅਵੇ ਦੀ ਢੁਆਈ ਨੂੰ ਸੱਚੇ ਜਿੰਨੀ ਚੰਗੀ ਤਰ੍ਹਾਂ ਸੁਰੱਖਿਅਤ ਕਰਦਾ ਹੈ।

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

ਦਾਅਵਾ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਵਾਲੀ ਪ੍ਰੌਕਸੀ ਦਾ ਨਾਮ ਦਿਓ

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

NGINX ਦਾ ਅਸਲ IP ਮੌਡਿਊਲ ਵੰਡ ਸਪਸ਼ਟ ਦਿਖਾਉਂਦਾ ਹੈ। set_real_ip_from ਉਹਨਾਂ ਭੇਜਣ ਵਾਲਿਆਂ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਦਾ ਦਾਅਵਾ ਗਿਣਿਆ ਜਾਂਦਾ ਹੈ, ਅਤੇ real_ip_header ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਖੇਤਰ ਇਸਨੂੰ ਢੋਂਦਾ ਹੈ; ਪਹਿਲਾ ਭਰੋਸਾ ਕਰਦਾ ਹੈ, ਦੂਜਾ ਸਿਰਫ਼ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ।

set_real_ip_from 10.20.0.0/24;
real_ip_header X-Forwarded-For;
# real_ip_recursive off - take the rightmost value in the field
# real_ip_recursive on  - walk the list back past every trusted address

ਸਿਰਫ਼ ਹੈਡਰ-ਚੋਣ ਨਿਰਦੇਸ਼ ਆਪਣੇ ਆਪ ਵਿੱਚ ਮੁੱਲ ਕਿਸ ਨੇ ਭੇਜਿਆ ਇਸ ਬਾਰੇ ਅਜੇ ਕੁਝ ਵੀ ਸਥਾਪਿਤ ਨਹੀਂ ਕਰਦਾ।

ਆਵਾਜਾਈ ਸੁਰੱਖਿਆ ਨੂੰ ਤੁਹਾਡੇ ਭਰੋਸੇਯੋਗ ਹਿੱਸਿਆਂ ਵਿਚਕਾਰ ਪੂਰਾ ਰਸਤਾ ਤੈਅ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਸਹੀ ਢੰਗ ਨਾਲ ਸਾਧਾਰਨ ਕਰਨ ਵਾਲਾ ਕਿਨਾਰਾ ਉਹ ਮੁੱਲ ਉਸੇ ਪਲ ਗੁਆ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਹੇਠਾਂ ਦਾ ਅਸੁਰੱਖਿਅਤ ਪੜਾਅ ਕਿਸੇ ਹੋਰ ਨੂੰ ਸਫ਼ਰ ਦੌਰਾਨ ਦਾਅਵਾ ਸੋਧਣ ਦਿੰਦਾ ਹੈ।

ਕਈ-ਪੜਾਅ ਲੜੀਆਂ ਨੂੰ ਸੁਚੇਤ ਤੌਰ 'ਤੇ ਸੰਭਾਲੋ

ਕਈ ਪ੍ਰੌਕਸੀਆਂ ਨੂੰ ਸਪਸ਼ਟ ਲੜੀ ਮਾਡਲ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਕਿਸੇ ਬਲੌਗ ਪੋਸਟ ਨੇ ਇਸ ਤਰ੍ਹਾਂ ਕੀਤਾ ਸੀ ਇਸ ਲਈ ਕਾਮੇ ਨਾਲ ਵੱਖ ਕੀਤਾ ਸਭ ਤੋਂ ਖੱਬਾ ਜਾਂ ਸੱਜਾ ਮੁੱਲ ਨਾ ਲਓ; ਲੱਭੋ ਕਿ ਤੁਹਾਡੀਆਂ ਪ੍ਰੌਕਸੀਆਂ ਵਿੱਚੋਂ ਕਿਹੜੀ ਜੋੜਦੀ ਹੈ, ਕਿਹੜੀ ਬਦਲਦੀ ਹੈ ਅਤੇ ਕਿਹੜੀ ਆਉਣ ਵਾਲਾ ਖੇਤਰ ਸੰਭਾਲਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, NGINX ਆਪਣੇ ਭਰੋਸੇਯੋਗ ਸਮੂਹ ਦੇ ਸਾਹਮਣੇ ਸੂਚੀ ਪਿੱਛੇ ਚੱਲ ਸਕਦਾ ਹੈ ਅਤੇ ਆਪਣੀ ਮਲਕੀਅਤ ਵਾਲੇ ਨਾ ਹੋਣ ਵਾਲੇ ਪਹਿਲੇ ਪਤੇ 'ਤੇ ਰੁਕ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਹ ਉਸ ਉਤਪਾਦ ਦਾ ਨਿਯਮ ਹੈ, ਹਰ ਫਰੇਮਵਰਕ ਵੱਲੋਂ ਮੰਨਿਆ ਜਾਣ ਵਾਲਾ ਕਾਨੂੰਨ ਨਹੀਂ। ਆਪਣੀ ਪ੍ਰੌਕਸੀ ਦੇ ਦਸਤਾਵੇਜ਼ ਉਹੀ ਦੋ ਸਵਾਲਾਂ ਨਾਲ ਪੜ੍ਹੋ: ਇਹ ਕਿਹੜਾ ਮੁੱਲ ਚੁਣਦੀ ਹੈ, ਅਤੇ ਕਿਹੜੇ ਭੇਜਣ ਵਾਲਿਆਂ 'ਤੇ ਭਰੋਸਾ ਕਰਦੀ ਹੈ?

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

ਜਦੋਂ ਤੁਸੀਂ ਪੜਾਅ ਜੋੜਦੇ ਹੋ, ਉਹ ਦਸਤਾਵੇਜ਼ ਦੁਬਾਰਾ ਵੇਖੋ। ਭਰੋਸੇਯੋਗ ਪ੍ਰੌਕਸੀ ਦੇ ਅੱਗੇ ਪਾਇਆ ਨਵਾਂ ਲੋਡ ਬੈਲੰਸਰ ਕਿਸੇ ਦੇ ਵੀ ਐਪਲੀਕੇਸ਼ਨ ਸੋਧੇ ਬਿਨਾਂ ਇਹ ਬਦਲ ਸਕਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਪਤਾ ਜਿੱਤਦਾ ਹੈ।

ਦੋਵੇਂ ਨਿਰੀਖਣ ਲੌਗ ਵਿੱਚ ਰੱਖੋ

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

ਇਸ ਜੋੜੀ ਦਾ ਅਰਥ ਯਾਦ ਰੱਖੋ। ਹੈਡਰ ਉਸ ਹਿੱਸੇ ਵੱਲੋਂ ਦਿੱਤਾ ਸੰਦਰਭ ਜੋੜਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਭਰੋਸਾ ਕਰਨ ਲਈ ਚੁਣਿਆ; ਪੀਅਰ ਉਹ ਇੱਕੋ ਪਤਾ ਰਹਿੰਦਾ ਹੈ ਜੋ ਤੁਹਾਡੇ ਹੋਸਟ ਨੇ ਸੱਚਮੁੱਚ ਵੇਖਿਆ। ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨਿੱਜੀ ਪਛਾਣ ਦਾ ਸਬੂਤ ਨਹੀਂ, ਅਤੇ ਕਿਸੇ ਇੱਕ ਨੂੰ ਸਬੂਤ ਮੰਨਣ ਵਾਲਾ ਡਿਜ਼ਾਈਨ ਕਿਸੇ ਬਾਰੇ ਗਲਤ ਹੋਵੇਗਾ।