VPN ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਰਾਊਟਰ ਦਾ ਐਡਮਿਨ ਜਵਾਬ ਦੇਣਾ ਕਿਉਂ ਬੰਦ ਕਰ ਦਿੰਦਾ ਹੈ

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

ਪਹਿਲਾਂ ਮਾਰਨ ਯੋਗ ਇਹ ਭਰਮ ਹੈ: ਚੱਲ ਰਹੀ ਸੁਰੰਗ ਅੰਦਰ ਵਾਪਸ ਜਾਣ ਦਾ ਰਾਹ ਨਹੀਂ ਹੈ। ਇਹ ਆਪਣੇ ਭਰੋਸੇ ਦੇ ਸਵਾਲਾਂ ਵਾਲਾ ਨਵਾਂ ਨੈੱਟਵਰਕ ਜੋੜ ਹੈ, ਅਤੇ ਇਹ ਤੁਹਾਡਾ ਪੁਰਾਣਾ ਪ੍ਰਬੰਧਨ ਰਾਹ ਚੁੱਪਚਾਪ ਹਟਾ ਸਕਦੀ ਹੈ ਜਦੋਂ ਕਿ ਕਿਸੇ ਨੇ ਨਾ ਦੇਖਿਆ ਹੋਇਆ ਨਵਾਂ ਰਾਹ ਖੋਲ੍ਹਦੀ ਹੈ।

ਸੁਰੰਗ ਕਦੇ ਪ੍ਰਬੰਧਨ ਰਾਹ ਨਹੀਂ ਸੀ

ਫ਼ਾਰਵਰਡਿੰਗ ਅਤੇ ਇਨਪੁਟ ਵੱਖਰੇ ਕੰਮ ਹਨ। "ਕੀ ਕੋਈ ਕਲਾਇੰਟ ਸੁਰੰਗ ਰਾਹੀਂ NAS ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ?" ਇਹ ਰਾਊਟਰ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲੇ ਪੈਕਟਾਂ ਬਾਰੇ ਫ਼ਾਰਵਰਡਿੰਗ ਸਵਾਲ ਹੈ। "ਕੀ ਮੈਂ ਰਾਊਟਰ ਦਾ SSH ਪੋਰਟ ਖੋਲ੍ਹ ਸਕਦਾ ਹਾਂ?" ਇਹ ਰਾਊਟਰ ਨੂੰ ਹੀ ਸੰਬੋਧਿਤ ਪੈਕਟਾਂ ਬਾਰੇ ਇਨਪੁਟ ਸਵਾਲ ਹੈ। ਫ਼ਾਰਵਰਡ ਕੀਤੀ ਟ੍ਰੈਫਿਕ ਲਈ ਲਿਖਿਆ ਇਜਾਜ਼ਤ ਨਿਯਮ ਦੂਜੇ ਸਵਾਲ ਲਈ ਕੁਝ ਨਹੀਂ ਕਰਦਾ, ਅਤੇ ਇਹੀ ਸਭ ਤੋਂ ਆਮ ਕਾਰਨ ਹੈ ਕਿ ਟ੍ਰੈਫਿਕ ਵਧੀਆ ਢੋਣ ਵਾਲੀ ਸੁਰੰਗ ਵੀ ਤੁਹਾਡਾ ਐਡਮਿਨ ਸੈਸ਼ਨ ਨਹੀਂ ਮੰਨਦੀ।

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

ਪਹਿਲੀ ਪਰਤ: ਰਾਊਟਰ ਦੇ ਆਪਣੇ ਪਤੇ ਵੱਲ ਰੂਟ ਹੈ?

ਕਲਾਇੰਟ 'ਤੇ ਸ਼ੁਰੂ ਕਰੋ ਅਤੇ ਕਰਨਲ ਨੂੰ ਪੁੱਛੋ ਕਿ ਪੈਕਟ ਕਿੱਥੇ ਜਾਵੇਗਾ। Linux 'ਤੇ ip route get 10.6.0.1 ਚੁਣਿਆ ਰੂਟ, ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਇੰਟਰਫੇਸ ਅਤੇ ਸਰੋਤ ਪਤਾ ਛਾਪਦਾ ਹੈ। ਜੇ ਇਹ ਤੁਹਾਡੇ ISP ਵੱਲ ਡਿਫ਼ਾਲਟ ਰੂਟ ਦਿਖਾਉਂਦਾ ਹੈ, ਤਾਂ ਪੈਕਟ ਕਦੇ ਸੁਰੰਗ ਵਿੱਚ ਨਹੀਂ ਵੜਦਾ, ਅਤੇ ਰਾਊਟਰ ਦਾ ਕੋਈ ਨਿਯਮ ਇਸ ਨੂੰ ਬਚਾ ਨਹੀਂ ਸਕਦਾ।

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

