ਤੁਹਾਡਾ GCP VM OpenVPN IPv6 ਪੂਲ ਨੂੰ ਜਵਾਬ ਕਿਉਂ ਨਹੀਂ ਦੇ ਸਕਦਾ

ਤੁਹਾਡਾ IPv6 VPN ਕਲਾਇੰਟ ਵਰਕਲੋਡ ਤੱਕ ਪਹੁੰਚਦਾ ਹੈ, ਵਰਕਲੋਡ ਟਨਲ ਵਿੱਚ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਜਵਾਬ ਕਦੇ ਨਹੀਂ ਪਹੁੰਚਦਾ। ਪਹਿਲੀ ਪ੍ਰਵਿਰਤੀ ਫਾਇਰਵਾਲ ਜਾਂ ਟਨਲ ਨੂੰ ਦੋਸ਼ ਦੇਣਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਦੋਸ਼ੀ ਨਹੀਂ ਹੁੰਦਾ। OpenVPN ਜੋ ਪਤਾ ਦਿੰਦਾ ਹੈ ਉਹ ਟਨਲ ਦੇ ਅੰਦਰ ਹੀ ਮੌਜੂਦ ਇੱਕ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਹੈ; fd42:90::/64 ਕਿਸੇ ਖਾਸ VM ਦੇ ਪਿੱਛੇ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਤੁਹਾਡੇ ਦੱਸਣ ਤੱਕ Google Cloud ਨੂੰ ਪਤਾ ਨਹੀਂ।

ਇਹ ਤੱਥ ਦੋ ਵੱਖਰੇ ਸਿਸਟਮਾਂ ਨੂੰ ਸਿੱਖਣਾ ਪਵੇਗਾ, ਅਤੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ OpenVPN ਹੈ। VPC ਨੂੰ ਕੁਝ ਵੀ ਵਾਪਸ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਰੂਟ ਦੀ ਲੋੜ ਹੈ, ਅਤੇ VM ਨੂੰ ਜੋ ਆਉਂਦਾ ਹੈ ਉਸ ਨੂੰ ਫਾਰਵਰਡ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣੀ ਪਵੇਗੀ। ਕਿਸੇ ਵੀ ਅੱਧ ਵਿੱਚ ਗਲਤੀ ਕਰੋ ਤਾਂ ਲੱਛਣ ਇੱਕੋ ਜਿਹਾ ਦਿਸਦਾ ਹੈ।

ਪੂਲ ਇੱਕ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਹੈ, ਸਬਨੈੱਟ ਨਹੀਂ

OpenVPN ਤੁਹਾਡੀ ਚੁਣੀ ਹੋਈ ਰੇਂਜ ਵਿੱਚੋਂ IPv6 ਪਤੇ ਦੇ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਹ ਰੇਂਜ ਟਨਲ ਦੇ ਦੋਵਾਂ ਸਿਰਿਆਂ ਵੱਲੋਂ ਮੰਨੀ ਗਈ ਇੱਕ ਕਲਪਨਾ ਹੈ। ਇਹ Google Cloud ਸਬਨੈੱਟ ਨਹੀਂ ਹੈ, VPC ਸਬਨੈੱਟ ਸੂਚੀ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦਾ, ਅਤੇ VM ਦਾ ਨੈੱਟਵਰਕ ਇੰਟਰਫ਼ੇਸ ਉਹ ਪਤੇ ਨਹੀਂ ਲੈਂਦਾ। ਇਸ ਲਈ ਕਲਾਇੰਟ ਨੂੰ ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਵਰਕਲੋਡ ਉਸ ਪਤੇ ’ਤੇ ਪੈਕਟ ਭੇਜਦਾ ਹੈ ਜਿਸ ਨੂੰ ਨੈੱਟਵਰਕ ਗੈਰ-ਰੂਟੇਬਲ ਮੰਨਦਾ ਹੈ।

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

