ਕਾਰਪੋਰੇਟ VPN ਪਿੱਛੇ ਐਪ ਦੀਆਂ ਬੇਨਤੀਆਂ ਫੇਲ ਹੁੰਦੀਆਂ ਹਨ, ਪਰ ਬ੍ਰਾਊਜ਼ਰ ਕੰਮ ਕਰਦਾ ਹੈ

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

ਉਹ ਬੇਨਤੀ ਵੇਖੋ ਜੋ ਐਪ ਸੱਚਮੁੱਚ ਭੇਜਦੀ ਹੈ

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

env | grep -i proxy            # Linux/macOS
netsh winhttp show proxy       # Windows, machine-wide
curl -sv --noproxy '*' https://svc.internal/
nc -vz svc.internal 8080

ਆਖਰੀ ਦੋਵਾਂ ਨੂੰ ਉਸੇ ਮੰਜ਼ਿਲ ਵੱਲ ਚਲਾਓ ਅਤੇ ਵੇਖੋ ਕਿ ਉਹ ਕਿੱਥੇ ਵੱਖ ਹੁੰਦੀਆਂ ਹਨ। ਕੰਮ ਕਰਦਾ ਬ੍ਰਾਊਜ਼ਰ ਅਤੇ ਕੰਮ ਕਰਦੀ curl ਅਤੇ ਕੰਮ ਨ ਕਰਦੀ ਐਪ ਸਮੱਸਿਆ ਨੂੰ ਉਸ ਚੀਜ਼ ਤੱਕ ਸੀਮਤ ਕਰ ਦਿੰਦੇ ਹਨ ਜੋ ਐਪ ਸ਼ਾਮਲ ਕਰਦੀ ਹੈ: ਇੱਕ ਪ੍ਰੌਕਸੀ, ਇੱਕ ਟ੍ਰਾਂਸਪੋਰਟ ਜਾਂ ਇੱਕ ਸੁਨੇਹਾ ਆਕਾਰ।

ਐਪ ਨੂੰ ਉਹ ਪ੍ਰੌਕਸੀ ਵਿਰਾਸਤ ਵਿੱਚ ਮਿਲੀ ਜਿਸਨੂੰ ਕਿਸੇ ਨੇ ਸੰਰਚਿਤ ਨਹੀਂ ਕੀਤਾ

ਬਹੁਤੇ HTTP ਸਟੈਕ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਤੋਂ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਪੜ੍ਹਦੇ ਹਨ। ਕਾਰਪੋਰੇਟ VPN ਕਲਾਇੰਟ ਅਕਸਰ ਇਸਨੂੰ ਆਪਣੀ ਪਹੁੰਚ ਪਰੋਫਾਈਲ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਥਾਪਤ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਬੇਨਤੀਆਂ ਉਸ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੀਆਂ ਹਨ ਜਿਸਦਾ ਵਿਕਾਸਕਾਰ ਨੇ ਕੋਡ ਵਿੱਚ ਕਦੇ ਜ਼ਿਕਰ ਨਹੀਂ ਕੀਤਾ। .NET ਵਿੱਚ ਡਿਫਾਲਟ ਹੈਂਡਲਰ IE/WinHTTP ਸੈਟਿੰਗਾਂ ਤੋਂ ਲੈਂਦਾ ਹੈ; Java -Dhttp.proxyHost ਪੜ੍ਹਦਾ ਹੈ; Node ਵਿੱਚ ਲਾਇਬ੍ਰੇਰੀ ਸ਼ਾਮਲ ਕਰਨ ਤੱਕ ਕੋਈ ਅੰਦਰੂਨੀ ਪ੍ਰੌਕਸੀ ਸਹਾਇਤਾ ਨਹੀਂ। ਫੇਲ ਹੋਣਾ ਘੱਟ ਹੀ ਸਾਫ਼ ਇਨਕਾਰ ਹੁੰਦਾ ਹੈ, ਇਸ ਲਈ ਲੋਕ ਸਰਵਰ ਵੱਲ ਵੇਖਣ ਲੱਗਦੇ ਹਨ।

ਪਰਖ ਦਾ ਖਰਚ ਇੱਕ ਬੇਨਤੀ ਹੈ: ਇੱਕ ਹੈਂਡਲਰ ’ਤੇ ਪ੍ਰੌਕਸੀ ਸਪੱਸ਼ਟ ਤੌਰ ’ਤੇ ਬੰਦ ਕਰੋ ਅਤੇ ਤੁਲਨਾ ਕਰੋ।

