Always-on ਅਤੇ kill switch ਇੱਕੋ ਸੈਟਿੰਗ ਸਕ੍ਰੀਨ 'ਤੇ ਦੋ ਲਾਈਨਾਂ ਦੀ ਦੂਰੀ 'ਤੇ ਹੁੰਦੇ ਹਨ, ਇਸ ਲਈ ਲੋਕ ਉਨ੍ਹਾਂ ਨੂੰ ਇੱਕੋ ਸੁਵਿਧਾ ਦੇ ਦੋ ਨਾਮ ਪੜ੍ਹਦੇ ਹਨ। ਉਹ ਅਜਿਹੇ ਨਹੀਂ ਹਨ। Always-on ਮੁੜ-ਜੁੜਨ ਦੀ ਨੀਤੀ ਹੈ: ਬੂਟ 'ਤੇ ਟਨਲ ਸ਼ੁਰੂ ਕਰੋ, ਕ੍ਰੈਸ਼ ਜਾਂ ਨੈੱਟਵਰਕ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਇਸਨੂੰ ਵਾਪਸ ਲਿਆਓ, ਅਤੇ ਫੇਲ ਹੁੰਦੇ ਰਹਿਣ ਤੱਕ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਰਹੋ। Kill switch ਟ੍ਰੈਫਿਕ ਦੀ ਨੀਤੀ ਹੈ: ਇਹ ਦੱਸਦਾ ਹੈ ਕਿ ਟਨਲ ਬੰਦ ਹੋਣ 'ਤੇ ਕਿਹੜੇ ਪੈਕਟ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਜਾ ਸਕਦੇ ਹਨ। ਪਹਿਲਾ ਦੂਜੇ ਤੋਂ ਬਿਨਾਂ ਚਾਲੂ ਕਰ ਸਕਦੇ ਹੋ, ਅਤੇ ਜ਼ਿਆਦਾਤਰ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਡਿਫਾਲਟ ਨਤੀਜਾ ਉਸ ਅੰਤਰਾਲ ਦੌਰਾਨ ਵੀ ਟ੍ਰੈਫਿਕ ਬਾਹਰ ਜਾਣ ਦਿੰਦਾ ਹੈ।

ਜਾਂਚ 1: ਕੀ ਬਲਾਕ ਆਪਣਾ ਵੱਖਰਾ ਸਵਿੱਚ ਹੈ?

Android 10 ਅਤੇ ਇਸ ਤੋਂ ਬਾਅਦ, ਸੰਭਾਲਿਆ VPN ਪ੍ਰੋਫਾਈਲ ਗੀਅਰ ਆਈਕਨ ਪਿੱਛੇ ਦੋ ਆਜ਼ਾਦ ਟੌਗਲ ਖੋਲ੍ਹਦਾ ਹੈ: Always-on VPN ਅਤੇ Block connections without VPN। kill switch ਸਿਰਫ਼ ਦੂਜਾ ਹੈ। ਸਿਰਫ਼ always-on ਨਾਲ ਟਨਲ ਡਿੱਗਣ ਤੋਂ ਬਾਅਦ ਵਾਪਸ ਆਉਂਦਾ ਹੈ, ਅਤੇ ਬੇਨਤੀ ਦੇ ਵਿਚਕਾਰਲੀ ਕੋਈ ਵੀ ਐਪ ਉਦੋਂ ਤੱਕ Wi-Fi ਜਾਂ ਮੋਬਾਈਲ ਡੇਟਾ ਰਾਹੀਂ ਨੈੱਟਵਰਕ ਤੱਕ ਪਹੁੰਚ ਸਕਦੀ ਹੈ।

ਪ੍ਰਬੰਧਿਤ ਡਿਵਾਈਸ ਨੀਤੀ API ਵਿੱਚ ਉਹੀ ਵੰਡ ਰੱਖਦੇ ਹਨ। setAlwaysOnVpnPackage() ਪੈਕੇਜ ਦਾ ਨਾਮ ਅਤੇ lockdownEnabled ਫਲੈਗ ਲੈਂਦਾ ਹੈ; ਜੋ ਪ੍ਰਬੰਧਕ ਪੈਕੇਜ ਸੈੱਟ ਕਰਕੇ ਫਲੈਗ false ਛੱਡ ਦਿੰਦਾ ਹੈ, ਉਸਨੇ ਪੱਕਾ ਟਨਲ ਬਣਾਇਆ ਹੈ, ਬੰਦ ਡਿਵਾਈਸ ਨਹੀਂ। ਕੰਸੋਲ ਦੀ ਸ਼ਬਦਾਵਲੀ ਇਹ ਫ਼ਰਕ ਘੱਟ ਹੀ ਦਿਖਾਉਂਦੀ ਹੈ।

