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 ರ ಪರಿವರ್ತನೆಗಳು ಜೊತೆಗೆ ಒಂದು ಉದ್ದೇಶಪೂರ್ವಕ ವೈಫಲ್ಯ. ಕಮಾಂಡ್ ಔಟ್‌ಪುಟ್‌ನಿಂದ ತುಂಬಿಸಲಾಗದ ಸಾಲು ನೀವು ಪರೀಕ್ಷಿಸದ ಸಾಲು, ಮತ್ತು ಮರುಸಂಪರ್ಕದ ಸಾಲನ್ನು ದಾಟಿ ಬೂಟ್ ಸಾಲಿನಲ್ಲಿ ವಿಫಲವಾಗುವ ಸಾಧನ ಸಾಕಷ್ಟು ಸಾಮಾನ್ಯ, ಹಾಗಾಗಿ ಹೆಚ್ಚುವರಿ ಹತ್ತು ನಿಮಿಷ ಯೋಗ್ಯ.

ಇದನ್ನು ಮುಗಿದಿದೆ ಎಂದು ಹೇಳುವ ಮೊದಲು:

  • ಬ್ಲಾಕಿಂಗ್ ಸೆಟ್ಟಿಂಗ್ ಮರುಸಂಪರ್ಕ ಸೆಟ್ಟಿಂಗ್‌ನಿಂದ ಪ್ರತ್ಯೇಕ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಅದರ ಮೌಲ್ಯವನ್ನು ಸಾಧನದಲ್ಲಿ ಓದಿ.
  • ಬ್ಲಾಕ್ ಅನ್ನು ಯಾವ ಪದರ ಜಾರಿಗೊಳಿಸುತ್ತದೆ - ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ, ಸಾಧನ ನೀತಿ ಅಥವಾ ಫೈರ್‌ವಾಲ್ - ಮತ್ತು ಆ ಪದರ ಎಲ್ಲಿ ಸಂರಚಿಸಲಾಗಿದೆ ಎಂದು ತಿಳಿಯಿರಿ.
  • ಬ್ಲಾಕ್ ಸಾಬೀತುಪಡಿಸುವ ಒಂದು ಪರಿಶೀಲನಾ ಕಮಾಂಡ್ ಇಟ್ಟುಕೊಳ್ಳಿ, ಮತ್ತು ಅದನ್ನು ಪರಿವರ್ತನೆಯ ಸಮಯದಲ್ಲಿ ಚಲಾಯಿಸಿ, ನಂತರವಲ್ಲ.
  • ಅಪವಾದಗಳ ಪಟ್ಟಿಯನ್ನು, ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸೇರಿಸಿ, ಬರೆಯಿರಿ ಮತ್ತು ಅದನ್ನು ಯಾರು ನವೀಕರಿಸುತ್ತಾರೆ ಎಂದು ಗುರುತಿಸಿ.
  • ನಿರ್ವಹಿತ ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಜಾರಿಯಲ್ಲಿರುವ ನೀತಿಯನ್ನು ಬಿಡಿ; ಬ್ಲಾಕ್ ತೆಗೆಯುವುದು ಟನಲ್ ಸರಿಪಡಿಸುವ ಬದಲು ಅಗತ್ಯವನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು