ਟਨਲ ਹਾਲੇ ਵੀ ਚੱਲ ਰਿਹਾ, ਰਸਤਾ ਗਿਆ: ਦੋ VPN ਫੇਲ੍ਹਤਾਂ ਵੱਖ ਕਰਨਾ

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

ਇੱਕੋ ਘਟਨਾ ਵਰਗੇ ਦਿਖਣ ਵਾਲੇ ਤਿੰਨ ਪੜਾਅ

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

ਇਸ ਲਈ ਪਹਿਲਾ ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਕਿਹੜਾ ਪੜਾਅ ਟੁੱਟਾ, ਨਾ ਕਿ ਕਿਹੜਾ ਪ੍ਰੋਟੋਕੋਲ ਦੋਸ਼ੀ ਹੈ। ਜਵਾਬ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਘਟਨਾ ਕਿਸਦੀ ਹੈ ਅਤੇ ਅਗਲੀ ਜਾਂਚ ਕਿਹੜਾ ਸਾਧਨ ਵਰਤੇਗੀ।

ਪਹਿਲਾਂ ਸਥਾਪਿਤ ਰਸਤਾ ਪੜ੍ਹੋ

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

ip route get 10.20.5.10
ip route show 10.20.0.0/16

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

ਫਿਰ ਪ੍ਰੋਟੋਕੋਲ ਦਾ ਆਪਣਾ ਦ੍ਰਿਸ਼ ਵੇਖੋ

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

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

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

ਜਦੋਂ ਘੜੀਆਂ ਸਹਿਮਤ ਨਹੀਂ ਹੁੰਦੀਆਂ

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

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

ਲੂਪ ਤੋਂ ਬਿਨਾਂ ਰਿਕਵਰੀ

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

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