UFW ਦਾ ਕਿਲ ਸਵਿੱਚ ਤੁਹਾਡੇ VPN ਨੂੰ ਰੋਕ ਰਿਹਾ ਹੈ? ਪੀਅਰ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿਓ
ਤੁਹਾਡਾ ਆਉਟਗੋਇੰਗ ਰੱਦ ਨਿਯਮ ਟਨਲ ਦਾ ਹੈਂਡਸ਼ੇਕ ਡੇਗ ਰਿਹਾ ਹੈ। ufw enable ਤੋਂ ਪਹਿਲਾਂ ਜੋੜਿਆ ਇੱਕ ਪੀਅਰ ਅਪਵਾਦ ਹੀ ਨੀਤੀ ਨੂੰ ਕਿਲ ਸਵਿੱਚ ਬਣਾਉਂਦਾ ਹੈ।
ਤੁਸੀਂ ਚੈਕਲਿਸਟ ਦੀ ਪਾਲਣਾ ਕੀਤੀ: ਆਉਟਗੋਇੰਗ ਨੂੰ ਰੱਦ ਕਰੋ, ਟਨਲ ਨੂੰ ਇਜਾਜ਼ਤ ਦਿਓ, ufw ਸਰਗਰਮ ਕਰੋ। ਫਿਰ ਕਲਾਇੰਟ ਹੈਂਡਸ਼ੇਕ ਉੱਤੇ ਉਡੀਕਦਾ ਹੈ ਅਤੇ ਕਦੇ ਵੀ ਜੁੜਦਾ ਨਹੀਂ, ਜਾਂ ਜੁੜਦਾ ਹੈ ਅਤੇ ਕੋਈ ਪੰਨਾ ਲੋਡ ਨਹੀਂ ਹੁੰਦਾ। ਦੋਵੇਂ ਅਸਫਲਤਾਵਾਂ ਇੱਕੋ ਖਾਲੀ ਥਾਂ ਤੋਂ ਆਉਂਦੀਆਂ ਹਨ। ਟਨਲ ਨੂੰ ਹੋਂਦ ਵਿੱਚ ਰਹਿਣ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਗੁੰਮ ਹੈ, ਕਿਉਂਕਿ ਟਨਲ ਉਹ ਇੰਟਰਫੇਸ ਨਹੀਂ ਜਿਸ ਵਿੱਚੋਂ ਤੁਹਾਡੇ ਪੈਕੇਟ ਬਾਹਰ ਜਾਂਦੇ ਹਨ।
tun0 ਉੱਤੇ ਇਜਾਜ਼ਤ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਸੇ ਨਾਲ ਕਿਉਂ ਨਹੀਂ ਮਿਲਦੀ
ਸੈਸ਼ਨ ਹੋਣ ਤੋਂ ਬਾਅਦ ਕਲਾਇੰਟ tun0 ਬਣਾਉਂਦਾ ਹੈ। ਉਸ ਸੈਸ਼ਨ ਨੂੰ ਬਣਾਉਣ ਵਾਲੇ ਡੇਟਾਗ੍ਰਾਮ ਪੋਰਟ 1194 ਉੱਤੇ ਪ੍ਰਦਾਤਾ ਨੂੰ ਭੇਜੇ ਆਮ UDP ਪੈਕੇਟ ਹਨ, ਅਤੇ ਉਹ ਭੌਤਿਕ ਸਰੋਤ ਪਤੇ ਨਾਲ wlan0 ਜਾਂ eth0 ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦੇ ਹਨ। allow out on tun0 ਸਿਰਫ਼ ਉਸ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮਿਲਦਾ ਹੈ ਜਿਸਦਾ ਆਉਟਗੋਇੰਗ ਇੰਟਰਫੇਸ tun0 ਹੈ, ਇਸ ਲਈ ਹੈਂਡਸ਼ੇਕ ਦੌਰਾਨ ਇਹ ਕਿਸੇ ਨਾਲ ਨਹੀਂ ਮਿਲਦਾ।
ਇਸ ਉੱਤੇ default deny outgoing ਰੱਖੋ ਅਤੇ ਬਾਹਰੀ ਪੈਕੇਟ ਇੰਟਰਫੇਸ ਦਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਸੁੱਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ। ਕਲਾਇੰਟ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ, ਸਮਾਂ ਖ਼ਤਮ ਹੁੰਦਾ ਹੈ ਅਤੇ TLS ਜਾਂ ਹੈਂਡਸ਼ੇਕ ਅਸਫਲਤਾ ਦੀ ਰਿਪੋਰਟ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਲੋਕ ਸਰਟੀਫਿਕੇਟ ਅਤੇ MTU ਵਿੱਚ ਖੋਜ ਕਰਨ ਲੱਗਦੇ ਹਨ ਜਦਕਿ ਫਾਇਰਵਾਲ ਚੁੱਪਚਾਪ ਕਨੈਕਸ਼ਨ ਖਾ ਰਿਹਾ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਡੇ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੋਕਣ ਲਈ ਬਣਾਇਆ ਨਿਯਮ ਹੀ ਉਸ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੁਕਣ ਤੋਂ ਰੋਕ ਰਿਹਾ ਹੈ।
ਤਤਕਾਲ ਸੁਧਾਰ ਲੀਕ ਨੂੰ ਸਥਾਈ ਬਣਾ ਦਿੰਦਾ ਹੈ। sudo ufw allow out on wlan0, ਜਾਂ ਡਿਫਾਲਟ ਨੂੰ ਵਾਪਸ ਇਜਾਜ਼ਤ ਉੱਤੇ ਮੋੜਨਾ, ਟਨਲ ਨੂੰ ਉੱਪਰ ਲਿਆਉਂਦਾ ਹੈ ਅਤੇ ਮਸ਼ੀਨ ਨੂੰ ਕਿਲ ਸਵਿੱਚ ਤੋਂ ਬਿਨਾਂ ਛੱਡ ਦਿੰਦਾ ਹੈ: ਅਗਲੀ ਵਾਰ ਜਦੋਂ ਟਨਲ ਡਿੱਗੇਗਾ, ਸਭ ਕੁਝ ਭੌਤਿਕ ਅਡੈਪਟਰ ਰਾਹੀਂ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗਾ। ਮੈਂ ਠੀਕ ਉਹਨਾਂ ਦੋ ਸੋਧਾਂ ਉੱਤੇ ਇੱਕ ਦੁਪਹਿਰ ਗੁਆ ਦਿੱਤੀ, ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਮੈਂ ਸਮਝ ਪਾਉਂਦਾ ਕਿ ਮੈਂ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਪੈਕੇਟ ਫਿਲਟਰ ਕਰ ਰਿਹਾ ਹਾਂ।
ਦੋ ਪੈਕੇਟ ਸਮੂਹਾਂ ਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ
ਤੁਹਾਡਾ ਟ੍ਰੈਫਿਕ ਫਾਇਰਵਾਲ ਨੂੰ ਦੋ ਵਾਰ, ਦੋ ਆਕਾਰਾਂ ਵਿੱਚ ਲੰਘਦਾ ਹੈ। ਅੰਦਰਲਾ ਪੈਕੇਟ ਟਨਲ ਪਤੇ ਤੋਂ tun0 ਰਾਹੀਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ। ਬਾਹਰਲਾ ਪੈਕੇਟ ਭੌਤਿਕ ਪਤੇ ਤੋਂ ਪੀਅਰ ਤੱਕ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਤਾਰ ਉੱਤੇ ਦਿਖਣ ਵਾਲੀ ਇੱਕੋ ਇੱਕ ਚੀਜ਼ ਉਹੀ ਹੈ। ਹਰ ਆਕਾਰ ਲਈ ਇੱਕ ਨਿਯਮ:
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'
ਪਤਾ ਅਤੇ ਪੋਰਟ ਆਪਣੀ ਹੀ ਪ੍ਰੋਫਾਈਲ ਵਾਲੇ ਨਾਲ ਬਦਲੋ। WireGuard ਪੀਅਰ ਆਮ ਤੌਰ 'ਤੇ 51820/udp ਉੱਤੇ ਜਵਾਬ ਦਿੰਦੇ ਹਨ; TCP 443 ਰਾਹੀਂ ਚੱਲਣ ਵਾਲੀਆਂ OpenVPN ਪ੍ਰੋਫਾਈਲਾਂ ਨੂੰ ਇਸ ਦੀ ਥਾਂ ਉਹ ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ। ਵੇਰਵੇ ਵੱਖਰੇ ਹਨ, ਆਕਾਰ ਨਹੀਂ: ਦੋਵੇਂ ਨਿਯਮ ਤੰਗ ਹਨ, ਅਤੇ ਮਿਲ ਕੇ ਉਹ ਉਹੀ ਇੱਕੋ ਗੰਤਵਿਅ ਤੈਅ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਟਨਲ ਬੰਦ ਹੋਣ ਵੇਲੇ ਮਸ਼ੀਨ ਪਹੁੰਚ ਸਕਦੀ ਹੈ।
ਕ੍ਰਮ ਦੂਜਾ ਮਿੱਥ ਹੈ। ਕੱਚੇ iptables ਨਾਲ ਤੁਸੀਂ ਚੇਨ ਨੂੰ ਉੱਪਰ ਤੋਂ ਹੇਠਾਂ ਪੜ੍ਹਦੇ ਹੋ ਅਤੇ ਸੋਚਦੇ ਹੋ ਕਿ ਕਿਹੜਾ ਨਿਯਮ ਜਿੱਤਦਾ ਹੈ। ufw ਤੁਹਾਡੀ ਟਾਈਪ ਕੀਤੀ ਸੂਚੀ ਦੁਆਲੇ ਪਤਲਾ ਆਵਰਣ ਨਹੀਂ ਹੈ; ਇਹ ਤੁਹਾਡੇ ਨਿਯਮਾਂ ਨੂੰ ਆਪਣੀਆਂ ਚੇਨਾਂ ਵਿੱਚ ਕੰਪਾਇਲ ਕਰਦਾ ਹੈ ਅਤੇ ਪਾਉਣ ਦੇ ਬਿੰਦੂ ਚੁਣਦਾ ਹੈ। ufw status ਉਹਨਾਂ ਨੂੰ ufw ਦੇ ਕ੍ਰਮ ਵਿੱਚ ਛਾਪਦਾ ਹੈ, ਤੁਹਾਡੇ ਕ੍ਰਮ ਵਿੱਚ ਨਹੀਂ। ਜਦੋਂ ਨਿਯਮ ਅਣਡਿੱਠਾ ਲੱਗੇ, ਤਾਂ ਕੁਝ ਵੀ ਦੁਬਾਰਾ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ufw show added ਨੂੰ ਕੰਪਾਇਲ ਕੀਤੇ ਸਮੂਹ ਨਾਲ iptables -S | grep ufw ਤੁਲਨਾ ਕਰੋ।
ਅਪਵਾਦ ਇੱਕ ਪਤੇ ਦੀ ਚੌੜਾਈ ਉੱਤੇ ਹੀ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ
ਪੀਅਰ ਨਿਯਮ ਤਦ ਤੱਕ ਹੀ ਸਹੀ ਹੈ ਜਦ ਤੱਕ ਇਹ ਉਸ ਪਤੇ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਜਿਸ ਨੂੰ ਕਲਾਇੰਟ ਡਾਇਲ ਕਰਦਾ ਹੈ। ਪ੍ਰਦਾਤਾ ਐਂਡਪੁਆਇੰਟ ਘੁਮਾਉਂਦੇ ਹਨ, ਅਤੇ ਹੋਸਟਨਾਮ ਹੱਲ ਕਰਨ ਵਾਲੀ ਪ੍ਰੋਫਾਈਲ DNS ਬਦਲਾਅ ਦਾ ਪਿੱਛਾ ਕਰਦਿਆਂ ਨਵੇਂ ਪਤੇ ਉੱਤੇ ਚਲੀ ਜਾਵੇਗੀ ਜਦਕਿ ਨਿਯਮ ਪੁਰਾਣੇ ਵੱਲ ਹੀ ਇਸ਼ਾਰਾ ਕਰਦਾ ਰਹੇਗਾ। ਜਦੋਂ ਮਹੀਨਿਆਂ ਤੋਂ ਚੱਲ ਰਿਹਾ ਟਨਲ ਉੱਪਰ ਆਉਣਾ ਬੰਦ ਕਰ ਦੇਵੇ, ਤਾਂ ਕੁਝ ਵੀ ਚੌੜਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਨਿਯਮ ਵਾਲੇ ਪਤੇ ਦੀ ਤੁਲਨਾ ਉਸ ਪਤੇ ਨਾਲ ਕਰੋ ਜਿਸ ਨੂੰ ਕਲਾਇੰਟ ਲੱਭ ਰਿਹਾ ਹੈ।
ਪੂਰੇ ਸਬਨੈੱਟ ਤੱਕ, ਜਾਂ ਪੋਰਟ 1194 ਦੇ ਹਰ ਗੰਤਵਿਅ ਤੱਕ ਚੌੜਾ ਕਰਨਾ ਨੀਤੀ ਨੂੰ ਫਿਰ ਮੋਰੀ ਵਾਲੇ ਫਾਇਰਵਾਲ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਅਪਵਾਦ ਹੀ ਕਿਲ ਸਵਿੱਚ ਹੈ; ਇੱਕ ਵਾਰ ਇਹ ਚੌੜਾ ਹੋ ਜਾਵੇ, ਤਾਂ ਬੰਦ ਕਰਨ ਲਈ ਕੁਝ ਨਹੀਂ ਬਚਦਾ। ਇਸ ਨੂੰ ਇੱਕ ਪਤੇ ਉੱਤੇ ਰੱਖੋ ਅਤੇ ਇੱਕ ਟਿੱਪਣੀ ਛੱਡੋ ਜੋ ਉਸ ਪ੍ਰੋਫਾਈਲ ਅਤੇ ਪ੍ਰਦਾਤਾ ਦਾ ਨਾਮ ਲਵੇ ਜਿਸਦਾ ਇਹ ਹੈ, ਕਿਉਂਕਿ ਛੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਪਤਾ ਮਨਮਾਨਿਆ ਲੱਗੇਗਾ।
ਨਾਮ ਹੱਲ ਕਰਨਾ ਆਪਣੀ ਵੱਖਰੀ ਲਾਈਨ ਦਾ ਹੱਕਦਾਰ ਹੈ। ਖੋਜ ਟਨਲ ਦੇ ਹੋਂਦ ਵਿੱਚ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ, ਭੌਤਿਕ ਇੰਟਰਫੇਸ ਉੱਤੇ ਹੁੰਦੀ ਹੈ, ਇਸ ਲਈ ਸਖ਼ਤ ਆਉਟਗੋਇੰਗ-ਰੱਦ ਨੀਤੀ ਕਲਾਇੰਟ ਨੂੰ ਆਪਣਾ ਸਰਵਰ ਲੱਭਣ ਤੋਂ ਅਸਮਰੱਥ ਛੱਡ ਸਕਦੀ ਹੈ। ਆਪਣੇ ਰਿਜ਼ੌਲਵਰ ਦੇ ਪਤੇ ਉੱਤੇ ਪੋਰਟ 53 ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ, ਜਾਂ ਇੱਕ ਵਾਰ ਹੱਲ ਕਰਕੇ ਪਤਾ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਪਿੰਨ ਕਰੋ। ਹਰ ਇੰਟਰਫੇਸ ਉੱਤੇ DNS ਦੀ ਇਜਾਜ਼ਤ ਦੇਣਾ ਇੱਕ ਫ਼ੈਸਲਾ ਹੈ, ਡਿਫਾਲਟ ਨਹੀਂ।
ਟਨਲ ਦੀ ਲੋੜ ਪੈਣ ਤੋਂ ਪਹਿਲਾਂ ਨੀਤੀ ਬਣਾਓ
ufw enable ਪੂਰੀ ਨੀਤੀ ਇੱਕੋ ਵਾਰ ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣੀਆਂ ਚੇਨਾਂ ਦੁਬਾਰਾ ਲੋਡ ਕਰਦਾ ਹੈ, ਅਤੇ ਚੱਲ ਰਹੇ ਫਾਇਰਵਾਲ ਉੱਤੇ ਡਿਫਾਲਟ ਨੀਤੀ ਬਦਲਣ ਨਾਲ ਉਹ ਵੀ ਦੁਬਾਰਾ ਲੋਡ ਹੁੰਦੀਆਂ ਹਨ। ufw ਮੈਨੁਅਲ ਚੇਤਾਵਨੀ ਦਿੰਦਾ ਹੈ ਕਿ ਇਸ ਨਾਲ SSH ਵਰਗੇ ਮੌਜੂਦਾ ਕਨੈਕਸ਼ਨ ਡਿੱਗ ਸਕਦੇ ਹਨ। ਇਸ ਲਈ ਹੁਕਮ ਇਸ ਕ੍ਰਮ ਵਿੱਚ ਜਾਂਦੇ ਹਨ, SSH ਨਿਯਮ ਸਰਗਰਮ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਤੇ ਕੰਸੋਲ ਸੈਸ਼ਨ ਖੁੱਲ੍ਹਾ ਰੱਖ ਕੇ:
sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose
ufw reset ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਉਸ ਬਲਾਕ ਤੋਂ ਬਾਹਰ ਰੱਖਿਆ ਗਿਆ ਹੈ। ਇਹ ਹਰ ਨਿਯਮ ਮਿਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਫਾਇਰਵਾਲ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਦੂਰ ਦੇ ਹੋਸਟ ਉੱਤੇ ਅਗਲਾ ਸਰਗਰਮੀਕਰਨ ਹੀ ਤੁਹਾਡਾ ਸੈਸ਼ਨ ਡਿੱਗਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਫਿਰ ਵੀ ਰੀਸੈਟ ਕਰੋ, ਤਾਂ SSH ਨਿਯਮ ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ ਅੱਗੇ ਵਧਣ ਤੋਂ ਪਹਿਲਾਂ ਕੰਸੋਲ ਰਾਹੀਂ ਵਾਪਸ ਆਉਣ ਦਾ ਦੂਜਾ ਰਾਹ ਪੱਕਾ ਕਰੋ।
ਕ੍ਰਮ ਦਿਖਾਵਟੀ ਨਹੀਂ ਹੈ। ufw ਚੱਲਦਿਆਂ ਸ਼ਾਮਲ ਕੀਤੇ ਨਿਯਮ ਕੁਝ ਫਲਸ਼ ਨਹੀਂ ਕਰਦੇ, ਪਰ ਜਿਸ ਪਲ ਤੁਸੀਂ ਡਿਫਾਲਟ ਨੀਤੀ ਪਲਟਦੇ ਹੋ, ਚੇਨਾਂ ਦੁਬਾਰਾ ਲੋਡ ਹੁੰਦੀਆਂ ਹਨ, ਅਤੇ ਪੁਰਾਣੀ ਨੀਤੀ ਵੱਲੋਂ ਇਜਾਜ਼ਤ ਦਿੱਤਾ ਸੈਸ਼ਨ ਉਹਨਾਂ ਨਾਲ ਚਲਾ ਜਾਂਦਾ ਹੈ। ਡਿਫਾਲਟ, ਇਜਾਜ਼ਤਾਂ ਅਤੇ ਸਰਗਰਮੀਕਰਨ ਇੱਕੋ ਪਾਸ ਵਿੱਚ ਕਰੋ, ਜਦੋਂ ਤੱਕ ਤੁਹਾਡੇ ਕੋਲ ਮਸ਼ੀਨ ਉੱਤੇ ਨਿਰਭਰ ਨਾ ਕਰਨ ਵਾਲਾ ਪ੍ਰਵੇਸ਼ ਮਾਰਗ ਹੈ।
ਅਵਰੋਧਿਤ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ, ਅਤੇ ਪਹਿਲਾਂ ਵਾਲੀ ਹਾਲਤ ਰੱਖੋ
ਬਿਨਾਂ ਜਾਂਚਿਆ ਕਿਲ ਸਵਿੱਚ ਇੱਕ ਅਨੁਮਾਨ ਹੈ. ਕਲਾਇੰਟ ਨੂੰ ਜਾਣਬੁੱਝ ਕੇ ਡਿਸਕਨੈਕਟ ਕਰੋ ਅਤੇ ਪੰਨਾ ਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ: ਇਹ ਅਸਫਲ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਦੁਬਾਰਾ ਜੁੜੋ ਅਤੇ ਇਹ ਕਿਸੇ ਨਿਯਮ ਨੂੰ ਛੂਹੇ ਬਿਨਾਂ ਠੀਕ ਹੋ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। sudo ufw status verbose ਡਿਫਾਲਟ ਅਤੇ ਲੌਗਿੰਗ ਸਥਿਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ, ਅਤੇ ufw status numbered ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਜਾਂਚ ਨਿਯਮ ਆਪਣੇ ਮਕਸਦ ਤੋਂ ਵੱਧ ਜੀਵੇ ਤਾਂ ਕਿਹੜਾ ਹਟਾਉਣਾ ਹੈ।
ਉਲਟੀ ਸਕ੍ਰਿਪਟ ਨੂੰ ਅੱਗੇ ਵਾਲੀ ਦੇ ਕੋਲ ਰੱਖੋ। ਆਉਟਗੋਇੰਗ-ਰੱਦ ਅਤੇ ਮਰੇ ਟਨਲ ਵਾਲੀ ਮਸ਼ੀਨ ਆਪਣੀ ਮੁਰੰਮਤ ਡਾਊਨਲੋਡ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਇਸ ਲਈ ਪਹਿਲਾਂ ਵਾਲੀ ਹਾਲਤ ਡਿਸਕ ਉੱਤੇ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਅਤੇ ਕੰਸੋਲ ਤੋਂ ਪੜ੍ਹੀ ਜਾ ਸਕਣੀ ਚਾਹੀਦੀ ਹੈ:
sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable
ਇਸ ਨੂੰ ਤਦ ਚਲਾਓ ਜਦੋਂ ਟਨਲ ਪਹਿਲਾਂ ਹੀ ਹੇਠਾਂ ਹੋਵੇ ਅਤੇ ਨਿਯਮ ਹਟਾਉਣੇ ਹੋਣ, ਨਿਯਮਿਤ ਕਦਮ ਵਜੋਂ ਨਹੀਂ। ਟਰਮੀਨਲ ਬੰਦ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਗੱਲਾਂ ਸਹੀ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ: ਪੀਅਰ ਨਿਯਮ ਠੀਕ ਇੱਕ ਪਤੇ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, DNS ਕੋਲ ਨਾਮਿਤ ਅਪਵਾਦ ਹੈ, ਸਰਗਰਮੀਕਰਨ ਇਜਾਜ਼ਤਾਂ ਤੋਂ ਬਾਅਦ ਆਇਆ, ਅਤੇ ਟਨਲ ਖਿੱਚਣ ਨਾਲ ਆਮ ਟ੍ਰੈਫਿਕ ਮਰਦਾ ਹੈ ਪਰ ਕਲਾਇੰਟ ਹਮੇਸ਼ਾ ਲਈ ਨਹੀਂ ਮਰਦਾ।