ਨੀਤੀ ਡੀਬਗ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਸਹੀ ਪਤੇ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ ਜਿਸ 'ਤੇ ਤੁਸੀਂ ਪਹੁੰਚਣਾ ਚਾਹੁੰਦੇ ਹੋ। ਪੁਰਾਣਾ DNS ਰਿਕਾਰਡ ਜਾਂ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਕੈਸ਼ ਕੀਤਾ ਗੁਆਂਢੀ ਐਂਟਰੀ ਤੁਹਾਨੂੰ ਉਸ ਪਤੇ 'ਤੇ ਭੇਜਦਾ ਹੈ ਜੋ ਰਾਊਟਰ ਕੋਲ ਕਦੇ ਨਹੀਂ ਸੀ।

ਦੂਜੀ ਪਰਤ: ਇਨਪੁਟ ਨੀਤੀ, ਫ਼ਾਰਵਰਡਿੰਗ ਨੀਤੀ ਨਹੀਂ

ਫਾਇਰਵਾਲ ਨਿਯਮਾਂ ਦਾ ਮੁਲਾਂਕਣ ਉਸ ਇੰਟਰਫੇਸ 'ਤੇ ਕਰਦੇ ਹਨ ਜਿੱਥੇ ਪੈਕਟ ਆਉਂਦਾ ਹੈ। pfSense ਅਤੇ OPNsense ਵਿੱਚ ਇੰਟਰਫੇਸ ਟੈਬ ਅਤੇ ਨਿਯਮਾਂ ਦਾ ਕ੍ਰਮ ਤੈਅ ਕਰਦੇ ਹਨ ਕਿ ਫਾਇਰਵਾਲ ਦੀਆਂ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਵੱਲ ਟ੍ਰੈਫਿਕ ਦੀ ਇਜਾਜ਼ਤ ਹੈ ਜਾਂ ਨਹੀਂ; LAN ਕਲਾਇੰਟਾਂ ਨੂੰ ਇੰਟਰਨੈੱਟ 'ਤੇ ਜਾਣ ਦੇਣ ਵਾਲਾ ਨਿਯਮ ਉਹ ਨਿਯਮ ਨਹੀਂ ਜੋ ਸੁਰੰਗ ਸਾਥੀ ਨੂੰ ਵੈੱਬ GUI ਖੋਲ੍ਹਣ ਦਿੰਦਾ ਹੈ। firewall4 ਵਾਲੇ OpenWrt ਵਿੱਚ ਹਰ ਜ਼ੋਨ ਇੱਕ ਇਨਪੁਟ ਨੀਤੀ ਰੱਖਦਾ ਹੈ, option input 'ACCEPT' ਜਾਂ 'REJECT', ਅਤੇ ਜਿਸ ਜ਼ੋਨ ਦਾ ਇਨਪੁਟ REJECT ਹੈ ਉਸ ਵਿੱਚ ਸੁਰੰਗ ਇੰਟਰਫੇਸ ਪ੍ਰਬੰਧਨ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਮੰਨਦਾ, ਪਰ ਫ਼ਾਰਵਰਡਿੰਗ ਦੀ ਇਜਾਜ਼ਤ ਹੋਣ 'ਤੇ ਟ੍ਰੈਫਿਕ ਫਿਰ ਵੀ ਫ਼ਾਰਵਰਡ ਕਰਦਾ ਹੈ।

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

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

ਤੀਜੀ ਪਰਤ: ਉਸ ਪਤੇ 'ਤੇ ਕੁਝ ਸੁਣ ਰਿਹਾ ਹੈ?

ਸੇਵਾ ਚੱਲ ਰਹੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਵੀ ਨਾ ਪਹੁੰਚਣਯੋਗ ਹੋ ਸਕਦੀ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਹੀ ਪਤੇ ਨਾਲ ਬੱਝੀ ਹੈ। OpenWrt ਦਾ uhttpd /etc/config/uhttpd ਵਿੱਚ ਸਪੱਸ਼ਟ ਸੁਣਨ ਐਂਟਰੀਆਂ ਰੱਖਦਾ ਹੈ, ਉਦਾਹਰਣ ਲਈ list listen_http '0.0.0.0:80'; ਜੋ ਬਿਲਡ ਸਿਰਫ਼ LAN ਪਤੇ ਨਾਲ ਬੱਝਦਾ ਹੈ ਉਹ ਸੁਰੰਗ ਪਤੇ 'ਤੇ ਕੁਝ ਨਹੀਂ ਸਵੀਕਾਰਦਾ, ਅਤੇ ਸੁਣਨ-ਇੰਟਰਫੇਸ ਸੈਟਿੰਗ ਦਿਖਾਉਣ ਵਾਲੇ ਉਤਪਾਦ ਵੀ ਉਹੀ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ। ਉੱਪਰਲੇ ਸੁਣਨ ਹੁਕਮ ਇਸ ਦਾ ਸਿੱਧਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ।

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

VPN ਇੰਟਰਫੇਸ ਇੱਕ ਹੱਦ ਹੈ, ਰਿਕਵਰੀ ਰਾਹ ਨਹੀਂ

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

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

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

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

