NetGuard ನ SOCKS ಮೋಡ್ TCP ಅನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ ಅಲ್ಲ
NetGuard ಆಂಡ್ರಾಯ್ಡ್ ನ VPN ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಟ್ರಾಫಿಕ್ ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಬೆಂಬಲಿತ ಸಂಪರ್ಕಗಳನ್ನು SOCKS ಗೆ ಒಪ್ಪಿಸಬಹುದು. UDP, DNS ಮತ್ತು ಪ್ರೊಫೈಲ್ ಗಳ ನಡುವಿನ ತಲುಪುವಿಕೆಗೆ ಪ್ರತ್ಯೇಕ ಆಡಿಟ್ ಬೇಕು.
NetGuard ಟ್ರಾಫಿಕ್ ಫಿಲ್ಟರ್ ಮಾಡಲು ಆಂಡ್ರಾಯ್ಡ್ ನ VPN ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಆಕ್ರಮಿಸುತ್ತದೆ ಮತ್ತು ಬೆಂಬಲಿತ ಸಂಪರ್ಕಗಳನ್ನು SOCKS ಎಂಡ್ ಪಾಯಿಂಟ್ ಗೆ ಒಪ್ಪಿಸಬಹುದು. ಈ ಎರಡು ಸಂಗತಿಗಳನ್ನು ಹೆಚ್ಚಾಗಿ “ಫೋನ್ VPN ನಲ್ಲಿದೆ” ಎಂದು ಓದಲಾಗುತ್ತದೆ, ಇದು ಕಾರ್ಯವಿಧಾನವು ಬೆಂಬಲಿಸದ ತೀರ್ಮಾನ. ಫಿಲ್ಟರ್ ಪ್ಯಾಕೆಟ್ ಗಳನ್ನು ನೋಡುತ್ತದೆ; ಪ್ರಾಕ್ಸಿ ತನಗೆ ನಿಜವಾಗಿ ಒಪ್ಪಿಸಿದ ಸಂಪರ್ಕಗಳನ್ನು ಮಾತ್ರ ನೋಡುತ್ತದೆ. ಈ ಎರಡು ಹೇಳಿಕೆಗಳ ನಡುವೆ ಕವರೇಜ್ ನ ಇಡೀ ಪ್ರಶ್ನೆ ಇದೆ.
ಮೂಲ ಯೋಜನೆಯ FAQ ಏಕ-ಸೇವಾ ಮಿತಿ ಮತ್ತು SOCKS ಆಯ್ಕೆ ಎರಡನ್ನೂ ದಾಖಲಿಸುತ್ತದೆ. ಆಯ್ಕೆಯ ಅಸ್ತಿತ್ವವು ಪ್ರತಿ ಅನುಮತಿಸಿದ ಪ್ಯಾಕೆಟ್ ಅದನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಸಾಕ್ಷಿ ಅಲ್ಲ, ಮತ್ತು ಕವರೇಜ್ ಪ್ರಶ್ನೆಗಳು ಈ ಕಂದರದಿಂದಲೇ ಬರುತ್ತವೆ.
ಒಂದೇ ಅಪ್ ಒಳಗಿನ ಎರಡು ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗಗಳು
ಅನುಷ್ಠಾನದ TCP ಭಾಗದಲ್ಲಿ SOCKS ಸಂಪರ್ಕ ನಿರ್ವಹಣೆ ಇದೆ, ಆದ್ದರಿಂದ ಅನುಮತಿಸಿದ TCP ಸಂಪರ್ಕವನ್ನು ಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಚರ್ಚಿಸಿ ಅದರ ಮೂಲಕ ಸಾಗಿಸಬಹುದು. UDP ಭಾಗಕ್ಕೆ ಪ್ರತ್ಯೇಕ ಸಾಕೆಟ್ ಮಾರ್ಗವಿದೆ, ಮತ್ತು ಅದರ ಕಳುಹಿಸುವಿಕೆ ಹಾಗೂ ಸ್ವೀಕಾರದ ನಿರ್ವಹಣೆ ಆ TCP ಚರ್ಚೆಯನ್ನು ಅವಲಂಬಿಸಿಲ್ಲ. ಆದ್ದರಿಂದ ಫಿಲ್ಟರ್ ಅನುಮತಿಸುವ ಡೇಟಾಗ್ರಾಮ್ ಎಂದಿಗೂ ಪ್ರಾಕ್ಸಿಯ ಮೂಲಕ ಹೋಗದೆ ಸಾಮಾನ್ಯ ಜಾಲಕ್ಕೆ ತಲುಪಬಹುದು. ಇದರಲ್ಲಿ ಅಪ್ ನ ದೋಷವಿಲ್ಲ; ಎರಡು ಮಾರ್ಗಗಳು ಜಾರಿಗೊಳಿಸುವುದು ಇಷ್ಟೇ.
ಈ ವ್ಯತ್ಯಾಸಕ್ಕೆ ಜನರು ಎರಡೂ ದಿಕ್ಕಿನಲ್ಲಿ ತಪ್ಪಾಗಿ ಹೇಳುವ ಪರಿಣಾಮವಿದೆ. ಪ್ರತಿ UDP ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸೋರಿಕೆ ಎನ್ನುವುದು ನಿರ್ಬಂಧದ ನಿಯಮಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ತಿರಸ್ಕೃತ ಡೇಟಾಗ್ರಾಮ್ ಎಂದಿಗೂ ಹೊರಹೋಗುವುದಿಲ್ಲ. ಇಡೀ ವ್ಯವಸ್ಥೆಯನ್ನು VPN ಎನ್ನುವುದು ಅನುಮತಿಸಿದ ನೇರ ಮಾರ್ಗವನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಕೆಲವು ಟ್ರಾಫಿಕ್ ನಿಜವಾಗಿಯೂ ಪ್ರಾಕ್ಸಿ ಇಲ್ಲದೆ ಹೊರಹೋಗುತ್ತದೆ. ನಿಮ್ಮ ಬಳಿ ಇರುವುದು ಭಾಗಶಃ ಪ್ರಾಕ್ಸಿ ಇರುವ ಫಿಲ್ಟರ್ ಮಾಡಿದ ಸಾಧನ, ಮತ್ತು ಪ್ರಾಮಾಣಿಕ ವಿವರಣೆ ಲೇಬಲ್ ಅಲ್ಲ, ಮ್ಯಾಟ್ರಿಕ್ಸ್.
UDP ಜಾಹೀರಾತು ಮಾಡುವುದು ಅದನ್ನು ಜಾರಿಗೊಳಿಸುವುದಲ್ಲ
UDP ಬೆಂಬಲ ಎಂದು ಹೇಳಿಕೊಳ್ಳುವ SOCKS ಸರ್ವರ್ ನಿಮ್ಮ ಫೋನ್ ನ ಅಪ್ ಗೆ ಅನುಗುಣವಾದ ಕ್ಲೈಂಟ್ ಬದಿಯ ನಿರ್ವಹಣೆಯನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ. ಪ್ರೋಟೋಕಾಲ್ ನ ಸೈದ್ಧಾಂತಿಕ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ಸ್ಥಾಪಿತ ಬಿಲ್ಡ್ ನ ವರ್ತನೆ ಬೇರೆ ಬೇರೆ ವಿಷಯಗಳು, ಮತ್ತು ನಿಮ್ಮ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿವರಿಸುವುದು ಎರಡನೆಯದು ಮಾತ್ರ.
ನೀವು ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ಆವೃತ್ತಿ ಮತ್ತು ಸಂರಚನೆಯನ್ನು ಪರಿಶೀಲಿಸಿ, ನಂತರ ನಿರುಪದ್ರವ ಡೇಟಾಗ್ರಾಮ್ ಹರಿವನ್ನು ಪರೀಕ್ಷಿಸಿ ಅದು ಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ಕಾಣುತ್ತದೆಯೇ ಎಂದು ಗಮನಿಸಿ. ಉಳಿದದ್ದೆಲ್ಲ ವೈಶಿಷ್ಟ್ಯಗಳ ಪಟ್ಟಿಯಿಂದ ಮಾಡಿದ ಅನುಮಾನ, ಮತ್ತು ವೈಶಿಷ್ಟ್ಯಗಳ ಪಟ್ಟಿಗಳು ಕೋಡ್ ಮಾರ್ಗಗಳನ್ನಲ್ಲ, ಉದ್ದೇಶಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ.
DNS ಮೂರನೇ ಮಾರ್ಗ, ವಿವರವಲ್ಲ
ಹೆಸರು ವಿಶ್ಲೇಷಣೆ ಮ್ಯಾಟ್ರಿಕ್ಸ್ ಗೆ ತನ್ನದೇ ಶಾಖೆಯನ್ನು ಸೇರಿಸುತ್ತದೆ. ಸ್ಥಳೀಯ DNS ಫಾರ್ವರ್ಡರ್, ಸಾಮಾನ್ಯ UDP ಪ್ರಶ್ನೆ, ಪ್ರಾಕ್ಸಿಯೇ ಪರಿಹರಿಸುವ ಗಮ್ಯಸ್ಥಾನ ಹೋಸ್ಟ್ ಹೆಸರು ಮತ್ತು ಬ್ರೌಸರ್ ನಲ್ಲಿನ ಎನ್ ಕ್ರಿಪ್ಟ್ ಮಾಡಿದ ರಿಸಾಲ್ವರ್ ನಾಲ್ಕು ವಿಭಿನ್ನ ವ್ಯವಸ್ಥೆಗಳು. ಅವು ಪ್ರಶ್ನೆಯನ್ನು ಯಾರು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಯಾವ ಜಾಲ ಮಾರ್ಗ ಅದನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂಬುದರಲ್ಲಿ ಭಿನ್ನ, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸಿದರೆ ಉಳಿದವುಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತು ಮಾಡದ ಪರೀಕ್ಷೆ ಉಂಟಾಗುತ್ತದೆ.
ನಿಮಗೆ ಯಾವುದು ಬೇಕು ಎಂದು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ಧರಿಸಿ. ಹೆಸರುಗಳು ಸುರಂಗದ ಮೂಲಕ ಪರಿಹಾರವಾಗಬೇಕು ಎಂಬುದು ಅಗತ್ಯವಾದರೆ, ಬ್ರೌಸರ್ ಸೆಟ್ಟಿಂಗ್ ಮಾತ್ರ ಅದನ್ನು ನೀಡದು, ಮತ್ತು ಹೋಸ್ಟ್ ಹೆಸರುಗಳನ್ನು ತಾನೇ ಪರಿಹರಿಸುವ ಪ್ರಾಕ್ಸಿ ತಾನು ನಿಜವಾಗಿ ನಿರ್ವಹಿಸುವ ಸಂಪರ್ಕಗಳಿಗೆ ಮಾತ್ರ ಉತ್ತರ ಬದಲಿಸುತ್ತದೆ.
ಪ್ರಾಕ್ಸಿ ಸಾಗಣೆ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಖಾಸಗಿ ಅಲ್ಲ
ಸಾದಾ SOCKS ಫೋನ್ ನಿಂದ ಪ್ರಾಕ್ಸಿಗೆ ಎನ್ ಕ್ರಿಪ್ಟ್ ಆದ ಕೊಂಡಿಯಲ್ಲ. ಎಂಡ್ ಪಾಯಿಂಟ್ ಅನ್ನು ಇನ್ನೊಂದು ಸಂರಕ್ಷಿತ ಮಾರ್ಗದ ಮೂಲಕ ತಲುಪಿದರೆ, ಆ ಮಾರ್ಗ ಮತ್ತು ಅದರ ವೈಫಲ್ಯ ನೀತಿಯನ್ನು ಹೆಸರಿಸಿ, ಏಕೆಂದರೆ ತೆರೆದ ಜಾಲಕ್ಕೆ ಹಿಂಜರಿತ ಎಚ್ಚರಿಕೆ ಇಲ್ಲದೆ ಖಾಸಗಿ ವ್ಯವಸ್ಥೆಯನ್ನು ಸಾರ್ವಜನಿಕವಾಗಿಸುತ್ತದೆ. ಪ್ರಾಕ್ಸಿಯ ಸ್ವಂತ ದೃಢೀಕರಣವೂ ಮುಖ್ಯ: ಹಂಚಿದ ಸಾಧನದಲ್ಲಿ ತೆರೆದ ಆಲಿಸುವವರು ಯಾರೂ ಲೆಕ್ಕ ಒಪ್ಪಿಸದ ಸೇವೆ.
ಪ್ರೊಫೈಲ್ ಗಳ ನಡುವಿನ ವ್ಯವಸ್ಥೆಗಳಿಗೂ ಅದೇ ಪರಿಶೀಲನೆ ಬೇಕು. ಕೆಲಸದ ಪ್ರೊಫೈಲ್ ನ VPN ತನ್ನ ಮಾರ್ಗ ಬಳಸುವ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮಾತ್ರ ರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ವೈಯಕ್ತಿಕ ಪ್ರೊಫೈಲ್ ನ ಫೈರ್ ವಾಲ್ ಜೊತೆ ಕೆಲಸದ ಸುರಂಗದ ಸಹಬಾಳ್ವೆ ಫೈರ್ ವಾಲ್ ನ ಮುಂದಿನ ಸಂಪರ್ಕ ಆ ಸುರಂಗವನ್ನು ತಲುಪುತ್ತದೆ ಎಂದು ಸಾಬೀತು ಮಾಡುವುದಿಲ್ಲ. ಎರಡು ಪ್ರೊಫೈಲ್ ಗಳು ಸಹಕರಿಸುತ್ತವೆ ಎಂದು ಊಹಿಸುವ ಬದಲು ತಲುಪುವಿಕೆ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ಪರಿಶೀಲಿಸಿ.
ಪುಟ ಲೋಡ್ ಬದಲು ಮ್ಯಾಟ್ರಿಕ್ಸ್ ನಿಂದ ಕವರೇಜ್ ಆಡಿಟ್ ಮಾಡಿ
ಅಧಿಕೃತ ಮೌಲ್ಯಮಾಪನಕ್ಕಾಗಿ, ನಿಮಗೆ ಮುಖ್ಯವಾದ ಪ್ರತಿ ವರ್ಗವನ್ನು ಪ್ರತಿನಿಧಿಸುವ ನಿರುಪದ್ರವ ಉದಾಹರಣೆಗಳನ್ನು ಆಯ್ಕೆಮಾಡಿ: ಅಗತ್ಯವಿರುವ TCP, ಅನುಮತಿಸಿದ UDP ಮತ್ತು ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳಲ್ಲಿ DNS. ಪ್ರತಿಯೊಂದಕ್ಕೂ ಅದು ಪ್ರಾಕ್ಸಿ ಆಯಿತೇ, ನಿರ್ಬಂಧಿಸಲಾಯಿತೇ ಅಥವಾ ನೇರವಾಗಿ ಕಳುಹಿಸಲಾಯಿತೇ ಎಂದು ದಾಖಲಿಸಿ. ಆ ಒಂದೇ ಕೋಷ್ಟಕವೇ ಫಲಿತಾಂಶ, ಮತ್ತು ಲೋಡ್ ಆದ ಪುಟದ ಸ್ಕ್ರೀನ್ ಶಾಟ್ ಗಿಂತ ಬಹಳ ಉಪಯುಕ್ತ.
ಆಯ್ದ ಎಲ್ಲ ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ದೂರದ ಸುರಂಗದ ಮೂಲಕ ಹೋಗಬೇಕು ಎಂಬುದು ಅಗತ್ಯವಾದರೆ, ಸಂಯೋಜಿತ ಫಿಲ್ಟರಿಂಗ್ ಮತ್ತು ಸುರಂಗೀಕರಣವನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಬೆಂಬಲಿಸುವ ಅನುಷ್ಠಾನವನ್ನು ಆಯ್ಕೆಮಾಡಿ. TCP ಮಾತ್ರ ಪ್ರಾಕ್ಸಿ ಸಂಯೋಜನೆ ಸಣ್ಣ ಕೆಲಸಗಳಿಗೆ ಉಪಯುಕ್ತವಾಗಿ ಉಳಿಯುತ್ತದೆ, ಉಳಿದ ಟ್ರಾಫಿಕ್ ಮರೆತುಹೋಗದೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರ್ವಹಿಸಲ್ಪಟ್ಟರೆ.