ਕਾਰਪੋਰੇਟ VPN ਕਨੈਕਟ ਹੁੰਦਿਆਂ ਹੀ ਡੀਬੱਗ ਪ੍ਰੌਕਸੀ ਅੰਨ੍ਹੀ ਹੋ ਜਾਂਦੀ ਹੈ

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

Windows ਹਰ ਕਨੈਕਸ਼ਨ ਲਈ ਵੱਖਰੀ ਪ੍ਰੌਕਸੀ ਰੱਖਦਾ ਹੈ

ਇੰਟਰਨੈਟ ਵਿਕਲਪਾਂ ਵਿੱਚ ਦੋ ਪਰਤਾਂ ਹਨ ਜੋ ਸੰਵਾਦ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ। ਲੋਕਲ ਨੈੱਟਵਰਕ ਸੈਟਿੰਗਾਂ ਆਮ ਲੋਕਲ ਕਨੈਕਸ਼ਨ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀਆਂ ਹਨ, ਜਦਕਿ ਡਾਇਲ-ਅੱਪ ਜਾਂ VPN ਐਂਟਰੀ HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections ਅਧੀਨ ਆਪਣੀ ਕਾਪੀ ਬਾਈਨਰੀ ਮੁੱਲ ਵਜੋਂ ਰੱਖਦੀ ਹੈ। ਜਾਣੇ-ਪਛਾਣੇ ਗਲੋਬਲ ਰਜਿਸਟਰੀ ਮੁੱਲ ਲਿਖਣ ਨਾਲ ਉਹ ਕਾਪੀ ਅੱਪਡੇਟ ਨਹੀਂ ਹੁੰਦੀ।

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

ਇੱਕ ਐਂਟਰੀ ਬਦਲਣ ਦਾ ਸਮਰਥਿਤ ਢੰਗ WinINET ਕਨੈਕਸ਼ਨ ਵਿਕਲਪ API ਹੈ: ਕਨੈਕਸ਼ਨ ਦਾ ਨਾਮ, ਫਲੈਗ, ਪ੍ਰੌਕਸੀ ਸਰਵਰ ਅਤੇ ਬਾਈਪਾਸ ਸੂਚੀ ਨਾਲ INTERNET_PER_CONN_OPTION_LIST ਭਰੋ, ਲਾਗੂ ਕਰੋ, ਫਿਰ ਰਿਫ੍ਰੈਸ਼ ਕਰੋ। ਤੇਜ਼ ਜਾਂਚ ਲਈ ਟਨਲ ਐਂਟਰੀ ਦਾ ਆਪਣਾ ਸੈਟਿੰਗਾਂ ਸੰਵਾਦ ਖੋਲ੍ਹੋ ਅਤੇ ਉਸਦੇ ਪ੍ਰੌਕਸੀ ਪੈਨਲ ਦੀ ਲੋਕਲ ਨੈੱਟਵਰਕ ਪੈਨਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ; ਕਿੱਥੇ ਵੇਖਣਾ ਹੈ ਪਤਾ ਹੋਣ 'ਤੇ ਫ਼ਰਕ ਆਮ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਹੁੰਦਾ ਹੈ।

ਪ੍ਰਬੰਧਿਤ PAC ਆਪਣੇ ਆਪ ਫਿਰ ਚਾਲੂ ਹੋ ਸਕਦਾ ਹੈ

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

ਜਾਂਚ ਕਰੋ ਅਤੇ, ਅਧਿਕਾਰਤ ਹੋਣ 'ਤੇ, ਟ੍ਰੈਫ਼ਿਕ ਲਿਜਾਣ ਵਾਲੀ ਸੇਵਾ ਲਈ ਉਹ ਦੋ ਸਵਿੱਚ ਬੰਦ ਕਰੋ:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

ਅੰਦਾਜ਼ੇ ਦੀ ਥਾਂ ਸੇਵਾ ਦਾ ਅਸਲੀ ਨਾਮ ਵਰਤੋ। Wi-Fi ਅਤੇ USB ਈਥਰਨੈੱਟ ਅਡੈਪਟਰ ਦੋਵੇਂ ਵਾਲੇ ਲੈਪਟਾਪ ਵਿੱਚ ਅਜਿਹੀਆਂ ਦੋ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਤੁਹਾਡਾ ਟ੍ਰੈਫ਼ਿਕ ਸਿਰਫ਼ ਇੱਕ ਲਿਜਾਂਦੀ ਹੈ। scutil --proxy ਮੌਜੂਦਾ ਮੁੱਢਲੀ ਸੇਵਾ ਦੇ ਮੁੱਲ ਛਾਪਦਾ ਹੈ। ਪ੍ਰੋਫ਼ਾਈਲ ਜਿੱਤ ਗਈ ਹੈ ਇਹ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਆਉਟਪੁੱਟ ਦੀ ਤੁਲਨਾ ਉਸ ਨਾਲ ਕਰੋ ਜੋ ਤੁਸੀਂ ਸੋਧਿਆ ਸੀ।