ਨੀਤੀ ਨੂੰ ਛੂਹਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸੀ ਦਾ ਰਾਹ ਤਿਆਰ ਕਰੋ

ਪਹਿਲੇ ਬਦਲਾਅ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਚੀਜ਼ਾਂ ਲਿਖੋ: ਜੇ ਸੁਰੰਗ ਮਰ ਜਾਵੇ ਤਾਂ ਤੁਸੀਂ ਡਿਵਾਈਸ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚੋਗੇ, ਜਿਵੇਂ ਸੀਰੀਅਲ ਕੰਸੋਲ, ਪ੍ਰਦਾਤਾ ਦਾ ਕੰਸੋਲ ਜਾਂ LAN ਵਿੱਚ ਮਸ਼ੀਨ; ਮੌਜੂਦਾ ਕੌਨਫਿਗਰੇਸ਼ਨ ਕਿੱਥੇ ਨਿਰਯਾਤ ਹੁੰਦੀ ਹੈ; ਤੁਸੀਂ ਕਿਹੜਾ ਇੱਕ ਨਿਯਮ ਜਾਂ ਰੂਟ ਬਦਲਣਾ ਹੈ; ਅਤੇ ਉਹੀ ਚੀਜ਼ ਠੀਕ-ਠੀਕ ਕਿਵੇਂ ਵਾਪਸ ਲਿਆਉਣੀ ਹੈ। OpenWrt 'ਤੇ sysupgrade -b /tmp/backup.tar.gz ਕੌਨਫਿਗਰੇਸ਼ਨ ਫੜਦਾ ਹੈ, ਅਤੇ ਬਦਲਾਅ uci commit ਤੱਕ ਬਕਾਇਆ ਰਹਿੰਦੇ ਹਨ, ਜੋ ਸਮੇਂ 'ਤੇ ਧਿਆਨ ਦੇਣ 'ਤੇ ਸਸਤਾ ਮੁੜ-ਪਹਿਲਾਂ ਕਰਨ ਦਾ ਮੌਕਾ ਦਿੰਦਾ ਹੈ। pfSense ਕੌਨਫਿਗਰੇਸ਼ਨ ਇਤਿਹਾਸ ਰੱਖਦਾ ਹੈ, ਅਤੇ AutoConfigBackup ਤਦ ਹੀ ਮਦਦ ਕਰਦਾ ਹੈ ਜੇ ਉਹ ਪਹਿਲਾਂ ਹੀ ਚਾਲੂ ਸੀ। ਜੇ ਰਾਊਟਰ fail-closed ਨਿਯਮ ਸਮੂਹ ਚਲਾਉਂਦਾ ਹੈ, ਤਾਂ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਤੁਹਾਡਾ ਯੋਜਨਾਬੱਧ ਰੱਖ-ਰਖਾਅ ਰਾਹ ਉਸ ਨਿਯਮ ਵੱਲੋਂ ਬਲਾਕ ਕੀਤੀ ਟ੍ਰੈਫਿਕ ਦੇ ਅੰਦਰ ਨਹੀਂ, ਅਤੇ ਯਾਦ ਰੱਖੋ ਕਿ ਰੀਬੂਟ ਸਥਾਈ ਨਿਯਮ ਮਿਟਾਉਣ ਦੀ ਥਾਂ ਮੁੜ ਲਾਗੂ ਕਰਦਾ ਹੈ।

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

ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਤੇਜ਼ ਜਾਂਚ:

• ਕੀ ਤੁਸੀਂ ਉਸ ਸਰੋਤ ਤੋਂ ਰਾਊਟਰ ਤੱਕ ਪਹੁੰਚ ਸਕਦੇ ਹੋ ਜੋ ਹੁਣੇ ਸੋਧੇ ਨਿਯਮ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ?
• ਕੀ ਸੁਰੰਗ ਇੰਟਰਫੇਸ ਦੀ ਇਨਪੁਟ ਨੀਤੀ ਸਿਰਫ਼ ਪ੍ਰਸ਼ਾਸਕ ਦੇ ਸਰੋਤ ਨੂੰ ਮਨਜ਼ੂਰ ਕਰਦੀ ਹੈ?
• ਕੀ ਪ੍ਰਬੰਧਨ ਸੇਵਾ ਉਸ ਪਤੇ ਨਾਲ ਬੱਝੀ ਹੈ ਜੋ ਸੁਰੰਗ 'ਤੇ ਮੌਜੂਦ ਹੈ?
• ਕੀ ਤੁਸੀਂ ਇੱਕ ਨਾਂਹ ਕੀਤਾ ਸਾਥੀ ਅਤੇ ਇੱਕ ਨਵਾਂ ਸੈਸ਼ਨ ਜਾਂਚਿਆ ਹੈ?
• ਕੀ WAN ਪ੍ਰਬੰਧਨ ਸਤਹ ਅਜੇ ਵੀ ਬੰਦ ਹੈ?