App Engine ਤੁਹਾਡੇ VPN ਡੇਟਾਬੇਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ: ਕੀ ਮੇਲ ਖਾਣਾ ਚਾਹੀਦਾ ਹੈ

ਇਹ ਦਾਅਵਾ ਕਿ App Engine Standard Cloud VPN ਰਾਹੀਂ ਨਿੱਜੀ ਡੇਟਾਬੇਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਸਕਦਾ, ਪਲੇਟਫਾਰਮ ਦੀ ਪਿਛਲੀ ਪੀੜ੍ਹੀ ਦਾ ਬਚਿਆ ਹੋਇਆ ਹੈ। Standard ਇੰਸਟੈਂਸਾਂ ਨੂੰ ਕੁਝ ਹੋਰ ਰਨਟਾਈਮਾਂ ਵਾਂਗ VPC-ਮੂਲ ਪਤਾ ਨਹੀਂ ਮਿਲਦਾ, ਪਰ ਉਹ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਵਿੱਚ ਮੌਜੂਦ Serverless VPC Access ਕਨੈਕਟਰ ਰਾਹੀਂ egress ਭੇਜ ਸਕਦੇ ਹਨ। ਇੱਕ ਵਾਰ ਉਹ ਮਾਰਗ ਬਣ ਜਾਵੇ, ਤਾਂ Cloud VPN ਅਤੇ ਦੂਰਲਾ ਫਾਇਰਵਾਲ ਕਨੈਕਟਰ ਦੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿਸੇ ਹੋਰ ਸਰੋਤ ਵਾਂਗ ਦੇਖਦੇ ਹਨ। ਅਸਫਲ ਹੋਣਾ ਘੱਟ ਹੀ ਕਾਬਲੀਅਤ ਆਪ ਹੁੰਦੀ ਹੈ। ਇਹ ਉਨ੍ਹਾਂ ਤਿੰਨ ਸੈਟਿੰਗਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਕਦੇ ਨਹੀਂ ਮਿਲਾਈਆਂ ਗਈਆਂ।

ਪੁਰਾਣਾ ਜਵਾਬ ਕਿੱਥੋਂ ਆਇਆ

ਕਨੈਕਟਰਾਂ ਦੇ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ, ਵਿਹਾਰਕ ਜਵਾਬ ਸੱਚਮੁੱਚ ਇਹ ਸੀ ਕਿ Standard ਸਿਰਫ਼ ਜਨਤਕ ਐਂਡਪੌਇੰਟਾਂ ਨਾਲ ਗੱਲ ਕਰ ਸਕਦਾ ਸੀ, ਅਤੇ ਟੀਮਾਂ ਇਸ ਤੋਂ ਬਚਣ ਲਈ ਪ੍ਰੌਕਸੀ VM ਜਾਂ ਕਿਸੇ ਹੋਰ ਰਨਟਾਈਮ ਵੱਲ ਚਲੀਆਂ ਗਈਆਂ। ਪਲੇਟਫਾਰਮ ਬਦਲਿਆ, ਲੋਕ-ਕਥਾ ਨਹੀਂ। ਔਨਲਾਈਨ ਬਹੁਤ ਸਾਰੀ ਸਲਾਹ ਅਜੇ ਵੀ ਉਸ ਯੁੱਗ ਨੂੰ ਦਰਸਾਉਂਦੀ ਹੈ ਜਦੋਂ egress ਦਾ ਕੋਈ ਵਿਕਲਪ ਹੀ ਨਹੀਂ ਸੀ।

ਸੁਧਾਰ ਸੁਣਨ ਨਾਲੋਂ ਸੰਖੇਪ ਹੈ। Standard ਨਿੱਜੀ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ, ਪਰ ਸਿਰਫ਼ ਸਮਰਥਿਤ egress ਏਕੀਕਰਨ ਰਾਹੀਂ, ਅਤੇ ਸਿਰਫ਼ ਉਨ੍ਹਾਂ ਮੰਜ਼ਿਲਾਂ ਲਈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਉਹ ਏਕੀਕਰਨ ਸੱਚਮੁੱਚ ਫੜਦਾ ਹੈ।

ਪਹਿਲਾਂ egress ਮਾਰਗ ਚੁਣੋ

