Google Cloud HA VPN ਤੋਂ ਆਉਣ ਵਾਲਾ AUTHENTICATION_FAILED ਆਮ ਤੌਰ 'ਤੇ ਲੋਕਾਂ ਨੂੰ ਪਹਿਲਾਂ ਸਾਂਝੀ ਕੀਤੀ ਕੁੰਜੀ ਵੱਲ ਵਾਪਸ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਕੁੰਜੀ ਆਮ ਤੌਰ 'ਤੇ ਸਹੀ ਹੁੰਦੀ ਹੈ। ਸੁਰੰਗ 1 ਪੜਾਅ 'ਤੇ ਰੁਕ ਜਾਂਦੀ ਹੈ ਕਿਉਂਕਿ Google ਕੁਝ ਹੋਰ ਵੀ ਤੁਲਦਾ ਹੈ: IKE ਅਦਾਨ-ਪ੍ਰਦਾਨ ਵੇਲੇ ਸਾਥੀ ਜਿਸ ਪਹਿਚਾਣ ਦਾ ਦਾਅਵਾ ਕਰਦਾ ਹੈ। FortiGate 'ਤੇ ਉਹ ਪਹਿਚਾਣ ਬਿਨਾਂ ਕਿਸੇ ਦੇ ਪਤਾ ਬਦਲੇ ਕਿਸਮ ਬਦਲ ਸਕਦੀ ਹੈ। ਕੁੰਜੀ ਦੋ ਵਾਰ ਦੁਬਾਰਾ ਭਰਨ ਤੋਂ ਬਾਅਦ ਲਾਗ ਨੂੰ ਪਹਿਚਾਣ ਦੀ ਅਸੰਗਤੀ ਵਜੋਂ ਪੜ੍ਹੋ।

ਇੱਕ ਫੇਲ੍ਹਤਾ, ਦੋ ਜਾਂਚਾਂ

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

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

FortiGate ਪਹਿਚਾਣ ਦੇ ਪੇਲੋਡ ਵਿੱਚ ਕੀ ਰੱਖਦਾ ਹੈ

ਮੁਸ਼ਕਲ ਤਦ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਕੋਈ ਸਥਾਨਕ ID ਸੈੱਟ ਕਰਦਾ ਹੈ ਤਾਂ ਜੋ ਦੋਵੇਂ ਧਿਰਾਂ ਸਹਿਮਤ ਹੋਣ। ਹਾਲੀਆ FortiOS ਬਿਲਡ ਉਸ ਪਹਿਚਾਣ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਯੋਗ ਡੋਮੇਨ ਨਾਮ ਵਜੋਂ ਚਿੰਨ੍ਹਿਤ ਕਰਦੇ ਹਨ, ਭਾਵੇਂ ਭਰੀ ਗਈ ਕੀਮਤ ਬਿੰਦੂਆਂ ਵਾਲਾ ਪਤਾ ਹੋਵੇ। ਇਸ ਲਈ Google ਪਤੇ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹੋਏ FQDN ਪਹਿਚਾਣ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, ਅਤੇ ਸੈਸ਼ਨ ਅਸਵੀਕਾਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਸੁਨੇਹੇ ਵਿੱਚ ਕੋਈ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਕਿਹੜਾ ਅੱਧ ਫੇਲ੍ਹ ਹੋਇਆ, ਇਸ ਲਈ ਰਿਪੋਰਟ ਪਰਮਾਣੀਕਰਨ ਫੇਲ੍ਹਤਾ ਵਜੋਂ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ।

IKE ਡੀਬੱਗਿੰਗ ਚਾਲੂ ਕਰਕੇ ਇਸਨੂੰ ਇੱਕ ਵਾਰ ਦੁਬਾਰਾ ਪੈਦਾ ਕਰੋ ਅਤੇ ਉਹ ਪਹਿਚਾਣ ਪੇਲੋਡ ਪੜ੍ਹੋ ਜੋ ਫਾਇਰਵਾਲ ਅਸਲ ਵਿੱਚ ਭੇਜਦਾ ਹੈ।

ਉਸੇ ਦੌਰ ਵਿੱਚ ਤਿੰਨ ਸਸਤੇ ਤੱਥ ਪੱਕੇ ਕਰੋ: ਦੋਵੇਂ ਸਿਰਿਆਂ ਦਾ IKE ਸੰਸਕਰਣ, ਨਾ ਦਿਸਣ ਵਾਲੇ ਆਖਰੀ ਅੱਖਰਾਂ ਸਮੇਤ ਸਹੀ ਕੁੰਜੀ, ਅਤੇ ਉਹ ਸਾਥੀ-ਪਤਾ ਜਿਸਦੀ Google ਉਮੀਦ ਕਰਦਾ ਹੈ। ਇਹ ਵੱਖਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਮਿਲਦੀ ਕੁੰਜੀ ਪਹਿਚਾਣ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦੀ।

ਵਿਕਲਪ, ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਲਾਗਤ

ਹਰ ਨਿਕਾਸ ਵੱਖਰੀ ਪਰਤ ਠੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਹਰ ਤੈਨਾਤੀ ਲਈ ਉਪਲਬਧ ਨਹੀਂ।

OptionWhen it worksWhat it costs
Set an address identity on the firewallYour firmware lets you choose the typeBehaviour you must retest per release
Put a public address on the negotiating interfaceThe firewall can hold a routable addressNot possible behind NAT
Terminate on a peer that accepts your identityAnother endpoint validates what you produceA topology change

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

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

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

ਜਦੋਂ NAT ਇੱਕ ਵਿਕਲਪ ਹਟਾ ਦਿੰਦਾ ਹੈ

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

ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੁਝ ਵੀ ਵਿਆਖਿਆ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ Google ਪਾਸੇ ਸੁਰੰਗ ਦੀ ਹਾਲਤ ਅਤੇ ਇਹ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ IKE ਰਸਤੇ ਵਿੱਚ ਸਿਰਫ਼ ਸੁੱਟਿਆ ਨਹੀਂ ਜਾ ਰਿਹਾ। ਸੁੱਟਿਆ ਪੈਕਟ ਸਮਾਂ ਖ਼ਤਮ ਹੋ ਕੇ ਰੁਕਦਾ ਹੈ; ਇਹ ਅਸਵੀਕਾਰ ਪੈਦਾ ਨਹੀਂ ਕਰਦਾ।

ਜਦੋਂ ਤੱਕ ਇਹ ਚੱਲਦਾ ਹੈ ਕੀ ਦਰਜ ਕਰਨਾ

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

ਉਹ ਰਿਕਾਰਡ ਹੀ ਅਗਲੇ ਅੱਪਗ੍ਰੇਡ ਤੋਂ ਬਾਅਦ ਵੀ ਹੱਲ ਦੀ ਲੋੜ ਹੈ ਜਾਂ ਨਹੀਂ, ਇਹ ਜਾਣਨ ਦਾ ਇੱਕੋ ਤਰੀਕਾ ਹੈ।

ਸੰਬੰਧਿਤ ਲੇਖ