ਸਰਵਰ-ਲਾਕ ਪ੍ਰੋਫ਼ਾਈਲ TLS ਪ੍ਰੌਕਸੀ ਪਿੱਛੇ ਫੇਲ ਹੁੰਦੀ ਹੈ: ਕਿਹੜੀ ਪੀੜ੍ਹੀ?
Access Server 2.8 ਅਤੇ 2.9 ਸਰਵਰ-ਲਾਕ ਪ੍ਰੋਫ਼ਾਈਲ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਬਣਾਉਂਦੇ ਹਨ। ਫਰੰਟਐਂਡ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਡੀ ਪ੍ਰੌਕਸੀ ਕਿਹੜਾ ਰਾਹ ਤੋੜਦੀ ਹੈ।
ਇੱਕ ਵਰਤੋਂਕਾਰ ਜੁੜ ਸਕਦਾ ਹੈ ਅਤੇ ਦੂਜਾ ਨਹੀਂ, ਉਸੇ ਪੋਰਟਲ ਰਾਹੀਂ, ਉਸੇ ਦਿਨ। ਦੋਵਾਂ ਕੋਲ ਸਰਵਰ-ਲਾਕ ਪ੍ਰੋਫ਼ਾਈਲ ਹਨ, ਦੋਵੇਂ ਇੱਕੋ Access Server ਬਿਲਡ ਉੱਤੇ ਹਨ, ਅਤੇ ਇੱਕੋ ਇੱਕ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਉਨ੍ਹਾਂ ਦੀ ਪ੍ਰੋਫ਼ਾਈਲ ਕਦੋਂ ਬਣੀ ਸੀ। ਇਹੀ ਉਹ ਨਮੂਨਾ ਹੈ ਜਿਸਨੂੰ ਪਛਾਣਨਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ "ਸਰਵਰ-ਲਾਕ" ਕਨੈਕਸ਼ਨ ਕ੍ਰਮ ਨਹੀਂ, ਨੀਤੀ ਦੱਸਦਾ ਹੈ। Access Server ਨੇ ਉਸ ਕਲਾਕ੍ਰਿਤੀ ਦੀਆਂ ਦੋ ਪੀੜ੍ਹੀਆਂ ਜਾਰੀ ਕੀਤੀਆਂ ਹਨ, ਅਤੇ TLS ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਉਨ੍ਹਾਂ ਦੇ ਸਿਰਫ਼ ਇੱਕ ਰਾਹ ਦੇ ਸਾਹਮਣੇ ਹੈ। ਤੁਸੀਂ ਕਿਹੜੀ ਸ਼ਾਖਾ ਵਿੱਚ ਹੋ, ਇਹ ਤਿੰਨ ਸ਼ਰਤਾਂ ਤੈਅ ਕਰਦੀਆਂ ਹਨ।
ਦੋ ਪੀੜ੍ਹੀਆਂ, ਦੋ ਕਨੈਕਸ਼ਨ ਕ੍ਰਮ
2.8 ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਪੁਰਾਣੇ ਡਿਜ਼ਾਈਨ ਵਿੱਚ, ਆਯਾਤ ਕੀਤੀ ਫ਼ਾਈਲ ਇੱਕ ਸਿਊਡੋ-ਪ੍ਰੋਫ਼ਾਈਲ ਹੈ। OpenVPN Connect ਇਸਨੂੰ HTTPS ਰਾਹੀਂ Access Server ਦੇ ਵੈੱਬ API ਸਾਹਮਣੇ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਵਰਤਦਾ ਹੈ, ਇੱਕ ਅਸਥਾਈ ਵਰਤੋਂਕਾਰ-ਲਾਕ ਪ੍ਰੋਫ਼ਾਈਲ ਅਤੇ ਸੈਸ਼ਨ ਟੋਕਨ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ VPN ਸਥਾਪਿਤ ਕਰਦਾ ਹੈ। ਦੋ ਟਰਾਂਸਪੋਰਟ ਕ੍ਰਮਵਾਰ ਚੱਲਦੇ ਹਨ, ਅਤੇ ਪਹਿਲਾ ਇੱਕ ਆਮ ਵੈੱਬ ਬੇਨਤੀ ਹੈ।
2.9 ਨਾਲ ਸ਼ੁਰੂ ਕੀਤਾ ਗਿਆ ਫਾਰਮੈਟ ਉਹ ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਬੂਟਸਟ੍ਰੈਪ ਨਹੀਂ ਕਰਦਾ। ਇਹ ਇੱਕ ਦੇਸੀ ਪ੍ਰੋਫ਼ਾਈਲ ਹੈ ਜਿਸਨੂੰ ਅਨੁਕੂਲ OpenVPN ਕਲਾਇੰਟ ਵਰਤ ਸਕਦੇ ਹਨ, ਸਿਰਫ਼ OpenVPN Connect ਹੀ ਨਹੀਂ। ਇਸਨੂੰ ਡਾਊਨਲੋਡ ਕਰਨ ਜਾਂ URL ਰਾਹੀਂ ਆਯਾਤ ਕਰਨ ਵਿੱਚ ਅਜੇ ਵੀ HTTPS ਸ਼ਾਮਲ ਹੋ ਸਕਦਾ ਹੈ — ਇਹ ਪ੍ਰਕਾਸ਼ਨ ਦਾ ਕਦਮ ਹੈ, ਪ੍ਰਤੀ-ਕਨੈਕਸ਼ਨ ਅਸਥਾਈ ਪ੍ਰੋਫ਼ਾਈਲ ਲੈਣਾ ਨਹੀਂ।
| Older server-locked (≤2.8) | Newer server-locked (2.9+) | |
|---|---|---|
| Before the tunnel | Web API call with credentials | Nothing; the profile is already local |
| Client requirement | OpenVPN Connect | Any compatible client |
| What a TLS web proxy can break | The bootstrap, before any VPN attempt | Download only, not the connection |
| Expected HTTP log on connect | A request from the client | Often nothing at all |
ਅੱਪਗ੍ਰੇਡ ਪਹਿਲਾਂ ਜਾਰੀ ਕੀਤੀਆਂ ਪ੍ਰੋਫ਼ਾਈਲਾਂ ਨੂੰ ਲਾਜ਼ਮੀ ਤੌਰ 'ਤੇ ਦੁਬਾਰਾ ਨਹੀਂ ਲਿਖਦਾ, ਇਸ ਲਈ ਮੌਜੂਦਾ ਸਰਵਰ ਸੰਸਕਰਣ ਅਜੇ ਵੀ ਪੁਰਾਣੀ ਕਲਾਕ੍ਰਿਤੀ ਵੰਡ ਸਕਦਾ ਹੈ। ਸਰਵਰ ਬਿਲਡ ਦੱਸਦਾ ਹੈ ਕਿ ਕੀ ਸੰਭਵ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਇਸ ਵਰਤੋਂਕਾਰ ਨੇ ਕੀ ਆਯਾਤ ਕੀਤਾ।
ਤੁਹਾਡੀ ਸ਼ਾਖਾ ਚੁਣਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ
ਪਹਿਲੀ ਸ਼ਰਤ ਕਲਾਕ੍ਰਿਤੀ ਦੀ ਪੀੜ੍ਹੀ ਹੈ। ਫ਼ਾਈਲ ਮੰਗੋ, ਇਹ ਕਿਵੇਂ ਬਣੀ ਇਹ ਵੇਖੋ, ਅਤੇ ਇਸਨੂੰ ਆਯਾਤ ਕਰਨ ਵਾਲੇ ਕਲਾਇੰਟ ਦਾ ਸੰਸਕਰਣ ਨੋਟ ਕਰੋ। ਜੇ ਫ਼ਾਈਲ ਤੋਂ ਪੀੜ੍ਹੀ ਤੈਅ ਨਾ ਕਰ ਸਕੋ, ਤਾਂ ਟੈਸਟ ਖਾਤੇ ਲਈ ਜਾਰੀ ਨਵੀਂ ਪ੍ਰੋਫ਼ਾਈਲ ਤੁਹਾਨੂੰ ਦੱਸੇਗੀ ਕਿ ਸਰਵਰ ਅੱਜ ਕੀ ਪੈਦਾ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਫੇਲ ਹੋ ਰਹੇ ਵਰਤੋਂਕਾਰ ਕੋਲ ਮੌਜੂਦ ਜਾਣਕਾਰੀ ਤੋਂ ਵੱਖਰੀ ਹੈ।
ਦੂਜੀ ਸ਼ਰਤ ਇਹ ਹੈ ਕਿ ਤੁਹਾਡਾ ਫਰੰਟਐਂਡ ਅਸਲ ਵਿੱਚ ਕੀ ਖ਼ਤਮ ਕਰਦਾ ਹੈ। TLS ਲਾਹੁਣ ਵਾਲੀ ਸੱਤਵੀਂ ਪਰਤ ਦੀ HTTP ਰਿਵਰਸ ਪ੍ਰੌਕਸੀ ਚੌਥੀ ਪਰਤ ਦੇ TCP ਫਾਰਵਰਡਰ ਵਰਗੀ ਵਸਤੂ ਨਹੀਂ ਹੈ, ਅਤੇ UDP ਫਾਰਵਰਡਰ ਵੀ ਨਹੀਂ। ਪੋਰਟ 443 ਉੱਤੇ Access Server ਦੀ ਆਮ ਬਣਤਰ OpenVPN TCP ਡੈਮਨ ਨੂੰ ਬ੍ਰਾਊਜ਼ਰ ਟ੍ਰੈਫਿਕ ਪਛਾਣ ਕੇ ਵੈੱਬ ਸੇਵਾਵਾਂ ਨੂੰ ਦੇਣ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ, ਇਸ ਲਈ ਸਾਹਮਣੇ ਅਸੰਬੰਧਿਤ HTTPS ਟਰਮੀਨੇਟਰ ਲਗਾਉਣ ਨਾਲ ਉਸ ਡੈਮਨ ਦੀ ਪ੍ਰੋਟੋਕੋਲ ਸੰਭਾਲ ਨਹੀਂ ਬਚਦੀ। ਇੱਕੋ ਸੰਖਿਆ 443 ਸਾਂਝੀ ਕਰਨਾ ਦੋ ਡਿਜ਼ਾਈਨਾਂ ਨੂੰ ਬਰਾਬਰ ਨਹੀਂ ਬਣਾਉਂਦਾ।
ਤੀਸਰੀ ਸ਼ਰਤ ਇਹ ਹੈ ਕਿ ਫੇਲ ਕਿੱਥੇ ਪੈਂਦੀ ਹੈ। VPN ਤੋਂ ਪਹਿਲਾਂ ਦੀ ਫੇਲ ਅਤੇ ਕੰਟਰੋਲ-ਚੈਨਲ ਦੀ ਫੇਲ ਸਿਰਫ਼ "ਜੁੜ ਰਿਹਾ ਹੈ" ਕਹਿਣ ਵਾਲੇ ਕਲਾਇੰਟ ਵਿੱਚ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਸਦੀਆਂ ਹਨ, ਪਰ ਉਹ ਵੱਖ-ਵੱਖ ਥਾਵਾਂ 'ਤੇ ਸਬੂਤ ਛੱਡਦੀਆਂ ਹਨ। ਜੇ ਪੁਰਾਣਾ ਫਾਰਮੈਟ ਚੱਲ ਰਿਹਾ ਹੈ ਤਾਂ ਬੂਟਸਟ੍ਰੈਪ ਉਮੀਦਵਾਰ ਹੈ। ਜੇ ਨਵਾਂ ਫਾਰਮੈਟ ਚੱਲ ਰਿਹਾ ਹੈ ਤਾਂ ਖਾਲੀ ਵੈੱਬ ਐਕਸੈਸ ਲੌਗ ਆਸਣਯੋਗ ਹੈ ਅਤੇ ਕਿਸੇ ਵੀ ਦਿਸ਼ਾ ਵਿੱਚ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ।
ਜਦੋਂ ਕਲਾਕ੍ਰਿਤੀ ਪੁਰਾਣੀ ਹੈ: ਬੂਟਸਟ੍ਰੈਪ ਪਹਿਲਾਂ ਫੇਲ ਹੁੰਦਾ ਹੈ
ਕਲਾਇੰਟ ਦੀ ਅੰਤਿਮ ਸਥਿਤੀ ਦੀ ਬਜਾਏ ਉਸਦੀ ਅਸਲ ਤਰੁਟੀ ਪੜ੍ਹੋ। ਦਿਲਚਸਪ ਖੇਤਰ HTTPS ਤਰੁਟੀ, ਕਲਾਇੰਟ ਵੱਲੋਂ ਉਮੀਦ ਕੀਤੀ ਸਰਵਰ ਪਛਾਣ, ਬੇਨਤੀ ਦਾ ਗਿਆ ਟਿਕਾਣਾ, ਅਤੇ ਸਰਟੀਫਿਕੇਟ ਪੜਤਾਲ ਪੂਰੀ ਹੋਈ ਜਾਂ ਨਹੀਂ ਹਨ। ਫਿਰ ਉਨ੍ਹਾਂ ਨੂੰ ਸਰਵਰ ਪਾਸੇ ਦੇ ਵੈੱਬ ਸੇਵਾ ਅਤੇ ਪ੍ਰੌਕਸੀ ਲੌਗ ਨਾਲ ਮਿਲਾਓ।
ਬ੍ਰਾਊਜ਼ਰ ਦਾ ਲੌਗਇਨ ਪੰਨੇ 'ਤੇ ਪਹੁੰਚਣਾ ਇਸ ਕਲਾਇੰਟ ਦੀ API ਪ੍ਰਮਾਣਿਕਤਾ ਸਫਲ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ ਹੈ। ਇਹ ਵੱਖ-ਵੱਖ ਬੇਨਤੀਆਂ ਹਨ, ਵੱਖ-ਵੱਖ ਸਰਟੀਫਿਕੇਟ ਉਮੀਦਾਂ ਅਤੇ ਅਕਸਰ ਵੱਖ-ਵੱਖ ਹੋਸਟਨਾਵਾਂ ਨਾਲ। ਜੇ ਪੋਰਟਲ ਸਹੀ ਢੰਗ ਨਾਲ ਪਰੋਸਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਕਲਾਇੰਟ ਫਿਰ ਵੀ ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਮਤਭੇਦ ਬੂਟਸਟ੍ਰੈਪ ਰਾਹ ਵਿੱਚ ਹੈ, ਵਰਤੋਂਕਾਰ ਦੇ ਪਾਸਵਰਡ ਵਿੱਚ ਨਹੀਂ।
TLS ਪੜਤਾਲ ਬੰਦ ਕਰਕੇ ਜਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਨੀਤੀ ਢਿੱਲੀ ਕਰਕੇ ਤੁਲਨਾ ਪਾਸ ਨਾ ਕਰਾਓ। ਇਹ ਨਿਦਾਨਯੋਗ ਸੰਰਚਨਾ ਅਸੰਗਤੀ ਨੂੰ ਕੰਮ ਕਰਨ ਵਾਲੇ ਪਰ ਅਣ-ਪੜਤਾਲੇ ਰਾਹ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਅਸਥਾਈ ਟੈਸਟ ਨੂੰ ਪੱਕੇ ਛੇਕ ਵਿੱਚ ਬਦਲਣ ਵਾਲਾ ਬਦਲਾਅ ਇਹੀ ਹੈ। Access Server ਦਾ ਕਨੈਕਸ਼ਨ-ਪ੍ਰੋਫ਼ਾਈਲ ਦਸਤਾਵੇਜ਼ ਦੋਵੇਂ ਪੀੜ੍ਹੀਆਂ ਅਤੇ ਅਸਥਾਈ-ਪ੍ਰੋਫ਼ਾਈਲ ਪ੍ਰਵਾਹ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੌਕਸੀ ਨੂੰ ਦੋਸ਼ੀ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚਣ ਵਾਲਾ ਹਵਾਲਾ ਇਹੀ ਹੈ।
ਜਦੋਂ ਕਲਾਕ੍ਰਿਤੀ ਨਵੀਂ ਹੈ: ਇਸਦੀ ਬਜਾਏ ਕੰਟਰੋਲ ਚੈਨਲ ਪੜ੍ਹੋ
2.9 ਸ਼ੈਲੀ ਦੀ ਪ੍ਰੋਫ਼ਾਈਲ ਨਾਲ ਕਲਾਇੰਟ ਸਿੱਧਾ ਦੇਸੀ VPN ਐਂਡਪੌਇੰਟ 'ਤੇ ਜਾਂਦਾ ਹੈ। ਪ੍ਰੋਫ਼ਾਈਲ ਵਿੱਚਲੇ ਐਂਡਪੌਇੰਟ, ਵਰਤਿਆ ਟਰਾਂਸਪੋਰਟ, ਅਤੇ ਕੰਟਰੋਲ-ਚੈਨਲ ਤਰੁਟੀ ਦੀ ਜਾਂਚ ਕਰੋ। ਜੇ ਕਲਾਇੰਟ ਕਦੇ ਵੀ HTTP ਬੇਨਤੀ ਨਹੀਂ ਭੇਜਦਾ, ਤਾਂ ਇਹ ਡਿਜ਼ਾਈਨ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ ਅਤੇ ਲੱਛਣ ਨਹੀਂ ਹੈ।
ਇੱਥੇ ਹੀ ਪ੍ਰੌਕਸੀ ਦਾ ਸਵਾਲ ਵੀ ਆਕਾਰ ਬਦਲਦਾ ਹੈ। HTTPS ਅਨਲੋਡ ਉਸ ਸਿਰਫ਼-TCP ਸਟ੍ਰੀਮ ਨੂੰ ਨਹੀਂ ਤੋੜ ਸਕਦਾ ਜਿਸਨੂੰ ਉਹ ਕਦੇ ਨਹੀਂ ਵੇਖਦਾ, ਪਰ ਇਹ ਪ੍ਰੋਫ਼ਾਈਲ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵਾਲੇ ਡਾਊਨਲੋਡ ਨੂੰ ਅਜੇ ਵੀ ਤੋੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਿਰਫ਼-TCP ਫਾਰਵਰਡਰ UDP ਬਿਲਕੁਲ ਨਹੀਂ ਢੋਵੇਗਾ। ਫਰੰਟਐਂਡ ਅਪ੍ਰਸੰਗਿਕ ਹੈ ਦਾ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਜਾਂਚੋ ਕਿ ਪ੍ਰੋਫ਼ਾਈਲ ਕਿਹੜਾ ਟਰਾਂਸਪੋਰਟ ਮੰਗਦੀ ਹੈ।
ਇੱਕ ਸਟ੍ਰੀਮ ਲਈ TLS ਪਾਸਥਰੂ ਇੱਕ ਤੰਗ ਬਣਤਰ ਹੈ। ਇਹ UDP ਫਾਰਵਰਡਿੰਗ ਨਹੀਂ ਦਿੰਦਾ, ਅਤੇ 443 ਉੱਤੇ ਡੈਮਨ ਦੇ ਆਪਣੇ ਸੇਵਾ-ਫਾਰਵਰਡਿੰਗ ਵਿਵਹਾਰ ਨੂੰ ਦੁਬਾਰਾ ਨਹੀਂ ਪੈਦਾ ਕਰਦਾ। ਜੇ ਤੁਹਾਡਾ ਫਰੰਟਐਂਡ ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਕਰਦਾ ਹੈ, ਤਾਂ ਦੱਸੋ ਕਿਹੜਾ, ਕਿਉਂਕਿ ਇਲਾਜ ਵੱਖਰਾ ਹੈ।
ਤੰਗ ਰਹਿਣ ਵਾਲੇ ਇਲਾਜ
ਸਭ ਤੋਂ ਘੱਟ ਦਖਲ ਵਾਲੀ ਜਾਂਚ ਇਹ ਹੈ ਕਿ ਟੈਸਟ ਖਾਤੇ ਲਈ ਨਵੀਂ ਸਮਰਥਿਤ ਪ੍ਰੋਫ਼ਾਈਲ ਬਣਾਓ ਅਤੇ ਉਹੀ ਪ੍ਰਮਾਣਿਕਤਾ ਲੋੜਾਂ ਨਾਲ ਇੱਛਤ ਦੇਸੀ ਐਂਡਪੌਇੰਟ ਰਾਹੀਂ ਜੁੜੋ। ਜੇ ਉਹ ਚੱਲੇ ਅਤੇ ਰੱਖੀ ਪੁਰਾਣੀ ਪ੍ਰੋਫ਼ਾਈਲ ਨਾ ਚੱਲੇ, ਤਾਂ ਤੁਸੀਂ ਇੱਕ ਕਦਮ ਵਿੱਚ ਕਲਾਕ੍ਰਿਤੀ ਨੂੰ ਸਰਵਰ ਅਤੇ ਪ੍ਰੌਕਸੀ ਤੋਂ ਵੱਖ ਕਰ ਦਿੱਤਾ ਹੈ।
ਵਰਤੋਂਕਾਰ-ਲਾਕ ਪ੍ਰੋਫ਼ਾਈਲ ਦੀ ਵੰਡ ਪੁਰਾਣੀ ਬੂਟਸਟ੍ਰੈਪ ਨਿਰਭਰਤਾ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿੰਦੀ ਹੈ, ਕਿਉਂਕਿ ਫੇਲ ਹੋ ਸਕਣ ਵਾਲੀ ਕੋਈ ਅਸਥਾਈ-ਪ੍ਰੋਫ਼ਾਈਲ ਅਦਲਾ-ਬਦਲੀ ਨਹੀਂ ਹੈ। ਇਹ ਇੱਛਤ ਵਰਤੋਂਕਾਰ ਲਈ ਜਾਰੀ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਦੇ ਵੀ ਪ੍ਰਸ਼ਾਸਕ ਤੋਂ ਨਕਲ ਨਹੀਂ, ਅਤੇ ਇਹ ਬਦਲਦੀ ਹੈ ਕਿ ਕਲਾਇੰਟ ਕੀ ਕਰਨ ਲਈ ਅਧਿਕਾਰਤ ਹੈ, ਇਸ ਲਈ ਇਸਨੂੰ ਅਸਥਾਈ ਉਪਾਅ ਨਹੀਂ, ਨੀਤੀ ਫੈਸਲਾ ਮੰਨੋ।
ਫਿਰ ਪ੍ਰਕਾਸ਼ਨ ਖਾਕਾ ਇਸ ਤਰ੍ਹਾਂ ਠੀਕ ਕਰੋ ਕਿ ਹਰ ਲੋੜੀਂਦਾ ਰਾਹ ਮੌਜੂਦ ਹੋਵੇ: ਡਾਊਨਲੋਡ ਅਤੇ ਪੋਰਟਲ ਵਰਤੋਂ ਲਈ ਵੈੱਬ ਰਾਹ, ਅਤੇ ਪ੍ਰੋਫ਼ਾਈਲ ਜਿਸ ਟਰਾਂਸਪੋਰਟ ਦੀ ਉਮੀਦ ਕਰਦੀਆਂ ਹਨ ਉਸ ਉੱਤੇ ਦੇਸੀ VPN ਰਾਹ। ਪ੍ਰੌਕਸੀ ਦਾ ਕੰਮ ਇੱਕੋ ਪਰਤ ਵਿੱਚ ਰੱਖੋ। ਚੱਲਣ ਵਾਲੀ ਵਰਤੋਂਕਾਰ-ਲਾਕ ਟਨਲ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਰਾਹ ਚੱਲਦਾ ਹੈ; ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਹਰ ਪ੍ਰੌਕਸੀ ਬਣਤਰ ਹਰ ਪੀੜ੍ਹੀ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ, ਅਤੇ ਪੁਰਾਣੀ ਬੂਟਸਟ੍ਰੈਪ ਫੇਲ ਨਵੇਂ ਫਾਰਮੈਟ ਦੀ ਨਿੰਦਾ ਨਹੀਂ ਕਰਦੀ।
- ਪ੍ਰੌਕਸੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਕ੍ਰਿਤੀ ਦੀ ਪੀੜ੍ਹੀ ਪਛਾਣੋ।
- ਤੈਅ ਕਰੋ ਕਿ ਫੇਲ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਹੁੰਦੀ ਹੈ ਜਾਂ ਇਸਦੇ ਅੰਦਰ।
- ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਫਰੰਟਐਂਡ ਕੀ ਖ਼ਤਮ ਕਰਦਾ ਹੈ: HTTP, TCP ਸਟ੍ਰੀਮ, ਜਾਂ UDP।
- ਨੀਤੀ ਅਣਬਦਲੀ ਰੱਖਦਿਆਂ ਨਵੀਂ ਜਾਰੀ ਪ੍ਰੋਫ਼ਾਈਲ ਦੇਸੀ ਐਂਡਪੌਇੰਟ ਸਾਹਮਣੇ ਪਰਖੋ।