VPN ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਬਾਅਦ Azure VM IMDS ਜਾਂ WireServer ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ

VM ਚੱਲ ਰਿਹਾ ਹੈ, VPN ਕਲਾਇੰਟ ਕਹਿੰਦਾ ਹੈ ਕਿ ਕਨੈਕਟ ਹੈ, ਅਤੇ ਕੁਝ ਮਿੰਟਾਂ ਬਾਅਦ Azure ਏਜੰਟ ਅਸਿਹਤ ਹਾਲਤ ਦੀ ਰਿਪੋਰਟ ਕਰਨ ਲੱਗਦਾ ਹੈ। ਕਦੇ SSH ਬਚਿਆ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਪੋਰਟਲ ਦਾ Run Command ਨਹੀਂ, ਜਿਸ ਕਰਕੇ ਲੋਕ ਰੂਟ ਟੇਬਲ ਦੀ ਥਾਂ ਏਜੰਟ ਵੱਲ ਦੇਖਦੇ ਹਨ। ਟਨਲ ਉੱਪਰ ਆਉਣ ਸਮੇਂ ਮਹਿਮਾਨ ਦੇ ਆਪਣੇ ਫਾਰਵਰਡਿੰਗ ਫੈਸਲੇ ਬਦਲ ਗਏ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਦੋ ਪਲੇਟਫਾਰਮ ਪਤੇ ਪਹਿਲੇ ਸ਼ਿਕਾਰ ਹੁੰਦੇ ਹਨ। ਮੈਂ ਇਸਨੂੰ ਏਜੰਟ ਫੇਲ ਹੋਣਾ ਮੰਨਣ ਤੋਂ ਪਹਿਲਾਂ ਰਾਊਟਿੰਗ ਲੱਛਣ ਮੰਨਦਾ ਹਾਂ।

ਲੱਛਣ ਟੁੱਟੇ ਏਜੰਟ ਵਰਗਾ ਦਿਸਦਾ ਹੈ

ਹੇਠਾਂ ਦਿੱਤੇ ਦੋਵੇਂ ਪਤੇ ਹੱਲ ਵਜੋਂ ਸੁਝਾਏ ਜਾਂਦੇ ਹਨ, ਪਰ ਇਹ ਇੱਕੋ ਸੇਵਾ ਨਹੀਂ। ਇੱਕ ਲਈ /32 ਕਾਪੀ ਕਰਨਾ ਕਿਉਂਕਿ ਉਹ ਦੂਜੇ ਲਈ ਕੰਮ ਕਰ ਗਿਆ—ਇਸੇ ਤਰ੍ਹਾਂ ਅਸਥਾਈ ਉਪਾਅ ਉਹ ਸਥਾਈ ਕਨਫਿਗਰੇਸ਼ਨ ਬਣ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ ਹਟਾਉਣ ਦੀ ਕਿਸੇ ਦੀ ਹਿੰਮਤ ਨਹੀਂ ਹੁੰਦੀ।

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

168.63.129.16 ਜਨਤਕ ਮੰਜ਼ਿਲ ਨਹੀਂ ਹੈ

168.63.129.16 Azure ਦਾ ਵਿਸ਼ੇਸ਼ ਵਰਚੁਅਲ ਪਲੇਟਫਾਰਮ ਪਤਾ ਹੈ, ਅਤੇ ਇਸਦੀ ਇੱਕ ਭੂਮਿਕਾ WireServer ਹੈ, ਜੋ VM ਏਜੰਟ ਫੈਬਰਿਕ ਨਾਲ ਗੱਲ ਕਰਨ ਲਈ ਵਰਤਦਾ ਹੈ। Microsoft ਦਸਤਾਵੇਜ਼ ਕਰਦਾ ਹੈ ਕਿ ਏਜੰਟ ਦਾ TCP ਪੋਰਟ 80 ਅਤੇ 32526 ਵੱਲ ਟ੍ਰੈਫਿਕ ਉਪਲਬਧ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਆਮ ਇੰਟਰਨੈਟ ਹੋਸਟ ਨਹੀਂ ਹੈ, ਅਤੇ ਪੂਰੀ-ਟਨਲ VPN ਨੂੰ ਇਸਨੂੰ ਦੂਰ ਦੇ ਨਿਕਾਸ ਤੱਕ ਨਹੀਂ ਲਿਜਾਣਾ ਚਾਹੀਦਾ। ਇਸੇ ਲਈ ਸਿਹਤਮੰਦ ਦਿਸਦਾ ਟਨਲ ਵੀ ਏਜੰਟ ਨੂੰ ਭੁੱਖਾ ਰੱਖ ਸਕਦਾ ਹੈ।

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

