ಕಿಲ್ ಸ್ವಿಚ್ ಆನ್ ಆಗಿದೆ, ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಟನೆಲ್‌ನಿಂದ ಹೊರಗಿಡಲಾಗಿದೆ, ಮತ್ತು ಎರಡು ಅಗತ್ಯಗಳು ಈಗ ಪರಸ್ಪರ ವಿರುದ್ಧವಾಗಿವೆ. ಒಂದು ಟನೆಲ್ ಹೊರತುಪಡಿಸಿ ಯಾವುದೂ ಹೊರಹೋಗಬಾರದು ಎಂದು ಹೇಳುತ್ತದೆ, ಇನ್ನೊಂದು ಈ ಪ್ರೋಗ್ರಾಂ ನೇರವಾಗಿ ಹೋಗಬೇಕು ಎಂದು ಹೇಳುತ್ತದೆ. ಪ್ರತಿ ಕ್ಲೈಂಟ್ ಈ ಘರ್ಷಣೆಯನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಪರಿಹರಿಸುತ್ತದೆ, ಮತ್ತು ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪುಟ ಯಾವ ನಿಯಮ ಗೆಲ್ಲುತ್ತದೆ ಎಂಬುದನ್ನು ವಿರಳವಾಗಿ ವಿವರಿಸುತ್ತದೆ. ಯಾವುದೇ ಲೇಬಲ್ ಅನ್ನು ನಂಬುವ ಮೊದಲು ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ನೀತಿಯನ್ನು ಬರೆಯಿರಿ.

ಎರಡು ನೀತಿಗಳು, ಒಂದು ಯಂತ್ರ

ಕಿಲ್ ಸ್ವಿಚ್ ವೈಫಲ್ಯದ ಬಗ್ಗೆ ಒಂದು ಭರವಸೆ: ಟನೆಲ್ ಸಂಚಾರವನ್ನು ರಕ್ಷಿಸದಿದ್ದಾಗ, ಸಂಚಾರ ನಿಲ್ಲುತ್ತದೆ. ವಿಭಜಿತ ಟನೆಲ್ ಆಯ್ಕೆಯ ಬಗ್ಗೆ ಒಂದು ಭರವಸೆ: ಈ ಪ್ರೋಗ್ರಾಂಗಳು ಅಥವಾ ಗಮ್ಯಸ್ಥಾನಗಳು ಟನೆಲ್ ಬಳಸುತ್ತವೆ, ಅವು ಬಳಸುವುದಿಲ್ಲ. ಎರಡನೇ ಭರವಸೆ ಮೊದಲನೆಯದು ನಿರ್ಧರಿಸಬೇಕಾದ ಸಂಚಾರವನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಯಾವ ಭರವಸೆಯೂ ತಪ್ಪಲ್ಲ; ಬೇರೆ ಬೇರೆ ಜನರು ಬೇರೆ ಬೇರೆ ಅಪಾಯಗಳಿಗಾಗಿ ಅವನ್ನು ಬರೆದಿದ್ದಾರೆ.

ಮೂರು ಫಲಿತಾಂಶಗಳು ಸಾಧ್ಯ ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಅನುಸ್ಥಾಪನೆಯ ಉದ್ದೇಶವಾಗಿತ್ತು. ಹೊರಗಿಟ್ಟ ಅಪ್ಲಿಕೇಶನ್ ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ನೇರವಾಗಿ ಉಳಿಯಬಹುದು, ಇದು ವಿಭಜನೆಯನ್ನು ಗೌರವಿಸಿ ಕಿಲ್ ಸ್ವಿಚ್ ಅನ್ನು ಮುರಿಯುತ್ತದೆ. ಅದನ್ನು ಉಳಿದ ಎಲ್ಲದರೊಂದಿಗೆ ನಿರ್ಬಂಧಿಸಬಹುದು, ಇದು ಕಿಲ್ ಸ್ವಿಚ್ ಅನ್ನು ಗೌರವಿಸಿ ವಿಭಜನೆಯನ್ನು ಮುರಿಯುತ್ತದೆ. ಅಥವಾ ಇಂಟರ್ಫೇಸ್ ಮಾಯವಾದ ನಂತರ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ನಿಯಮವನ್ನು ಹೇಗೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದ ಮೇಲೆ ಅದನ್ನು ಕೆಲವೊಮ್ಮೆ ಮಾತ್ರ ನಿರ್ಬಂಧಿಸಬಹುದು. ಆ ಕೊನೆಯ ಸಂದರ್ಭವೇ ಟಿಕೆಟ್‌ಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ ಪಟ್ಟಿ ಬರೆಯಿರಿ