ਸੇਵਾ ਨਾਲ ਜੁੜਿਆ ਕਨੈਕਟਰ ਹੀ ਉਸਦੀ ਟ੍ਰੈਫਿਕ ਨੂੰ VPC ਵਿੱਚ ਪਾਉਂਦਾ ਹੈ। ਕਨੈਕਟਰ ਦਸਤਾਵੇਜ਼ ਖੇਤਰੀ ਪੂਰਵ-ਸ਼ਰਤ ਅਤੇ egress ਸੈਟਿੰਗਾਂ ਦੀ ਸੂਚੀ ਦਿੰਦੇ ਹਨ; ਕਨੈਕਟਰ ਸੇਵਾ ਦੇ ਖੇਤਰ ਵਿੱਚ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਅਤੇ ਤੈਨਾਤ ਕਰਨ ਵਾਲੀ ਪਛਾਣ ਲਈ ਵਰਤੋਂਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

vpc_access_connector:
  name: projects/PROJECT_ID/locations/REGION/connectors/CONNECTOR_NAME
  egress_setting: private-ranges-only

private-ranges-only ਨਿੱਜੀ ਮੰਜ਼ਿਲਾਂ ਨੂੰ VPC ਵਿੱਚ ਭੇਜਦਾ ਹੈ ਅਤੇ ਬਾਕੀ ਸਭ ਕੁਝ ਆਮ ਇੰਟਰਨੈੱਟ ਮਾਰਗ ਉੱਤੇ ਛੱਡ ਦਿੰਦਾ ਹੈ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਡੇਟਾਬੇਸ ਕਨੈਕਸ਼ਨ ਨੂੰ ਚਾਹੀਦਾ ਹੁੰਦਾ ਹੈ। all-traffic ਬਾਹਰ ਜਾਣ ਵਾਲੀ ਟ੍ਰੈਫਿਕ ਨੂੰ VPC ਰਾਹੀਂ ਵਿਆਪਕ ਤੌਰ 'ਤੇ ਧੱਕਦਾ ਹੈ, ਇਸ ਲਈ ਆਮ ਇੰਟਰਨੈੱਟ ਕਾਲਾਂ ਵੀ VPC ਦੀ NAT ਅਤੇ ਫਾਇਰਵਾਲ ਸਥਿਤੀ ਵਿਰਾਸਤ ਵਿੱਚ ਪਾਉਂਦੀਆਂ ਹਨ।

ਫਾਈਲ ਨੂੰ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਸੰਪਾਦਿਤ ਕਰਨ ਨਾਲ ਤੈਨਾਤ ਕਰਨ ਤੱਕ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ। ਚੱਲ ਰਿਹਾ ਸੰਸਕਰਣ ਉਹ ਸੰਰਚਨਾ ਰੱਖਦਾ ਹੈ ਜਿਸ ਨਾਲ ਇਹ ਬਣਿਆ ਸੀ।

ਸਰੋਤ ਪਤਾ ਕਨੈਕਟਰ ਹੈ, ਤੁਹਾਡਾ ਲੈਪਟਾਪ ਨਹੀਂ

ਇੱਥੇ ਹੀ ਜ਼ਿਆਦਾਤਰ ਡੀਬੱਗਿੰਗ ਸਮਾਂ ਜਾਂਦਾ ਹੈ। ਦੂਰਲੇ VPN ਗੇਟਵੇ ਅਤੇ ਡੇਟਾਬੇਸ ਫਾਇਰਵਾਲ ਨੂੰ VPC ਦੇ ਅੰਦਰ ਕਨੈਕਟਰ ਦੀ ਅਲਾਟ ਕੀਤੀ ਰੇਂਜ ਮਨਜ਼ੂਰ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ, ਨਾ ਤੁਹਾਡੇ ਦਫ਼ਤਰ ਦਾ ਪਤਾ ਅਤੇ ਨਾ ਸੇਵਾ ਦਾ ਜਨਤਕ egress ਪਤਾ। ਇੱਕ ਵੀ ਨਿਯਮ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਰੇਂਜ ਕੰਸੋਲ ਵਿੱਚ ਲੱਭੋ।

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

