Linux EHOSTUNREACH OpenVPN ਨਾਲ: ਕਿਹੜਾ ਅਗਲਾ ਹੌਪ ਫੇਲ੍ਹ ਹੋਇਆ?

EHOSTUNREACH ਦੂਰਲੀ ਅਸਫਲਤਾ ਜਿੰਨਾ ਹੀ ਅਕਸਰ ਸਥਾਨਕ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ। ਕਰਨਲ ਪੈਕੇਟ ਨੂੰ ਰੱਦ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਰੂਟ ਕਹਿੰਦਾ ਹੈ ਕਿ ਮੰਜ਼ਿਲ ਅਪਹੁੰਚ ਹੈ, ਕਿਉਂਕਿ Ethernet ਦਾ ਅਗਲਾ ਹੌਪ ਕਦੇ ਜਵਾਬ ਨਹੀਂ ਦਿੱਤਾ, ਜਾਂ ਕਿਉਂਕਿ ਰਾਹ ਦੇ ਹੋਰ ਅੱਗੇ ਤੋਂ ICMP host-unreachable ਰਿਪੋਰਟ ਆਈ। ਹਰ ਸਰੋਤ ਵੱਖਰੀ ਸਾਰਣੀ ਜਾਂ ਕੈਸ਼ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਵੱਖਰੀ ਥਾਂ ਤੇ ਠੀਕ ਹੁੰਦਾ ਹੈ। ਸਾਈਫਰ ਛੂਹਣ ਜਾਂ ਟਨਲ ਮੁੜ ਸਥਾਪਿਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚੁਣਿਆ ਰੂਟ ਅਤੇ ਅਗਲੇ ਹੌਪ ਦੀ ਸਥਿਤੀ ਪੜ੍ਹੋ।

ਉਹ ਪਤਾ ਅਤੇ ਨੇਮਸਪੇਸ ਚੁਣੋ ਜੋ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਵਰਤਦਾ ਹੈ

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

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

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

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

ਸਪਸ਼ਟ ਅਪਹੁੰਚ ਰੂਟ ਪੈਕੇਟ ਨੂੰ ਸਥਾਨਕ ਤੌਰ ਤੇ ਰੱਦ ਕਰਦਾ ਹੈ

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

ਰੂਟ ਦੀਆਂ ਕਿਸਮਾਂ ਆਪਸ ਵਿੱਚ ਬਦਲੀਆਂ ਨਹੀਂ ਜਾ ਸਕਦੀਆਂ। Blackhole ਭੇਜਣ ਵਾਲੇ ਨੂੰ ਗਲਤੀ ਦਿੱਤੇ ਬਿਨਾਂ ਪੈਕੇਟ ਸੁੱਟਦਾ ਹੈ, prohibit EACCES ਵਾਪਸ ਦਿੰਦਾ ਹੈ, ਅਤੇ unreachable EHOSTUNREACH ਵਾਪਸ ਦਿੰਦਾ ਹੈ। ਇਸ ਲਈ ਮੁੜ-ਕਨੈਕਸ਼ਨ ਦੌਰਾਨ ਸਿੰਕ ਰੂਟ ਸਥਾਪਿਤ ਕਰਨ ਵਾਲਾ VPN ਸਹਾਇਕ host-unreachable ਗਲਤੀਆਂ ਦੀ ਬੌਛਾਰ ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ ਜੋ ਟਨਲ ਚੜ੍ਹਦਿਆਂ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦੀ ਹੈ, ਜਦੋਂ ਕਿ blackhole ਰੂਟ ਇਸਦੀ ਥਾਂ ਚੁੱਪ ਸਮਾਂ-ਸਮਾਂਤਰ ਪੈਦਾ ਕਰਦਾ।

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

ਮਰਿਆ ਗੁਆਂਢੀ Ethernet ਤੇ ਉਹੀ ਗਲਤੀ ਪੈਦਾ ਕਰਦਾ ਹੈ

ਜਦੋਂ ਚੁਣਿਆ ਰੂਟ ਆਨ-ਲਿੰਕ ਗੇਟਵੇ ਵਰਤਦਾ ਹੈ, ਤਾਂ ਡਿਲਿਵਰੀ ਲਈ ਹੱਲ ਕੀਤਾ ਲਿੰਕ-ਲੇਅਰ ਪਤਾ ਚਾਹੀਦਾ ਹੈ। ਕਰਨਲ ARP ਜਾਂ IPv6 ਗੁਆਂਢੀ ਬੇਨਤੀ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਜੇ ਜਵਾਬ ਨਾ ਆਵੇ ਤਾਂ ਪੈਕੇਟ ਫ੍ਰੇਮ ਨਹੀਂ ਹੋ ਸਕਦਾ। ਫਿਰ ਭੇਜਣਾ EHOSTUNREACH ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ ਭਾਵੇਂ ਰੂਟ ਆਪਣੇ ਆਪ ਵੈਧ ਹੈ।

