DHCP ਨਵੀਨੀਕਰਨ ਤੋਂ ਬਾਅਦ VPN ਡਿੱਗਦਾ ਹੈ? ਪਤਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

ਡਿੱਗੇ ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

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

ਘਟਨਾ ਦੇ ਆਸਪਾਸ ਚਾਰ ਮੁੱਲਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ

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

ip -4 -brief addr show dev wlan0
ip -4 route show default
resolvectl status | grep -A3 'DNS Servers'
journalctl -u NetworkManager --since -10m --no-pager | grep -i dhcp

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

ਨਵੀਨੀਕਰਨ ਕੀ ਬਦਲ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

RFC 2131 ਨਵੀਨੀਕਰਨ ਨੂੰ ਕਿਰਾਏ ਦੇ ਅੱਧੇ ਸਮੇਂ 'ਤੇ ਅਸਲ ਸਰਵਰ ਨੂੰ ਬੇਨਤੀ ਵਜੋਂ ਬਿਆਨ ਕਰਦਾ ਹੈ, ਅਤੇ ਜੇ ਪਹਿਲੀ ਕੋਸ਼ਿਸ਼ ਦਾ ਜਵਾਬ ਨਾ ਮਿਲੇ ਤਾਂ ਅੱਠ ਵਿੱਚੋਂ ਸੱਤ ਹਿੱਸੇ 'ਤੇ ਕਿਸੇ ਵੀ ਸਰਵਰ ਨਾਲ ਦੁਬਾਰਾ ਬਾਈਂਡਿੰਗ। ਦੋਵੇਂ ਕਦਮਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕਲਾਇੰਟ ਨੂੰ ਵੱਖਰਾ ਪਤਾ ਲੈਣ ਦੀ ਮੰਗ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਸਹਿਯੋਗੀ ਸਰਵਰ ਆਮ ਤੌਰ 'ਤੇ ਮੌਜੂਦਾ ਬਾਈਂਡਿੰਗ ਵਧਾ ਦਿੰਦਾ ਹੈ। ਅਸਲ ਪਤਾ ਬਦਲਾਅ ਆਮ ਤੌਰ 'ਤੇ ਕਿਸੇ ਹੋਰ ਰਾਹੀਂ ਆਉਂਦਾ ਹੈ: ਸਰਵਰ ਨਵੀਨੀਕਰਨ ਤੋਂ ਇਨਕਾਰ ਕਰਦਾ ਹੈ, ਕਲਾਇੰਟ ਆਪਣੀ ਸਥਿਤੀ ਗੁਆ ਕੇ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ, ਜਾਂ ਨੈੱਟਵਰਕ ਡਿਵਾਈਸ ਨੂੰ ਹੋਰ ਹਿੱਸੇ ਵਿੱਚ ਲੈ ਜਾਂਦਾ ਹੈ।

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

ਜਦੋਂ ਕਲਾਇੰਟ ਅਨੁਕੂਲ ਨਹੀਂ ਹੋ ਪਾਉਂਦਾ

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

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

ਦੋਸ਼ ਦੇਣ ਤੋਂ ਪਹਿਲਾਂ ਘਟਨਾ ਦੁਹਰਾਓ

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

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