ਟੂਲ ਨੂੰ ਅਸਲੀ ਅੱਪਸਟਰੀਮ ਵੱਲ ਮੋੜੋ

ਜੇ ਸਕ੍ਰਿਪਟ ਵਿੱਚ ਕਾਰਪੋਰੇਟ ਪ੍ਰੌਕਸੀ ਹੈ, ਤਾਂ ਉਸਨੂੰ ਪੜ੍ਹੋ ਅਤੇ ਉਹੀ ਪਤਾ ਕੈਪਚਰ ਟੂਲ ਦੇ ਅੰਦਰ ਬਾਹਰੀ ਪ੍ਰੌਕਸੀ ਵਜੋਂ ਦਰਜ ਕਰੋ। ਫਿਰ ਟੂਲ ਅਸਲੀ ਅੱਪਸਟਰੀਮ ਵੱਲ ਭੇਜਦਾ ਹੈ, ਜਿਸਦੀ ਕਾਰਪੋਰੇਟ ਪ੍ਰੌਕਸੀ ਉਮੀਦ ਕਰਦੀ ਹੈ, ਅਤੇ ਨੀਤੀ ਨਾਲ ਲੜਨ ਦੀ ਥਾਂ ਬੇਨਤੀ ਦੇ ਰਾਹ ਵਿੱਚ ਹੀ ਰਹਿੰਦਾ ਹੈ।

ਇਹੀ ਉਹ ਕਦਮ ਹੈ ਜੋ ਤੁਹਾਨੂੰ ਮੁੜ ਕਨਫਿਗਰ ਕਰਨ ਦੀ ਥਾਂ ਡੀਬੱਗਿੰਗ ਵਿੱਚ ਰੱਖਦਾ ਹੈ।

ਪ੍ਰੌਕਸੀ ਨੂੰ ਟਨਲ ਦੇ ਅੰਦਰ ਧੱਕੋ

OpenVPN ਅਧਾਰਿਤ ਕਲਾਇੰਟ ਟਨਲ ਚੜ੍ਹਨ ਤੋਂ ਬਾਅਦ ਲਾਗੂ ਹੋਣ ਵਾਲੇ ਪ੍ਰੌਕਸੀ ਵਿਕਲਪ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ, ਜੋ ਉਦੋਂ ਸੁਵਿਧਾਜਨਕ ਹੈ ਜਦੋਂ ਰੂਟ ਕਲਾਇੰਟ ਕੋਲ ਹੋਣ:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

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

ਕੁਝ ਕਲਾਇੰਟ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ ਕਦੇ ਨਹੀਂ ਪੜ੍ਹਦੇ

Firefox ਆਪਣੀਆਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ ਰੱਖਦਾ ਹੈ, ਇਸ ਲਈ ਜਦੋਂ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਨਹੀਂ ਕਰਦਾ ਤਾਂ ਵੀ ਇਹ ਕਦੇ-ਕਦੇ ਕੈਪਚਰ ਜਾਰੀ ਰੱਖਦਾ ਹੈ। ਸਵੈਚਾਲਿਤ ਕਨਫਿਗਰੇਸ਼ਨ ਨਾ ਸਮਝਣ ਵਾਲਾ ਪੁਰਾਣਾ .NET ਕਲਾਇੰਟ ਜਿੱਥੇ ਵੀ ਚੱਲੇ ਸਿੱਧਾ ਜੁੜਦਾ ਹੈ, ਇਸ ਲਈ ਟਨਲ ਐਂਟਰੀ ਰਾਹੀਂ ਲੋਡ ਹੋਣ ਵਾਲਾ ਪੇਜ ਵੀ ਐਪ ਦੇ ਅੰਦਰ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।

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

ਕਨਫਿਗਰੇਸ਼ਨ ਪੜ੍ਹੋ, ਟੌਗਲ ਨਹੀਂ

ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਕੰਮ ਕਰੋ: ਟਨਲ ਐਂਟਰੀ ਦਾ ਆਪਣਾ ਪ੍ਰੌਕਸੀ ਮੁੱਲ, ਪ੍ਰਤੀ-ਸੇਵਾ PAC ਅਤੇ ਸਵੈ-ਖੋਜ ਸਥਿਤੀ, ਫਿਰ ਐਪ ਦੀ ਆਪਣੀ ਪ੍ਰੌਕਸੀ ਹੈਂਡਲਿੰਗ। ਤੁਹਾਡੀ ਧਾਰਨਾ ਨਾਲੋਂ ਵੱਖਰੇ ਪਹਿਲੇ 'ਤੇ ਰੁਕੋ।

ਇੱਥੇ ਹਰ ਮਾਮਲਾ ਕਨਫਿਗਰੇਸ਼ਨ ਤਰਜੀਹ ਦੀ ਸਮੱਸਿਆ ਹੈ। ਕੋਈ ਵੀ ਟਨਲ ਤੁਹਾਡਾ ਟੂਲ ਤੋੜਦਾ ਨਹੀਂ।