VPN ਰਾਹੀਂ Cloud SQL ਦਾ ਪ੍ਰਾਈਵੇਟ IP: ਉਹ ਰੂਟ ਜੋ ਕੋਈ ਨਿਰਯਾਤ ਨਹੀਂ ਕਰਦਾ

ਕਈ ਟੀਮਾਂ ਮੰਨਦੀਆਂ ਹਨ ਕਿ Cloud SQL ਦਾ ਪ੍ਰਾਈਵੇਟ IP ਸਿਰਫ਼ VPC ਦੇ ਅੰਦਰੋਂ ਹੀ ਕੰਮ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਵਿਸ਼ਵਾਸ ਟਿਕਿਆ ਰਹਿੰਦਾ ਹੈ ਕਿਉਂਕਿ ਅਸਫ਼ਲਤਾ ਡੇਟਾਬੇਸ ਦੀ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਖਦੀ ਹੈ। Google, Cloud VPN ਜਾਂ Cloud Interconnect ਰਾਹੀਂ ਜੁੜੇ ਨੈੱਟਵਰਕਾਂ ਤੋਂ ਪਹੁੰਚ ਦਾ ਦਸਤਾਵੇਜ਼ੀਕਰਨ ਕਰਦਾ ਹੈ। ਉਨ੍ਹਾਂ ਨੈੱਟਵਰਕਾਂ ਨੂੰ ਕੋਈ ਖ਼ਾਸ ਡੇਟਾਬੇਸ ਸੁਵਿਧਾ ਨਹੀਂ ਚਾਹੀਦੀ, ਸਗੋਂ ਦੋ ਰੂਟ ਅਦਲ-ਬਦਲ ਚਾਹੀਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅੱਧ-ਕਨਫ਼ਿਗਰ ਛੱਡਣਾ ਸੌਖਾ ਹੈ। ਟਨਲ ਉੱਪਰ ਆਉਂਦੀ ਹੈ, ਕੰਪਿਊਟ ਇੰਸਟੈਂਸ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਸਮਾਂ-ਸੀਮਾ ਲੰਘ ਜਾਂਦਾ ਹੈ — ਇਹੀ ਉਹ ਸੁਮੇਲ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਗ਼ਲਤ ਕੰਸੋਲ ਵੱਲ ਭੇਜਦਾ ਹੈ।

ਭਰਮ: ਪ੍ਰਾਈਵੇਟ IP ਦਾ ਮਤਲਬ ਹੈ VPC ਲਈ ਪ੍ਰਾਈਵੇਟ

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

ਕਿਉਂਕਿ ਇਹ ਪੀਅਰਿੰਗ ਹੈ, ਇਸਦਾ ਪੀਅਰਿੰਗ ਵਿਵਹਾਰ ਵੀ ਹੈ, ਜਿਸ ਵਿੱਚ ਉਹ ਹਿੱਸਾ ਵੀ ਸ਼ਾਮਲ ਹੈ ਜਿੱਥੇ ਕਸਟਮ ਰੂਟ ਆਪਣੇ ਆਪ ਪਾਰ ਨਹੀਂ ਹੁੰਦੇ।

ਭਰਮ: ਕੰਮ ਕਰਦੀ ਟਨਲ ਡੇਟਾਬੇਸ ਰੂਟ ਨੂੰ ਨਾਲ ਲੈ ਜਾਂਦੀ ਹੈ