fd42:90::/64 ਵਰਗੀ ਵਿਲੱਖਣ ਸਥਾਨਕ ਐਡਰੈਸਿੰਗ ਇਸ ਅੰਦਰੂਨੀ ਨੈੱਟਵਰਕ ਲਈ ਵਾਜਬ ਚੋਣ ਹੈ। ਉਪਸਰਗ ਇਹ ਵੀ ਯਾਦ ਕਰਾਉਂਦਾ ਹੈ ਕਿ ਡਿਜ਼ਾਈਨ ਸੁਭਾਵਿਕ ਤੌਰ ’ਤੇ ਨਿੱਜੀ ਹੈ। ULA ਪੂਲ ਵਿੱਚ ਕੁਝ ਵੀ ਇਸ ਨੂੰ ਜਨਤਕ ਇੰਟਰਨੈੱਟ ’ਤੇ ਕਾਨੂੰਨੀ ਸਰੋਤ ਨਹੀਂ ਬਣਾਉਂਦਾ।

VPC ਨੂੰ ਮੰਜ਼ਿਲ ਅਤੇ ਅਗਲੀ ਹੌਪ ਦਿਓ

ਜਵਾਬ ਲਈ ਅਜਿਹਾ VPC ਰੂਟ ਚਾਹੀਦਾ ਹੈ ਜਿਸ ਦੀ ਮੰਜ਼ਿਲ ਪੂਲ ਹੋਵੇ ਅਤੇ ਅਗਲੀ ਹੌਪ VPN VM ਹੋਵੇ। ਮੌਜੂਦਾ ਸਟੈਟਿਕ-ਰੂਟ ਦਸਤਾਵੇਜ਼ IPv6 ਮੰਜ਼ਿਲ ਰੇਂਜਾਂ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ ਅਤੇ ਦੱਸਦਾ ਹੈ ਕਿ ਕਿਹੜੀਆਂ ਅਗਲੀ ਹੌਪ ਕਿਸਮਾਂ ਯੋਗ ਹਨ, ਇਸ ਲਈ ਪੁਰਾਣੀ IPv4 ਉਦਾਹਰਨ ਕਾਪੀ ਕਰਨ ਦੀ ਬਜਾਏ ਆਪਣੀ ਟੋਪੋਲੋਜੀ ਲਈ ਸਮਰਥਿਤ ਰੂਪ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ।

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

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

gcloud compute routes create vpn6-return \
  --network=vpn-vpc \
  --destination-range=fd42:90::/64 \
  --next-hop-instance=openvpn-vm \
  --next-hop-instance-zone=europe-west1-b

ਫਾਰਵਰਡਿੰਗ ਦੋ ਵਾਰ ਸਮਰੱਥ ਕਰਨੀ ਪਵੇਗੀ

ਰੂਟ ਪੈਕਟ ਨੂੰ ਇੰਸਟੈਂਸ ਤੱਕ ਪਹੁੰਚਾਉਂਦਾ ਹੈ। ਇਹ ਇੰਸਟੈਂਸ ਨੂੰ ਉਹ ਕੁਝ ਫਾਰਵਰਡ ਕਰਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕਰਦਾ ਜੋ ਇਸ ਨੂੰ ਸੰਬੋਧਿਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਉਹ ਇਜਾਜ਼ਤ ਦੋ ਪੱਧਰਾਂ ’ਤੇ ਹੁੰਦੀ ਹੈ।

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

sysctl -w net.ipv6.conf.all.forwarding=1

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

OpenVPN ਨੂੰ ਦੱਸੋ ਕਿ ਕਿਸ ਕੋਲ ਕੀ ਹੈ

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

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

ਇੰਟਰਨੈੱਟ ਈਗ੍ਰੈਸ ਇਸ ਡਿਜ਼ਾਈਨ ਤੋਂ ਬਾਹਰ ਰੱਖੋ

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

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