var handler = new HttpClientHandler { UseProxy = false };
using var client = new HttpClient(handler);

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

ਤੁਸੀਂ ਚੁਣਿਆ ਪੋਰਟ ਉਹ ਪੋਰਟ ਨਹੀਂ ਜਿਸਦੀ ਨੀਤੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ

ਰੂਟ ਕੀਤਾ ਹੋਸਟ ਆਗਿਆ ਪ੍ਰਾਪਤ ਸੇਵਾ ਨਹੀਂ ਹੈ। ਕਾਰਪੋਰੇਟ ਨੀਤੀ ਆਮ ਤੌਰ ’ਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਵੈੱਬ ਪੋਰਟਾਂ ਦੀ ਆਗਿਆ ਦਿੰਦੀ ਹੈ ਅਤੇ ਬਾਕੀ ਛੱਡ ਦਿੰਦੀ ਹੈ, ਇਸ ਲਈ 8080 ਜਾਂ 1883 ’ਤੇ ਸੇਵਾ ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਹੈ ਜਦੋਂ ਕਿ 443 ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਇੱਥੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ: ਉਹ ਪਰਿਭਾਸ਼ਾ ਅਨੁਸਾਰ 443 ਵਰਤਦਾ ਹੈ।

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

ਕੱਚਾ TCP ਜਿਸਨੂੰ ਰਸਤਾ ਰੀਸੈਟ ਕਰਦਾ ਹੈ

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

ਟ੍ਰਾਂਸਪੋਰਟ ਬਦਲੋ, ਦੁਬਾਰਾ ਪਰਖੋ ਅਤੇ ਉਸੇ ਰਨ ਵਿੱਚ ਹੋਰ ਕੁਝ ਨਾ ਬਦਲੋ। ਉਹ ਇੱਕ-ਚਲ ਪਰਖ ਦੱਸਦੀ ਹੈ ਕਿ ਰੀਸੈਟ ਰਸਤੇ ਤੋਂ ਆਇਆ ਜਾਂ ਸੇਵਾ ਤੋਂ।

ਕਨੈਕਸ਼ਨ ਜੋ ਸਿਰਫ਼ ਵੱਡੇ ਪੇਲੋਡ ’ਤੇ ਬੰਦ ਹੁੰਦੇ ਹਨ

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

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

ਇੱਕੋ ਪਾਸ ਵਿੱਚ ਚਾਰਾਂ ਨੂੰ ਕਿਵੇਂ ਵੱਖ ਕਰੀਏ

ਤਿੰਨ ਨਿਰੀਖਣ ਬਹੁਤੇ ਮਾਮਲੇ ਹੱਲ ਕਰ ਦਿੰਦੇ ਹਨ। ਫੇਲ ਹੋਣਾ ਤੁਰੰਤ ਹੁੰਦਾ ਹੈ ਜਾਂ ਸਿਰਫ਼ ਵੱਡੀ ਬਾਡੀ ਨਾਲ? ਪ੍ਰੌਕਸੀ ਬੰਦ ਹੋਣ ’ਤੇ ਉਹੀ ਬੇਨਤੀ ਸਫਲ ਹੁੰਦੀ ਹੈ? ਪੋਰਟ ਜਾਂ ਟ੍ਰਾਂਸਪੋਰਟ ਬਦਲਣ ’ਤੇ ਨਤੀਜਾ ਬਦਲਦਾ ਹੈ? ਅਗਲੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਜਵਾਬ ਲਿਖ ਲਓ, ਕਿਉਂਕਿ ਕਾਰਪੋਰੇਟ VPN ਅਤੇ ਵਿਰਾਸਤੀ ਪ੍ਰੌਕਸੀ ਅਤੇ ਐਪ ਦਾ ਡਿਫਾਲਟ ਇਕੱਠੇ ਤਿੰਨ ਸੰਭਾਵੀ ਕਾਰਨ ਦਿੰਦੇ ਹਨ।

ਹਰ ਪਰਖ ਵਿੱਚ ਇੱਕ ਚਲ ਰੱਖੋ ਅਤੇ ਤੁਸੀਂ ਵਰਤਿਆ ਮੰਜ਼ਿਲ ਹੋਸਟ ਨੋਟ ਕਰੋ। ਉਸ ਆਧਾਰ-ਰੇਖਾ ਤੋਂ ਬਿਨਾਂ ਅਗਲਾ ਵਿਅਕਤੀ ਚਾਰੇ ਕਦਮ ਸ਼ੁਰੂ ਤੋਂ ਦੁਹਰਾਉਂਦਾ ਹੈ।