ಟನೆಲ್ ಬಳಸಬೇಕಾದ ಪ್ರೋಗ್ರಾಂಗಳು, ನೇರವಾಗಿ ಹೋಗಬೇಕಾದವುಗಳು ಮತ್ತು ಯಾವುದೇ ಪಟ್ಟಿಯಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣದಿರಬೇಕಾದ ಹೆಸರುಗಳು ಅಥವಾ ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ. ರೆಸಾಲ್ವರ್ ವರ್ತನೆ ಮತ್ತು IPv6 ಬದಿಯನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸೇರಿಸಿ, ಏಕೆಂದರೆ ಎರಡೂ ಪುಟ ಸಂಚಾರಕ್ಕಿಂತ ಭಿನ್ನ ನೀತಿಯನ್ನು ಅನುಸರಿಸಬಹುದು.

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

ಒಂದಲ್ಲ, ಎರಡು ಪಟ್ಟಿಗಳು ಬೇಕು: ಟನೆಲ್ ಏನನ್ನು ಸಾಗಿಸಬೇಕು ಮತ್ತು ಯಾವ ಕಾರಣಕ್ಕೂ ಅದರ ಹೊರಗೆ ಹೋಗಬಾರದು ಎಂಬುದು. ಎರಡರಲ್ಲೂ ಕಾಣುವ ಅಪ್ಲಿಕೇಶನ್ ಜಾರಿ ವಿವರವಲ್ಲ, ಅಗತ್ಯದ ಘರ್ಷಣೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಸಂರಚಿಸುವ ಮೊದಲು ಅದನ್ನು ಬಗೆಹರಿಸಬೇಕು.

ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ಕ್ಲೈಂಟ್ ಏನು ಮಾಡುತ್ತದೆ

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

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

ನಿಮ್ಮ ಮುಂದಿರುವ ಆಪರೇಟಿಂಗ್ ಸಿಸ್ಟಂನ ವರ್ತನೆಯನ್ನು ಓದಿ, ಬೇರೆಡೆ ಇದೇ ಹೆಸರಿನ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನಲ್ಲ. ಜಾರಿಗೊಳಿಸುವ API ಗಳು ಭಿನ್ನ, ಮತ್ತು ಒಂದು ಚೆಕ್‌ಬಾಕ್ಸ್ ಡೆಸ್ಕ್‌ಟಾಪ್‌ನಲ್ಲಿ ಮತ್ತು ಫೋನ್‌ನಲ್ಲಿ ಸಂಪೂರ್ಣ ಭಿನ್ನ ಅರ್ಥಗಳನ್ನು ಹೊಂದಿರಬಹುದು. ಆವೃತ್ತಿಯೂ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಲಾಕ್‌ಡೌನ್ ನಿಯಂತ್ರಣ Android ಬಿಡುಗಡೆಗಳ ನಡುವೆ ಪರದೆಗಳ ನಡುವೆ ಸರಿದಿದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಬದಿಯ ವಿನಾಯಿತಿ ಪಟ್ಟಿ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಲಾಕ್‌ಡೌನ್‌ನಷ್ಟೇ ನಿಯಂತ್ರಣವಲ್ಲ.

ಮೂರು ಕ್ಷಣಗಳು: ಟನೆಲ್ ಆನ್, ಟನೆಲ್ ಆಫ್, ಮರುಸಂಪರ್ಕ

ಮೂರು ಕ್ಷಣಗಳಲ್ಲಿ ನಿರುಪದ್ರವಿ ವಿನಂತಿಗಳನ್ನು ಬಳಸಿ: ಟನೆಲ್ ಕೆಲಸ ಮಾಡುತ್ತಿರುವಾಗ, ನಿಮಗೆ ಮುಖ್ಯವಾದ ವೈಫಲ್ಯದ ಸಮಯದಲ್ಲಿ, ಮತ್ತು ಮರುಸಂಪರ್ಕದ ನಂತರ. ಒಂದು ಬ್ರೌಸರ್ ಫಲಿತಾಂಶ ಹೊರಗಿಟ್ಟ ಅಪ್ಲಿಕೇಶನ್‌ನ ವರ್ತನೆಯನ್ನು ಸ್ಥಾಪಿಸಲಾರದು.

curl -sS --max-time 8 https://api.ipify.org
curl -sS --max-time 8 --interface tun0 https://api.ipify.org
dig +short example.com

ನಿರ್ಗಮನ ವಿಳಾಸ ಯಾವ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಸ್ಪಷ್ಟ ಇಂಟರ್ಫೇಸ್ ಪರೀಕ್ಷೆ ಟನೆಲ್ ಏಕೈಕ ಲಭ್ಯ ನಿರ್ಗಮನವಾದಾಗ ಏನಾಗುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಯಾವುದನ್ನೂ ಚಲಾಯಿಸುವ ಮೊದಲು ಪ್ರತಿ ಸಾಲಿನ ಪಕ್ಕದಲ್ಲಿ ನಿರೀಕ್ಷಿತ ಫಲಿತಾಂಶವನ್ನು ಬರೆಯಿರಿ, ಇಲ್ಲದಿದ್ದರೆ ಔಟ್‌ಪುಟ್ ನಂತರ ಅರ್ಥೈಸಲ್ಪಡುತ್ತದೆ.

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

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