Azure S2S VPN ਜੁੜਿਆ ਹੈ ਪਰ ਟ੍ਰੈਫਿਕ ਨਹੀਂ: IKE ਲੌਗ ਪੜ੍ਹੋ

ਪੋਰਟਲ Connected ਕਹਿੰਦਾ ਹੈ, ਟਨਲ ਦਾ ਅਪਟਾਈਮ ਕਾਊਂਟਰ ਹੈ, ਅਤੇ ਤੁਹਾਡੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਤੋਂ ਆਇਆ trace ਦੂਜੇ ਹੌਪ ਉੱਤੇ ਮਰ ਜਾਂਦਾ ਹੈ। ਕਨੈਕਸ਼ਨ ਦੀ ਸਥਿਤੀ IKE ਅਤੇ IPsec ਗੱਲਬਾਤ ਦਾ ਵਰਣਨ ਕਰਦੀ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਕਿਸੇ ਵੀ ਪਾਸੇ ਇੱਕ ਪੈਕੇਟ ਨੀਤੀ ਪਰਤ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਇਹਨਾਂ ਟਿਕਟਾਂ ਵਿੱਚੋਂ ਬਹੁਤਿਆਂ ਦਾ ਕਾਰਨ ਦੋ ਗਲਤੀਆਂ ਹਨ ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ Azure ਰੂਟ ਬਦਲ ਕੇ ਠੀਕ ਨਹੀਂ ਹੁੰਦੀ। ਦੋਵੇਂ ਪਹਿਲਾਂ ਹੀ ਗੇਟਵੇ ਵੱਲੋਂ ਬਣਾਏ ਲੌਗ ਵਿੱਚ ਲਿਖੀਆਂ ਹੋਈਆਂ ਹਨ, ਇਸ ਲਈ ਮੈਂ ਰੂਟ ਟੇਬਲ ਵਿੱਚੋਂ ਨਹੀਂ, ਉੱਥੋਂ ਸ਼ੁਰੂ ਕਰਦਾ ਹਾਂ।

Connected ਅਸਲ ਵਿੱਚ ਕੀ ਪ੍ਰਮਾਣਿਤ ਕਰਦਾ ਹੈ

ਜੁੜਿਆ site-to-site ਕਨੈਕਸ਼ਨ ਦਾ ਅਰਥ ਹੈ ਕਿ ਪੜਾਅ 1 ਅਤੇ ਪੜਾਅ 2 ਪੂਰੇ ਹੋਏ ਅਤੇ ਸੁਰੱਖਿਆ ਐਸੋਸੀਏਸ਼ਨ ਸਰਗਰਮ ਹਨ। ਇਹ ਗੱਲਬਾਤ ਬਾਰੇ ਇੱਕ ਬਿਆਨ ਹੈ: ਦੋਵੇਂ ਪੀਅਰ ਇੱਕ ਪ੍ਰਸਤਾਵ ਉੱਤੇ ਸਹਿਮਤ ਹੋਏ, ਚਾਬੀਆਂ ਬਦਲੀਆਂ ਅਤੇ SA ਦੀ ਜੋੜੀ ਇੰਸਟਾਲ ਕੀਤੀ। ਇਹ ਨਹੀਂ ਦੱਸਦਾ ਕਿ ਟ੍ਰੈਫਿਕ ਚੋਣਕਾਰ ਉਹਨਾਂ ਸਬਨੈੱਟਾਂ ਨਾਲ ਮਿਲਦੇ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਸੁਰੱਖਿਅਤ ਮੰਨਦੇ ਹੋ, ਅਤੇ ਨਾ ਹੀ ਇਹ ਕਿ ਡੀਕ੍ਰਿਪਟ ਕਰਨ ਮਗਰੋਂ ਦੂਜਾ ਪਾਸਾ ਪੈਕੇਟ ਨੂੰ ਕਿਤੇ ਰੂਟ ਕਰੇਗਾ। ਟਨਲ ਹਫ਼ਤਿਆਂ ਤੱਕ ਚਾਲੂ ਰਹਿ ਸਕਦਾ ਹੈ ਜਦਕਿ ਹਰ ਦਿਲਚਸਪ ਫਲੋ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਇਹੀ ਉਹ ਪੈਟਰਨ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਸਿਹਤਮੰਦ ਗੇਟਵੇ ਦੁਬਾਰਾ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕਰਦਾ ਹੈ।