ਜੇ ਏਜੰਟ ਹੀ ਸਮੱਸਿਆ ਦੀ ਰਿਪੋਰਟ ਕਰ ਰਿਹਾ ਹੈ, ਤਾਂ ਕੁਝ ਵੀ ਦੁਬਾਰਾ ਇੰਸਟਾਲ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸੇਵਾ ਦੀ ਸਥਿਤੀ ਅਤੇ ਉਸ ਪਤੇ ਤੱਕ ਦਾ ਰਾਹ ਜਾਂਚੋ।

169.254.169.254 ਦੇ ਆਪਣੇ ਨਿਯਮ ਹਨ

169.254.169.254 Azure Instance Metadata Service ਦਾ link-local ਪਤਾ ਹੈ। ਇਸ ਵੱਲ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀਆਂ ਆਪਣੀਆਂ ਸ਼ਰਤਾਂ ਹਨ: ਪ੍ਰਾਇਮਰੀ NIC ਅਤੇ ਪ੍ਰਾਇਮਰੀ IP, ਪਤੇ ਦਾ ਸਮਰਥਨ ਕਰਨ ਵਾਲੀ DHCP ਕਨਫਿਗਰੇਸ਼ਨ, ਅਤੇ ਕਿਸੇ ਵੀ HTTP ਪ੍ਰਾਕਸੀ ਨੂੰ ਬਾਈਪਾਸ ਕਰਨਾ। ਇਹਨਾਂ ਨੂੰ ਦੂਰ ਦੇ VPN ਨਿਕਾਸ ਜਾਂ ਮਨਮਾਨੇ ਇੰਟਰਨੈਟ ਗੇਟਵੇ ਰਾਹੀਂ ਭੇਜਣਾ ਉਹ ਪਹੁੰਚ ਮਾਡਲ ਨਹੀਂ ਜੋ Microsoft ਦੱਸਦਾ ਹੈ।

ਉਹ ਪ੍ਰਾਕਸੀ ਸ਼ਰਤ ਉਹਨਾਂ ਨੂੰ ਫੜਦੀ ਹੈ ਜਿਨ੍ਹਾਂ ਨੇ ਰਾਹ ਠੀਕ ਕੀਤਾ ਅਤੇ ਫਿਰ ਵੀ ਫੇਲ੍ਹ ਦੇਖਦੇ ਹਨ। ਮਹਿਮਾਨ HTTP ਪ੍ਰਾਕਸੀ IMDS ਤੋੜ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ip route get ਠੀਕ ਉਹੀ ਇੰਟਰਫੇਸ ਦਿੰਦਾ ਹੈ ਜਿਸਦੀ ਤੁਸੀਂ ਉਮੀਦ ਕਰਦੇ ਹੋ, ਇਸ ਲਈ ਰਾਹਾਂ ਦੇ ਨਾਲ ਪ੍ਰਾਕਸੀ ਅਪਵਾਦ ਵੀ ਜਾਂਚੋ।

ਇਸਨੂੰ ਡੀਬੱਗ ਕਰਦਿਆਂ ਮੈਟਾਡੇਟਾ ਜਵਾਬ ਸਪੋਰਟ ਟਿਕਟ ਵਿੱਚ ਪੇਸਟ ਨਾ ਕਰੋ। ਉਹਨਾਂ ਵਿੱਚ ਘਟਨਾ ਤੋਂ ਵੱਧ ਚੱਲਣ ਵਾਲੇ ਪ੍ਰਮਾਣ ਪੱਤਰ ਅਤੇ ਇੰਸਟੈਂਸ ਵੇਰਵੇ ਹੋ ਸਕਦੇ ਹਨ।

ਮਹਿਮਾਨ ਦੀ ਨੀਤੀ ਰਾਊਟਿੰਗ ਪੜ੍ਹੋ, ਸਿਰਫ ਮੁੱਖ ਟੇਬਲ ਨਹੀਂ

Linux ਮਹਿਮਾਨ 'ਤੇ ਤਿੰਨ ਸਿਰਫ-ਪੜ੍ਹਨ ਵਾਲੇ ਕਮਾਂਡ ਪਰਤਾਂ ਨੂੰ ਵੱਖ ਕਰਦੇ ਹਨ: ਨੀਤੀ ਨਿਯਮਾਂ ਲਈ ip -4 rule show, ਫਿਰ ਕਰਨਲ ਜੋ ਫੈਸਲੇ ਅਸਲ ਵਿੱਚ ਲੈਂਦਾ ਹੈ ਉਹਨਾਂ ਲਈ ip -4 route get 168.63.129.16 ਅਤੇ ip -4 route get 169.254.169.254। ਇਹਨਾਂ ਨੂੰ VPN ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਬਾਅਦ ਚਲਾਓ। ਉਹਨਾਂ ਦੋਵਾਂ ਆਉਟਪੁੱਟਾਂ ਦਾ ਫਰਕ ਤੁਹਾਡਾ ਤਬਦੀਲੀ-ਸੈੱਟ ਹੈ, ਅਤੇ ਕਲਾਇੰਟ ਨੇ ਕੀ ਕੀਤਾ ਇਸ ਬਾਰੇ ਕਿਸੇ ਵੀ ਅੰਦਾਜ਼ੇ ਨਾਲੋਂ ਵੱਧ ਲਾਭਦਾਇਕ ਹੈ।

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

