ਜੇ ਤੁਸੀਂ Identity-Aware Proxy ਵਰਤਦੇ ਹੋ ਤਾਂ ਕੀ ਤੁਹਾਨੂਂ ਅਜੇ ਵੀ VPN ਦੀ ਲੋੜ ਹੈ?

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

ਦੋਨੇ ਦਰਵਾਜੇ ਵੱਖਰੀਆਂ ਚੀਜਾਂ ਨੂੰ ਅਧਿਕਾਰਿਤ ਕਰਦੇ ਹਨ

ਐਪਲੀਕੇਸ਼ਨ ਦਰਵਾਜਾ ਤਯ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਇਹ ਬੇਨਤੀ, ਇਸ ਪਛਾਣ ਤੋਂ, ਇਸ ਸੁਰੱਖਿਤ ਸੰਸਾਧਨ ਤਕ ਪੁੱਜ ਸਕਦੀ ਹੈ ਕਿ ਨਹੀਂ। Google ਦਾ Identity-Aware Proxy ਸਰੇਖਾ ਠੀਕ ਇਹੀ ਰੂਪ ਦੱਸਦਾ ਹੈ: HTTPS ਐਪਾਂ ਦੇ ਅੱਗੇ IAM ਭੂਮਿਕਾ ਰਾਹੀਂ ਚਲਦੀ ਕੇਂਦਰੀ ਅਧਿਕਾਰ ਤੱਹ। ਸੀਮਾ ਸੰਸਾਧਨ ਹੈ, ਅਤੇ ਪਹੁੰਚ ਦੀ ਇਕਾਈ ਬੇਨਤੀ ਹੈ। ਰੂਟ ਕੀਤਾ VPN ਕੁਝ ਵੱਧ ਮੋਟਾ ਅਤੇ ਵੱਡਾ ਕੰਮ ਕਰਦਾ ਹੈ: ਕਲਾਇਂਟ ਨੂੰ ਨਿੱਸਚਿਤ ਨੈਟਵਰਕ ਖੇਤਰ ਵਿੱਚ ਪ੍ਰਵੇਸ਼ ਦਿੰਦਾ ਹੈ, ਉਸ ਤੋਂ ਬਾਦ ਵੀ ਐਪ ਤਯ ਕਰਦੀ ਹੈ ਕਿ ਉਹ ਕਲਾਇਂਟ ਕੀ ਕਰ ਸਕਦਾ ਹੈ।

ਦੋਨੇਵਾਂ ਮੌਡਲਾਂ ਵਿੱਚੋਂ ਕੋਈ ਦੂਜੇ ਨੂੰ ਲਾਜਮੀ ਨਹੀਂ ਬਣਦਾ। ਦਰਵਾਜੇ ਤੋਂ ਲੰਘਣਾ ਕਿਸੇ ਖਾਸ ਰਿਕਾਰਡ ਪੱਢਨ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਆਖਦਾ, ਅਤੇ ਨੈਟਵਰਕ ਤੇ ਹੋਣਾ ਕੰਮ ਕਰਨ ਦੀ ਇਜਾਜਤ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਆਖਦਾ।

ਪ੍ਰੌਕਸੀ ਕੀ ਨਹੀਂ ਢੱਕਦੀ, ਅਤੇ VPN ਕੀ ਢੱਕਦਾ ਹੈ

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

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

ਕਲਾਇਂਟ ਵਰਕਫ਼ਲੋ ਆਰਕੀਟੈਕਚਰ ਡਾਇਗਰਾਮ ਤੋਂ ਵੱਧ ਤਯ ਕਰਦਾ ਹੈ

ਰੀਡਾਇਰੈਕਟ ਅਤੇ ਕਦੇ ਕਦੇ MFA ਚੁਣੌਤੀ ਸੱਦਾਂ ਬ੍ਰਾਊਜ਼ਰ ਸਾਇਨ-ਇਨ ਉਸ ਬੰਦੇ ਲਈ ਵੱਧਿਆ ਅਨੁਭਵ ਹੈ ਜੋ ਬੁੱਕਮਾਰਕ ਤੇ ਕਲਿੱਕ ਕਰਦਾ ਹੈ। cron ਕੰਮ, CLI ਜਾਂ ਬਿੱਲਡ ਐਜੰਟ ਕੋਲੋਂ ਬ੍ਰਾਊਜ਼ਰ ਨਹੀਂ ਹੁੰਦਾ ਅਤੇ ਇੰਟਰੈਕਟਿਵ ਪ੍ਰੋੰਪਟ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦੇ ਸਕਦਾ, ਇਸ ਲਈ ਉਨੂੰ ਦਸਤਾਵੇਜੀਕ੃ਤ ਗੈਰ-ਇੰਟਰੈਕਟਿਵ ਰਾਹ ਜਾਂ ਟੰਨਲ ਦੀ ਲੋੜ ਹੈ। ਉਸ ਲੋੜ ਦੀ ਖੋਜ ਆਮ ਤੌਰ ਤੇ ਡਿਜ਼ਾਇਨ ਮੰਜੂਰ ਹੋਣ ਤੋਂ ਬਾਦ ਹੁੰਦੀ ਹੈ।

ਐਪਾਂ ਗਿਣਨ ਤੋਂ ਪਹਿਲਾਂ ਕਲਾਇਂਟ ਗਿਣੋ। ਇੱਕ ਡੈਸ਼ਬੋਰਡ ਸੌ ਲੋਕਾਂ ਦੀ ਸੇਵਾ ਕਰ ਸਕਦਾ ਹੈ; ਇੱਕ ਡੇਟਾਬੇਸ ਪੋਰਟ ਪੂਰੀ ਟੀਮ ਨੂੰ ਰੋਕ ਸਕਦਾ ਹੈ।

ਡਿਵਾਇਸ ਦੀ ਸਥਿਤੀ ਕਿਸੇ ਵੀ ਦਰਵਾਜੇ ਦਾ ਗੁਣ ਨਹੀਂ ਹੈ

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

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

ਕੁਝ ਨਵਾਜ਼ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵਿਕਲਪਿਕ ਰਾਹ ਲੱਭੋ

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

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

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