Cloud VPN ਦੀਆਂ ਉਹ ਸੀਮਾਵਾਂ ਜੋ ਤੁਸੀਂ ਟਿਊਨ ਨਹੀਂ ਕਰ ਸਕਦੇ: IKE ਆਯੁ ਅਤੇ ਪੀਅਰ NAT

ਰਿਮੋਟ ਡਿਵਾਈਸ ਨੂੰ 24 ਘੰਟਿਆਂ ਦਾ ਫੇਜ਼ 1 ਆਯੁ ਦਿਓ ਅਤੇ Google ਪਾਸੇ ਸਭ ਕੁਝ ਸਹੀ ਸੰਰਚਿਤ ਹੋਣ ਦੇ ਬਾਵਜੂਦ Cloud VPN ਟਨਲ ਹੇਠਾਂ ਹੀ ਰਹੇਗਾ। ਪੀਅਰ ਅਜਿਹਾ ਮੁੱਲ ਪੇਸ਼ ਕਰ ਰਿਹਾ ਹੈ ਜੋ ਜਵਾਬਦੇਹ ਸਵੀਕਾਰ ਨਹੀਂ ਕਰੇਗਾ, ਇਸ ਲਈ ਗੱਲਬਾਤ ਜਾਂ ਤਾਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ ਜਾਂ ਬੇਅੰਤ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। Cloud VPN ਫੇਜ਼ 1 ਨੂੰ 36,000 ਸਕਿੰਟ, ਭਾਵ ਦਸ ਘੰਟਿਆਂ ਤੱਕ ਸੀਮਿਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹ ਸੀਮਾ ਅਜਿਹੀ ਸੈਟਿੰਗ ਨਹੀਂ ਜੋ ਤੁਸੀਂ ਵਧਾ ਸਕੋ। ਬਦਲਾਅ ਰਿਮੋਟ ਡਿਵਾਈਸ ’ਤੇ ਹੀ ਕਰਨਾ ਹੈ।

ਪੀਅਰ ਪੁੱਛਦਾ ਹੈ, ਜਵਾਬਦੇਹ ਫੈਸਲਾ ਕਰਦਾ ਹੈ

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

ਕੇਸ ਖੋਲ੍ਹਣ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਦੀ ਆਪਣੀ ਸਥਿਤੀ ਪੜ੍ਹੋ, ਕਿਉਂਕਿ ਵਿਸਥਾਰਤ ਸਥਿਤੀ ਆਮ ਤੌਰ ’ਤੇ ਉਹ ਪੜਾਅ ਦੱਸਦੀ ਹੈ ਜੋ ਫੇਲ੍ਹ ਹੋਇਆ:

gcloud compute vpn-tunnels describe office-tunnel \
  --region europe-west1 \
  --format="value(status,detailedStatus)"

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

36,000 ਸਕਿੰਟ ਹੀ ਸਿਖਰਲੀ ਸੀਮਾ ਹੈ

ਫੇਜ਼ 1 36,000 ਸਕਿੰਟ ’ਤੇ ਰੁਕਦਾ ਹੈ। 86,400 ’ਤੇ ਸੈੱਟ ਡਿਵਾਈਸ ਅਜਿਹੀ ਚੀਜ਼ ਮੰਗ ਰਹੀ ਹੈ ਜਿਸ ਨਾਲ ਜਵਾਬਦੇਹ ਕਦੇ ਸਹਿਮਤ ਨਹੀਂ ਹੋਵੇਗਾ, ਅਤੇ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਨਾਲ ਉਸ ਦਾ ਮਨ ਨਹੀਂ ਬਦਲਦਾ। ਰਿਮੋਟ ਪ੍ਰਸਤਾਵ ਨੂੰ ਸੀਮਾ ਅੰਦਰ ਵਾਪਸ ਲਿਆਓ ਅਤੇ ਉਹੀ ਸੰਰਚਨਾ ਸਥਾਪਿਤ ਹੋ ਜਾਵੇਗੀ; ਇਹ ਅਸਮਾਨਤਾ ਹੀ ਪੂਰਾ ਪਾਠ ਹੈ, ਕਿਉਂਕਿ ਤੁਸੀਂ ਆਪਣਾ ਮੁੱਲ ਘਟਾ ਸਕਦੇ ਹੋ ਪਰ Google ਦਾ ਨਹੀਂ ਵਧਾ ਸਕਦੇ।