ਗੁਆਂਢੀ ਸਾਰਣੀ ਪੜਾਅ ਦਾ ਨਾਂ ਦਿੰਦੀ ਹੈ। INCOMPLETE ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਹੱਲ ਅਜੇ ਚੱਲ ਰਿਹਾ ਹੈ, FAILED ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਆਖਰੀ ਕੋਸ਼ਿਸ਼ ਨੂੰ ਜਵਾਬ ਨਹੀਂ ਮਿਲਿਆ, ਅਤੇ REACHABLE ਜਾਂ STALE ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕਰਨਲ ਕੋਲ ਵਰਤੋਂਯੋਗ ਪਤਾ ਹੈ। VPN ਗੇਟਵੇ ਲਈ FAILED ਐਂਟਰੀ ਸਥਾਨਕ ਡਿਲਿਵਰੀ ਸਮੱਸਿਆ ਹੈ, ਟਨਲ ਦੇ ਦੂਰਲੇ ਪਾਸੇ ਬਾਰੇ ਸਬੂਤ ਨਹੀਂ।

ਐਂਟਰੀ ਅਸਲ ਅਗਲੇ ਹੌਪ ਲਈ ਪੜ੍ਹੋ, ਦੂਰਲੇ ਇੰਟਰਨੈੱਟ ਪਤੇ ਲਈ ਨਹੀਂ। ਦੂਰਲੇ ਪਤੇ ਤੱਕ ਆਮ ਤੌਰ ਤੇ ਰਾਊਟਰ ਰਾਹੀਂ ਪਹੁੰਚਦੇ ਹਨ, ਇਸ ਲਈ ਉਸਦਾ ਆਪਣਾ ARP ਰਿਕਾਰਡ ਨਹੀਂ ਹੋਵੇਗਾ; ਇਸ ਲਈ ਪੁੱਛਣਾ ਸ਼੍ਰੇਣੀਗਤ ਗਲਤੀ ਹੈ ਜੋ ਲੋਕਾਂ ਨੂੰ ਉਹ ਗੁੰਮ ਐਂਟਰੀ ਲੱਭਣ ਭੇਜਦੀ ਹੈ ਜੋ ਕਦੇ ਹੋਣੀ ਹੀ ਨਹੀਂ ਸੀ ਚਾਹੀਦੀ।

ਦੂਰਲੀਆਂ ਰਿਪੋਰਟਾਂ ਅਤੇ ਅਸਿੰਕ੍ਰੋਨਸ UDP ਗਲਤੀਆਂ

EHOSTUNREACH ਬਾਹਰੋਂ ਵੀ ਆ ਸਕਦਾ ਹੈ। ਜੋ ਰਾਊਟਰ ਪੈਕੇਟ ਅੱਗੇ ਨਹੀਂ ਭੇਜ ਸਕਦਾ ਉਹ ICMP host unreachable ਭੇਜ ਸਕਦਾ ਹੈ, ਅਤੇ ਕਰਨਲ ਉਹ ਰਿਪੋਰਟ ਫਲੋ ਦੇ ਮਾਲਕ ਸਾਕਟ ਨੂੰ ਦਿੰਦਾ ਹੈ। ਉਸ ਹਾਲਤ ਵਿੱਚ ਰੂਟ ਅਤੇ ਗੁਆਂਢੀ ਠੀਕ ਹਨ, ਅਤੇ ਅਸਫਲਤਾ ਸਥਾਨਕ ਨੈੱਟਵਰਕ ਤੋਂ ਪਾਰ ਦੇ ਹੌਪ ਦੀ ਹੈ।

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

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

ਕ੍ਰਿਪਟੋ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਪਰਤਾਂ ਵੱਖ ਕਰੋ

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

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

ਪਹਿਲੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਮੰਜ਼ਿਲ, ਨੇਮਸਪੇਸ, ਚੁਣੀ ਸਾਰਣੀ, ਅਗਲਾ ਹੌਪ, ਗੁਆਂਢੀ ਦੀ ਸਥਿਤੀ ਅਤੇ ਗਲਤੀ ਦਾ ਸਮਾਂ ਦਰਜ ਕਰੋ। ਸੁਧਾਰ ਤੋਂ ਬਾਅਦ ਉਹੀ ਖੋਜ ਮੁੜ ਚਲਾਓ; ਹੁਣ ਟਨਲ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰਦਾ ਰੂਟ ਅਤੇ ਹੁਣ ਹੱਲ ਹੁੰਦੀ ਗੁਆਂਢੀ ਐਂਟਰੀ ਅਸੰਬੰਧਿਤ ਪਤੇ ਤੇ ਸਫਲ ping ਤੋਂ ਵੱਧ ਮਜ਼ਬੂਤ ਸਬੂਤ ਹਨ।