VPN ಆನ್ ಇರುವಾಗ ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಾಗಬಾರದು: ಅದನ್ನು ಯಾವುದು ಜಾರಿಗೊಳಿಸುತ್ತದೆ

kill switch ಗಳು ಮತ್ತು ಅತಿಕ್ರಮಣ-ನಿಷೇಧದ ನಿಯಮಗಳು ವಿರುದ್ಧ ದಿಕ್ಕುಗಳಿಗೆ ತೋರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ VPN ಸೆಟ್ಟಿಂಗ್‌ಗಳು ಎರಡನೆಯದನ್ನು ಎಂದಿಗೂ ವ್ಯಕ್ತಪಡಿಸುವುದಿಲ್ಲ. kill switch ಕುಸಿದ ಟನೆಲ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ, ಆದರೆ ಈ ಅಗತ್ಯವು ಮೇಲಿರುವ ಟನೆಲ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಚಿತ್ರದಿಂದ ಹೊರಗಿಡುತ್ತದೆ. ಒಂದು ವಿನ್ಯಾಸ ನಿರ್ಧಾರವು ಬಹುಪಾಲನ್ನು ಪರಿಹರಿಸುತ್ತದೆ: ಅಪ್ಲಿಕೇಶನ್ ನಿಲ್ಲಿಸಬೇಕೋ, ಪ್ರಾರಂಭವನ್ನು ತಡೆಯಬೇಕೋ, ಅಥವಾ ಕೇವಲ ನೆಟ್‌ವರ್ಕ್ ಪ್ರವೇಶವನ್ನು ಕಸಿದುಕೊಳ್ಳಬೇಕೋ. ಫೈರ್‌ವಾಲ್ ನಿಯಮ ಅಥವಾ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಕೊಲ್ಲುವ ಲೂಪ್‌ಗೆ ಕೈಹಾಕುವ ಮೊದಲು ಆ ಪದರವನ್ನು ಆರಿಸಿ, ಏಕೆಂದರೆ ವೀಕ್ಷಣೆಯಿಂದ ಜಾರಿಗೊಳಿಸುವ ನಿಯಮವು ಪ್ರತಿ ಪ್ರಾರಂಭದಲ್ಲೂ ಒಂದು ಕಿಟಕಿಯನ್ನು ಸೋರಿಸುತ್ತದೆ.

ಪುರಾಣ: kill switch ಪ್ರೋಗ್ರಾಂಗಳು ಪ್ರಾರಂಭವಾಗುವುದನ್ನು ತಡೆಯುತ್ತದೆ

kill switch ಗಳು ಸಂಚಾರ ನಿಯಂತ್ರಣಗಳು, ಮತ್ತು ಅವು ಅದರ ಬಗ್ಗೆ ಪ್ರಾಮಾಣಿಕ: ಟನೆಲ್ ಸ್ಥಿತಿಯ ಪ್ರಕಾರ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅನುಮತಿಸುತ್ತವೆ ಅಥವಾ ನಿರಾಕರಿಸುತ್ತವೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪ್ರೋಗ್ರಾಂ ಪ್ರಾರಂಭಿಸಲು ನಿರಾಕರಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಯಾವುದೂ ಯಾವ ಎಕ್ಸಿಕ್ಯೂಟೆಬಲ್ ಸಾಕೆಟ್ ತೆರೆಯಿತು ಎಂದು ಪರಿಶೀಲಿಸುವುದಿಲ್ಲ. ಡೆಸ್ಕ್‌ಟಾಪ್ ಶಾರ್ಟ್‌ಕಟ್, ನಿಗದಿತ ಕಾರ್ಯ ಮತ್ತು ಹಿನ್ನೆಲೆ ಸಹಾಯಕ—ಎಲ್ಲವೂ ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೆಸರು ತಿಳಿದ ಯಾವುದನ್ನೂ ದಾಟದೆ ನೆಟ್‌ವರ್ಕ್ ತಲುಪುತ್ತವೆ. ಈ ಎರಡು ಯಾಂತ್ರಿಕೆಗಳ ನಡುವಿನ ಅಂತರವೇ ಬಹುಪಾಲು ಗೊಂದಲ ವಾಸಿಸುವ ಸ್ಥಳ.