ਸਥਿਤੀ ਕੰਸੋਲ ਤੋਂ ਨਹੀਂ, ਡਿਵਾਈਸ ਤੋਂ ਪੜ੍ਹੋ: adb shell settings get global always_on_vpn_app ਅਤੇ adb shell settings get global always_on_vpn_lockdown। ਜੇ ਪਹਿਲਾ null ਦਿੰਦਾ ਹੈ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਪੱਧਰ 'ਤੇ ਕੋਈ ਪੈਕੇਜ ਲਾਗੂ ਨਹੀਂ; ਜੇ ਦੂਜਾ 0 ਦਿੰਦਾ ਹੈ, ਤਾਂ ਪਲੇਟਫਾਰਮ ਕੁਝ ਵੀ ਬਲਾਕ ਨਹੀਂ ਕਰ ਰਿਹਾ। Android VPN ਗਾਈਡ ਇਨ੍ਹਾਂ ਨੂੰ ਇੱਕ ਮੋਡ ਨਹੀਂ, ਵੱਖਰੀਆਂ ਸਮਰੱਥਾਵਾਂ ਵਜੋਂ ਦੱਸਦੀ ਹੈ।

ਜਾਂਚ 2: ਬਲਾਕ ਕਿਹੜੀ ਪਰਤ ਦਾ ਹੈ?

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

Where you see the labelWhat the label promisesWhat actually blocks
Android VPN profileAlways-on VPNBlock connections without VPN
Android device policyAlways-on packagelockdownEnabled flag
Windows built-in VPNAlways On tunnelOutbound firewall rules
WireGuard for WindowsTunnel serviceBlock untunneled traffic option
wg-quick on LinuxRoute via AllowedIPsYour own nftables or iptables rules

Windows ਨਾ-ਬਲਾਕ ਕਰਨ ਵਾਲੇ ਲੇਬਲ ਦੀ ਸਭ ਤੋਂ ਸਾਫ਼ ਉਦਾਹਰਨ ਹੈ। ਉੱਥੇ Always On ਟਨਲ ਦੀ ਨਿਰੰਤਰਤਾ ਦੱਸਦਾ ਹੈ: ਮਸ਼ੀਨ ਪ੍ਰਮਾਣਿਕਤਾ ਲਈ ਡਿਵਾਈਸ ਟਨਲ ਅਤੇ ਸਾਈਨ-ਇਨ ਖਾਤੇ ਲਈ ਯੂਜ਼ਰ ਟਨਲ, ਪ੍ਰੋਫਾਈਲ XML ਜਾਂ Add-VpnConnection ਰਾਹੀਂ ਸੈੱਟ ਹੁੰਦਾ ਹੈ। ਉਸ ਪ੍ਰੋਫਾਈਲ ਵਿੱਚ ਟਨਲ ਨਾ ਹੋਣ 'ਤੇ ਬਾਹਰ ਜਾਣ ਵਾਲਾ ਪੈਕਟ ਰੋਕਣ ਵਾਲਾ ਕੁਝ ਨਹੀਂ, ਅਤੇ ਆਊਟਬਾਊਂਡ ਫਿਲਟਰਿੰਗ ਡਿਫਾਲਟ ਰੂਪ 'ਚ ਚਾਲੂ ਨਹੀਂ, ਇਸ ਲਈ Wi-Fi 'ਤੇ ਲੈਪਟਾਪ VPN ਬੰਦ ਹੋਣ 'ਤੇ ਵੀ ਕੰਮ ਕਰਦਾ ਰਹਿੰਦਾ ਹੈ।

WireGuard ਵੀ ਇਸੇ ਤਰ੍ਹਾਂ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ, ਪਰ ਕਲਾਇੰਟ ਅਨੁਸਾਰ। WireGuard for Windows ਵਿੱਚ ਹਰ ਟਨਲ ਲਈ ਫਿਲਟਰ ਨਿਯਮ ਲਾਉਣ ਵਾਲਾ Block untunneled traffic ਵਿਕਲਪ ਹੈ; Linux ਟੂਲਾਂ ਵਿੱਚ ਅਜਿਹਾ ਸਵਿੱਚ ਨਹੀਂ। wg-quick ਹਰ AllowedIPs ਐਂਟਰੀ ਲਈ ਰੂਟ ਅਤੇ ਇੱਕ fwmark ਨਿਯਮ ਜੋੜਦਾ ਹੈ, ਅਤੇ wg-quick down ਦੋਵੇਂ ਹਟਾ ਦਿੰਦਾ ਹੈ, ਇਸ ਲਈ ਭੌਤਿਕ ਡਿਫਾਲਟ ਰੂਟ ਇੱਕ ਵੀ ਪੈਕਟ ਡਿੱਗਣ ਤੋਂ ਬਿਨਾਂ ਮੁੜ ਸੰਭਾਲ ਲੈਂਦਾ ਹੈ।

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

