ਕੀ VPN ਕਿਲ ਸਵਿੱਚ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਟਿਕਦੀ ਹੈ? ਇਸਨੂੰ ਕਿਵੇਂ ਜਾਂਚੀਏ
ਰੀਬੂਟ ਕਿਲ ਸਵਿੱਚ ਬਾਰੇ ਤੁਹਾਨੂੰ ਸੋਚ ਤੋਂ ਘੱਟ ਦੱਸਦਾ ਹੈ। ਕਿਹੜੀ ਪਰਤ ਬਲਾਕ ਨੂੰ ਬਹਾਲ ਕਰਦੀ ਹੈ, ਇਹ ਕਦੋਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ ਅਤੇ ਸਾਈਨ-ਇਨ ਤੋਂ ਪਹਿਲਾਂ ਇਸਨੂੰ ਕਿਵੇਂ ਪਰਖਣਾ ਹੈ, ਇਹ ਜਾਂਚੋ।
ਰੀਬੂਟ ਕਰਨਾ ਲੋਕਾਂ ਵੱਲੋਂ ਕਿਲ ਸਵਿੱਚ ਪਰਖਣ ਦਾ ਸਭ ਤੋਂ ਆਮ ਤਰੀਕਾ ਹੈ, ਅਤੇ ਇਹੀ ਸਭ ਤੋਂ ਵੱਧ ਝੂਠ ਬੋਲਣ ਵਾਲੀ ਜਾਂਚ ਹੈ। ਕਲਾਇੰਟ ਵਿੱਚ ਚੈਕਬਾਕਸ ਸਿਰਫ਼ ਇੱਕ ਤਰਜੀਹ ਹੈ; ਅਸਲ ਗੱਲ ਇਹ ਹੈ ਕਿ ਨੈੱਟਵਰਕ ਸਟੈਕ ਉੱਪਰ ਆਉਣ ਵਾਲੇ ਪਲ ਅਤੇ ਟਨਲ ਦੇ ਸੱਚਮੁੱਚ ਸਥਾਪਿਤ ਹੋਣ ਵਾਲੇ ਪਲ ਵਿਚਕਾਰ ਕੋਈ ਚੀਜ਼ ਬਲਾਕ ਲਾਗੂ ਕਰਦੀ ਹੈ ਜਾਂ ਨਹੀਂ। Windows ਉੱਤੇ ਉਹ ਚੀਜ਼ ਆਮ ਤੌਰ ਉੱਤੇ Windows Filtering Platform ਵਿੱਚ ਇੱਕ ਫਿਲਟਰ, Linux ਉੱਤੇ ਇੱਕ ਯੂਨਿਟ ਵੱਲੋਂ ਲੋਡ ਕੀਤਾ ਨਿਯਮ-ਸਮੂਹ, macOS ਉੱਤੇ pf ਐਂਕਰ, Android ਉੱਤੇ ਸਿਸਟਮ ਦੇ ਆਪਣੇ ਹਮੇਸ਼ਾ-ਚਾਲੂ ਅਤੇ ਲਾਕਡਾਊਨ ਫਲੈਗ ਹੁੰਦੇ ਹਨ। ਇਹ ਪ੍ਰਬੰਧ ਰੀਬੂਟ ਦੌਰਾਨ ਬਹੁਤ ਵੱਖਰੇ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ ਪਲੇਟਫਾਰਮ-ਪੱਧਰ ਦੇ ਪ੍ਰਬੰਧ ਹੀ ਕਿਸੇ ਦੇ ਸਾਈਨ ਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਆਪਣੀ ਥਾਂ ਉੱਤੇ ਹੁੰਦੇ ਹਨ।
ਰੀਬੂਟ ਤਿੰਨ ਵੱਖਰੇ ਸਵਾਲ ਪੁੱਛਦਾ ਹੈ
ਸਵਾਲ ਨੂੰ ਵੰਡੋ। ਪਹਿਲਾ, ਕੀ ਨੀਤੀ ਡਿਸਕ ਉੱਤੇ ਉਸ ਰੂਪ ਵਿੱਚ ਹੈ ਜਿਸਨੂੰ ਬੂਟ ਵੇਲੇ ਕੋਈ ਚੀਜ਼ ਪੜ੍ਹਦੀ ਹੈ? ਦੂਜਾ, ਕੀ ਉਹ ਪਾਠਕ ਕਿਸੇ ਵੀ ਟ੍ਰੈਫਿਕ ਦੇ ਬਾਹਰ ਜਾਣ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦਾ ਹੈ? ਤੀਜਾ, ਕੀ ਨੀਤੀ ਤੁਹਾਡੇ ਲਈ ਜ਼ਰੂਰੀ ਟ੍ਰੈਫਿਕ ਨੂੰ ਢਕਦੀ ਹੈ, ਯਾਨੀ ਹਰ ਪ੍ਰਕਿਰਿਆ, ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਅਤੇ DNS। ਪਹਿਲੇ ਨੂੰ ਹਾਂ ਅਤੇ ਦੂਜੇ ਨੂੰ ਨਾ ਆਖਣਾ ਠੀਕ ਉਹੀ ਅਸਫਲਤਾ ਪੈਦਾ ਕਰਦਾ ਹੈ ਜਿਸਨੂੰ ਲੋਕ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਨਾ ਟਿਕਣ ਵਾਲੀ ਕਿਲ ਸਵਿੱਚ ਕਹਿੰਦੇ ਹਨ: ਸ਼ੁਰੂ ਵੇਲੇ ਕੁਝ ਸਕਿੰਟ ਟ੍ਰੈਫਿਕ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਕੋਈ ਜਾਂਚਣ ਨਾ ਜਾਵੇ ਤਾਂ ਕਿਸੇ ਨੂੰ ਪਤਾ ਨਹੀਂ ਲੱਗਦਾ।
ਪਰਤਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖੋ। ਸੰਭਾਲਿਆ ਫਾਇਰਵਾਲ ਨਿਯਮ-ਸਮੂਹ, ਬੂਟ ਉੱਤੇ ਸ਼ੁਰੂ ਹੁੰਦੀ ਸੇਵਾ ਅਤੇ ਕਲਾਇੰਟ ਦੀ ਤਰਜੀਹ ਤਿੰਨ ਵੱਖਰੇ ਜੀਵਨ-ਕਾਲ ਵਾਲੀਆਂ ਤਿੰਨ ਵੱਖਰੀਆਂ ਵਸਤੂਆਂ ਹਨ। ਤਰਜੀਹ ਰੀਬੂਟ ਤੋਂ ਬਾਅਦ ਟਿਕਦੀ ਹੈ ਕਿਉਂਕਿ ਇਹ ਕਾਨਫਿਗ ਫਾਈਲ ਵਿੱਚ ਮੁੱਲ ਹੈ। ਨਿਯਮ ਹੀ ਇੱਕੋ-ਇੱਕ ਚੀਜ਼ ਹਨ ਜੋ ਪੈਕਟ ਰੋਕਦੇ ਹਨ, ਅਤੇ ਉਹ ਜਿਸ ਕਰਨਲ ਨੇ ਫੜਿਆ ਹੋਇਆ ਸੀ ਉਸ ਨਾਲ ਹੀ ਗਾਇਬ ਹੋ ਜਾਂਦੇ ਹਨ।
ਬਲਾਕ ਬਹਾਲ ਕਰਨ ਵਾਲੀ ਵਸਤੂ ਲੱਭੋ
Linux ਉੱਤੇ netfilter ਨਿਯਮ ਕਰਨਲ ਵਿੱਚ ਰਹਿੰਦੇ ਹਨ। ਤੁਸੀਂ ਪ੍ਰਬੰਧ ਨਾ ਕੀਤਾ ਹੋਵੇ ਤਾਂ ਬੂਟ ਵੇਲੇ ਕੋਈ ਚੀਜ਼ ਉਹਨਾਂ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਲਿਖਦੀ: iptables-save ਦੇ ਨਾਲ netfilter-persistent, nftables.service ਲੋਡ ਕਰਦਾ ਹੈ /etc/nftables.conf, ਜਾਂ ਤੁਹਾਡੀ ਆਪਣੀ ਸਕ੍ਰਿਪਟ ਚਲਾਉਂਦਾ systemd ਯੂਨਿਟ। ਕੀ ਸਮਰੱਥ ਹੈ ਇਹ ਜਾਂਚੋ, ਤੁਸੀਂ ਕੀ ਸੰਰਚਿਤ ਕੀਤਾ ਸੀ ਇਹ ਯਾਦ ਕਰਨ ਦੀ ਥਾਂ।
systemctl is-enabled nftables netfilter-persistent 2>/dev/null sudo nft list ruleset sudo iptables -S OUTPUT
ਬੂਟ ਤੋਂ ਕੁਝ ਸਕਿੰਟ ਬਾਅਦ ਖਾਲੀ ਨਿਯਮ-ਸਮੂਹ ਹੀ ਸਿਰਲੇਖ ਵਾਲੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਹੈ। Windows ਉੱਤੇ ਕਲਾਇੰਟ ਸੇਵਾ ਨੂੰ ਪੁੱਛੋ ਕਿ ਇਹ ਕਿਵੇਂ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਫਿਰ ਟਨਲ ਹੇਠਾਂ ਹੁੰਦਿਆਂ ਪਲੇਟਫਾਰਮ ਫਿਲਟਰ ਦੀ ਸਥਿਤੀ ਡੰਪ ਕਰੋ।
Get-Service | Where-Object { $_.Name -match 'vpn' } | Select-Object Name, Status, StartType
netsh wfp show stateਦੂਜਾ ਕਮਾਂਡ wfpstate.xml ਨੂੰ ਮੌਜੂਦਾ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਲਿਖਦਾ ਹੈ। ਕਲਾਇੰਟ ਜੁੜਨ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਮੌਜੂਦ ਬਲਾਕ ਕਿਰਿਆ ਵਾਲੇ ਫਿਲਟਰ ਲੱਭੋ। Base Filtering Engine ਬੂਟ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਹੀ ਚੱਲਦਾ ਹੈ ਅਤੇ ਸਥਾਈ ਫਲੈਗ ਨਾਲ ਜੋੜੇ ਫਿਲਟਰ ਬਹਾਲ ਕਰਦਾ ਹੈ, ਇਸੇ ਲਈ ਕੁਝ ਕਿਲ ਸਵਿੱਚ ਕੋਈ ਕਲਾਇੰਟ ਵਿੰਡੋ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਟ੍ਰੈਫਿਕ ਰੋਕਦੀਆਂ ਹਨ ਅਤੇ ਕੁਝ ਨਹੀਂ। macOS ਉੱਤੇ sudo pfctl -s info ਦੱਸਦਾ ਹੈ ਕਿ pf ਸਮਰੱਥ ਹੈ ਜਾਂ ਨਹੀਂ, sudo pfctl -s rules ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕੀ ਲੋਡ ਹੈ, ਅਤੇ VPN ਕਲਾਇੰਟ ਆਮ ਤੌਰ ਉੱਤੇ ਆਪਣੇ ਨਿਯਮ ਮੁੱਖ ਸਮੂਹ ਦੀ ਥਾਂ ਐਂਕਰ ਨਾਲ ਜੋੜਦੇ ਹਨ। ਜਿਹੜਾ ਨਿਯਮ utun3 ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ, ਉਹ ਅਗਲੇ ਬੂਟ ਤੋਂ ਬਾਅਦ ਕਿਸੇ ਹੋਰ ਇੰਟਰਫੇਸ ਵੱਲ ਸੰਕੇਤ ਕਰ ਸਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਉਹ ਨੰਬਰ ਰਨਟਾਈਮ ਵਿੱਚ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।
ਨੈੱਟਵਰਕ ਉੱਪਰ ਆਉਣ ਅਤੇ ਟਨਲ ਉੱਪਰ ਆਉਣ ਵਿਚਕਾਰਲੇ ਪਾੜੇ ਨੂੰ ਵੇਖੋ
ਖਤਰਨਾਕ ਅੰਤਰਾਲ ਪੂਰਾ ਰੀਬੂਟ ਨਹੀਂ, ਉਹ ਪਾੜਾ ਹੈ। ਇੰਟਰਫੇਸ ਨੂੰ ਇੱਕ ਪਲ ਲੀਜ਼ ਅਤੇ ਡਿਫਾਲਟ ਰੂਟ ਮਿਲਦਾ ਹੈ, VPN ਸੇਵਾ ਦੂਜੇ ਪਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਅਤੇ ਟਨਲ ਹੋਰ ਵੀ ਦੇਰ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ, ਕਈ ਵਾਰ ਤਾਂ ਵਰਤੋਂਕਾਰ ਦੇ ਸਾਈਨ ਇਨ ਕਰਨ ਅਤੇ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਏਜੰਟ ਦੇ ਚੱਲਣ ਤੋਂ ਬਾਅਦ ਹੀ। ਜੇ ਬਲਾਕ ਸਭ ਤੋਂ ਅੰਤ ਵਿੱਚ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਪਾੜੇ ਵਿੱਚ ਸਭ ਕੁਝ ਖੁੱਲ੍ਹਾ ਬਾਹਰ ਨਿਕਲ ਜਾਂਦਾ ਹੈ।
systemd ਹੋਸਟਾਂ ਉੱਤੇ ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਦੀ ਥਾਂ ਕ੍ਰਮ ਪੜ੍ਹੋ। VPN ਅਤੇ ਫਾਇਰਵਾਲ ਯੂਨਿਟਾਂ ਉੱਤੇ systemctl cat ਚਲਾਓ ਅਤੇ After= ਤੇ Before= ਦੇ ਮੁਕਾਬਲੇ network-pre.target ਜਾਂ network-online.target ਵੇਖੋ। network-online.target ਤੋਂ ਬਾਅਦ ਕ੍ਰਮਬੱਧ ਫਾਇਰਵਾਲ ਯੂਨਿਟ ਇੰਟਰਫੇਸ ਕੋਲੋਂ ਹਾਰ ਜਾਂਦੀ ਹੈ; ਜਿਸਦੀ network-pre.target ਮੰਗ ਕਰਦੀ ਹੈ ਅਤੇ ਜੋ ਉਸ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰਮਬੱਧ ਹੈ, ਉਹ ਜਿੱਤਦੀ ਹੈ। Windows ਉੱਤੇ ਬਰਾਬਰ ਦੇ ਸਵਾਲ ਸੇਵਾ ਦੀ ਸਟਾਰਟ ਕਿਸਮ ਅਤੇ ਉਸਦੀਆਂ ਨਿਰਭਰਤਾਵਾਂ ਹਨ, ਕਿਉਂਕਿ Manual ਉੱਤੇ ਰੱਖੀ ਸੇਵਾ ਬੂਟ-ਸਮੇਂ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਰੋਕ ਨਹੀਂ ਸਕਦੀ। ਜੇ ਤੁਹਾਡੀ ਲੋੜ ਵਿੱਚ ਸਾਈਨ-ਇਨ ਤੋਂ ਪਹਿਲਾਂ ਦਾ ਟ੍ਰੈਫਿਕ ਵੀ ਸ਼ਾਮਲ ਹੈ, ਤਾਂ ਸਿਰਫ਼ ਡਿਵਾਈਸ-ਪੱਧਰੀ ਪ੍ਰਬੰਧ ਹੀ ਇਸਨੂੰ ਪੂਰਾ ਕਰਦਾ ਹੈ: Always On VPN ਡਿਵਾਈਸ ਟਨਲ ਮਸ਼ੀਨ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਪ੍ਰਮਾਣਿਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਵਰਤੋਂਕਾਰ ਦੇ ਲੌਗਇਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਜੁੜਦਾ ਹੈ, ਅਤੇ Microsoft ਡਿਵਾਈਸ ਟਨਲ ਦੀ ਕਾਨਫਿਗਰੇਸ਼ਨ ਦਸਤਾਵੇਜ਼ਬੱਧ ਕਰਦਾ ਹੈ ਵਰਤੋਂਕਾਰ ਟਨਲ ਤੋਂ ਵੱਖਰੀ। Android ਹੋਰ ਰਾਹ ਲੈਂਦਾ ਹੈ, ਹਮੇਸ਼ਾ-ਚਾਲੂ VPN ਲਾਗੂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਤੋਂ ਬਿਨਾਂ ਜੁੜਾਅ ਐਪ ਪ੍ਰਕਿਰਿਆ ਤੋਂ ਨਹੀਂ, ਸਿਸਟਮ ਤੋਂ ਰੋਕਦਾ ਹੈ।
ਜਾਂਚ ਚਲਾਓ, ਫਿਰ ਦੋ ਸਮਾਂ-ਰੇਖਾਵਾਂ ਦੀ ਤੁਲਨਾ ਕਰੋ
ਜੇ ਲੀਕ ਹੋਵੇ ਤਾਂ ਕੁਝ ਵੀ ਖਰਚ ਨਾ ਹੋਣ ਵਾਲੀ ਮੰਜ਼ਿਲ ਨਾਲ ਰੀਬੂਟ ਕਰੋ, ਅਤੇ ਸਥਿਤੀ ਪਾੜੇ ਤੋਂ ਬਾਅਦ ਨਹੀਂ, ਪਾੜੇ ਦੌਰਾਨ ਕੈਪਚਰ ਕਰੋ। ਸਭ ਤੋਂ ਸਾਫ਼ ਤਰੀਕਾ ਬੂਟ-ਸਮੇਂ ਪ੍ਰੋਬ ਹੈ: ਪਲੇਟਫਾਰਮ ਜਿੰਨੀ ਜਲਦੀ ਆਗਿਆ ਦਿੰਦਾ ਹੈ ਓਨੀ ਜਲਦੀ ਸ਼ੁਰੂ ਹੁੰਦਾ oneshot ਯੂਨਿਟ ਜਾਂ ਨਿਯਤ ਕੀਤਾ ਕੰਮ, ਜੋ ਡਿਫਾਲਟ ਰੂਟ ਅਤੇ ਫਾਇਰਵਾਲ ਸਥਿਤੀ ਦਰਜ ਕਰਦਾ ਹੈ, ਛੋਟੇ ਟਾਈਮਆਊਟ ਨਾਲ ਇੱਕ ਬੇਨਤੀ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ ਅਤੇ ਸਥਾਨਕ ਫਾਈਲ ਵਿੱਚ ਇੱਕ ਲਾਈਨ ਜੋੜਦਾ ਹੈ। ਉਸ ਰਿਕਾਰਡ ਦੀ journalctl -b -u ਜਾਂ ਸਿਸਟਮ ਲੌਗ ਤੋਂ ਮਿਲਦੇ VPN ਸੇਵਾ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਦੇ ਸਮੇਂ ਨਾਲ ਤੁਲਨਾ ਕਰੋ।
ਫਿਰ ਆਮ ਜਾਂਚ ਚਲਾਓ: ਟਨਲ ਉੱਤੇ, ਜੁੜਾਅ ਕੱਟੋ, ਸਿੱਧਾ ਟ੍ਰੈਫਿਕ ਰੁਕਦਾ ਹੈ ਜਾਂ ਨਹੀਂ ਵੇਖੋ, ਬਹਾਲ ਕਰੋ। ਦੂਜੇ ਵਿੱਚ ਪਾਸ ਹੋਣਾ ਅਤੇ ਪਹਿਲੇ ਵਿੱਚ ਫੇਲ ਹੋਣਾ ਆਮ ਨਤੀਜਾ ਹੈ, ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਲਾਗੂ ਕਰਨਾ ਕਲਾਇੰਟ ਪਾਸੇ ਹੈ, ਕਲਾਇੰਟ ਦੇ ਜੁੜਨ ਵੇਲੇ ਲਾਗੂ ਹੁੰਦਾ ਹੈ, ਬੂਟ ਉੱਤੇ ਨਹੀਂ। ਮੈਂ ਸਭ ਤੋਂ ਅੰਤ ਵਿੱਚ ਜਿਸ ਮਸ਼ੀਨ ਦੀ ਜਾਂਚ ਕੀਤੀ, ਉਸ ਵਿੱਚ ਬਲਾਕ NetworkManager ਦੀ ਡਿਸਪੈਚਰ ਸਕ੍ਰਿਪਟ ਤੋਂ ਆਇਆ ਸੀ: ਮੌਜੂਦ ਅਤੇ ਸਹੀ ਅਤੇ ਇੰਟਰਫੇਸ ਉੱਪਰ ਆਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦੇ ਸਕਿੰਟਾਂ ਲਈ ਬੇਕਾਰ। ਦੋਵੇਂ ਨਤੀਜੇ ਲਿਖੋ, ਕਿਉਂਕਿ ਰੀਬੂਟ ਵਿੱਚ ਟਿਕਣ ਦਾ ਅਰਥ ਤਦ ਹੀ ਹੈ ਜਦੋਂ ਤੁਸੀਂ ਦੱਸੋ ਕਿ ਕਿਹੜੀ ਪਰਤ ਕਿਹੜੇ ਪਲ ਤੋਂ ਟਿਕੀ।
ਵਾਪਸੀ ਦਾ ਰਾਹ ਤੋੜੇ ਬਿਨਾਂ ਪਾੜਾ ਬੰਦ ਕਰੋ
ਜੇ ਬੂਟ ਉੱਤੇ ਬਲਾਕ ਨਹੀਂ ਹੈ, ਤਾਂ ਦੂਜਾ ਕਲਾਇੰਟ ਨਿਯਮ ਜੋੜਨ ਦੀ ਥਾਂ ਲਾਗੂ ਕਰਨ ਨੂੰ ਇੱਕ ਪਰਤ ਹੇਠਾਂ ਲੈ ਜਾਓ। ਨਿਯਮ-ਸਮੂਹ ਸੰਭਾਲੋ ਅਤੇ ਨੈੱਟਵਰਕ ਵਰਤੋਂਯੋਗ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕ੍ਰਮਬੱਧ ਯੂਨਿਟ ਤੋਂ ਲੋਡ ਕਰੋ, ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਸ ਯੂਨਿਟ ਨੂੰ ਉਹ DNS ਖੋਜ ਜਾਂ ਨੈੱਟਵਰਕ ਮਾਊਂਟ ਨਹੀਂ ਚਾਹੀਦਾ ਜਿਸਦੀ ਉਹ ਰੱਖਿਆ ਕਰਨੀ ਹੈ। ਦਾਇਰਾ ਸਮੇਂ ਜਿੰਨਾ ਹੀ ਜ਼ਰੂਰੀ ਹੈ: ਵਰਤੋਂਕਾਰ ID ਜਾਂ cgroup ਨਾਲ ਮਿਲਦੇ ਨਿਯਮ ਹਰ ਸਿਸਟਮ ਡੈਮਨ ਨੂੰ ਬਲਾਕ ਤੋਂ ਬਾਹਰ ਰੱਖਦੇ ਹਨ, ਅਤੇ ਸਿਰਫ਼ IPv4 ਸੰਭਾਲਣ ਵਾਲਾ ਸਮੂਹ IPv6 ਅਤੇ DNS ਨੂੰ ਪਹੁੰਚਯੋਗ ਰੱਖਦਾ ਹੈ।
ਆਪਣੇ ਲਈ ਵਾਪਸੀ ਦਾ ਰਾਹ ਛੱਡੋ। ਜੋ ਮਸ਼ੀਨ ਬੂਟ ਉੱਤੇ ਸਭ ਕੁਝ ਰੋਕਦੀ ਹੈ ਅਤੇ ਫਿਰ ਪ੍ਰਮਾਣਿਤ ਨਹੀਂ ਕਰ ਸਕਦੀ, ਉਸ ਕੋਲ ਨੈੱਟਵਰਕ ਹੀ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਹੱਲ ਬਲਾਕ ਮਿਟਾਉਣਾ ਨਹੀਂ ਬਲਕਿ ਕ੍ਰੈਡੈਂਸ਼ੀਅਲ ਜਾਂ ਕ੍ਰਮ ਠੀਕ ਕਰਨਾ ਹੈ। ਸਥਾਨਕ ਕੰਸੋਲ ਦੀ ਦਸਤਾਵੇਜ਼ਬੱਧ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਟਨਲ ਨੂੰ ਸੱਚਮੁੱਚ ਜੋ ਚਾਹੀਦਾ ਹੈ ਉਸ ਲਈ ਤੰਗ, ਜਾਣ-ਬੁੱਝ ਕੇ ਕੀਤਾ ਅਪਵਾਦ ਰੱਖੋ, ਜਿਵੇਂ ਸਰਵਰ ਦਾ ਪਤਾ ਅਤੇ ਟਨਲ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਰਿਜ਼ੌਲਵਰ।
ਇਸ ਪ੍ਰਬੰਧ ਉੱਤੇ ਭਰੋਸਾ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਚਾਰ ਚੀਜ਼ਾਂ ਕ੍ਰਮ ਨਾਲ ਪੱਕੀਆਂ ਕਰੋ। ਨੀਤੀ ਉੱਥੇ ਸੰਭਾਲੀ ਹੈ ਜਿੱਥੋਂ ਬੂਟ ਪੜ੍ਹਦਾ ਹੈ। ਉਹ ਪਾਠਕ ਇੰਟਰਫੇਸ ਵਰਤੋਂਯੋਗ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਚੱਲਦਾ ਹੈ। ਬਲਾਕ ਦੋਵੇਂ ਪਤਾ ਪਰਿਵਾਰ ਅਤੇ DNS ਢਕਦਾ ਹੈ। ਬਲਾਕ ਸਰਗਰਮ ਹੁੰਦਿਆਂ ਵੀ VPN ਪ੍ਰਮਾਣਿਤ ਕਰ ਸਕਦਾ ਹੈ। ਚਾਰੇ ਪੂਰੇ ਹੋਣ ਤੇ ਰੀਬੂਟ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ।