Cloud VPN ਸਥਿਤੀ: IKE ਲੌਗ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤ ਦੀ ਸਥਿਤੀ ਪੜ੍ਹੋ
ਪ੍ਰਬੰਧਿਤ ਟਨਲ ਅਲਾਟਮੈਂਟ, IKE ਅਤੇ ਰੂਟ ਕੀਤੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਵੱਖਰੇ ਪੜਾਵਾਂ ਵਜੋਂ ਦੱਸਦਾ ਹੈ। ਪੀਅਰ ਨੂੰ ਸੋਧਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਆਬਜੈਕਟ ਅਤੇ ਇੱਕ ਸਮਾਂ-ਵਿੰਡੋ ਨੂੰ ਸਹਿ-ਸੰਬੰਧਿਤ ਕਰੋ।
ਇੱਕ Cloud VPN ਟਨਲ ਇੱਕੋ ਸਮੇਂ ਦੋ ਜੀਵਨ-ਚੱਕਰ ਚਲਾਉਂਦਾ ਹੈ, ਅਤੇ ਉਹ ਇੱਕੋ ਘੜੀ ਉੱਤੇ ਨਹੀਂ ਹਨ। ਸਰੋਤ ਨੂੰ ਪਹਿਲਾਂ ਅਲਾਟ ਅਤੇ ਕਨਫਿਗਰ ਹੋਣਾ ਪੈਂਦਾ ਹੈ, ਤਦ ਹੀ ਇਹ ਗੱਲਬਾਤ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਉਸ ਤੋਂ ਬਾਅਦ ਪ੍ਰੋਟੋਕੋਲ ਦਾ IKE ਸੁਨੇਹਿਆਂ ਦਾ ਆਪਣਾ ਕ੍ਰਮ ਹੈ। ਸਥਿਤੀ ਖੇਤਰ ਪਹਿਲੇ ਬਾਰੇ ਦੱਸ ਸਕਦਾ ਹੈ, ਪਰ ਦੂਜੇ ਬਾਰੇ ਕੁਝ ਵੀ ਲਾਭਦਾਇਕ ਨਹੀਂ ਕਹਿੰਦਾ। ਦੋਹਾਂ ਨੂੰ ਇੱਕ ਚੀਜ਼ ਵਜੋਂ ਪੜ੍ਹਨਾ ਹੀ ਉਹ ਤਰੀਕਾ ਹੈ ਜਿਸ ਨਾਲ ਕੁੰਜੀ ਦੀ ਅਸੰਗਤੀ ਉੱਤੇ ਪ੍ਰੋਵਿਜ਼ਨਿੰਗ ਦੇਰੀ ਦਾ ਦੋਸ਼ ਲੱਗਦਾ ਹੈ।
ਇੱਕ ਟਨਲ ਆਬਜੈਕਟ ਅਤੇ ਇੱਕ ਸਮਾਂ-ਵਿੰਡੋ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ।
ਦੋ ਜੀਵਨ-ਚੱਕਰ, ਇੱਕ ਟਨਲ ਆਬਜੈਕਟ
ਸਰੋਤ ਦਾ ਜੀਵਨ-ਚੱਕਰ ਭਾਵ ਪ੍ਰਦਾਤਾ ਟਨਲ ਤਿਆਰ ਕਰਦਾ ਹੈ: ਪਤੇ, ਕਨਫਿਗਰੇਸ਼ਨ, ਸਮਰੱਥਾ। ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਜੀਵਨ-ਚੱਕਰ ਤਦ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਦੋਹਾਂ ਧਿਰਾਂ ਕੋਲ IKE_SA_INIT, ਫਿਰ IKE_AUTH, ਫਿਰ ਚਾਈਲਡ ਸੁਰੱਖਿਆ ਸੰਗਠਨਾਂ ਦੀ ਅਦਲਾ-ਬਦਲੀ ਲਈ ਲੋੜੀਂਦੀ ਕਨਫਿਗਰੇਸ਼ਨ ਹੁੰਦੀ ਹੈ। ਪਹਿਲੇ ਪੜਾਅ ਵਿੱਚ ਰਿਹਾ ਟਨਲ ਪ੍ਰਮਾਣਿਕਤਾ ਵਿੱਚ ਫੇਲ੍ਹ ਨਹੀਂ ਹੋਇਆ, ਕਿਉਂਕਿ ਪ੍ਰਮਾਣਿਕਤਾ ਅਜੇ ਅਜ਼ਮਾਈ ਨਹੀਂ ਗਈ।
ਇਹੀ ਫ਼ਰਕ ਪੂਰੀ ਸਮੱਸਿਆ ਹੈ। ਬਾਕੀ ਸਭ ਕੁਝ ਇਹ ਹੈ ਕਿ ਅਸੰਬੰਧਿਤ ਸੁਨੇਹਿਆਂ ਨੂੰ ਮਿਲਾਏ ਬਿਨਾਂ ਇਸ ਦਾ ਨਿਰੀਖਣ ਕਿਵੇਂ ਕਰੀਏ।
ਆਬਜੈਕਟ ਪੜ੍ਹੋ, ਕੰਸੋਲ ਦਾ ਸਾਰ ਨਹੀਂ
API ਨੂੰ ਸਿਰਫ਼ ਉਹ ਦੋ ਖੇਤਰ ਮੰਗੋ ਜੋ ਮਾਅਨੇ ਰੱਖਦੇ ਹਨ ਅਤੇ ਹੋਰ ਕੁਝ ਨਹੀਂ, ਤਾਂ ਜੋ ਜਵਾਬ ਰਾਤ ਤਿੰਨ ਵਜੇ ਪੜ੍ਹਨ ਜੋਗਾ ਛੋਟਾ ਰਹੇ: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". status ਖੇਤਰ ਜੀਵਨ-ਚੱਕਰ ਦੇ ਪੜਾਅ ਦਾ ਨਾਂ ਦੱਸਦਾ ਹੈ, ਅਤੇ detailedStatus ਉਸ ਨਾਲ ਜੁੜਿਆ ਪੜ੍ਹਨਯੋਗ ਕਾਰਨ ਲੈ ਕੇ ਚੱਲਦਾ ਹੈ। ਪੂਰਾ ਕਨਫਿਗਰੇਸ਼ਨ ਡੰਪ ਹੋਰ ਸਵਾਲਾਂ ਦਾ ਜਵਾਬ ਦਿੰਦਾ ਹੈ ਅਤੇ ਟਿਕਟ ਵਿੱਚ ਚਿੰਬੜਾਉਣਾ ਔਖਾ ਹੁੰਦਾ ਹੈ। ਅਜਿਹੀਆਂ ਸਿਰਫ਼-ਪੜ੍ਹਨ ਵਾਲੀਆਂ ਕਾਲਾਂ ਟਨਲ ਨਹੀਂ ਬਦਲ ਸਕਦੀਆਂ, ਜੋ ਘਟਨਾ ਦੇ ਅਜੇ ਸਰਗਰਮ ਰਹਿਣ ਤੱਕ ਮਹੱਤਵਪੂਰਨ ਹੈ।
ਕਾਲ ਦਾ ਟਾਈਮਸਟੈਂਪ ਮੁੱਲਾਂ ਦੇ ਕੋਲ ਦਰਜ ਕਰੋ, ਕਿਉਂਕਿ ਦੋਵੇਂ ਖੇਤਰ ਹਿਲਦੇ ਹਨ।
ALLOCATING_RESOURCES ਕੁੰਜੀ ਦੀ ਅਸੰਗਤੀ ਨਹੀਂ ਹੈ
ਜਦੋਂ ਟਨਲ ALLOCATING_RESOURCES ਦੱਸਦਾ ਹੈ, ਪ੍ਰਦਾਤਾ ਅਜੇ ਆਬਜੈਕਟ ਜੋੜ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਉਸ ਪੜਾਅ ਵਿੱਚ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਦੀ ਅਸੰਗਤੀ ਦੇਖੀ ਨਹੀਂ ਜਾ ਸਕਦੀ, ਅਤੇ ਰੋਕਿਆ ਹੋਇਆ ਪੀਅਰ ਪੋਰਟ ਵੀ ਉੱਨਾ ਹੀ ਅਪ੍ਰਮਾਣਿਤ ਹੈ। ਜੋ ਤੁਸੀਂ ਜਾਂਚ ਸਕਦੇ ਹੋ ਉਹ ਵਿਸਥਾਰਤ ਸੁਨੇਹਾ ਹੈ, ਕੀ ਪ੍ਰੋਜੈਕਟ ਅਤੇ ਸੇਵਾ ਸਿਹਤਮੰਦ ਦਿਖਦੇ ਹਨ, ਅਤੇ ਕੀ ਟਨਲ ਕਨਫਿਗਰੇਸ਼ਨ ਪੀਅਰ ਨਾਲ ਸੰਪਰਕ ਕਰਨ ਲਈ ਕਾਫ਼ੀ ਪੂਰੀ ਹੈ। ਹੁਣ ਭੇਤ ਬਦਲਣਾ ਉਹ ਮੁੱਲ ਬਦਲਦਾ ਹੈ ਜੋ ਕਦੇ ਪਰਖਿਆ ਨਹੀਂ ਗਿਆ।
ਕਨਫਿਗਰੇਸ਼ਨ ਬਾਰੇ ਸਿੱਟਾ ਕੱਢਣ ਤੋਂ ਪਹਿਲਾਂ ਸਥਿਤੀ ਦੇ ਬਦਲਣ ਦੀ ਉਡੀਕ ਕਰੋ।
ESTABLISHED ਪਹੁੰਚ ਜਾਂਚਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਹੈ
ਸਥਾਪਿਤ ਟਨਲ ਦਾ ਮਤਲਬ ਹੈ IKE ਪੂਰਾ ਹੋਇਆ, ਇਹ ਨਹੀਂ ਕਿ ਟ੍ਰੈਫਿਕ ਵਹਿ ਰਿਹਾ ਹੈ। ਟਨਲ ਵੱਲੋਂ ਲਿਜਾਏ ਜਾਂਦੇ ਰੂਟਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਅਤੇ ਜਿੱਥੇ Cloud Router ਸ਼ਾਮਲ ਹੈ, BGP ਸੈਸ਼ਨ ਅਤੇ ਇਸ ਵੱਲੋਂ ਸਿੱਖੇ ਪ੍ਰੀਫਿਕਸਾਂ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਫਿਰ ਮਨਜ਼ੂਰਸ਼ੁਦਾ ਐਪਲੀਕੇਸ਼ਨ ਅਦਲਾ-ਬਦਲੀ ਦੀ ਪਰਖ ਕਰੋ, ਕਿਉਂਕਿ ਫਾਇਰਵਾਲ ਨਿਯਮ ਜਾਂ ਗੁੰਮ ਰੂਟ ਪੂਰੀ ਤਰ੍ਹਾਂ ਸਿਹਤਮੰਦ ਟਨਲ ਰਾਹੀਂ ਟ੍ਰੈਫਿਕ ਰੋਕ ਸਕਦੇ ਹਨ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵੱਖਰਾ ਨਿਰੀਖਣ ਅਤੇ ਵੱਖਰਾ ਸੁਧਾਰ ਹੈ।
ਸਥਿਤੀ ਤੁਹਾਨੂੰ ਦੱਸਦੀ ਹੈ ਕਿ ਅੱਗੇ ਕਿਹੜਾ ਸਵਾਲ ਪੁੱਛਣਾ ਹੈ। ਇਹ ਕਦੇ ਵੀ ਤੁਹਾਡੀ ਥਾਂ ਪਹੁੰਚ ਦੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦੀ।
ਇੱਕ ਆਬਜੈਕਟ ਅਤੇ ਇੱਕ ਸਮਾਂ-ਵਿੰਡੋ ਨੂੰ ਸਹਿ-ਸੰਬੰਧਿਤ ਕਰੋ
ਲੌਗ ਵਿੱਚ ਪੁਰਾਣੀ ਪ੍ਰਮਾਣਿਕਤਾ ਅਸਫਲਤਾ ਪਿਛਲੀ ਕੋਸ਼ਿਸ਼ ਦੀ ਹੈ, ਜਦੋਂ ਤੱਕ ਇਸ ਦਾ ਟਾਈਮਸਟੈਂਪ ਤੁਹਾਡੇ ਜਾਂਚੇ ਜਾ ਰਹੇ ਵਿੰਡੋ ਦੇ ਅੰਦਰ ਨਾ ਆਵੇ। ਉਸੇ ਮਿੰਟਾਂ ਲਈ ਟਨਲ ਸਰੋਤ ਦੇ ਲੌਗ ਖਿੱਚੋ ਜਿਨ੍ਹਾਂ ਦੀ ਸਥਿਤੀ ਤੁਸੀਂ ਦਰਜ ਕੀਤੀ ਸੀ, ਅਤੇ ਪਛਾਣਕਰਤਿਆਂ ਨੂੰ ਇਕੱਠਾ ਰੱਖੋ। ਬਾਅਦ ਦੀ IKE ਘਟਨਾ ਦਿਖਾ ਸਕਦੀ ਹੈ ਕਿ ਗੱਲਬਾਤ ਸ਼ੁਰੂ ਹੋ ਗਈ ਹੈ, ਜਦੋਂ ਕਿ ਤੁਸੀਂ ਜਿਸ ਕੰਸੋਲ ਸੁਨੇਹੇ ਨੂੰ ਵੇਖ ਰਹੇ ਹੋ ਉਹ ਪਹਿਲਾਂ ਹੀ ਪੁਰਾਣਾ ਹੈ।
ਜੇ ਤੁਸੀਂ ਕੁਝ ਇਕੱਠਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਟਨਲ ਠੀਕ ਹੋ ਜਾਵੇ, ਤਾਂ ਇਹ ਦੱਸੋ। ਅਣ-ਨਿਰਧਾਰਿਤ ਕਾਰਨ ਅਸੰਬੰਧਿਤ ਲਾਈਨਾਂ ਨਾਲ ਬਣੀ ਭਰੋਸੇਮੰਦ ਕਹਾਣੀ ਨਾਲੋਂ ਵਧੀਆ ਰਿਕਾਰਡ ਹੈ।
ਅਗਲਾ ਕਦਮ ਹਮੇਸ਼ਾ ਇੱਕੋ ਆਕਾਰ ਦਾ ਹੁੰਦਾ ਹੈ: ਇੱਕ ਆਬਜੈਕਟ, ਇੱਕ ਵਿੰਡੋ, ਇੱਕ ਪੜਾਅ। ਇਸ ਤੋਂ ਚੌੜਾ ਜੋ ਵੀ ਹੈ ਉਹ ਸਾਰ ਹੈ, ਨਿਦਾਨ ਨਹੀਂ।