ਜਾਂਚ 3: ਆਈਕਨ ਨਹੀਂ, ਅੰਤਰਾਲ ਮਾਪੋ

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

ਸਭ ਤੋਂ ਸਸਤਾ ਟੈਸਟ ਜਾਣ-ਬੁੱਝ ਕੇ ਟਨਲ ਬੰਦ ਕਰਦਾ ਹੈ ਅਤੇ ਫਿਰ ਬਾਹਰ ਨਿਕਲਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦਾ ਹੈ। ਟਨਲ ਬੰਦ ਹੋਣ 'ਤੇ curl -m 5 -sS -o /dev/null -w '%{http_code}' https://example.com ਦਾ 200 ਦੇਣਾ ਮਤਲਬ ਨੀਤੀ fail-open ਹੈ; ਟਾਈਮਆਊਟ ਜਾਂ ਰੱਦਿਆ ਕਨੈਕਸ਼ਨ ਮਤਲਬ ਕੁਝ ਅਜੇ ਵੀ ਬਲਾਕ ਕਰ ਰਿਹਾ ਹੈ। ip route get 1.1.1.1 ਉਸ ਇੰਟਰਫੇਸ ਦਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜੋ ਪੈਕਟ ਲੈ ਜਾਵੇਗਾ, ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਟਰੇ ਆਈਕਨ ਤੋਂ ਵੱਧ ਜਾਣਕਾਰੀ ਦਿੰਦਾ ਹੈ, ਅਤੇ systemctl status wg-quick@wg0 ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਇੰਟਰਫੇਸ ਸਾਫ਼ ਹਟਾਇਆ ਗਿਆ ਸੀ ਜਾਂ ਨਹੀਂ।

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

ਜਾਂਚ 4: ਲਾਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਅਪਵਾਦ ਤੈਅ ਕਰੋ

ਦੋ ਅਪਵਾਦ ਢਾਂਚਾਗਤ ਹਨ। ਕਲਾਇੰਟ ਨੂੰ ਖੁਦ VPN ਸਰਵਰ ਤੱਕ ਪਹੁੰਚਣਾ ਪੈਂਦਾ ਹੈ, ਇਸ ਲਈ ਸਭ ਕੁਝ ਸੁੱਟਣ ਵਾਲਾ ਨਿਯਮ-ਸਮੂਹ ਉਸ ਮੁੜ-ਜੁੜਨ ਨੂੰ ਵੀ ਰੋਕਦਾ ਹੈ ਜੋ ਸੁਰੱਖਿਆ ਵਾਪਸ ਲਿਆਵੇਗਾ। Captive portal ਤੱਕ ਵੀ ਉੱਠੇ ਬਿਨਾਂ ਟਨਲ ਰਾਹੀਂ ਨਹੀਂ ਪਹੁੰਚਿਆ ਜਾ ਸਕਦਾ, ਇਸ ਲਈ ਹੋਟਲ ਦੇ Wi-Fi 'ਤੇ ਲਾਕ ਕੀਤੇ ਡਿਵਾਈਸ ਨੂੰ ਪੋਰਟਲ ਖੋਲ੍ਹਣ ਦਾ ਲਿਖਤੀ ਤਰੀਕਾ ਚਾਹੀਦਾ ਹੈ, ਤੁਰੰਤ ਬਣਾਇਆ ਨਹੀਂ।

ਘੱਟੋ-ਘੱਟ ਰੂਪ, ਐਂਡਪੌਇੰਟ ਦੀ ਆਗਿਆ ਅਤੇ ਬਾਕੀ ਸਭ ਸੁੱਟਿਆ:

table inet vpnlock {
  chain output {
    type filter hook output priority 0; policy drop;
    oifname "lo" accept
    ip daddr 203.0.113.10 udp dport 51820 accept
    oifname "wg0" accept
  }
}

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

ਜਾਂਚ 5: ਅਸਲ ਵਿੱਚ ਕੀ ਸਾਬਤ ਕੀਤਾ, ਦਰਜ ਕਰੋ

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

ਇਸਨੂੰ ਪੂਰਾ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ:

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

ਸੰਬੰਧਿਤ ਲੇਖ