ਦੋ ਰੇਂਜਾਂ ਨੂੰ ਇਹ ਸਫ਼ਰ ਝੱਲਣਾ ਪੈਂਦਾ ਹੈ। ਪਹਿਲੀ ਕਲਾਇੰਟ ਪ੍ਰੀਫਿਕਸ ਹੈ: ਤੁਹਾਡੇ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਨੂੰ ਖ਼ਾਸ ਪ੍ਰੀਫਿਕਸਾਂ ਨਾਲ Cloud Router ਨੂੰ ਜਾਣਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਡਿਫ਼ਾਲਟ ਰੂਟ ਉਹ ਆਯਾਤ ਨਹੀਂ ਦੇ ਸਕਦਾ ਜੋ ਉਤਪਾਦਕ ਨੈੱਟਵਰਕ ਨੂੰ ਵਾਪਸੀ ਰਾਹ ਲਈ ਚਾਹੀਦਾ ਹੈ। ਦੂਜੀ ਅਲਾਟ ਕੀਤੀ ਸੇਵਾ ਰੇਂਜ ਹੈ, ਜੋ ਬਾਹਰੀ ਧਿਰ ਨੂੰ ਸਿੱਖਣੀ ਪੈਂਦੀ ਹੈ ਤਾਂ ਜੋ ਡੇਟਾਬੇਸ ਵੱਲ ਉਸ ਦੇ ਪੈਕਟਾਂ ਨੂੰ ਜਾਣ ਦੀ ਥਾਂ ਮਿਲੇ। ਇਹ ਵੱਖਰੀਆਂ ਸੀਮਾਵਾਂ 'ਤੇ ਰੱਖੇ ਜਾਂਦੇ ਵੱਖਰੇ ਰੂਟ ਹਨ, ਅਤੇ ਇੱਕ ਠੀਕ ਕਰਨ ਨਾਲ ਦੂਜਾ ਟੁੱਟਿਆ ਰਹਿੰਦਾ ਹੈ।

Google ਪਾਸੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਸੰਬੰਧਿਤ ਪੀਅਰਿੰਗ ਕਨੈਕਸ਼ਨਾਂ 'ਤੇ Export custom routes ਚਾਲੂ ਕਰਨਾ ਅਤੇ ਟਨਲ ਲਈ Cloud Router ਦੇ ਐਲਾਨੇ ਰੂਟਾਂ ਵਿੱਚ ਅਲਾਟ ਕੀਤੀ ਸੇਵਾ ਰੇਂਜ ਜੋੜਨਾ।

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

ਭਰਮ: Cloud SQL Auth Proxy ਨੈੱਟਵਰਕ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ

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

ਇਹ ਜੋ ਨਹੀਂ ਕਰਦਾ ਉਹ ਹੈ ਡਿਸਕਨੈਕਟਿਡ ਲੈਪਟਾਪ ਨੂੰ ਸਿਰਫ਼-ਪ੍ਰਾਈਵੇਟ ਇੰਸਟੈਂਸ ਤੱਕ ਪਹੁੰਚਣ ਦੇਣਾ।

ਭਰਮ: Private Service Connect ਉਹੀ ਨਿਯਮ ਮੰਨਦਾ ਹੈ

Private Service Connect ਤੁਹਾਡੇ ਆਪਣੇ ਸਬਨੈੱਟ ਵਿੱਚ endpoint ਅਤੇ ਤੁਹਾਡੇ ਕੰਟਰੋਲ ਵਾਲੀ DNS ਵਿਵਸਥਾ ਵਰਤਦਾ ਹੈ, ਇਸ ਲਈ ਉੱਥੇ ਜਾਣ ਵਾਲਾ ਰੂਟ ਤੁਹਾਡੀ ਮਲਕੀਅਤ ਵਾਲੇ ਪਤੇ ਤੱਕ ਦਾ ਆਮ ਰੂਟ ਹੈ। ਪੀਅਰਿੰਗ ਨਿਰਯਾਤ ਸੈਟਿੰਗਾਂ ਉਸ ਡਿਜ਼ਾਈਨ 'ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ, ਅਤੇ ਪੀਅਰਿੰਗ ਬਦਲਾਅ PSC ਤੈਨਾਤੀ ਵਿੱਚ ਕਾਪੀ ਕਰਨਾ ਪਹੁੰਚ ਵਧਾਏ ਬਿਨਾਂ ਜੋਖਮ ਵਧਾਉਂਦਾ ਹੈ।