ಪ್ರೋಗ್ರಾಂ ಪ್ರಾರಂಭವಾಗಬಹುದೇ ಎಂಬುದನ್ನು ನಿಜವಾಗಿ ನಿರ್ಧರಿಸುವ ವ್ಯವಸ್ಥೆ ಅಪ್ಲಿಕೇಶನ್ ನಿಯಂತ್ರಣ. Windows ನಲ್ಲಿ ಅದು AppLocker ಅಥವಾ WDAC, ನಿರ್ವಹಿಸಲಾದ macOS ನಲ್ಲಿ ಸಾಧನ ಪ್ರೊಫೈಲ್ ಜಾರಿಗೊಳಿಸುವ ಅನುಮತಿ ಪಟ್ಟಿ. ಎರಡೂ ಟನೆಲ್‌ನಿಂದ ಸ್ವತಂತ್ರ, ಆದ್ದರಿಂದ ಎರಡೂ ಅಗತ್ಯಗಳನ್ನು ಒಂದೇ ಟಿಕೆಟ್‌ನಲ್ಲಿ ವಿಲೀನಗೊಳಿಸಿ ನಂತರ ಯಾವುದೂ ಪೂರೈಸುವುದಿಲ್ಲ.

ಸಾಧನಕ್ಕೆ ಹೆಸರಿಡುವ ಮೊದಲು ಮೋಡ್‌ಗೆ ಹೆಸರಿಡಿ

ನಿಯಮವನ್ನು ಮೂರು ಸ್ಥಿತಿಗಳ ಸ್ಟೇಟ್ ಮೆಷಿನ್ ಆಗಿ ಬರೆಯಿರಿ: ಸಾಮಾನ್ಯ ಬಳಕೆ, VPN ಕೆಲಸದ ಅವಧಿ ಮತ್ತು ನಿರ್ಗಮನ. ನಿಷಿದ್ಧ ಅತಿಕ್ರಮಣವು ಮಧ್ಯದ ಸ್ಥಿತಿಗೆ ಸೇರಿದೆ, ಕ್ಲೈಂಟ್ ಸಾಫ್ಟ್‌ವೇರ್‌ಗೆ ಅಲ್ಲ.

ಸ್ಥಿತಿಯನ್ನು ಬದಲಿಸುವವರು ಕ್ರಮವಾಗಿ ಮೂರು ಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ: ಅಪ್ಲಿಕೇಶನ್‌ನ ಕೆಲಸ ಮುಗಿಸುವುದು, ಅದರ ಸಾಮಾನ್ಯ ಸ್ಥಗಿತವನ್ನು ಕೇಳುವುದು, ಮತ್ತು ಟನೆಲ್ ಮೇಲೇರುವ ಮೊದಲು ನಿದರ್ಶನ ಹೋಗಿದೆ ಎಂದು ದೃಢೀಕರಿಸುವುದು. ಇನ್ನೊಂದು ತುದಿಯಲ್ಲೂ ಕ್ರಮ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಮೊದಲು ಸಂಪರ್ಕಿಸಿ ನಂತರ ಪ್ರೋಗ್ರಾಂ ನಿಲ್ಲಿಸುವ VPN ಈಗಾಗಲೇ ಅತಿಕ್ರಮಣಕ್ಕೆ ಅವಕಾಶ ನೀಡಿದೆ. ಅಗತ್ಯವು ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯನ್ನು ಒಳಗೊಂಡರೆ, ಸಂಪರ್ಕಿತ ಸೂಚಕಕ್ಕಾಗಿ ಕಾಯುವುದು ತೀರ ತಡವಾಗಿದೆ.

ದ್ವಿಮುಖ ಘರ್ಷಣೆ ನಿಜವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ

ನಿಜವಾಗಿ systemd ನಿರ್ವಹಿಸುವ ಎರಡು ಸೇವೆಗಳಿಗೆ Conflicts= ಸಮ್ಮಿತೀಯ: ಒಂದನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ ಇನ್ನೊಂದು ನಿಲ್ಲುತ್ತದೆ. ಯುನಿಟ್ ಉಲ್ಲೇಖ ಈ ವರ್ತನೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ ಮತ್ತು ಒಂದು ನಿಲ್ಲಿಸುವುದನ್ನು ಮುಗಿಸಬೇಕಾದಾಗ ಇನ್ನೊಂದು ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲು ಸ್ಪಷ್ಟ ಕ್ರಮವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಒತ್ತಾಯಿಸುತ್ತದೆ. ಆ ಕ್ರಮ ನಮೂದುಗಳಿಲ್ಲದೆ ನಿಲ್ಲಿಸುವಿಕೆ ಮತ್ತು ಪ್ರಾರಂಭ ಸ್ಪರ್ಧಿಸುತ್ತವೆ, ಮತ್ತು ಫಲಿತಾಂಶ ಸಮಯವನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಇದು ನಿರಾಕರಣೆ ಪಟ್ಟಿ ಅಲ್ಲ. ಅವಲಂಬನೆಯನ್ನು ತಲೆಕೆಳಗಾಗಿ ಜೋಡಿಸಿ, ಆಗ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭವು ಬದಲಿಗೆ VPN ಅನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಟನೆಲ್ ಮುನ್ಸೂಚನೀಯ ಕ್ಷಣದಲ್ಲಿ ತಾನಾಗಿಯೇ ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸಿದಾಗ ಶಂಕಿಸಬೇಕಾದ ವೈಫಲ್ಯ ಅದೇ. ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲಿಕೇಶನ್ systemd ಯುನಿಟ್ ಅಲ್ಲ, NetworkManager ಸಂಪರ್ಕವೂ ಯುನಿಟ್ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಈ ಮಾದರಿ ನೀವೇ ಸುತ್ತುವ ಸೇವೆಗಳಿಗೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ.

