ਸਮਝੌਤਾ ਹੋਏ ਹੋਸਟ 'ਤੇ ਕਿੱਲ ਸਵਿੱਚ ਕੀ ਕਵਰ ਕਰਦਾ ਹੈ, ਇਹ ਕਿਵੇਂ ਪਰਖੀਏ

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

ਸਰਵਰ ਤੋਂ ਨਹੀਂ, ਕਲਾਇੰਟ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ

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

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

ਪਹਿਲਾ ਕਦਮ: ਜਿਨ੍ਹਾਂ ਰਾਹਾਂ ਨੂੰ ਤੁਸੀਂ ਕਵਰ ਸਮਝਦੇ ਹੋ, ਉਨ੍ਹਾਂ 'ਤੇ ਬਲਾਕ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ

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

curl -m 5 -sS -o /dev/null -w '%{http_code}
' https://example.com
ping -c 2 1.1.1.1
ip route
nft list ruleset   # or: iptables -S

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

ਕਲਾਇੰਟ ਦੇ allow-LAN ਵਿਕਲਪ ਨੂੰ ਚਾਲੂ ਅਤੇ ਬੰਦ ਕਰਕੇ ਉਹੀ ਕਮਾਂਡਾਂ ਦੁਹਰਾਓ। ਉਹੀ ਟੌਗਲ ਸਭ ਤੋਂ ਵੱਧ ਹੈਰਾਨੀ ਦੀ ਥਾਂ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਉਸ ਰਾਹ ਨੂੰ ਮੁੜ ਖੋਲ੍ਹਦਾ ਹੈ ਜੋ ਬਾਕੀ ਨੀਤੀ ਬੰਦ ਕਰਨ ਲਈ ਲਿਖੀ ਗਈ ਸੀ।

ਦੂਜਾ ਕਦਮ: DNS ਅਤੇ IPv6 ਨੂੰ ਵੱਖਰੇ ਰਾਹਾਂ ਵਜੋਂ ਜਾਂਚੋ

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

dig +short example.com
dig +short @1.1.1.1 example.com
curl -6 -m 5 -sS https://example.com -o /dev/null -w '%{http_code}
'
ip -6 route

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

ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਬਾਹਰੋਂ ਪੜ੍ਹਨਾ ਔਖਾ ਬਣਾਉਂਦੇ ਹਨ, ਕਿਉਂਕਿ DNS over HTTPS ਲਈ ਕਨਫਿਗਰ ਕੀਤਾ ਬ੍ਰਾਊਜ਼ਰ ਪ੍ਰਸ਼ਨ ਨੂੰ HTTPS ਬੇਨਤੀ ਰਾਹੀਂ ਹੱਲ ਕਰਦਾ ਹੈ: ਪ੍ਰਸ਼ਨ ਓਨਾ ਹੀ ਰੁਕਿਆ ਹੁੰਦਾ ਹੈ ਜਿੰਨਾ ਉਸ ਸਿਰੇ ਤੱਕ ਦਾ ਪੋਰਟ 443 ਰੁਕਿਆ ਹੁੰਦਾ ਹੈ। ਜਿਸ ਹੋਸਟ 'ਤੇ ਨੀਤੀ ਸਥਾਨਕ ਸਬਨੈੱਟ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ, ਉੱਥੇ ਉਹ ਬੇਨਤੀ ਹਾਲੇ ਵੀ LAN ਦੇ ਰਿਜ਼ੌਲਵਰ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ।

ਤੀਜਾ ਕਦਮ: ਨੈੱਟਵਰਕ ਐਕਸਪੋਜ਼ਰ ਨੂੰ ਐਂਡਪੌਇੰਟ ਐਕਸਪੋਜ਼ਰ ਤੋਂ ਵੱਖ ਕਰੋ

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

ਰੁਜ਼ਗਾਰਦਾਤਾ ਵੱਲੋਂ ਜਾਣ-ਬੁੱਝ ਕੇ ਲਗਾਏ ਨਿਗਰਾਨੀ ਸਾਫ਼ਟਵੇਅਰ ਲਈ ਵੀ ਇਹੀ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਰਾਹ ਰੋਕਣ ਨਾਲ ਇਹ ਹਟਦਾ ਨਹੀਂ, ਅਤੇ ਨਵਾਂ VPN ਸਰਵਰ ਖਰੀਦਣਾ ਇਲਾਜ ਨਹੀਂ, ਕਿਉਂਕਿ ਐਕਸਪੋਜ਼ਰ ਟਨਲ ਤੋਂ ਪਹਿਲਾਂ ਹੈ।

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

ਚੌਥਾ ਕਦਮ: ਉਹ ਦਾਅਵਾ ਲਿਖੋ ਜਿਸਨੂੰ ਤੁਹਾਡਾ ਟੈਸਟ ਸਮਰਥਨ ਦਿੰਦਾ ਹੈ

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

ਦੋਵੇਂ ਸਮੱਸਿਆਵਾਂ ਵੱਖਰੀਆਂ ਰੱਖੋ ਅਤੇ ਹਰ ਇੱਕ ਨੂੰ ਆਪਣਾ ਨਿਯੰਤਰਣ ਦਿਓ:

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

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