ਕਿਉਂ ਹੋਸਟ ਦੇ URL ਨਾਲ ਮਹਿਮਾਨ VM ਵਿੱਚ PAC ਪ੍ਰੌਕਸੀ ਫੇਲ ਹੁੰਦੀ ਹੈ

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

PAC URL ਇੱਕ ਸਕ੍ਰਿਪਟ ਹੈ, ਪ੍ਰੌਕਸੀ ਨਹੀਂ

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

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

ਚਾਰੇ ਕਦਮ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਫੇਲ ਹੁੰਦੇ ਹਨ

ਮਹਿਮਾਨ ਦੇ ਅੰਦਰ ਚਾਰ ਗੱਲਾਂ ਕ੍ਰਮ ਨਾਲ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ, ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਆਪਣੀ ਗਲਤੀ-ਨਿਸ਼ਾਨੀ ਹੈ। ਮਹਿਮਾਨ PAC ਫਾਈਲ ਲਿਆਉਂਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ ਸਥਾਨਕ ਜਾਣਕਾਰੀ ਨਾਲ ਮੰਗੇ URL ਲਈ ਸਕ੍ਰਿਪਟ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦੀ ਹੈ। ਚੁਣੀ ਪ੍ਰੌਕਸੀ ਹੱਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਉੱਥੇ ਪਹੁੰਚਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਪ੍ਰੌਕਸੀ ਮੰਗਦੀ ਹੈ ਤਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਹੁੰਦੀ ਹੈ।

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

curl -sS -o /dev/null -w '%{http_code}\n' http://pac.corp.example/proxy.pac
getent hosts pac.corp.example

ਜੇ ਉਹ ਬੇਨਤੀ ਮਹਿਮਾਨ ਤੋਂ ਫੇਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਹੋਸਟ ਤੋਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਤਾਂ ਸਮੱਸਿਆ ਸਕ੍ਰਿਪਟ ਦੀ ਸਮੱਗਰੀ ਵਿੱਚ ਨਹੀਂ, ਮਹਿਮਾਨ ਦੇ PAC ਸਰਵਰ ਤੱਕ ਦੇ ਰਾਹ ਵਿੱਚ ਹੈ। ਜੇ ਉਹ JavaScript ਫਾਈਲ ਵਾਪਸ ਕਰਦੀ ਹੈ, ਤਾਂ ਦੂਜੇ ਕਦਮ ਤੇ ਜਾਓ ਅਤੇ ਪਤਾ ਕਰੋ ਕਿ ਸਕ੍ਰਿਪਟ ਮਹਿਮਾਨ ਦੇ ਸੰਦਰਭ ਲਈ ਕੀ ਤੈਅ ਕਰਦੀ ਹੈ।

ਉਹੀ ਸਕ੍ਰਿਪਟ VM ਦੇ ਅੰਦਰ ਵੱਖਰੇ ਤਰੀਕੇ ਨਾਲ ਤੈਅ ਕਰਦੀ ਹੈ

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

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

ਮਹਿਮਾਨ ਨੇ ਹੋਸਟ ਦੀਆਂ ਪ੍ਰੌਕਸੀ ਸੈਟਿੰਗਾਂ ਵਿਰਾਸਤ ਵਿੱਚ ਲਈਆਂ ਇਹ ਸਿੱਟਾ ਨਾ ਕੱਢੋ, ਕਿਉਂਕਿ ਉਸਦਾ ਟ੍ਰੈਫਿਕ ਹੋਸਟ-ਪਾਸੇ ਅਨੁਵਾਦ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ। ਨੈੱਟਵਰਕ ਅਨੁਵਾਦ ਪੈਕਟ ਅੱਗੇ ਭੇਜਦਾ ਹੈ; ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਕਨਫਿਗਰੇਸ਼ਨ ਦੀ ਨਕਲ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਸਿਸਟਮ ਪ੍ਰੌਕਸੀ ਐਪਲੀਕੇਸ਼ਨ ਕਨਫਿਗਰੇਸ਼ਨ ਹੈ।

ਉਹ ਸੰਦ ਜੋ PAC ਬਿਲਕੁਲ ਨਹੀਂ ਪੜ੍ਹਦੇ