ಮೊದಲ ಪ್ರಾರಂಭವಲ್ಲ, ಪರಿವರ್ತನೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ

ನಾಲ್ಕು ಪರಿವರ್ತನೆಗಳು ಅಗತ್ಯವು ನಿಲ್ಲುತ್ತದೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ: ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಅವಧಿಗೆ ಪ್ರವೇಶ, ಅವಧಿಯ ಮಧ್ಯದಲ್ಲಿ ಅದನ್ನು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸುವುದು, ವಿಫಲ VPN ಪ್ರಾರಂಭ, ಮತ್ತು ಉದ್ದೇಶಪೂರ್ವಕ ಸಂಪರ್ಕ ಕಡಿತ. ಪ್ರತಿಯೊಂದನ್ನು ಪರೀಕ್ಷಿಸಿ ಫಲಿತಾಂಶವನ್ನು ಯುನಿಟ್ ಫೈಲ್‌ಗಳ ಪಕ್ಕದಲ್ಲಿ ಇಡಿ. ಕೆಳಗಿನ ಆದೇಶಗಳು ಪ್ರಸ್ತುತ ಸಂಬಂಧವನ್ನು ಓದಿ ನಂತರ ಅತ್ಯಂತ ಮುಖ್ಯವಾದ ಪರಿವರ್ತನೆಯನ್ನು ಅಭ್ಯಾಸ ಮಾಡುತ್ತವೆ.

systemctl show work-vpn.service -p Conflicts -p After
systemctl start work-vpn.service
systemctl is-active office-sync.service
nmcli connection show --active

ಮೂರನೇ ಆದೇಶವು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯವಾಗಿ ಬಿಡಬೇಕು, ಮತ್ತು ನಾಲ್ಕನೆಯದು ಅವಧಿ ನಡೆಯುತ್ತಿರುವಾಗ ಕೇವಲ ಟನೆಲ್ ಸಂಪರ್ಕವನ್ನು ಪಟ್ಟಿ ಮಾಡಬೇಕು. ಬೇರೆ ಫಲಿತಾಂಶ ಎಂದರೆ ಪರಿವರ್ತನೆ ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಜಾರಿಯಾಗುತ್ತಿಲ್ಲ.

ಅವಧಿಯ ಸಮಯದಲ್ಲಿ ಮರುಪ್ರಾರಂಭವು ಹೊದಿಕೆ-ಆಧಾರಿತ ವಿನ್ಯಾಸವನ್ನು ಬಯಲು ಮಾಡುವ ಸಂದರ್ಭ, ಏಕೆಂದರೆ ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಿಂದ ಪ್ರಾರಂಭವಾದ ಶಾರ್ಟ್‌ಕಟ್ ಎಂದಿಗೂ ಲಾಂಚರ್ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವುದಿಲ್ಲ. ಈ ಬೈಪಾಸ್ ಮುಖ್ಯವಾದರೆ, ಜಾರಿಗೊಳಿಸುವಿಕೆ ಅಪ್ಲಿಕೇಶನ್ ನಿಯಂತ್ರಣಕ್ಕೆ ಸೇರಿದೆ, VPN ಕ್ಲೈಂಟ್‌ಗೆ ಅಲ್ಲ. ಅವಧಿಯ ಅಂತ್ಯವನ್ನೂ ದಾಖಲಿಸಿ, ಮತ್ತು ಪ್ರವೇಶದಲ್ಲಿ ನಿಲ್ಲಿಸಿದ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಮತ್ತೆ ತೆರೆಯುವ ಬದಲು ಉದ್ದೇಶಪೂರ್ವಕ ಮುಂದುವರಿಕೆಯನ್ನು ಆದ್ಯತೆ ನೀಡಿ. ಪ್ರತಿ ಪರಿವರ್ತನೆಯ ಫಲಿತಾಂಶವನ್ನು ಯುನಿಟ್ ಫೈಲ್‌ಗಳನ್ನು ಇಡುವ ಅದೇ ಟಿಪ್ಪಣಿಯಲ್ಲಿ ದಾಖಲಿಸಿ.