Cloud SQL Auth Proxy ਬਨਾਮ ਡੇਟਾਬੇਸ ਲਈ ਸਿੱਧਾ VPN ਰੂਟ
Auth Proxy ਅਤੇ ਸਿੱਧਾ VPN ਰੂਟ ਇੱਕੋ ਸਮੱਸਿਆ ਦੇ ਵੱਖਰੇ ਅੱਧ ਹੱਲ ਕਰਦੇ ਹਨ। ਪਹਿਲਾਂ ਕਨੈਕਟਰ ਅਧਿਕਾਰ, ਪੋਰਟ ਅਤੇ ਡੇਟਾਬੇਸ ਲੌਗਇਨ ਦੀ ਤੁਲਨਾ ਕਰੋ।
VPN 'ਤੇ ਮੌਜੂਦ ਲੈਪਟਾਪ ਤੋਂ ਨਿੱਜੀ Cloud SQL ਇੰਸਟੈਂਸ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਦੋ ਸਮਝਦਾਰ ਤਰੀਕੇ ਹਨ। ਇੱਕ ਹੈ ਤੁਹਾਡੇ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਰੂਟ ਰਾਹੀਂ ਇੰਸਟੈਂਸ ਦੇ ਨਿੱਜੀ ਪਤੇ 'ਤੇ ਸਿੱਧਾ ਕਨੈਕਸ਼ਨ। ਦੂਜਾ ਹੈ Cloud SQL Auth Proxy, ਜੋ loopback 'ਤੇ ਸੁਣਦਾ ਹੈ ਅਤੇ Cloud SQL ਵੱਲ ਕਨੈਕਸ਼ਨ ਖੁਦ ਖੋਲ੍ਹਦਾ ਹੈ। ਇਹ ਮੁਕਾਬਲੇ ਵਾਲੇ ਉਤਪਾਦਾਂ ਨਾਲੋਂ ਵੱਧ, ਇਸ ਸਵਾਲ ਦੇ ਦੋ ਵੱਖਰੇ ਜਵਾਬ ਹਨ ਕਿ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਕਿਸ ਕੋਲ ਹੈ ਅਤੇ ਰੂਟ ਕਿਸ ਕੋਲ ਹੈ। ਗਲਤ ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਅਧਿਕਾਰ ਗਲਤੀ ਵਜੋਂ ਸਾਹਮਣੇ ਆਉਂਦੀ ਹੈ, ਜੋ ਨੈੱਟਵਰਕ ਗਲਤੀ ਵਾਂਗ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ।
ਇਹ ਉਹ ਤੁਲਨਾ ਹੈ ਜੋ ਮੈਂ ਟੀਮ ਸਾਹਮਣੇ ਰੱਖਾਂਗਾ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਉਹ ਜਾਂਚਾਂ ਜੋ ਸੱਚਮੁੱਚ ਫੈਸਲਾ ਕਰਦੀਆਂ ਹਨ।
ਇੱਕੋ ਇੰਸਟੈਂਸ ਤੱਕ ਦੋ ਰਾਹ
ਸਿੱਧਾ ਰਾਹ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਤੋਂ ਪ੍ਰੋਜੈਕਟ ਦੇ VPC ਵਿੱਚ ਜਾਣ ਵਾਲੇ private-services-access ਰੂਟ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਤੁਹਾਡਾ ਕਲਾਇੰਟ ਇੰਸਟੈਂਸ ਦੇ ਨਿੱਜੀ ਪਤੇ ਨਾਲ PostgreSQL ਬੋਲਦਾ ਹੈ, ਅਤੇ ਕਨੈਕਸ਼ਨ ਰਾਊਟਿੰਗ, firewall ਨਿਯਮਾਂ ਅਤੇ ਡੇਟਾਬੇਸ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲਾਂ 'ਤੇ ਜੀਵਦਾ ਜਾਂ ਮਰਦਾ ਹੈ।
ਪ੍ਰੌਕਸੀ ਰਾਹ ਉਹੀ ਰੂਟ ਵਰਤਦਾ ਹੈ ਪਰ ਇੱਕ ਸਥਾਨਕ ਪ੍ਰਕਿਰਿਆ ਜੋੜਦਾ ਹੈ। ਪ੍ਰੌਕਸੀ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਦੇ default credentials ਨਾਲ Google API 'ਤੇ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੀ ਹੈ, ਕਨੈਕਟਰ ਰਾਹੀਂ ਇੰਸਟੈਂਸ ਨਾਲ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਦੀ ਹੈ ਅਤੇ ਇੱਕ loopback ਪੋਰਟ ਦਿੰਦੀ ਹੈ ਜਿਸਨੂੰ ਤੁਹਾਡਾ ਕਲਾਇੰਟ PostgreSQL ਮੰਨਦਾ ਹੈ। ਦੋ ਛਾਲਾਂ ਤਿੰਨ ਹੋ ਜਾਂਦੀਆਂ ਹਨ, ਅਤੇ ਵਿਚਕਾਰਲੀ IAM ਅਧਿਕਾਰ ਢੋਂਦੀ ਹੈ। VPN ਰੂਟ ਅਜੇ ਵੀ ਤੁਹਾਡੀ ਸੰਭਾਲ ਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੌਕਸੀ ਇਸਨੂੰ ਕਦੇ ਉਸ ਜਾਂਚ ਦਾ ਬਦਲ ਨਹੀਂ ਮੰਨਦੀ।
ਹਰ ਰਾਹ ਅਸਲ ਵਿੱਚ ਕੀ ਅਧਿਕਾਰ ਦਿੰਦਾ ਹੈ
ਸਭ ਤੋਂ ਵੱਡਾ ਫ਼ਰਕ ਇਹ ਹੈ ਕਿ ਹਰ ਵਿਕਲਪ ਤੁਹਾਡੇ ਵੱਲੋਂ ਕੀ ਅਧਿਕਾਰ ਦੇ ਸਕਦਾ ਹੈ:
| Question | Direct private IP | Auth Proxy |
|---|---|---|
| Who proves identity to the network | Your client, through the VPN and a database login | The proxy, through IAM to Google's API |
| IAM role needed for the connector | None | Cloud SQL Client or equivalent |
| Database user authentication | Always required | Still required unless IAM database authentication is enabled |
| Shape of the local leg | Client to instance | Client to loopback, proxy to instance |
ਪ੍ਰੌਕਸੀ ਦੀ IAM ਜਾਂਚ ਅਤੇ ਡੇਟਾਬੇਸ ਲੌਗਇਨ ਦੋ ਵੱਖਰੇ ਦਰਵਾਜ਼ੇ ਹਨ, ਅਤੇ ਇੱਕ ਵਿੱਚੋਂ ਲੰਘਣਾ ਦੂਜਾ ਨਹੀਂ ਖੋਲ੍ਹਦਾ। ਜੋ ਟੀਮ ਪ੍ਰੌਕਸੀ ਚਾਲੂ ਕਰਕੇ ਮੰਨ ਲੈਂਦੀ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਖਾਤਾ ਹੁਣ ਬੇਲੋੜਾ ਹੈ, ਉਹ ਨੈੱਟਵਰਕਿੰਗ ਨਾਲ ਕੋਈ ਸਬੰਧ ਨ ਰੱਖਣ ਵਾਲੀਆਂ ਪਾਸਵਰਡ ਅਸਫਲਤਾਵਾਂ ਵਿੱਚ ਦੁਪਹਿਰ ਬਿਤਾਏਗੀ।
ਪੋਰਟ ਅਤੇ ਰੂਟ, ਨਾਲ-ਨਾਲ
ਪ੍ਰੌਕਸੀ ਨੂੰ API ਲਈ ਬਾਹਰ ਜਾਣ ਵਾਲਾ TCP 443 ਅਤੇ ਇੰਸਟੈਂਸ ਕਨੈਕਸ਼ਨ ਲਈ TCP 3307 ਚਾਹੀਦਾ ਹੈ, ਦੋਵੇਂ Google ਦੇ Auth Proxy ਸੰਖੇਪ ਵਿੱਚ ਦੱਸੇ ਗਏ ਹਨ। ਤੁਹਾਡਾ VPN ਰੂਟ ਦੂਜੇ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ; ਪਹਿਲਾ ਆਮ ਤੌਰ 'ਤੇ ਆਮ ਰਾਹ ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ।
ਸਿੱਧੇ ਕਨੈਕਸ਼ਨ ਲਈ ਲੋੜ ਹੈ ਕਿ ਇੰਸਟੈਂਸ ਦਾ PostgreSQL ਪੋਰਟ ਨਿੱਜੀ ਰੂਟ ਰਾਹੀਂ ਪਹੁੰਚਯੋਗ ਹੋਵੇ, ਜੋ ਬਿਲਕੁਲ ਵੱਖਰੀ firewall ਗੱਲ ਹੈ। ਜੇ ਤੁਹਾਡੀ ਨੈੱਟਵਰਕ ਟੀਮ ਕਲਾਇੰਟ ਸਬਨੈੱਟਾਂ ਤੋਂ ਸਿਰਫ਼ 443 ਬਾਹਰ ਜਾਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਬਿਨਾਂ ਕਿਸੇ ਨਿਯਮ ਬਦਲਾਅ ਦੇ ਫਿੱਟ ਬੈਠਦੀ ਹੈ ਅਤੇ ਸਿੱਧਾ ਰਾਹ ਨਹੀਂ। ਇਹ ਇੱਕ ਤੱਥ ਕਿਸੇ ਵੀ ਆਰਕੀਟੈਕਚਰ ਪਸੰਦ ਨਾਲੋਂ ਵੱਧ ਵਾਰ ਚੋਣ ਤੈਅ ਕਰਦਾ ਹੈ।
ਦੋਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਰਾਹ ਨਹੀਂ ਮੰਗਦਾ ਕਿ ਇੰਸਟੈਂਸ ਦਾ ਜਨਤਕ ਪਤਾ ਹੋਵੇ, ਅਤੇ ਕੋਈ ਵੀ ਇੱਕ ਜੋੜਨ ਦਾ ਜਾਇਜ਼ ਨਹੀਂ ਠਹਿਰਾਉਂਦਾ।
ਜਿੱਥੇ ਪ੍ਰੌਕਸੀ ਮਦਦ ਨਹੀਂ ਕਰਦੀ
ਪ੍ਰੌਕਸੀ ਗੁੰਮ ਰੂਟ ਠੀਕ ਨਹੀਂ ਕਰਦੀ. ਜੇ private-services-access ਰੂਟ ਨਹੀਂ ਹੈ, ਜਾਂ VPN ਇਸਨੂੰ ਨਹੀਂ ਢੋਂਦਾ, ਤਾਂ ਕਨੈਕਟਰ ਅਸਫਲ ਹੋ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਕਿ ਸਥਾਨਕ ਸਰੋਤਾ ਅਜੇ ਵੀ ਉੱਥੇ ਬੈਠਾ ਸੁਣ ਰਿਹਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਉਲਝਣ ਵਾਲਾ ਹਿੱਸਾ ਇਹੀ ਹੈ।
ਇਹ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਅਤੇ ਪ੍ਰੌਕਸੀ ਵਿਚਕਾਰਲੇ ਹਿੱਸੇ ਦੀ ਵੀ ਰੱਖਿਆ ਨਹੀਂ ਕਰਦੀ। ਇੱਕ ਲੈਪਟਾਪ 'ਤੇ ਉਹ ਹਿੱਸਾ loopback ਹੈ ਅਤੇ ਠੀਕ ਹੈ। ਜੇ ਤੁਸੀਂ ਸਹਿਕਰਮੀ ਦੇ ਪਹੁੰਚਣ ਲਈ ਸਰੋਤੇ ਨੂੰ wildcard ਪਤੇ ਨਾਲ ਬੰਨ੍ਹਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਬਿਨਾਂ ਪ੍ਰਮਾਣਿਕਤਾ ਵਾਲਾ ਡੇਟਾਬੇਸ ਗੇਟਵੇ ਬਣਾ ਕੇ ਉਸਨੂੰ ਸੁਵਿਧਾ ਕਿਹਾ ਹੈ। ਇਸਨੂੰ loopback 'ਤੇ ਰੱਖੋ ਅਤੇ ਸਹਿਕਰਮੀ ਨੂੰ ਆਪਣਾ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਲੈਣ ਦਿਓ।
ਅਤੇ ਇਹ Private Service Connect ਅਤੇ private services access ਨੂੰ ਇੱਕ-ਦੂਜੇ ਦੇ ਬਦਲ ਵਜੋਂ ਵਰਤਣਯੋਗ ਨਹੀਂ ਬਣਾਉਂਦੀ। PSC ਇੰਸਟੈਂਸ ਨੂੰ ਆਪਣੀ DNS ਵਿਵਸਥਾ ਅਤੇ --private-ip ਰੂਪ ਦੀ ਥਾਂ --psc ਕਾਲ ਚਾਹੀਦੀ ਹੈ।
ਚੁਣੋ, ਫਿਰ ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ ਪਰਖੋ
ਜਦੋਂ ਤੁਸੀਂ ਰਾਹ ਵਿੱਚ IAM, ਥੋੜ੍ਹੇ ਸਮੇਂ ਦੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਅਤੇ ਆਉਂਦੇ firewall ਵਿੱਚ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਚਾਹੁੰਦੇ, ਤਾਂ ਪ੍ਰੌਕਸੀ ਚੁਣੋ।
ਜਦੋਂ ਕਿਸੇ ਸਮਰਥਿਤ ਕਲਾਇੰਟ ਕੋਲ ਪਹਿਲਾਂ ਹੀ ਮਜ਼ਬੂਤ ਡੇਟਾਬੇਸ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਹੋਣ ਅਤੇ ਨੈੱਟਵਰਕ ਟੀਮ ਪੋਰਟ ਖੋਲ੍ਹਣ ਵਿੱਚ ਸਹਿਜ ਹੋਵੇ, ਤਾਂ ਸਿੱਧਾ ਰਾਹ ਚੁਣੋ। ਕਿਸੇ ਵੀ ਤਰ੍ਹਾਂ, ਸਫਲ ਕਨੈਕਸ਼ਨ ਦੀ ਥਾਂ ਅਸਲੀ ਕਵੈਰੀ ਨਾਲ ਪਰਖੋ: ਕਨੈਕਟ ਕਰੋ, ਕਿਸੇ ਜਾਣੇ-ਪਛਾਣੇ ਟੇਬਲ 'ਤੇ ਇੱਕ ਪੜ੍ਹਤ ਚਲਾਓ ਅਤੇ ਦੇਖੋ ਕਿ ਸਰਵਰ ਤੁਹਾਡੇ ਸੈਸ਼ਨ ਬਾਰੇ ਕੀ ਦੇਖਦਾ ਹੈ।
VPN ਦੁਬਾਰਾ ਕਨੈਕਟ ਹੋਣ ਤੋਂ ਬਾਅਦ, ਮਿਆਦ ਪੁੱਗੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ, ਗੁੰਮ ਨਿੱਜੀ ਰੂਟ ਅਤੇ ਡੇਟਾਬੇਸ ਲੌਗਇਨ ਇਨਕਾਰ ਨੂੰ ਤਿੰਨ ਵੱਖਰੀਆਂ ਅਸਫਲਤਾਵਾਂ ਮੰਨੋ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਨੈੱਟਵਰਕ ਸਮੱਸਿਆ ਹੈ, ਅਤੇ ਸਿਰਫ਼ ਇੱਕ ਨੇ ਹੀ ਕਦੇ firewall ਨਿਯਮ ਬਦਲਣ ਵੱਲ ਲੈ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।