ਦੋਵੇਂ ਤੁਹਾਨੂੰ ਪ੍ਰਾਈਵੇਟ ਪਤਾ ਦਿੰਦੇ ਹਨ; ਸਮਾਨਤਾ ਉੱਥੇ ਹੀ ਖ਼ਤਮ ਹੁੰਦੀ ਹੈ।

ਰਾਹ ਨੂੰ ਸਹੀ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਚੋ

ਬਾਹਰੀ ਕਲਾਇੰਟ ਤੋਂ ਪਹਿਲਾਂ ਡੇਟਾਬੇਸ ਦਾ TCP endpoint ਜਾਂਚੋ। ਪੂਰਾ ਹੋਇਆ TCP ਹੈਂਡਸ਼ੇਕ ਮਤਲਬ ਰੂਟਿੰਗ, ਫਾਇਰਵਾਲ ਅਤੇ ਸਰੋਤਾ ਸਭ ਥਾਂ 'ਤੇ ਹਨ, ਅਤੇ ਅਗਲੀ ਜਾਂਚ ਮਨਜ਼ੂਰ ਪ੍ਰਮਾਣਿਕ ਕਾਰਵਾਈ ਹੈ। ਉਸ ਵੇਲੇ ਪ੍ਰਮਾਣਿਕਤਾ ਦਾ ਇਨਕਾਰ ਅਸਲ ਵਿੱਚ ਚੰਗੀ ਖ਼ਬਰ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਸਾਬਤ ਕਰਦਾ ਹੈ ਕਿ ਡੇਟਾਬੇਸ ਸਰੋਤੇ ਨੇ ਜਵਾਬ ਦਿੱਤਾ। ICMP ਸਮਾਂ-ਸੀਮਾ ਡੇਟਾਬੇਸ ਪਹੁੰਚ ਬਾਰੇ ਲਗਭਗ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ, ਕਿਉਂਕਿ ਕਈ ਰਾਹ TCP ਨੂੰ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਅੱਗੇ ਭੇਜਦੇ ਹੋਏ ਇਸਨੂੰ ਸੁੱਟ ਦਿੰਦੇ ਹਨ।

ਜੇ ਤੁਹਾਡੀਆਂ ਕਲਾਇੰਟ ਰੇਂਜਾਂ RFC 1918 ਤੋਂ ਬਾਹਰ ਹਨ, ਤਾਂ ਇਹ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਡਿਜ਼ਾਈਨ ਅਸਮਰਥਿਤ ਹੈ, ਵਾਧੂ ਰੂਟ-ਨਿਰਯਾਤ ਅਤੇ ਨੈੱਟਵਰਕ-ਅਧਿਕਾਰ ਲੋੜਾਂ ਦੀ ਸਮੀਖਿਆ ਕਰੋ।

ਕਨੈਕਸ਼ਨ ਨਾਲ ਚਾਰ ਵਸਤੂਆਂ ਦਰਜ ਕਰੋ: ਬਾਹਰੀ ਪ੍ਰੀਫਿਕਸ, ਅਲਾਟ ਕੀਤੀ ਸੇਵਾ ਰੇਂਜ, ਸ਼ਾਮਲ ਪੀਅਰਿੰਗ ਕਨੈਕਸ਼ਨ ਅਤੇ ਐਲਾਨ ਕਰਨ ਵਾਲਾ ਰਾਊਟਰ। ਇਹ ਚਾਰੇ ਪੂਰਾ ਪ੍ਰਾਈਵੇਟ ਰਾਹ ਸਮਝਾਉਂਦੇ ਹਨ, ਅਤੇ ਉਹ ਇਸ ਕਥਾ ਨੂੰ ਬਦਲ ਦਿੰਦੇ ਹਨ ਕਿ Cloud SQL ਨੂੰ ਜਾਂ ਤਾਂ ਹਮੇਸ਼ਾ ਪ੍ਰੌਕਸੀ ਚਾਹੀਦੀ ਹੈ ਜਾਂ VPN ਰਾਹੀਂ ਬਿਲਕੁਲ ਪਹੁੰਚਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ।