OpenVPN ਲਈ macOS pf ਕਿਲ ਸਵਿੱਚ: ਬੰਦ ਹੋਣ ਵਾਲੇ ਨਿਯਮ
pf ਨਿਯਮਾਂ ਦਾ ਸਮੂਹ ਸੁਰੰਗ ਹੇਠਾਂ ਹੋਣ ਵੇਲੇ ਸਿੱਧੀ ਟ੍ਰੈਫਿਕ ਰੋਕਦਾ ਹੈ। ਕਲਾਇੰਟ ਦਾ ਆਪਣੇ ਸਰਵਰ ਤੱਕ ਦਾ ਰਾਹ ਰੱਖੋ, ਫਿਰ ਸੁਰੰਗ ਬੰਦ ਕਰਕੇ ਰੋਕ ਸਾਬਤ ਕਰੋ।
macOS ਉੱਤੇ, ਕਿਲ ਸਵਿੱਚ ਉੱਤੇ ਹੀ ਚੰਗਾ ਹੁੰਦਾ ਹੈ ਜਿੰਨੀ ਇਸ ਪਿੱਛੇ ਪੈਕਟ ਫਿਲਟਰ ਨੀਤੀ, ਅਤੇ pf ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਉਹ ਨੀਤੀ ਲਾਗੂ ਕਰਦਾ ਹੈ। ਨੀਤੀ ਨੂੰ ਇੱਕੋ ਸਮੇਂ ਦੋ ਉਲਟ ਕੰਮ ਕਰਨੇ ਪੈਂਦੇ ਹਨ: ਕਲਾਇੰਟ ਨੂੰ ਆਪਣੇ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣ ਦੇਣਾ ਤਾਂ ਜੋ ਸੁਰੰਗ ਹੋ ਸਕੇ, ਅਤੇ ਬਾਕੀ ਸਭ ਨੂੰ ਸਿੱਧਾ ਬਾਹਰ ਜਾਣ ਤੋਂ ਰੋਕਣਾ। ਪ੍ਰਕਾਸ਼ਿਤ ਨਿਯਮ-ਸਮੂਹਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਦੂਜਾ ਕਰ ਲੈਂਦੇ ਹਨ ਅਤੇ ਪਹਿਲਾ ਭੁੱਲ ਜਾਂਦੇ ਹਨ, ਇਸ ਲਈ ਮਸ਼ੀਨ ਸੁਰੱਖਿਆ ਪਾਉਣ ਦੀ ਥਾਂ ਕਨੈਕਟੀਵਿਟੀ ਗੁਆ ਦਿੰਦੀ ਹੈ। ਜੋ ਸੰਸਕਰਣ ਕੰਮ ਕਰਦਾ ਹੈ ਉਹ ਅੰਤਮ ਬਿੰਦੂ, ਰਿਜ਼ੋਲਵਰ ਅਤੇ ਸੁਰੰਗ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਅਤੇ ਇਸ ਤੋਂ ਵੱਧ ਕੁਝ ਨਹੀਂ।
ਪੈਕਟ ਫਿਲਟਰ ਕੀ ਤੈਅ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ ਕੀ ਨਹੀਂ
pf ਇੰਟਰਫੇਸ, ਪਤੇ, ਪ੍ਰੋਟੋਕੋਲ ਨੰਬਰ ਅਤੇ ਪੋਰਟ ਦੇਖਦਾ ਹੈ, ਅਤੇ ਉੱਥੇ ਹੀ ਰੁਕ ਜਾਂਦਾ ਹੈ। ਇਹ ਕਦੇ ਨਹੀਂ ਜਾਣਦਾ ਕਿ ਕਿਹੜੀ ਪ੍ਰਕਿਰਿਆ ਨੇ ਸਾਕਟ ਖੋਲ੍ਹਿਆ, ਇਸ ਲਈ ਇੱਕ ਪ੍ਰੋਗਰਾਮ ਲਈ ਲਿਖੀ ਇਜਾਜ਼ਤ ਹਰ ਉਸ ਪ੍ਰੋਗਰਾਮ ਦੀ ਇਜਾਜ਼ਤ ਬਣ ਜਾਂਦੀ ਹੈ ਜੋ ਉਸੇ ਪੋਰਟ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ ਇੱਕ ਖੁੱਲ੍ਹਾ UDP ਅਪਵਾਦ ਕਿਲ ਸਵਿੱਚ ਨੂੰ ਫਿਰ ਆਮ ਨੈੱਟਵਰਕ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਐਪਲੀਕੇਸ਼ਨ-ਜਾਣੂ ਰੋਕ ਕਲਾਇੰਟ ਜਾਂ ਸਿਸਟਮ ਐਕਸਟੈਂਸ਼ਨ ਦਾ ਕੰਮ ਹੈ, ਇਸ ਫਾਈਲ ਦਾ ਨਹੀਂ।
ਫਿਲਟਰ ਰੂਟ ਵੀ ਨਹੀਂ ਬਣਾਉਂਦਾ। ਜਦੋਂ ਕਲਾਇੰਟ ਡਿੱਗਦਾ ਹੈ, ਡਿਫਾਲਟ ਰੂਟ ਅਜੇ ਵੀ ਕਿਸੇ ਮਰੇ ਸੁਰੰਗ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਅਤੇ pf ਉਸਨੂੰ Wi-Fi ਉੱਤੇ ਚੁੱਪਚਾਪ ਵਾਪਸ ਜਾਣ ਦੀ ਥਾਂ ਰੋਕੇ ਹੋਏ ਪੈਕਟਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। ਰੋਕ ਹੀ ਲੋੜੀਂਦਾ ਨਤੀਜਾ ਹੈ, ਟਾਲਣ ਵਾਲੀ ਖਰਾਬੀ ਨਹੀਂ।
ਨਤੀਜਾ ਨਿਯਮ ਦੇ ਪਾਠ ਨਾਲੋਂ ਵੱਧ ਵਾਰ ਕ੍ਰਮ ਤੈਅ ਕਰਦਾ ਹੈ। quick ਤੋਂ ਬਿਨਾਂ pf ਮੇਲ ਤੋਂ ਬਾਅਦ ਵੀ ਮੁਲਾਂਕਣ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਆਖਰੀ ਮਿਲਦਾ ਨਿਯਮ ਜਿੱਤਦਾ ਹੈ, ਇਸ ਲਈ ਹੇਠਾਂ ਵੱਲ ਇੱਕ ਚੌੜਾ ਪਾਸ ਉੱਪਰਲੇ ਸਾਵਧਾਨ ਅਪਵਾਦਾਂ ਨੂੰ ਰੱਦ ਕਰ ਦਿੰਦਾ ਹੈ। ਪਾਸਾਂ ਨੂੰ quick ਨਿਸ਼ਾਨ ਲਗਾਉਣ ਨਾਲ ਪਹਿਲਾ ਮੇਲ ਅੰਤਿਮ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਨੀਤੀ ਲੇਖਕ ਆਮ ਤੌਰ ’ਤੇ ਇਹੀ ਚਾਹੁੰਦਾ ਹੈ।
ਪਹਿਲਾਂ ਇੰਟਰਫੇਸ ਅਤੇ ਅੰਤਮ ਬਿੰਦੂ ਦੇ ਤੱਥ ਪੜ੍ਹੋ
ਹਰ Mac ਉੱਤੇ ਵਾਇਰਲੈਸ ਇੰਟਰਫੇਸ ਇੱਕੋ ਤਰ੍ਹਾਂ ਨੰਬਰ ਨਹੀਂ ਹੁੰਦੇ, ਅਤੇ ਸੁਰੰਗ ਡਿਵਾਈਸ ਨੂੰ ਅਜਿਹਾ ਨੰਬਰ ਮਿਲਦਾ ਹੈ ਜੋ ਬੂਟਾਂ ਵਿਚਕਾਰ ਬਦਲ ਸਕਦਾ ਹੈ। ਜੋ ਨਿਯਮ ਨਾ-ਮੌਜੂਦ ਡਿਵਾਈਸ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਉਹ ਪਾਰਸ ਹੁੰਦਿਆਂ ਫੇਲ੍ਹ ਹੋ ਜਾਂਦਾ ਹੈ, ਜੋ ਸ਼ੋਰਗੁਲ਼ ਅਤੇ ਫੜਨਾ ਸੌਖਾ ਹੈ, ਜਦਕਿ ਗਲਤ ਮੌਜੂਦ ਡਿਵਾਈਸ ਦਾ ਨਾਮ ਲੈਣ ਵਾਲਾ ਨਿਯਮ ਸਾਫ਼ ਪਾਰਸ ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹ ਟ੍ਰੈਫਿਕ ਆਉਣ ਦਿੰਦਾ ਹੈ ਜਿਸਨੂੰ ਤੁਸੀਂ ਰੋਕਣਾ ਚਾਹੁੰਦੇ ਸੀ।
ਤੱਥ ਉਦੋਂ ਇਕੱਠੇ ਕਰੋ ਜਦੋਂ ਕਲਾਇੰਟ ਜੁੜਿਆ ਹੋਵੇ, ਕਿਉਂਕਿ ਸੁਰੰਗ ਡਿਵਾਈਸ ਸਿਰਫ਼ ਤਦ ਹੀ ਹੁੰਦਾ ਹੈ। ਤੁਹਾਨੂੰ ਡਿਫਾਲਟ ਰੂਟ ਰੱਖਣ ਵਾਲਾ ਇੰਟਰਫੇਸ, ਕਲਾਇੰਟ ਵੱਲੋਂ ਬਣਾਇਆ ਡਿਵਾਈਸ, ਅਤੇ ਉਸ ਸਰਵਰ ਦਾ ਪਤਾ ਤੇ ਪੋਰਟ ਚਾਹੀਦਾ ਹੈ ਜਿਸਨੂੰ ਇਹ ਡਾਇਲ ਕਰਦਾ ਹੈ। ਉਹੀ ਆਖਰੀ ਮੁੱਲ ਹੈ ਜੋ ਜ਼ਿਆਦਾਤਰ ਨਿਯਮ-ਸਮੂਹ ਛੱਡ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਉਸਨੂੰ ਛੱਡਣਾ ਹੀ ਕਾਰਨ ਹੈ ਕਿ ਕਾਪੀ ਕੀਤਾ ਸਮੂਹ ਆਪਣੀ ਹੀ ਸੁਰੰਗ ਰੋਕ ਦਿੰਦਾ ਹੈ।
route -n get default
ifconfig -l
scutil --nc list
ਪਹਿਲਾ ਕਮਾਂਡ ਉਸ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ ਜੋ ਹੁਣ ਜਿੱਤ ਰਿਹਾ ਹੈ, ਦੂਜਾ ਹਰ ਉਸ ਡਿਵਾਈਸ ਦੀ ਸੂਚੀ ਦਿੰਦਾ ਹੈ ਜੋ ਕਰਨਲ ਜਾਣਦਾ ਹੈ, ਅਤੇ ਤੀਜਾ ਉਹ VPN ਕਨਫਿਗਰੇਸ਼ਨ ਦਿਖਾਉਂਦਾ ਹੈ ਜੋ ਸਿਸਟਮ ਸ਼ੁਰੂ ਕਰ ਸਕਦਾ ਹੈ। ਉਹ ਜਵਾਬ ਲਿਖ ਲਓ, ਫਿਰ ਕਲਾਇੰਟ ਦੀ ਆਪਣੀ ਕਨਫਿਗਰੇਸ਼ਨ ਤੋਂ ਸਰਵਰ ਦਾ ਪਤਾ ਅਤੇ ਪੋਰਟ ਪੜ੍ਹੋ।
ਸੁਰੰਗ ਦੇ ਰਾਹ ਦੁਆਲੇ ਨਿਯਮ-ਸਮੂਹ ਲਿਖੋ
ਹੇਠਾਂ ਦਿੱਤੀ ਫਾਈਲ ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਇਨਕਾਰ ਕਰਦੀ ਹੈ ਅਤੇ ਪੰਜ ਚੀਜ਼ਾਂ ਮੁੜ ਸਵੀਕਾਰ ਕਰਦੀ ਹੈ: ਲੂਪਬੈਕ, ਸੁਰੰਗ ਡਿਵਾਈਸ, ਕਲਾਇੰਟ ਦਾ ਆਪਣੇ ਸਰਵਰ ਤੱਕ ਦਾ ਰਾਹ, ਸੁਰੰਗ ਬਣਨ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਰਿਜ਼ੋਲਵਰ, ਅਤੇ ਉਹ ਦੋ ਅਦਲ-ਬਦਲ ਜੋ ਵਾਇਰਲੈਸ ਲਿੰਕ ਨੂੰ ਕੰਮ ਦਾ ਰੱਖਦੇ ਹਨ। ਇੰਟਰਫੇਸ ਨਾਮ ਅਤੇ ਸਰਵਰ ਦਾ ਪਤਾ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਇਸ ਲਈ ਜੋ ਮੁੱਲ ਤੁਸੀਂ ਪੁਸ਼ਟ ਕੀਤੇ ਹਨ ਉਹ ਰੱਖੋ। ਸੁਰੰਗ ਦਾ ਨੰਬਰ ਵੀ ਤੁਹਾਡੇ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਵੇਗਾ।
set skip on lo0
block all
pass out quick on utun0
# maintain this line when the server address changes
pass out quick on en1 inet proto udp to 203.0.113.10 port 1194
# only the resolver the client uses before the tunnel exists
pass out quick on en1 inet proto udp to 192.0.2.53 port 53
pass out quick on en1 inet proto udp from any port 68 to any port 67
pass out quick on en1 inet proto udp to 224.0.0.251 port 5353
DHCP ਲਾਈਨ ਇਸ ਲਈ ਹੈ ਕਿਉਂਕਿ Mac ਪਤਾ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਪਤਾ ਮੰਗਦਾ ਹੈ, ਇਸ ਲਈ ਬੇਨਤੀ ਕੰਮ ਦੇ ਸਰੋਤ ਪਤੇ ਤੋਂ ਬਿਨਾਂ ਪੋਰਟ 68 ਤੋਂ ਪੋਰਟ 67 ਵੱਲ ਨਿਕਲਦੀ ਹੈ। ਮਲਟੀਕਾਸਟ ਲਾਈਨ ਸਿਸਟਮ ਨੂੰ ਫੈਸਲਾ ਕਰਨ ਦਿੰਦੀ ਹੈ ਕਿ ਵਾਇਰਲੈਸ ਲਿੰਕ ਵਰਤਣ ਯੋਗ ਹੈ ਜਾਂ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਹਟਾਉਣ ਨਾਲ ਅਜਿਹੀ ਮਸ਼ੀਨ ਬਣਦੀ ਹੈ ਜੋ ਚੱਲ ਰਹੇ ਨੈੱਟਵਰਕ ਉੱਤੇ ਵੀ ਕੋਈ ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਦੱਸਦੀ। ਅੰਤਮ ਬਿੰਦੂ ਦੀ ਲਾਈਨ ਉਹ ਹੈ ਜੋ OpenVPN ਨੂੰ ਆਪਣੇ ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣ ਦਿੰਦੀ ਹੈ; ਇਸ ਤੋਂ ਬਿਨਾਂ block all ਬਾਹਰੀ ਹੈਂਡਸ਼ੇਕ ਡੇਗ ਦਿੰਦਾ ਹੈ ਅਤੇ ਸੁਰੰਗ ਕਦੇ ਉੱਪਰ ਨਹੀਂ ਆਉਂਦੀ। ਰਿਜ਼ੋਲਵਰ ਦੀ ਲਾਈਨ ਆਮ DNS ਇਜਾਜ਼ਤ ਨਾਲੋਂ ਤੰਗ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਮਸ਼ੀਨ ਵੱਲੋਂ ਕੀਤੇ ਹਰ ਸਵਾਲ ਦੀ ਥਾਂ ਇੱਕ ਪਤਾ ਅਤੇ ਇੱਕ ਪੋਰਟ ਦਾ ਨਾਮ ਲੈਂਦੀ ਹੈ।
ਉਹ ਅੰਤਮ ਬਿੰਦੂ ਅਤੇ ਰਿਜ਼ੋਲਵਰ ਅਪਵਾਦ ਹੀ ਦੋ ਹਨ ਜੋ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ; ਬਾਕੀ ਸਭ ਰੋਕਿਆ ਰਹਿੰਦਾ ਹੈ। ਜੇ ਕਲਾਇੰਟ ਸ਼ਬਦੀ ਪਤਾ ਡਾਇਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਰਿਜ਼ੋਲਵਰ ਲਾਈਨ ਹਟਾ ਦਿਓ ਅਤੇ ਅੰਤਮ ਬਿੰਦੂ ਦੀ ਲਾਈਨ ਰੱਖੋ। ਜੇ ਸਰਵਰ ਦਾ ਪਤਾ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਅਗਲੇ ਕਨੈਕਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਉਹ ਲਾਈਨ ਅੱਪਡੇਟ ਕਰੋ, ਜਾਂ ਕਲਾਇੰਟ ਦੇ ਆਪਣੇ ਹੁੱਕ ਤੋਂ pf ਟੇਬਲ ਭਰੋ ਅਤੇ ਇਸਦੀ ਥਾਂ ਟੇਬਲ ਨਾਲ ਮੇਲ ਕਰੋ।
ਸੁਰੰਗ ਹੇਠਾਂ ਉਤਾਰੋ, ਫਿਰ ਰੀਬੂਟ ਕਰੋ
ਲੋਡ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪਾਰਸ ਕਰੋ, ਕਿਉਂਕਿ ਵਾਕ-ਰਚਨਾ ਗਲਤੀ ਸੁੱਕੇ ਟੈਸਟ ਵਿੱਚ ਸਸਤੀ ਅਤੇ ਦੂਰ ਦੇ ਸੈਸ਼ਨ ਵਿੱਚ ਮਹਿੰਗੀ ਪੈਂਦੀ ਹੈ। ਫਿਰ ਫਾਈਲ ਲੋਡ ਕਰੋ, ਫਿਲਟਰ ਬੰਦ ਹੋਵੇ ਤਾਂ ਚਾਲੂ ਕਰੋ, ਅਤੇ ਪੜ੍ਹੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਲਾਗੂ ਹੈ। ਮੁੜ ਪੜ੍ਹਨਾ ਰਸਮ ਨਹੀਂ ਹੈ: ਕੋਈ ਹੋਰ ਐਂਕਰ ਤੁਹਾਡੇ ਨਾ ਲਿਖੇ ਨਿਯਮ ਜੋੜ ਸਕਦਾ ਹੈ, ਇਸ ਲਈ ਛਪੇ ਸਮੂਹ ਦੀ ਆਪਣੀ ਫਾਈਲ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
sudo pfctl -n -v -f /etc/pf.conf
sudo pfctl -f /etc/pf.conf
sudo pfctl -e
sudo pfctl -s rules
sudo pfctl -s Anchors
sudo pfctl -a <anchor> -s rules
sudo pfctl -s info
ਨਿਯਮ ਲੋਡ ਹੋਣ ’ਤੇ ਸੁਰੰਗ ਹੇਠਾਂ ਉਤਾਰੋ ਅਤੇ ਪੰਨਾ ਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ। ਆਮ ਟ੍ਰੈਫਿਕ ਰੁਕਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਮਸ਼ੀਨ ਦੇ ਸੌਣ ਤੇ ਜਾਗਣ ਤੋਂ ਬਾਅਦ ਵੀ ਰੁਕਿਆ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਸੇ ਤਬਦੀਲੀ ਵਿੱਚ ਪੁਰਾਣੀ ਹਾਲਤ ਵਾਪਸ ਆਉਂਦੀ ਹੈ। ਮੁੜ ਜੁੜੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਨਿਯਮ-ਸਮੂਹ ਨੂੰ ਛੋਹਣ ਤੋਂ ਬਿਨਾਂ ਟ੍ਰੈਫਿਕ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ। ਜੇ ਸੁਰੰਗ ਬੰਦ ਹੋਣ ’ਤੇ ਵੀ ਬ੍ਰਾਊਜ਼ਰ ਚੱਲਦਾ ਹੈ, ਤਾਂ ਕੋਈ ਨਿਯਮ ਤੁਹਾਡੀ ਸੋਚ ਨਾਲੋਂ ਚੌੜਾ ਹੈ, ਅਤੇ ਮੁੜ ਪੜ੍ਹਨਾ ਆਮ ਤੌਰ ’ਤੇ ਉਸਦਾ ਨਾਮ ਦੱਸ ਦਿੰਦਾ ਹੈ।
ਰੀਬੂਟ ਉਹ ਹਿੱਸਾ ਹੈ ਜੋ ਲੋਕ ਛੱਡ ਦਿੰਦੇ ਹਨ। macOS ਬੂਟ ’ਤੇ /etc/pf.conf ਪੜ੍ਹਦਾ ਹੈ, ਪਰ ਫਾਈਲ ਪੜ੍ਹਨਾ ਫਿਲਟਰ ਚਾਲੂ ਕਰਨ ਦੇ ਬਰਾਬਰ ਨਹੀਂ, ਇਸ ਲਈ ਹੁਣ ਕੰਮ ਕਰਨ ਵਾਲਾ ਨਿਯਮ-ਸਮੂਹ ਰੀਸਟਾਰਟ ਤੋਂ ਬਾਅਦ ਨਿਸ਼ਕਿਰਿਆ ਹੋ ਸਕਦਾ ਹੈ। ਫਿਰ sudo pfctl -s info ਚਲਾਓ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਥਿਤੀ ਲਾਈਨ ਫਿਲਟਰ ਨੂੰ ਸਰਗਰਮ ਦੱਸਦੀ ਹੈ।
ਬਾਹਰ ਨਿਕਲਣ ਅਤੇ ਰੀਸਟਾਰਟ ਦੇ ਰਾਹ ਨੂੰ ਇਮਾਨਦਾਰ ਰੱਖੋ
ਸਭ ਕੁਝ ਰੋਕਣ ਵਾਲਾ ਨਿਯਮ-ਸਮੂਹ ਤੁਹਾਨੂੰ ਦੂਰੋਂ ਸੰਭਾਲੀ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਵੀ ਕਰ ਸਕਦਾ ਹੈ। ਜਦੋਂ ਹੋ ਸਕੇ ਸਥਾਨਕ ਸੈਸ਼ਨ ਤੋਂ ਸੰਪਾਦਿਤ ਕਰੋ, ਪਿਛਲੀ ਫਾਈਲ ਨਵੀਂ ਦੇ ਕੋਲ ਰੱਖੋ, ਅਤੇ ਲੋੜ ਪੈਣ ਤੋਂ ਪਹਿਲਾਂ ਵਾਪਸੀ ਦਾ ਰਾਹ ਜਾਣੋ। ਹੇਠਾਂ ਦਿੱਤੇ ਕਮਾਂਡ ਫਿਲਟਰ ਬੰਦ ਕਰਦੇ ਹਨ ਅਤੇ ਤੁਹਾਡੀ ਰੱਖੀ ਕਾਪੀ ਮੁੜ ਲੋਡ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਕੰਸੋਲ ਤੋਂ ਚਲਾਉਣ ਦਾ ਕ੍ਰਮ ਹੈ, ਹੁਣੇ ਕੱਟੀ ਸੁਰੰਗ ਰਾਹੀਂ ਨਹੀਂ। ਪੰਜ ਸਕਿੰਟ ਦੀ ਵਾਪਸੀ ਹਰ ਵਾਰ ਇੱਕ ਚਤੁਰ ਨਿਯਮ ਨੂੰ ਹਰਾਉਂਦੀ ਹੈ।
sudo pfctl -d
sudo pfctl -f /etc/pf.conf.previous
sudo pfctl -s rules
ਟਿਕਾਊਪਣ ਲਈ ਲਾਂਚ ਡੀਮਨ ਚਾਹੀਦਾ ਹੈ ਜੋ pfctl -e ਚਲਾਵੇ ਅਤੇ ਬੂਟ ’ਤੇ ਤੁਹਾਡੀ ਫਾਈਲ ਲੋਡ ਕਰੇ। ਇਸਨੂੰ ਕਿਸੇ ਹੋਰ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਵਾਲੇ ਕੰਮ ਵਾਂਗ ਵੇਖੋ: ਪੂਰੇ ਪਾਥ, ਬਾਅਦ ਵਿੱਚ ਪੜ੍ਹਨ ਯੋਗ ਲਾਗ, ਅਤੇ ਉਸ ਮਸ਼ੀਨ ’ਤੇ ਟੈਸਟ ਜਿੱਥੇ ਤੁਸੀਂ ਸਰੀਰਕ ਤੌਰ ’ਤੇ ਪਹੁੰਚ ਸਕਦੇ ਹੋ। ਚੁੱਪਚਾਪ ਫੇਲ੍ਹ ਹੋਣ ਵਾਲਾ ਡੀਮਨ ਮਸ਼ੀਨ ਨੂੰ ਅਸੁਰੱਖਿਅਤ ਅਤੇ ਆਮ ਦਿਖਣ ਵਾਲਾ ਛੱਡ ਦਿੰਦਾ ਹੈ।
ਖਾਲੀ ਥਾਵਾਂ ਦਾ ਦਸਤਾਵੇਜ਼ ਬਣਾਓ, ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਉਸ ਦੂਜੇ VPN ਕਲਾਇੰਟ ਤੋਂ ਜੋ ਆਪਣਾ ਸੁਰੰਗ ਡਿਵਾਈਸ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਹਾਡੇ ਨਿਯਮ ਇੱਕ ਸੁਰੰਗ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਲੈਂਦੇ ਹਨ, ਇਸ ਲਈ ਦੂਜਾ ਰੋਕਿਆ ਰਹਿੰਦਾ ਹੈ ਜਾਂ ਬਾਅਦ ਵਿੱਚ ਜੋੜੇ ਚੌੜੇ ਨਿਯਮ ਨਾਲ ਮੇਲ ਖਾ ਜਾਂਦਾ ਹੈ। ਟੈਥਰਿੰਗ ਅਤੇ ਹਾਟਸਪਾਟ ਇੰਟਰਫੇਸ ਕਦੇ-ਕਦੇ ਹੀ ਦਿਸਦੇ ਹਨ ਅਤੇ ਉਸੇ ਟਿੱਪਣੀ ਦੇ ਯੋਗ ਹਨ। ਉਹਨਾਂ ਖਾਲੀ ਥਾਵਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਨੀਤੀ ਛੱਡਣ ਦਾ ਕਾਰਨ ਨਹੀਂ; ਇਹ ਉਹ ਸ਼ਰਤਾਂ ਹਨ ਜਿਨ੍ਹਾਂ ਹੇਠ ਇਹ ਅਜੇ ਵੀ ਲਾਗੂ ਹੈ।