Azure P2S: VNet ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਇੱਕ Windows ਕਲਾਇੰਟ ਦੇ ਰੂਟ ਗੁੰਮ

ਦੋ ਲੈਪਟਾਪ ਇੱਕੋ Azure point-to-site ਗੇਟਵੇ ਉੱਤੇ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦੇ ਹਨ, ਅਤੇ ਨਵੇਂ ਜੁੜੇ VNet ਤੱਕ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਪਹੁੰਚਦਾ ਹੈ। ਦੋਵੇਂ Connected ਦਿਖਾਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਪ੍ਰਮਾਣੀਕਰਨ ਫ਼ਰਕ ਨਹੀਂ ਹੈ; ਫ਼ਰਕ ਉਹ ਮੰਜ਼ਿਲ ਰੂਟ ਹਨ ਜੋ ਉਹ ਰੱਖਦੇ ਹਨ। ਜੋ ਕਲਾਇੰਟ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ, ਇੱਕ ਮੰਜ਼ਿਲ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਫਿਰ ਹੀ ਤੈਅ ਕਰੋ ਕਿ ਖਾਲੀ ਥਾਂ ਗੇਟਵੇ ਪੈਕੇਜ ਦੀ ਹੈ ਜਾਂ ਸਥਾਨਕ ਰੂਟ ਸਾਰਣੀ ਦੀ।

ਗੇਟਵੇ ਤੋਂ ਨਹੀਂ, ਜੋ ਕਲਾਇੰਟ ਅਸਫਲ ਹੁੰਦਾ ਹੈ ਉਸ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

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

route print ਨਾਲ ਇੱਕ ਮੰਜ਼ਿਲ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

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

ਟਕਰਾਉ ਵਾਲਾ ਸਥਾਨਕ ਪ੍ਰੀਫਿਕਸ ਵੀ ਉਹੀ ਲੱਛਣ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਕੁਝ ਵੀ ਸ਼ਾਮਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਤੈਅ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਵਿੱਚੋਂ ਕਿਹੜੀ ਹਾਲਤ ਹੈ: ਟਨਲ ਰੂਟ ਬਿਲਕੁਲ ਨਹੀਂ, ਜਾਂ ਟਨਲ ਰੂਟ ਵਧੇਰੇ ਖਾਸ ਰੂਟ ਤੋਂ ਹਾਰਦਾ ਹੈ।

TTL expired ਰੂਟ ਵੰਡ ਦਾ ਬੱਗ ਨਹੀਂ

TTL expired in transit ਵਾਪਸ ਕਰਨ ਵਾਲਾ ping ਕਹਿੰਦਾ ਹੈ ਕਿ ਪੈਕੇਟ ਨੇ ਆਪਣਾ ਹੌਪ ਕੋਟਾ ਖ਼ਤਮ ਕਰ ਦਿੱਤਾ, ਜਿਸ ਦਾ ਆਮ ਅਰਥ ਫਾਰਵਰਡਿੰਗ ਲੂਪ ਹੈ, ਟੁੱਟਿਆ VPN ਡਰਾਈਵਰ ਨਹੀਂ। Windows ping 255 ਤੱਕ TTL ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ, ਅਤੇ ਮੁੱਲ ਵਧਾਉਣ ਨਾਲ ਲੂਪ ਠੀਕ ਨਹੀਂ ਹੁੰਦਾ; ਇਹ ਸਿਰਫ਼ ਉਹੀ ਗਲਤੀ ਦੇਰ ਕਰਦਾ ਹੈ। ਸੁਨੇਹੇ ਨੂੰ ਮਾਰਗ ਦਾ ਲੱਛਣ ਮੰਨੋ, ਰੂਟ ਵੰਡ ਦਾ ਸਬੂਤ ਨਹੀਂ।

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

ਪੈਕੇਜ ਉਸੇ ਗੇਟਵੇ ਉੱਤੇ ਮੁੜ ਬਣਾਓ ਜੋ ਇਸ ਦਾ ਮਾਲਕ ਹੈ

