Apple VPN ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ Proxy ਖੇਤਰ ਅਸਲ ਵਿੱਚ ਕੀ ਕਰਦਾ ਹੈ
ਪ੍ਰੌਕਸੀ ਖੇਤਰ ਭਰਨ ਨਾਲ VPN HTTP ਨਹੀਂ ਬਣ ਜਾਂਦਾ। ਇੱਥੇ ਦੋ ਕਨੈਕਸ਼ਨ ਸ਼ਾਮਲ ਹਨ, ਅਤੇ ਖੇਤਰ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ।
Apple VPN ਸੰਰਚਨਾ ਵਿੱਚ Proxy ਖੇਤਰ ਭਰਨ ਨਾਲ ਲੱਗਦਾ ਹੈ ਕਿ ਇਹ ਟਨਲ ਨੂੰ ਵੈੱਬ ਪੋਰਟ ਰਾਹੀਂ ਮੋੜ ਦੇਵੇਗਾ। ਪਰ ਇਹ ਅਜਿਹਾ ਨਹੀਂ ਕਰਦਾ। ਖੇਤਰ ਉਸ ਟ੍ਰੈਫਿਕ ਲਈ ਐਪਲੀਕੇਸ਼ਨ-ਪੱਧਰੀ ਵਿਚੋਲਾ ਚੁਣਦਾ ਹੈ ਜੋ ਕੋਈ ਅਨੁਕੂਲ ਐਪ ਉੱਥੇ ਭੇਜਣ ਦਾ ਫੈਸਲਾ ਕਰਦੀ ਹੈ। ਜਦਕਿ VPN ਕਲਾਇੰਟ ਦਾ ਆਪਣਾ ਗੇਟਵੇ ਨਾਲ ਕਨੈਕਸ਼ਨ ਉਸ ਪ੍ਰੋਟੋਕੋਲ, ਲਿਸਨਰ ਅਤੇ ਟ੍ਰਾਂਸਪੋਰਟ ਨਾਲ ਤੈਅ ਹੁੰਦਾ ਹੈ ਜੋ ਤੁਸੀਂ ਸੰਰਚਿਤ ਕੀਤਾ, ਅਤੇ ਇਹ ਵੱਖਰੇ ਫੈਸਲੇ ਹਨ।
ਦੋ ਕਨੈਕਸ਼ਨ, ਦੋ ਮਾਲਕ
ਅਜਿਹੀ ਕੋਈ ਵੀ ਸੈਟਿੰਗ ਵਿੱਚ ਕਲਾਇੰਟ ਤੋਂ ਗੇਟਵੇ ਤੱਕ ਅਤੇ ਐਪ ਤੋਂ ਮੰਜ਼ਿਲ ਤੱਕ ਕਨੈਕਸ਼ਨ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ। Proxy ਭਾਗ ਦੂਜੇ ਬਾਰੇ ਬੋਲਦਾ ਹੈ, ਭਾਵੇਂ ਉਹ ਪਹਿਲੇ ਵਾਲੇ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਹੀ ਹੋਵੇ।
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Apple ਦਾ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ ਦਾ ਸੰਦਰਭ HTTP, HTTPS, SOCKS ਅਤੇ ਆਪਣੇ-ਆਪ ਪ੍ਰੌਕਸੀ ਸੰਰਚਨਾ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ, ਜੋ ਐਪਾਂ ਦੀਆਂ ਪ੍ਰੌਕਸੀ ਚੋਣਾਂ ਦਾ ਵਰਣਨ ਹੈ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਐਂਟਰੀ ਇਹ ਨਹੀਂ ਦੱਸਦੀ ਕਿ IPsec ਜਾਂ WireGuard ਪੈਕਟ ਗੇਟਵੇ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਦਾ ਹੈ।
ਇਹ ਮਾਮਲਾ ਨਿਪਟਾਉਣ ਵਾਲੀ ਇੱਕ ਤੇਜ਼ ਜਾਂਚ ਇਹ ਹੈ। VPN ਕਲਾਇੰਟ ਆਪਣੇ ਲੌਗ ਵਿੱਚ ਜੋ ਪੋਰਟ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਦੱਸਦਾ ਹੈ, ਉਹ ਦੱਸੋ। ਜੇ ਉਹ ਲਾਈਨ ਅਜੇ ਵੀ UDP 500 ਜਾਂ UDP 51820 ਕਹਿੰਦੀ ਹੈ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਖੇਤਰ ਨੇ ਉਸ ਵਿੱਚ ਕੁਝ ਨਹੀਂ ਬਦਲਿਆ।
ਖੇਤਰ ਕਦੋਂ ਸਹੀ ਸਾਧਨ ਹੈ
ਇੱਕ ਅਸਲੀ ਮਾਮਲਾ ਹੈ ਜਿੱਥੇ ਪ੍ਰੌਕਸੀ ਟਨਲ ਦੇ ਅੱਗੇ ਖੜ੍ਹਾ ਹੁੰਦਾ ਹੈ, ਪਰ ਇਹ ਪ੍ਰੋਫਾਈਲ ਖੇਤਰ ਨਹੀਂ, ਕਲਾਇੰਟ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ. OpenVPN ਦਾ ਮੈਨੂਅਲ HTTP CONNECT ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਲਿਜਾਏ ਜਾਣ ਵਾਲੇ TCP ਕਨੈਕਸ਼ਨਾਂ ਲਈ --http-proxy ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ। ਇਸਨੂੰ ਵਰਤਣ ਲਈ ਮੇਲ ਖਾਂਦਾ ਕਲਾਇੰਟ ਵਿਕਲਪ, ਉਸ ਤਰ੍ਹਾਂ ਪਹੁੰਚਯੋਗ ਗੇਟਵੇ ਅਤੇ ਵਰਤੇ ਜਾ ਰਹੇ ਪੋਰਟ ’ਤੇ CONNECT ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਪ੍ਰੌਕਸੀ ਚਾਹੀਦਾ ਹੈ।
ਜੇ ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਉਹ ਵਿਕਲਪ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨੈੱਟਵਰਕ ਪੋਰਟ ’ਤੇ CONNECT ਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ। ਜੇ ਕਲਾਇੰਟ ਇਹ ਨਹੀਂ ਦਿੰਦਾ, ਤਾਂ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ ਭਰਨ ਦਾ ਟਨਲ ’ਤੇ ਕੋਈ ਅਸਰ ਨਹੀਂ ਹੁੰਦਾ।
ਕਦੋਂ ਇਹ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ
ਪ੍ਰੌਕਸੀ ਖੇਤਰ ਭਰਿਆ ਹੋਣ ਕਰਕੇ IKEv2 ਜਾਂ IPsec ਪ੍ਰੋਫਾਈਲ HTTP ਟਨਲ ਨਹੀਂ ਬਣ ਜਾਂਦਾ। WireGuard ਵੀ ਨਹੀਂ, ਜਿਸਦੇ ਸੰਰਚਨਾ ਫਾਰਮੈਟ ਵਿੱਚ ਪ੍ਰੌਕਸੀ ਦੀ ਧਾਰਨਾ ਨਹੀਂ ਹੈ। ਗੇਟਵੇ ਪੋਰਟ ਬਦਲਣ ਨਾਲ ਉਸਦਾ ਪ੍ਰੋਟੋਕੋਲ ਵੀ ਨਹੀਂ ਬਦਲਦਾ। ਅਤੇ ਆਮ HTTPS ਦਾ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਐਂਡਪੌਇੰਟ ਆਪਣੇ-ਆਪ VPN ਲਿਸਨਰ ਨਹੀਂ ਹੁੰਦਾ।
ਉਹੀ ਜਾਲ ਪੁਰਾਣੀਆਂ iPad ਗਾਈਡਾਂ ਤੋਂ PPTP ਯੁੱਗ ਦੇ ਪ੍ਰੋਫਾਈਲ ਕਾਪੀ ਕਰਨ ਵਾਲਿਆਂ ਨੂੰ ਵੀ ਫੜਦਾ ਹੈ। ਵਿਕਲਪ ਇੰਟਰਫੇਸ ਵਿੱਚ ਅਜੇ ਵੀ ਹਨ; ਉਨ੍ਹਾਂ ਪਿੱਛੇ ਦੀ ਸੇਵਾ ਹੁਣ ਉਹ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਬੋਲਦੀ।
ਕਿਹੜੀ ਪਰਤ ਠੀਕ ਕਰਨੀ ਹੈ ਦਾ ਫੈਸਲਾ
ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪੁੱਛੋ ਕਿ ਕਿਹੜੀ ਪਰਤ ਫੇਲ੍ਹ ਹੋਈ। ਜੇ ਕਲਾਇੰਟ ਸੈਸ਼ਨ ਸਥਾਪਤ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਤਾਂ ਸਮੱਸਿਆ ਟ੍ਰਾਂਸਪੋਰਟ ਵਿੱਚ ਹੈ ਅਤੇ ਪ੍ਰੌਕਸੀ ਖੇਤਰ ਅਪ੍ਰਸੰਗਿਕ ਹੈ। ਜੇ ਟਨਲ ਚਾਲੂ ਹੈ ਪਰ ਇੱਕ ਐਪ ਆਪਣੇ ਸਰਵਰ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦੀ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੌਕਸੀ ਦੇਖਣਾ ਲਾਹੇਵੰਦ ਹੈ। ਜੇ ਟਨਲ ਚਾਲੂ ਹੈ ਅਤੇ ਸਾਰੀਆਂ ਐਪਾਂ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਟਨਲ ਦੇ ਅੰਦਰ ਰੂਟਿੰਗ ਅਤੇ DNS ਸ਼ੱਕੀ ਹਨ।
ਪਹਿਲੇ ਮਾਮਲੇ ਲਈ, ਆਪਰੇਟਰ ਨੂੰ ਪੁੱਛੋ ਕਿ ਉਹ ਕਿਹੜਾ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਵਿਕਲਪਿਕ ਟ੍ਰਾਂਸਪੋਰਟ ਜਾਂ ਨੈੱਟਵਰਕ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। TCP 443 ’ਤੇ OpenVPN ਮੌਜੂਦ ਹੈ ਕਿਉਂਕਿ ਕੁਝ ਨੈੱਟਵਰਕ ਸਿਰਫ਼ ਇਸੇ ਦੀ ਆਗਿਆ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਇਸ ਲਈ ਸਰਵਰ ਦਾ ਇਸਨੂੰ ਸੁਣਨਾ ਅਜੇ ਵੀ ਜ਼ਰੂਰੀ ਹੈ।
ਰੋਕੇ ਹੋਏ UDP ਪੋਰਟ ਨੂੰ ਤਤਕਾਲ ਉਪਾਅ ਦੀ ਆਗਿਆ ਨਾ ਸਮਝੋ। ਹੈਂਡਸ਼ੇਕ ਫਿੱਟ ਕਰਨ ਲਈ ਗੇਟਵੇ ਦੇ ਸਰਟੀਫਿਕੇਟ ਜਾਂ ਪਛਾਣ ਜਾਂਚ ਬੰਦ ਕਰਨ ਦੀ ਥਾਂ ਉਨ੍ਹਾਂ ਨੂੰ ਅਟੂਟ ਰੱਖੋ।
ਦੋਵੇਂ ਪਰਤਾਂ ਇੱਕ-ਇੱਕ ਕਰਕੇ ਪੁਸ਼ਟੀ ਕਰੋ
ਪਹਿਲਾਂ ਟਨਲ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ: ਕਲਾਇੰਟ ਦੇ ਸਥਿਤੀ ਪੰਨੇ ’ਤੇ ਸਥਾਪਿਤ ਸੈਸ਼ਨ ਅਤੇ ਜ਼ੀਰੋ ਤੋਂ ਵੱਖਰੀ ਬਾਈਟ ਗਿਣਤੀ ਦੇਖੋ। ਫਿਰ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗ ਸਿੱਧੀ ਪੜ੍ਹੋ, ਪ੍ਰਭਾਵੀ ਸੰਰਚਨਾ ਲਈ scutil --proxy ਜਾਂ ਸੰਭਾਲੇ ਮੁੱਲ ਲਈ networksetup -getwebproxy Wi-Fi ਵਰਤ ਕੇ। ਫਿਰ ਇੱਕ ਐਪ ਜਾਂਚੋ ਜੋ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ ਦਾ ਸਤਿਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਜੋ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੀਆਂ ਮੂਲ ਐਪਾਂ ਇਸਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀਆਂ ਹਨ।
ਤਿੰਨ ਨਤੀਜੇ, ਤਿੰਨ ਵੱਖਰੇ ਸੁਧਾਰ।
ਜੇ ਦੋਵੇਂ ਪਰਤਾਂ ਸਫਲਤਾ ਦੱਸਦੀਆਂ ਹਨ ਅਤੇ ਐਪ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਸਪਲਿਟ ਟਨਲਿੰਗ, DNS ਅਤੇ ਐਪ ਦੀਆਂ ਆਪਣੀਆਂ ਨੈੱਟਵਰਕ ਸੈਟਿੰਗਾਂ ਦੇਖੋ। ਇਹ ਤੀਜੀ ਪਰਤ ਹੈ, ਅਤੇ ਉਹ ਵੀ ਪ੍ਰੌਕਸੀ ਖੇਤਰ ਨਹੀਂ ਹੈ।