ਸਿਰਫ਼ VM ਸਬਨੈੱਟ ਸਵੀਕਾਰ ਕਰਨ ਵਾਲੀ ਟਨਲ ਕਨੈਕਟਰ ਦੇ ਪੈਕਟ ਬਿਨਾਂ ਕਿਸੇ ਲਾਭਦਾਇਕ ਗਲਤੀ ਸੁਨੇਹੇ ਦੇ ਸੁੱਟ ਦੇਵੇਗੀ, ਇਸ ਲਈ ਡੇਟਾਬੇਸ ਦਾ ਟਾਈਮਆਊਟ ਪ੍ਰਮਾਣਿਕਤਾ ਸਮੱਸਿਆ ਵਾਂਗ ਦਿਸਦਾ ਹੈ।

DNS ਵੱਖਰੇ ਮਾਰਗ ਰਾਹੀਂ ਸਫ਼ਰ ਕਰਦਾ ਹੈ

ਨਿੱਜੀ ਡੇਟਾਬੇਸ ਹੋਸਟਨਾਮ ਨੂੰ ਕਨੈਕਟਰ ਜਿਸ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ ਉਸਦੇ ਅੰਦਰ ਹੱਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, Cloud DNS ਪੀਅਰਿੰਗ ਜਾਂ VPC ਵਰਤ ਸਕਦਾ ਹੈ ਅਜਿਹੇ ਫਾਰਵਰਡਿੰਗ ਜ਼ੋਨ ਰਾਹੀਂ। ਤੁਹਾਡੇ ਵਰਕਸਟੇਸ਼ਨ 'ਤੇ ਇਸਨੂੰ ਹੱਲ ਕਰਨਾ ਤੈਨਾਤ ਸੇਵਾ ਬਾਰੇ ਕੁਝ ਵੀ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ, ਕਿਉਂਕਿ ਤੁਹਾਡਾ ਲੈਪਟਾਪ ਉਹ ਰਿਜ਼ੋਲਵਰ ਨਹੀਂ ਵਰਤਦਾ।

ਜੇ ਨਾਮ VPC ਦੇ ਅੰਦਰੋਂ ਜਨਤਕ ਪਤੇ 'ਤੇ ਹੱਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਗਲਤ ਫਾਇਰਵਾਲ ਡੀਬੱਗ ਕਰਨ ਜਾ ਰਹੇ ਹੋ।

URL Fetch ਕਨੈਕਟਰ ਨਹੀਂ ਵਰਤਦਾ

egress ਸੈਟਿੰਗ ਰਨਟਾਈਮ ਦੇ ਆਮ ਬਾਹਰ ਜਾਣ ਵਾਲੇ ਸਾਕਟਾਂ ਨੂੰ ਕਵਰ ਕਰਦੀ ਹੈ, ਅਤੇ ਪੁਰਾਣੀ URL Fetch ਸੇਵਾ ਉਸ ਮਾਰਗ ਦਾ ਹਿੱਸਾ ਨਹੀਂ ਹੈ। urlfetch ਰਾਹੀਂ ਜਾਰੀ ਬੇਨਤੀ ਸੰਰਚਨਾ ਜੋ ਵੀ ਕਹੇ, ਕਨੈਕਟਰ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੀ ਹੈ। ਜਦੋਂ ਅਸਫਲ ਕਾਲ ਕਿਸੇ ਪੁਰਾਣੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਹੁੰਦੀ ਹੈ ਜੋ ਅਜੇ ਵੀ URL Fetch ਵਰਤਦੀ ਹੈ, ਤਾਂ ਹੱਲ ਉਸ ਕਾਲ ਨੂੰ ਮਿਆਰੀ HTTP ਕਲਾਇੰਟ 'ਤੇ ਲਿਜਾਣਾ ਹੈ।

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

ਇੱਕ ਤੰਗ ਕਿਊਰੀ ਨਾਲ ਪੁਸ਼ਟੀ ਕਰੋ

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

VPC ਦੇ ਅੰਦਰ VM ਤੋਂ ਸਫਲ ਕਿਊਰੀ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਰੂਟ ਮੌਜੂਦ ਹੈ। ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ ਕਿ ਸੇਵਾ ਨੇ ਇਸਨੂੰ ਚੁਣਿਆ।