Google Cloud VPC ਤੱਕ ਦੂਰੋਂ ਡਿਵੈਲਪਰ ਪਹੁੰਚ: ਸਹੀ ਰਾਹ ਚੁਣੋ

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

ਮੰਜ਼ਿਲਾਂ ਅਤੇ ਪ੍ਰੋਟੋਕੋਲ ਲਿਖੋ

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

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

ਕੁਝ TCP ਸੇਵਾਵਾਂ ਲਈ IAP

Identity-Aware Proxy ਵਿੱਚ TCP ਫਾਰਵਰਡਿੰਗ ਸੇਵਾ ਨੂੰ ਇੰਟਰਨੈੱਟ 'ਤੇ ਖੋਲ੍ਹੇ ਬਿਨਾਂ ਯੋਗ VM ਸਰੋਤਾਂ ਤੱਕ ਪ੍ਰਮਾਣਿਤ ਸੁਰੰਗ ਦਿੰਦੀ ਹੈ। ਰੋਜ਼ਾਨਾ ਰੂਪ gcloud compute ssh instance-1 --tunnel-through-iap --zone=us-central1-a ਹੈ, ਅਤੇ ਇੱਕ ਪੋਰਟ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ gcloud compute start-iap-tunnel instance-1 5432 --local-host-port=localhost:15432 --zone=us-central1-a ਨਾਲ ਫਾਰਵਰਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

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

IAP TCP ਫਾਰਵਰਡਿੰਗ ਤੀਜੀ ਪਰਤ ਦਾ VPN ਨਹੀਂ ਹੈ। ਇਹ TCP ਨੂੰ ਚੁਣੀ ਹੋਈ ਮੰਜ਼ਿਲ ਤੱਕ ਲੈ ਜਾਂਦੀ ਹੈ, ਮਨਮਾਨੀ IP ਟ੍ਰੈਫ਼ਿਕ ਜਾਂ UDP ਨਹੀਂ, ਅਤੇ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਈ ਸੇਵਾਵਾਂ ਵਿੱਚ ਨਿੱਜੀ DNS ਚਾਹੀਦਾ ਹੋਵੇ ਤਾਂ ਇਹ ਚੰਗੀ ਤਰ੍ਹਾਂ ਨਹੀਂ ਬੈਠਦੀ।

ਵਧੇਰੇ ਚੌੜੀ ਪਹੁੰਚ ਲਈ ਰਿਮੋਟ-ਐਕਸੈਸ VPN

ਜਦੋਂ ਕਈ ਮੰਜ਼ਿਲਾਂ, ਪ੍ਰੋਟੋਕੋਲ ਜਾਂ ਨਿੱਜੀ DNS ਜ਼ੋਨ ਚਾਹੀਦੇ ਹੋਣ, ਤਾਂ VM ਜਾਂ ਸਮਰਥਿਤ ਯੰਤਰ 'ਤੇ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਪ੍ਰਬੰਧਿਤ ਰਿਮੋਟ-ਐਕਸੈਸ VPN ਵਧੀਆ ਰੂਪ ਹੈ। ਉਹ ਤੈਨਾਤੀ Google-ਪ੍ਰਬੰਧਿਤ Cloud VPN ਤੋਂ ਵੱਖਰੀ ਹੈ: ਕਲਾਇੰਟ ਪਛਾਣ ਰਜਿਸਟਰੇਸ਼ਨ, ਸੌਫਟਵੇਅਰ ਅੱਪਡੇਟ, ਕਲਾਇੰਟ ਰਸਤੇ ਅਤੇ VPC ਵਾਪਸੀ ਰਸਤੇ ਤੁਹਾਡੇ ਕੋਲ ਹਨ।

ਸਿਰਫ਼ ਜਨਤਕ ਲਿਸਨਰ ਨਹੀਂ, ਪੂਰੀ ਸੂਚੀ ਦੀ ਯੋਜਨਾ ਬਣਾਓ। ਸੁਰੰਗ ਪੂਲ, ਉਸ ਵੱਲ ਵਾਪਸ VPC ਰਾਹ, ਫਾਰਵਰਡਿੰਗ ਨਿਯੰਤਰਣ, DNS ਹੱਲ ਅਤੇ ਪ੍ਰਤੀ-ਸੇਵਾ ਪਹੁੰਚ ਨੀਤੀ ਸ਼ਾਮਲ ਕਰੋ। ਜੋ VPN ਜੁੜਦਾ ਹੈ ਪਰ ਅੰਦਰੂਨੀ ਨਾਮ ਹੱਲ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਉਹ ਡਿਵੈਲਪਰ ਦੇ ਕੰਮ ਦੇ ਪ੍ਰਵਾਹ ਨੂੰ ਉੱਨੀ ਹੀ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਕਰਦਾ ਹੈ ਜਿੰਨਾ ਕਦੇ ਨਾ ਜੁੜਨ ਵਾਲਾ VPN ਕਰਦਾ ਹੈ।

Cloud VPN ਇੱਕ ਸਾਈਟ ਗੇਟਵੇ ਹੈ, ਲੈਪਟਾਪ ਪ੍ਰੋਫ਼ਾਈਲ ਨਹੀਂ

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

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

ਤਸਦੀਕ ਕਰੋ ਅਤੇ ਦਰਜ ਕਰੋ

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

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