ਪੁਰਾਣੇ ਗੇਟਵੇ ਰਾਹੀਂ ਦੋਵੇਂ /32 ਰੂਟ ਜੋੜਨ ਵਾਲੀ ਵਿਧੀ ਦਾ ਵਿਰੋਧ ਕਰੋ। link-local ਪਲੇਟਫਾਰਮ ਰਾਹ ਅਤੇ ਆਮ WAN ਅਗਲਾ ਹੌਪ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ, ਅਤੇ ਸਰਵਵਿਆਪੀ ਅਪਵਾਦ ਅਸਲ ਨੀਤੀ ਟਕਰਾਅ ਲੁਕਾਉਂਦਾ ਹੈ।

ਪ੍ਰਸ਼ਾਸਨ ਅਤੇ ਰਿਕਵਰੀ ਵੱਖ ਰੱਖੋ

ਤੁਹਾਡਾ SSH ਜਾਂ RDP ਜਵਾਬ ਵੀ ਪੂਰੀ-ਟਨਲ ਡਿਫਾਲਟ ਦੁਆਰਾ ਫੜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਪਲੇਟਫਾਰਮ ਐਂਡਪੌਇੰਟ ਦੀ ਥਾਂ ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਦੇਖੇ ਗਏ ਪਤੇ ਨੂੰ ਨਿਸ਼ਾਨਾ ਬਣਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਇਸਦੀ ਆਪਣੀ ਬੇਨਤੀ-ਜਵਾਬ ਜੋੜੀ ਤੋਂ ਨਿਦਾਨ ਕਰੋ, ਅਤੇ VPN ਨੀਤੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਸੀਰੀਅਲ ਕੰਸੋਲ ਵਰਗਾ ਸੁਤੰਤਰ ਰਿਕਵਰੀ ਚੈਨਲ ਰੱਖੋ। ਜੇ ਤੈਨਾਤੀ VM ਨੂੰ ਦੁਬਾਰਾ ਚਾਲੂ ਕਰਦੀ ਹੈ ਅਤੇ ਏਜੰਟ ਅਸਿਹਤਤਾ ਦੱਸਦਾ ਹੈ, ਤਾਂ ਰਾਹ ਬਦਲਾਅ ਨੇ ਰੀਬੂਟ ਕੀਤਾ ਮੰਨਣ ਦੀ ਥਾਂ ਦਰਜ ਕੀਤੀ ਕਾਰਵਾਈ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਸੇਵਾ ਜਾਂਚੋ।

ਫਿਰ ਤਿੰਨ ਪ੍ਰਵਾਹ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਜਾਂਚੋ: ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਜੋ ਨਿੱਜੀ ਸਰੋਤ ਚਾਹੁੰਦੇ ਸੀ, ਸਮਰਥਿਤ ਏਜੰਟ ਅਤੇ ਪਲੇਟਫਾਰਮ ਸੰਚਾਰ, ਅਤੇ ਪ੍ਰਸ਼ਾਸਨੀ ਰਾਹ। ਇੱਕ ਨੂੰ ਬਹਾਲ ਕਰਨਾ ਬਾਕੀ ਦੋ ਬਚੇ ਹੋਣ ਦਾ ਸਬੂਤ ਨਹੀਂ।

ਮਨਜ਼ੂਰ ਅਪਵਾਦ ਮਹਿਮਾਨ ਨੈੱਟਵਰਕ ਅਤੇ VPN ਕਨਫਿਗਰੇਸ਼ਨ ਦੇ ਮਾਲਕ ਦੇ ਨਾਮ ਹੇਠ ਲਿਖੋ, ਜਿਸ ਵਿੱਚ ਦੁਬਾਰਾ ਜੁੜਨ ਅਤੇ ਦੁਬਾਰਾ ਚਾਲੂ ਹੋਣ 'ਤੇ ਕੀ ਹੁੰਦਾ ਹੈ ਸ਼ਾਮਲ ਹੈ। Azure UDR ਮਹਿਮਾਨ ਦੀ ਰੂਟ ਟੇਬਲ ਨਹੀਂ ਹਨ, ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਸੋਧਣ ਨਾਲ ਸਥਾਨਕ ਨੀਤੀ ਨਿਯਮ ਠੀਕ ਨਹੀਂ ਹੋਵੇਗਾ।