ਚੁਣਿਆ ਮੁੱਲ ਡਿਜ਼ਾਈਨ ਨੋਟਾਂ ਵਿੱਚ ਲਿਖੋ। ਨਹੀਂ ਤਾਂ ਅਗਲਾ ਇੰਜੀਨੀਅਰ 24 ਘੰਟਿਆਂ ਦਾ ਪ੍ਰਯੋਗ ਦੁਹਰਾਏਗਾ ਅਤੇ ਉਸੇ ਕੰਧ ’ਤੇ ਪਹੁੰਚੇਗਾ।

ਸਮਰਥਿਤ ਸਮੂਹ ਹਰ ਗੇਟਵੇ ਕਿਸਮ ਅਤੇ IKE ਸੰਸਕਰਣ ਲਈ ਇੱਥੇ ਪ੍ਰਕਾਸ਼ਿਤ ਹੁੰਦਾ ਹੈ: Cloud VPN ਸੰਖੇਪਵਿੱਚ, ਇਸ ਲਈ ਆਮ IKE ਗਾਈਡ ਦੀ ਥਾਂ ਆਪਣੀ ਟੋਪੋਲੋਜੀ ਵਾਲਾ ਭਾਗ ਪੜ੍ਹੋ।

ਸਮਾਂ-ਸਾਰਣੀ ਅਨੁਸਾਰ ਡਿੱਗਣ ਵਾਲਾ ਟਨਲ

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

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

ਸਮੂਹ ਗੇਟਵੇ ਕਿਸਮ ਤੋਂ ਆਉਂਦੇ ਹਨ

ਸਾਈਫਰ ਅਤੇ ਅਖੰਡਤਾ ਸਮੂਹ strongSwan ਵਾਂਗ ਸੰਪਾਦਿਤ ਕਰਨ ਯੋਗ ਪ੍ਰਤੀ-ਟਨਲ ਪ੍ਰੋਫਾਈਲ ਨਹੀਂ ਹਨ। ਤੁਸੀਂ ਉਹਨਾਂ ਨੂੰ ਗੇਟਵੇ ਕਿਸਮ ਅਤੇ IKE ਸੰਸਕਰਣ ਨਾਲ ਚੁਣਦੇ ਹੋ, ਅਤੇ ਨਾ ਹੋਣ ਵਾਲਾ ਪ੍ਰੋਫਾਈਲ ਲੱਭਣਾ ਦੁਪਹਿਰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ।

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

ਪ੍ਰਤੀ ਡਿਵਾਈਸ ਇੱਕ ਬਾਹਰੀ ਪਤਾ

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

ਉਹ ਬਾਹਰੀ ਪਤਾ ਸਥਿਰ ਵੀ ਰੱਖੋ। ਡਿਵਾਈਸ ਨੂੰ ਦੂਜੇ NAT ਪਿੱਛੇ ਲੈ ਜਾਓ ਅਤੇ ਹਰ ਪ੍ਰਸਤਾਵ ਦੇ ਅਜੇ ਵੀ ਮੇਲ ਖਾਣ ਦੇ ਬਾਵਜੂਦ ਸੰਬੰਧ ਟੁੱਟ ਜਾਂਦਾ ਹੈ। ਇਹ ਲਿਖਣਾ ਲਾਭਦਾਇਕ ਹੈ ਕਿ ਕਿਹੜੇ ਮੁੱਲ Google ਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਤੁਹਾਡੇ: ਆਯੁ, ਸਮੂਹ ਅਤੇ ਇੱਕ-ਤੋਂ-ਇੱਕ NAT ਉਹਨਾਂ ਦੇ ਪਾਸੇ ਸਥਿਰ ਹਨ, ਜਦੋਂ ਕਿ ਪ੍ਰਸਤਾਵ, ਸਿਲੈਕਟਰ, ਰੂਟਿੰਗ ਅਤੇ BGP ਤਰਜੀਹਾਂ ਤੁਹਾਡੀਆਂ ਹਨ।