Microsoft ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਕਿ ਸੰਬੰਧਿਤ ਟੋਪੋਲੋਜੀ ਬਦਲਾਵਾਂ ਤੋਂ ਬਾਅਦ Windows ਕਲਾਇੰਟ ਪੈਕੇਜ ਮੁੜ ਡਾਊਨਲੋਡ ਅਤੇ ਸਥਾਪਤ ਕਰਨੇ ਪੈਂਦੇ ਹਨ। ਇਸ ਪ੍ਰੋਫ਼ਾਈਲ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ Azure ਗੇਟਵੇ ਤੋਂ ਮੌਜੂਦਾ ਪੈਕੇਜ ਲਵੋ, ਫਿਰ ਉਸ ਕਲਾਇੰਟ ਲਈ ਸਮਰਥਿਤ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਲਾਗੂ ਕਰੋ। ਅਸੰਬੰਧਿਤ VPN ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਫ਼ਾਈਲ ਬਦਲਣਾ ਗੇਟਵੇ-ਖਾਸ ਸੈਟਿੰਗਾਂ ਮੁੜ ਬਣਾਉਣ ਵਰਗਾ ਕੰਮ ਨਹੀਂ ਹੈ। ਪੈਕੇਜ ਮੁੜ ਡਾਊਨਲੋਡ ਕਰਨਾ ਸਸਤਾ ਹੈ; ਸਥਾਨਕ ਰੂਟਾਂ ਦਾ ਅੰਦਾਜ਼ਾ ਲਾਉਣਾ ਨਹੀਂ।

ਮੁੜ ਕਨੈਕਟ ਕਰੋ ਅਤੇ ਮੂਲ ਮੰਜ਼ਿਲ ਦਾ ਰੂਟ ਮੁੜ ਪੜ੍ਹੋ। ਬਦਲਾਅ ਦੇ ਰਿਕਾਰਡ ਨਾਲ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਦੀਆਂ ਕਤਾਰਾਂ ਰੱਖੋ, ਤਾਂ ਜੋ ਨਤੀਜਾ ਮੈਂ ਕਲਾਇੰਟ ਮੁੜ ਸਥਾਪਤ ਕੀਤਾ ਨਾਲੋਂ ਵਧੇਰੇ ਸਹੀ ਹੋਵੇ।

Azure P2S ਰੂਟਿੰਗ ਸਥਿਤੀਆਂ ਸਿੱਧੇ ਪੀਅਰ ਕੀਤੇ VNet ਨੂੰ ਹੋਰ ਟਨਲਾਂ ਰਾਹੀਂ ਪਹੁੰਚਣ ਵਾਲੇ ਨੈੱਟਵਰਕਾਂ ਤੋਂ ਵੱਖ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਨਵਾਂ ਪੈਕੇਜ ਪੀਅਰਿੰਗ ਨੂੰ ਪਾਰਗਾਮੀ ਨਹੀਂ ਬਣਾ ਸਕਦਾ। ਕੁਝ Windows site-to-site ਜਾਂ BGP ਸਥਿਤੀਆਂ ਲਈ ਹੱਥੀਂ ਸੰਰਚਿਤ ਦੂਰਸਥ ਰੂਟ ਵੀ ਚਾਹੀਦੇ ਹਨ, ਇਸ ਲਈ ਪੈਕੇਜ ਰਿਫ਼੍ਰੈਸ਼ ਸਰਵਵਿਆਪੀ ਰੂਟ ਵੰਡ ਵਿਧੀ ਨਹੀਂ ਹੈ।

ਅਸਥਾਈ ਰੂਟ ਅਸਥਾਈ ਰੱਖੋ

ਹੱਥੀਂ ਬਣਾਇਆ ਰੂਟ ਗੁੰਮ ਕਲਾਇੰਟ ਰੂਟ ਨੂੰ ਅਲੱਗ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਸ ਨੂੰ ਅਸਲ ਡਿਜ਼ਾਈਨ ਤੋਂ ਬਣਾਓ: route add 10.24.0.0 mask 255.255.0.0 172.16.0.1 if 42, ਪੱਕੇ ਫ਼ਲੈਗ ਤੋਂ ਬਿਨਾਂ, ਤਾਂ ਜੋ ਰੀਬੂਟ ਉੱਤੇ ਇਹ ਗਾਇਬ ਹੋ ਜਾਵੇ। ਇੰਟਰਫੇਸ ਇੰਡੈਕਸ ਅਤੇ ਅਗਲਾ ਹੌਪ ਜੁੜੇ VPN ਅਡਾਪਟਰ ਤੋਂ ਚੁਣੋ, ਅੰਦਾਜ਼ੇ ਤੋਂ ਨਹੀਂ।

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

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