ਪਿੰਗ ਵਾਚਡੌਗ ਟੁੱਟੀ ਸੁਰੰਗ ਨੂੰ ਸਿਹਤਮੰਦ ਸੁਰੰਗ ਤੋਂ ਵੱਖ ਨਹੀਂ ਕਰ ਸਕਦਾ

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

ਜਾਂਚ ਹੀ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਬਾਕੀ ਸਭ ਤੈਅ ਕਰਦਾ ਹੈ।

ਇੰਟਰਨੈੱਟ ਤੇ ਪਿੰਗ ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕਰਦਾ ਹੈ

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

ਗਲਤੀ ਦੀਆਂ ਦੋਵੇਂ ਦਿਸ਼ਾਵਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਨਿਕਾਸ ਕੋਡ ਵਿੱਚ ਨਹੀਂ ਦਿਸਦੀ। ਉਸ ਸੰਕੇਤ ਤੇ ਬਣਿਆ ਵਾਚਡੌਗ cron ਸਮਾਂ-ਸਾਰਣੀ ਨਾਲ ਸਿੱਕਾ ਉਛਾਲਣਾ ਹੈ।

ਸੁਰੰਗ ਦੇ ਪਿੱਛੇ ਰਹਿਣ ਵਾਲੀ ਕੋਈ ਚੀਜ਼ ਜਾਂਚੋ

ip -brief addr show tun0
ip route get 10.100.20.10
nc -z -w3 10.100.20.10 443

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

ਜਾਂਚ ਨੂੰ ਸਮੇਂ ਵਿੱਚ ਸੀਮਿਤ ਰੱਖੋ ਅਤੇ ਇਸਨੂੰ ਵੱਖਰੀ ਨਿਕਾਸ ਸਥਿਤੀ ਦਿਓ। ਜੋ ਜਾਂਚ ਤੀਹ ਸਕਿੰਟ ਲਟਕਦੀ ਹੈ, ਉਹ ਵਾਚਡੌਗ ਨੂੰ ਅੰਦਰੂਨੀ ਦੇਰੀ ਵਾਲਾ ਰੁਕਾਵਟ ਖੋਜਕ ਬਣਾ ਦਿੰਦੀ ਹੈ।

ਇੱਕ ਲਾਈਨ ਅਤੇ ਲੂਪ ਵਿੱਚੋਂ ਚੁਣੋ

* * * * * nc -z -w5 10.100.20.10 443 || myvpn reconnect

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

failures=0
while sleep 30; do
  if nc -z -w5 10.100.20.10 443; then failures=0
  else failures=$((failures+1)); fi
  if [ $failures -ge 3 ]; then myvpn reconnect; failures=0; fi
done

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

ਸਰਵਰ ਬਦਲਣਾ ਵੱਖਰਾ ਫ਼ੈਸਲਾ ਹੈ

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

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

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