ਪਹਿਲਾਂ ਜਾਂਚਣ ਯੋਗ ਦੋ ਗਲਤੀਆਂ ਹਨ: ESP ਦੀ ਥਾਂ AH ਪ੍ਰਸਤਾਵਿਤ ਕਰਨ ਵਾਲਾ ਪੀਅਰ, ਅਤੇ ਉਸ ਥਾਂ ਵਿੱਚ ਨੰਬਰਿਤ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਜਿਸ ਨੂੰ ਗੇਟਵੇ ਅੰਦਰੂਨੀ ਨਹੀਂ ਮੰਨੇਗਾ।

ਰੂਟ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਐਕਸਪੋਰਟ ਕੀਤਾ ਲੌਗ ਖੋਲ੍ਹੋ

ਪੋਰਟਲ ਵਿੱਚ ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਗੇਟਵੇ ਖੋਲ੍ਹੋ ਅਤੇ ਕਨੈਕਸ਼ਨ ਉੱਤੇ VPN troubleshoot ਕਾਰਵਾਈ ਚਲਾਓ, ਫਿਰ ਬਣਨ ਵਾਲਾ ਬੰਡਲ ਡਾਊਨਲੋਡ ਕਰਕੇ ਖੋਲ੍ਹੋ। ਅੰਦਰ ਪੜਾਅ 1 ਅਤੇ ਪੜਾਅ 2 ਦੇ ਤਬਾਦਲਿਆਂ ਵਾਲਾ IKE ਲੌਗ ਹੈ, ਸਮਾਂ-ਮੋਹਰਾਂ ਨਾਲ ਅਤੇ ਸਾਦਾ ਟੈਕਸਟ ਵਜੋਂ ਪੜ੍ਹਨ ਯੋਗ। ਇਸ ਵਿੱਚ transform ਲਾਈਨ ਲੱਭੋ, ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਪੜ੍ਹਨ ਦੀ ਥਾਂ, ਕਿਉਂਕਿ ਦਿਲਚਸਪ ਐਂਟਰੀ ਆਮ ਤੌਰ ਉੱਤੇ ਕੁਝ ਸੌ ਲਾਈਨਾਂ ਅੰਦਰ ਹੁੰਦੀ ਹੈ। ਪੋਰਟਲ ਤੱਕ ਪਹੁੰਚ ਨਾ ਹੋਣ ਬਾਰੇ, ਡਾਇਗਨੋਸਟਿਕ ਸੈਟਿੰਗਾਂ ਚਾਲੂ ਹੋਣ ਉੱਤੇ ਉਹੀ ਡਾਇਗਨੋਸਟਿਕਸ ਗੇਟਵੇ ਦੇ ਲੌਗ ਮੰਜ਼ਿਲ ਵਿੱਚ ਦਿਖਦੇ ਹਨ।

ਦੋ ਐਂਟਰੀਆਂ ਸਭ ਤੋਂ ਵੱਧ ਮੁੱਲ ਰੱਖਦੀਆਂ ਹਨ। ਪਹਿਲੀ ਲਗਭਗ ਇਸ ਤਰ੍ਹਾਂ ਪੜ੍ਹੀ ਜਾਂਦੀ ਹੈ: expected ESP with combined authentication and cipher, received AH. ਦੂਜੀ IKE ਤਬਾਦਲੇ ਦੌਰਾਨ invalid payload ਗਲਤੀ ਹੈ, ਜਿਸਦਾ ਅਰਥ ਆਮ ਤੌਰ ਉੱਤੇ ਗਲਤ ਬਣਾਇਆ ਜਾਂ ਅਸਮਰਥਿਤ ਪ੍ਰਸਤਾਵ ਫੀਲਡ ਹੁੰਦਾ ਹੈ।

