ਤੁਹਾਡੇ VPN ਗੇਟਵੇ ਨੂੰ ਅਜੇ ਵੀ ਅਪਡੇਟ ਸਥਾਪਤ ਕਰਨ ਦਾ ਰਾਹ ਚਾਹੀਦਾ ਹੈ

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

ਗੇਟਵੇ ਨੂੰ ਬੰਦ ਕਰਨਾ ਸਹੀ ਹੈ। ਇਸ ਨੂੰ ਇੰਨਾ ਕੱਸ ਕੇ ਬੰਦ ਕਰਨਾ ਕਿ ਇਹ ਪੈਚ ਲੈਣਾ ਬੰਦ ਕਰ ਦੇਵੇ, ਇੱਕ ਵੱਖਰਾ ਫੈਸਲਾ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਅਣਜਾਣੇ ਵਿੱਚ ਲਿਆ ਗਿਆ।

ਸਥਾਨਕ ਆਉਟਪੁੱਟ ਕਲਾਇੰਟ ਫਾਰਵਰਡਿੰਗ ਨਹੀਂ ਹੈ

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

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

ਉਸ ਪੜਾਅ ਦਾ ਨਾਮ ਦੱਸੋ ਜੋ ਅਸਫਲ ਹੋਇਆ

ਅਪਡੇਟ ਗਲਤੀਆਂ ਵੱਖਰੀਆਂ ਹੱਦਾਂ ਦੇ ਨਾਮ ਦੱਸਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਪੜ੍ਹਨ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕਿਹੜੀ ਅਸਫਲ ਹੋਈ ਪੋਰਟ ਨਿਯਮ ਵੱਲ ਝਪਟਣਾ ਦੁਪਹਿਰ ਬਰਬਾਦ ਕਰਦਾ ਹੈ। ਅਜਿਹਾ ਰਿਪੋਜ਼ਟਰੀ ਨਾਮ ਜੋ ਹੱਲ ਨਾ ਹੋਵੇ resolver ਦਾ ਸਵਾਲ ਹੈ, ਟਰਾਂਸਪੋਰਟ ਦਾ ਸਵਾਲ ਨਹੀਂ।

getent hosts deb.debian.org
curl -sSI https://deb.debian.org/debian/dists/stable/Release | head -n 1
apt-get -o Debug::Acquire::https=true update

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

ਨਿਯਮ ਜੋੜਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰੋਤ ਸੂਚੀ ਪੜ੍ਹੋ

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

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

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

ਸੰਭਾਲ ਦਾ ਇੱਕ ਰਾਹ ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਟਿਕੇ ਰਹੋ

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

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

ਜਾਂਚਾਂ ਨੂੰ ਕਮਜ਼ੋਰ ਕੀਤੇ ਬਿਨਾਂ ਤਸਦੀਕ ਕਰੋ

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

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

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