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

ਇੱਕ ਹੀ ਕੰਮ, ਦੋ ਢੰਗ

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

PropertyTeardown scriptFirewall unit
Runs when the client is killedNoYes
Needs privilege at teardown timeUsually yesConfigured once, at boot
Acts on the whole machineOften, including recovery pathsOnly on the flows it matches

ਉਹੀ ਸਾਰਣੀ ਪੂਰੀ ਦਲੀਲ ਹੈ। ਸਿਰਫ਼ ਸਾਫ਼ ਬੰਦ ਹੋਣ ਵੇਲੇ ਚੱਲਣ ਵਾਲੀ ਸਕ੍ਰਿਪਟ ਉਹ ਕੇਸ ਢਕਦੀ ਹੈ ਜਿਸ ਦੀ ਤੁਹਾਨੂੰ ਸਭ ਤੋਂ ਘੱਟ ਚਿੰਤਾ ਸੀ; ਅਸਲ ਕੇਸ ਕ੍ਰੈਸ਼ ਜਾਂ ਨੈੱਟਵਰਕ ਦਾ ਗਾਇਬ ਹੋਣਾ ਹੈ, ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਸਾਫ਼ ਟਿਅਰਡਾਊਨ ਨਹੀਂ ਦਿੰਦਾ।

ਟਿਅਰਡਾਊਨ ਹੁੱਕ ਕੀ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕੀ ਨਹੀਂ

ਦਰਜ ਪੈਟਰਨ ਨੈੱਟਵਰਕ ਇੰਟਰਫੇਸਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ ਅਤੇ loopback ਤੋਂ ਬਿਨਾਂ ਸਭ ਕੁਝ ਹੇਠਾਂ ਕਰ ਦਿੰਦਾ ਹੈ। ਭੌਤਿਕ ਜੰਤਰ ਹੇਠਾਂ ਹੋਣ ਵੇਲੇ ਟਨਲ ਤੋਂ ਬਾਹਰ ਕੁਝ ਨਹੀਂ ਬਚ ਸਕਦਾ, ਅਤੇ ਇਹੀ ਠੀਕ ਇਰਾਦਾ ਹੈ।

#!/bin/sh
for dev in /sys/class/net/*; do
  name=$(basename "$dev")
  [ "$name" = lo ] || ip link set dev "$name" down
done

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

ਹੁੱਕ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਵੇਖੋ ਕਲਾਇੰਟ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। root ਵਜੋਂ ਹੱਥੋਂ ਚਲਾਉਣ ਵੇਲੇ ਜੋ ਸਕ੍ਰਿਪਟ ਕੰਮ ਕਰਦੀ ਹੈ, ਉਹ ਬੂਟ ਵੇਲੇ ਸ਼ੁਰੂ ਹੋਣ ਵਾਲੀ ਸੇਵਾ ਬਾਰੇ ਕੁਝ ਸਾਬਤ ਨਹੀਂ ਕਰਦੀ।

ਫਾਇਰਵਾਲ ਨਿਯਮ ਕੀ ਵੱਖਰਾ ਕਰਦਾ ਹੈ

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

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

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

ਖਾਲੀ ਥਾਂ ਹੈ ਜਾਂ ਨਹੀਂ ਇਹ persist-tun ਤੈਅ ਕਰਦਾ ਹੈ

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

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

ਮੁੜ-ਕਨੈਕਸ਼ਨ ਦਾ ਰਸਤਾ ਜੀਵਿਤ ਰੱਖੋ, ਫਿਰ ਚਾਰ ਸਥਿਤੀਆਂ ਜਾਂਚੋ

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

ip route add 198.51.100.20/32 via 192.168.0.1 dev wlan0

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

ਸੰਬੰਧਿਤ ਲੇਖ