ਦੋਵੇਂ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਆਨ-ਪ੍ਰੀਮਾਈਜ਼ ਡਿਵਾਈਸ ਨੇ ਕੀ ਪ੍ਰਸਤਾਵਿਤ ਕੀਤਾ, ਇਸ ਲਈ ਦੋਵੇਂ ਪੀਅਰ ਪਾਸੇ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਹਨ। ਕਨੈਕਸ਼ਨ ਦਾ Azure ਪਾਸਾ ਦੁਬਾਰਾ ਬਣਾਉਣ ਨਾਲ ਤੁਹਾਡੇ ਫਾਇਰਵਾਲ ਵੱਲੋਂ ਭੇਜਿਆ ਪ੍ਰਸਤਾਵ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਫਿਰ ਵੀ ਇਹ ਕਰਨਾ ਇਸ ਕੰਮ ਵਿੱਚ ਸਭ ਤੋਂ ਵੱਧ ਬਰਬਾਦ ਹੋਣ ਵਾਲਾ ਘੰਟਾ ਹੈ। ਪੀਅਰ ਉੱਤੇ ਪੜਾਅ 2 ਨੂੰ ਸੰਯੁਕਤ ਪ੍ਰਮਾਣੀਕਰਨ ਅਤੇ ਸਾਈਫਰ ਨਾਲ ESP ਉੱਤੇ ਸੈੱਟ ਕਰੋ ਅਤੇ ਐਲਗੋਰਿਦਮ ਦੀ ਗੱਲਬਾਤ ਕਰਨ ਦਿਓ, ਫਿਰ ਜਾਂਚੋ ਕਿ combined mode ਵਰਗੇ ਨਾਂ ਵਾਲਾ ਵਿਕਰੇਤਾ ਚੈੱਕਬਾਕਸ ਹੇਠੋਂ ਚੁੱਪਚਾਪ AH ਪ੍ਰਸਤਾਵ ਚੁਣ ਰਿਹਾ ਹੈ ਜਾਂ ਨਹੀਂ।

ਵਰਚੁਅਲ ਨੈੱਟਵਰਕ ਦੀ ਪਤਾ-ਸਪੇਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚ ਪ੍ਰੀਫਿਕਸ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

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

ping ਨਹੀਂ, ਰਾਹ ਜਾਂਚੋ

ਕੰਮ ਕਰਦੇ ਟਨਲ ਨੂੰ ਕੰਮ ਕਰਦੇ ਰੂਟ ਤੋਂ ਵੱਖ ਕਰਨ ਵਾਲਾ trace ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਦਾ ਹੈ: ਪਹਿਲਾ ਹੌਪ ਆਨ-ਪ੍ਰੀਮਾਈਜ਼ ਗੇਟਵੇ, ਫਿਰ ਕੁਝ ਜਵਾਬ ਨਾ ਦੇਣ ਵਾਲੇ ਹੌਪ, ਫਿਰ ਦੂਰ ਦਾ ਹੋਸਟ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਜੇ trace ਕਦੇ ਹੋਸਟ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ, ਤਾਂ ਉਹ TCP ਪੋਰਟ ਜਾਂਚੋ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਅਸਲ ਵਿੱਚ ਵਰਤਦੀ ਹੈ, ਕਿਉਂਕਿ ICMP ਕਾਫ਼ੀ ਵਾਰ ਫਿਲਟਰ ਹੁੰਦਾ ਹੈ ਕਿ ਅਸਫਲ ping ਬਹੁਤ ਘੱਟ ਸਾਬਤ ਕਰਦਾ ਹੈ। ਉਹੀ trace ਦੂਰ ਦੇ ਹੋਸਟ ਤੋਂ Azure ਦੀ ਵਰਚੁਅਲ ਮਸ਼ੀਨ ਵੱਲ ਚਲਾਓ। ਦੋਵਾਂ ਨਤੀਜਿਆਂ ਵਿਚਕਾਰ ਅਸਮਮਿਤੀ ਹੀ ਗੁੰਮ ਵਾਪਸੀ ਰੂਟ ਜਾਂ ਸਿਰਫ਼ ਇੱਕ ਦਿਸ਼ਾ ਦੀ ਆਗਿਆ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਲੱਭਣ ਦਾ ਸਭ ਤੋਂ ਤੇਜ਼ ਤਰੀਕਾ ਹੈ।

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

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