ਕਮਾਂਡ-ਲਾਈਨ ਸੰਦ ਵੱਖਰੀ ਹੱਦ ਹਨ, ਅਤੇ ਇੱਥੇ ਹੀ ਬਹੁਤ ਸਮਾਂ ਬਰਬਾਦ ਹੁੰਦਾ ਹੈ। curl PAC ਫਾਈਲਾਂ ਨਹੀਂ ਚਲਾਉਂਦਾ, ਜਿਵੇਂ ਉਸਦਾ ਪ੍ਰੌਕਸੀ ਦਸਤਾਵੇਜ਼ ਸਪਸ਼ਟ ਕਹਿੰਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਚਰ ਨੂੰ PAC ਡਾਊਨਲੋਡ URL ਵੱਲ ਸੇਧਿਤ ਕਰਨ ਨਾਲ ਸਕ੍ਰਿਪਟ ਪ੍ਰੌਕਸੀ ਅੰਤ-ਬਿੰਦੂ ਨਹੀਂ ਬਣਦੀ; ਸੰਦ JavaScript ਫਾਈਲ ਨਾਲ HTTP ਬੋਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ ਅਤੇ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਵਰਗਾ ਦਿਖਣ ਵਾਲੇ ਢੰਗ ਨਾਲ ਫੇਲ ਹੋਵੇਗਾ।

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

Linux ਤੇ ਡੈਸਕਟਾਪ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ, ਸਿਸਟਮ ਸੈਟਿੰਗ ਨੂੰ ਸਵੈਚਾਲਿਤ ਮੋਡ ਵਿੱਚ ਰੱਖਣਾ ਅਤੇ URL ਵੀ ਦੇਣਾ ਪਵੇਗਾ; ਮੋਡ ਅਜੇ ਮੈਨੁਅਲ ਹੁੰਦਿਆਂ ਸੰਭਾਲਿਆ URL ਕੁਝ ਨਹੀਂ ਕਰਦਾ। ਦੋਵੇਂ ਜਾਂਚੋ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮਹਿਮਾਨ ਦੇ ਅੰਦਰ ਜਾਂਚੋ:

gsettings get org.gnome.system.proxy mode
gsettings get org.gnome.system.proxy autoconfig-url

DIRECT ਵੀ ਇੱਕ ਫੈਸਲਾ ਹੈ

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

ਇਸ ਲਈ ਉਸੇ ਦਿਸ਼ਾ ਵਿੱਚ ਪ੍ਰਮਾਣਿਤ ਕਰੋ ਜਿਸ ਵਿੱਚ ਲੋੜ ਲਿਖੀ ਗਈ ਸੀ। ਜੇ ਲੋੜ «ਇਹ ਐਪਲੀਕੇਸ਼ਨ ਅੰਦਰੂਨੀ ਸਾਈਟ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ» ਹੈ, ਤਾਂ ਸਾਬਤ ਕਰੋ ਕਿ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਪਹੁੰਚਦੀ ਹੈ, ਅਤੇ ਲਿਖੋ ਕਿ ਕਿਹੜੀ ਪ੍ਰੌਕਸੀ ਜਾਂ ਰਾਹ ਉਸਨੂੰ ਲੈ ਗਿਆ। ਜੇ ਲੋੜ «VM ਕਾਰਪੋਰੇਟ ਨੈੱਟਵਰਕ ਤੇ ਹੈ» ਹੈ, ਤਾਂ ਚੁਣੀ ਪ੍ਰੌਕਸੀ ਰਾਹੀਂ ਚੱਲਣ ਵਾਲਾ ਬ੍ਰਾਊਜ਼ਰ ਉਸ ਬ੍ਰਾਊਜ਼ਰ ਲਈ ਸਬੂਤ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ।

ਪਰਖ ਪਾਸ ਹੋਣ ਲਈ ਹੋਸਟ ਦੀ ਟਨਲ ਬੰਦ ਕਰਨ ਜਾਂ ਫਾਰਵਰਡਿੰਗ ਨੀਤੀ ਢਿੱਲੀ ਕਰਨ ਦੀ ਥਾਂ ਮਹਿਮਾਨ ਦੇ ਅੰਦਰ ਜ਼ੰਜੀਰ ਠੀਕ ਕਰੋ। ਜ਼ੰਜੀਰ ਵਿੱਚ ਚਾਰ ਕੜੀਆਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਛੱਡਣ ਵਾਲਾ ਬਦਲਾਅ ਅਗਲੀ ਵਾਰ ਸਕ੍ਰਿਪਟ ਅਪਡੇਟ ਹੋਣ ਜਾਂ ਮਹਿਮਾਨ ਦਾ ਪਤਾ ਬਦਲਣ ਤੱਕ ਟਿਕਿਆ ਰਹੇਗਾ।