Android VpnService ಅನುಮತಿ ಪಟ್ಟಿ: ಅನುಮತಿಸಿದ ಪುಟಗಳು ಇನ್ನೂ ಏಕೆ ನೇತಾಡುತ್ತವೆ

ನಿಮ್ಮ ಅನುಮತಿ ಪಟ್ಟಿ ಬಹುಶಃ ಸರಿಯಾಗಿದೆ. ಪುಟಗಳು DNS ಉತ್ತರ, ರೂಟ್ ಕೋಷ್ಟಕ, ರೆಸಾಲ್ವರ್ ಸಾಕೆಟ್ ಅಥವಾ MTU ಕಾರಣ ನೇತಾಡುತ್ತವೆ. ಪರಿಶೀಲನೆಯ ಕ್ರಮ ಇಲ್ಲಿದೆ.

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

ಹೊಂದಿಸುವಿಕೆಯೇ ಅಪರೂಪಕ್ಕೆ ದೋಷಿ

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

ಖಾಲಿ A ದಾಖಲೆ ಸಾಂಪ್ರದಾಯಿಕ ತಪ್ಪು. ಶೂನ್ಯ ಉತ್ತರಗಳೊಂದಿಗೆ NOERROR ಹಿಂತಿರುಗಿಸುವುದು ಮಾನ್ಯ ಉತ್ತರದಂತೆ ಕಾಣುತ್ತದೆ, ಹಾಗಾಗಿ stub ರೆಸಾಲ್ವರ್ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಬ್ರೌಸರ್ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, AAAA ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಬೇರೆ ರೆಸಾಲ್ವರ್ ಪ್ರಯತ್ನಿಸುತ್ತದೆ, ಮತ್ತು ಬಹಳ ತಡವಾಗಿ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಪ್ರಶ್ನೆ ವಿಭಾಗವನ್ನು ಪುನರಾವರ್ತಿಸಿ ವಹಿವಾಟು ID ಯನ್ನು ನಕಲಿಸಿ ನೀಡಿದ ಉತ್ತರ ಸಂಕೇತ 3, ಅಂದರೆ NXDOMAIN, ಸಂಭಾಷಣೆಯನ್ನು ತಕ್ಷಣ ಮುಗಿಸುತ್ತದೆ. ನೀವು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಿರಾಕರಿಸುವ ಪ್ರತಿ ಹೆಸರಿಗೂ ಅದನ್ನು ಬಳಸಿ.

IPv6 ಕೂಡ ಡೀಫಾಲ್ಟ್ ಬದಲು ಅದೇ ನಿರ್ಣಯಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ. ನೀವು A ಗೆ NXDOMAIN ಉತ್ತರಿಸಿ AAAA ಗೆ ಅವಕಾಶ ನೀಡಿದರೆ, ಕ್ಲೈಂಟ್ IPv6 ಮೂಲಕ ನಿರ್ಬಂಧಿತ ಹೆಸರನ್ನು ತಲುಪಬಹುದು ಮತ್ತು ಫಿಲ್ಟರ್ ಸೋರುತ್ತದೆ. ಕೆಲವು ಅನುಷ್ಠಾನಗಳು ನಿರ್ಬಂಧಿತ AAAA ಪ್ರಶ್ನೆಗಳಿಗೆ loopback ವಿಳಾಸದಿಂದ ಉತ್ತರಿಸುತ್ತವೆ, ಇದರಿಂದ ಸಂಪರ್ಕ ಪರ್ಯಾಯಕ್ಕೆ ಇಳಿಯುವ ಬದಲು ತಕ್ಷಣ ವಿಫಲವಾಗುತ್ತದೆ. ಒಂದು ನೀತಿ ಆರಿಸಿ, ಅದನ್ನು ಎರಡೂ ದಾಖಲೆ ಪ್ರಕಾರಗಳಿಗೆ ಅನ್ವಯಿಸಿ, ಮತ್ತು ಎರಡನ್ನೂ ಲಾಗ್ ಮಾಡಿ.

ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುವ ಮಾರ್ಗ ಎಲ್ಲದಕ್ಕೂ ಒಡೆಯನಾಗುತ್ತದೆ

DNS ಮಾತ್ರ ಇರುವ ವಿನ್ಯಾಸ ಎಂದಿಗೂ addRoute("0.0.0.0", 0) ಸೇರಿಸುವುದಿಲ್ಲ, ಹಾಗಾಗಿ TUN ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಪ್ರಶ್ನೆಗಳು ಮಾತ್ರ ಪ್ರವೇಶಿಸುತ್ತವೆ ಮತ್ತು ಉಳಿದೆಲ್ಲವೂ ಕೆಳಗಿನ ನೆಟ್‌ವರ್ಕ್ ಬಳಸುತ್ತಲೇ ಇರುತ್ತದೆ. ಅದೇ ಸುರಕ್ಷಿತ ಆಕಾರ, ಮತ್ತು ಕೆಲವು ಅನುಮತಿ ಪಟ್ಟಿಗಳು Wi-Fi ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಂತೆ ಕಾಣುತ್ತಾ ಮೊಬೈಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ ಎಂಬುದನ್ನೂ ಅದು ವಿವರಿಸುತ್ತದೆ.

ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗ ಇರುವ ಕ್ಷಣದಿಂದ ಪ್ರತಿ ಹರಿವೂ ನಿಮ್ಮದು. ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬಂದು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸದೆ ಅಥವಾ ಉತ್ತರಿಸದೆ ಇರುವ TCP ಪ್ಯಾಕೆಟ್ ಕ್ಲೈಂಟ್‌ನ ಸಮಯ ಮುಗಿಯುವವರೆಗೆ ಸಾಲಿನಲ್ಲಿ ಕೂರುತ್ತದೆ, ಮತ್ತು ಯಾವುದೂ ತಪ್ಪಾಗಿಲ್ಲದ ಕಾರಣ ಲಾಗ್ ಮಾಡಲು ದೋಷವೂ ಇಲ್ಲ. ಯಾರೋ ಒಬ್ಬರು ಮುರಿದ ಅನುಮತಿ ಪಟ್ಟಿಯ ಮೇಲೆ ಪೂರ್ಣ ಮಧ್ಯಾಹ್ನ ಕಳೆದದ್ದನ್ನು ನಾನು ನೋಡಿದೆ, ಅದು ವಾಸ್ತವವಾಗಿ ಪೋರ್ಟ್ 443 ಗೆ ಕಾಣೆಯಾದ ಫಾರ್ವರ್ಡರ್ ಆಗಿತ್ತು. ನೀವು ಬಿಟ್ಟುಬಿಡಲು ನಿರ್ಧರಿಸುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್‌ನ ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಲಾಗ್ ಮಾಡಿ.

ರೆಸಾಲ್ವರ್ ಸಾಕೆಟ್ ಸುರಂಗದಿಂದ ಹೊರಬರಬೇಕು

ಫಾರ್ವರ್ಡಿಂಗ್ ಮುಂದಿನ ಬಲೆಯ ಸ್ಥಳ. ವಾಹಕದ ರೆಸಾಲ್ವರ್‌ಗಳು ಸುರಂಗ ತಲುಪಲಾಗದ ಖಾಸಗಿ ವಿಳಾಸದಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ, ಹಾಗಾಗಿ ನೀವು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಪ್ರಶ್ನೆ ಎಲ್ಲಿಗೂ ಹೋಗುವುದಿಲ್ಲ ಮತ್ತು ಆ್ಯಪ್ ಓದುವ ಸಮಯ ಮೀರಿದೆ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ. ಅನುಮೋದಿತ ಪ್ರಶ್ನೆಗಳನ್ನು ತಲುಪಬಹುದೆಂದು ನಿಮಗೆ ತಿಳಿದಿರುವ ರೆಸಾಲ್ವರ್‌ಗೆ ಕಳುಹಿಸಿ, ಮತ್ತು ಆ ಸಾಕೆಟ್ ಅನ್ನು ಮೊದಲು VpnService.protect() ಗೆ ಕೊಡಿ. ರಕ್ಷಿಸದ ಸಾಕೆಟ್ ಪ್ರಶ್ನೆಯನ್ನು ನಿಮ್ಮದೇ ಸುರಂಗಕ್ಕೆ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅಲ್ಲಿ ಅದು ಮತ್ತೆ ಆ್ಯಪ್‌ಗೆ ತಲುಪಿ ಸಮಯ ಮಿತಿ ಸಕ್ರಿಯವಾಗುವವರೆಗೆ ಸುತ್ತುತ್ತದೆ.

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

ಗಾತ್ರ ಮತ್ತು ಚೆಕ್‌ಸಮ್ ಸಂದೇಶವಿಲ್ಲದೆ ವಿಫಲವಾಗುತ್ತವೆ

ಮೌನ ಬಿಟ್ಟುಬಿಡುವಿಕೆ ಗಾತ್ರದಿಂದಲೂ ಬರುತ್ತದೆ. ದೊಡ್ಡ ಉತ್ತರ ಗುಂಪಿನ DNS ಉತ್ತರ, ಅಥವಾ ಉದಾರ ಆಯ್ಕೆಗಳಿರುವ TCP ಹಸ್ತಲಾಘವ, ನೀವು ಎಂದಿಗೂ ಸ್ಪಷ್ಟವಾಗಿ ಸೆಟ್ ಮಾಡದ ಮಾರ್ಗ MTU ಮೀರಬಹುದು; ತುಣುಕು ಮೇಲ್ಮುಖವಾಗಿ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ ಮತ್ತು ಕ್ಲೈಂಟ್ ಒಂದೋ ಚಿಕ್ಕದಾಗಿ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತದೆ ಅಥವಾ ಪ್ರಯತ್ನ ಬಿಡುತ್ತದೆ. ಇಂಟರ್‌ಫೇಸ್ MTU ಅನ್ನು 1280 ಕ್ಕೆ ಹೊಂದಿಸುವುದು ಸಂಪ್ರದಾಯವಾದಿ ಆಯ್ಕೆಯಾಗಿದ್ದು ಹೆಚ್ಚಿನ ಮೊಬೈಲ್ ಮಾರ್ಗಗಳಲ್ಲಿ ಉಳಿಯುತ್ತದೆ, ಮತ್ತು ಯಾರೂ ಅಳೆಯದ ಡೀಫಾಲ್ಟ್ ಅನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುವುದಕ್ಕಿಂತ ಸ್ಪಷ್ಟವಾಗಿರುವುದು ಉತ್ತಮ.

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

VpnService ನಿಮಗಾಗಿ ಏನು ಮಾಡುವುದಿಲ್ಲ

ಅವುಗಳ ಸುತ್ತ ವಿನ್ಯಾಸ ಮಾಡುವ ಮೊದಲು ಎರಡು ಮಿತಿಗಳನ್ನು ತಿಳಿಯುವುದು ಒಳ್ಳೆಯದು. ಯಾವುದೇ ಸಾಮಾನ್ಯ ಆ್ಯಪ್ Wi-Fi ಹೊರಗೆ ಸಿಸ್ಟಮ್-ವ್ಯಾಪಿ ಪ್ರಾಕ್ಸಿ ಅಥವಾ PAC ಫೈಲ್ ಸ್ಥಾಪಿಸಲಾಗದು, ಮತ್ತು ಆ ಭಾಗ ಬದಲಾಗಿಲ್ಲ. ಪ್ರತಿ ಆ್ಯಪ್ ಮಾರ್ಗ ಬದಲಾಗಿದೆ: API 29 ಕ್ಕಿಂತ ಮೊದಲು VpnService.Builder ಪ್ರಾಕ್ಸಿಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹೊತ್ತೊಯ್ಯಲಾಗದು, ಮತ್ತು API 29 ರಿಂದ setHttpProxy(ProxyInfo.buildPacProxy(uri)) VPN ನೆಟ್‌ವರ್ಕ್‌ಗಾಗಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಲು ವೇದಿಕೆಗೆ PAC ಸ್ಕ್ರಿಪ್ಟ್ ನೀಡುತ್ತದೆ. ಹಳೆಯ API ಗಳನ್ನು ಗುರಿಯಾಗಿಸಿದಾಗ ಅಥವಾ PAC ಮಾದರಿ ನಿಯಮವನ್ನು ವ್ಯಕ್ತಪಡಿಸಲಾಗದಿದ್ದಾಗ ನಿಯಮಗಳನ್ನು ನಿಮ್ಮ ಸ್ವಂತ ಕೋಡ್‌ನಲ್ಲಿ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ. UDP ಕೂಡ ಉಚಿತವಲ್ಲ: ಬ್ರೌಸರ್‌ಗಳು SOCKS ಪ್ರಾಕ್ಸಿ ಮೂಲಕ TCP ಮಾತ್ರ ಕಳುಹಿಸುತ್ತವೆ, ಮತ್ತು ಹೆಚ್ಚಿನ SOCKS5 ಕ್ಲೈಂಟ್‌ಗಳು UDP ASSOCIATE ಅನ್ನು ಎಂದಿಗೂ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದಿಲ್ಲ, ಹಾಗಾಗಿ ಪ್ರಾಕ್ಸಿ ಆಧಾರಿತ ವಿನ್ಯಾಸ TCP ಆರೋಗ್ಯವಾಗಿ ಕಾಣುತ್ತಿರುವಾಗ UDP ಅನ್ನು ಬಿಡುತ್ತದೆ ಅಥವಾ ಸೋರಿಸುತ್ತದೆ.

ಆ ಎರಡನೇ ಮಿತಿಯೇ UDP ಆಧಾರಿತ ಪ್ರೋಟೋಕಾಲ್ ಸಾಮಾನ್ಯ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ನಿಮ್ಮ VPN ಸಂಪರ್ಕಗೊಳ್ಳುವ ಕ್ಷಣ ವಿಫಲವಾಗುವ ಕಾರಣ. ಸುರಂಗ UDP ಹೊತ್ತೊಯ್ಯಬೇಕೆಂದು ನಿರೀಕ್ಷಿಸಿದರೆ, ಫಾರ್ವರ್ಡರ್ ಅದಕ್ಕಾಗಿ ಫಾರ್ವರ್ಡಿಂಗ್ ಮಾರ್ಗವನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸಬೇಕು, ಬೇರೆ ಸಾಕೆಟ್ ಪ್ರಕಾರದ TCP ಮಾರ್ಗವನ್ನು ಮಾತ್ರವಲ್ಲ.

ಈ ಕ್ರಮದಲ್ಲಿ ಪರಿಶೀಲಿಸಿ

ಪಟ್ಟಿಯನ್ನು ಕ್ರಮವಾಗಿ ಕೆಲಸ ಮಾಡಿ ಮತ್ತು ವಿಫಲವಾಗುವ ಮೊದಲ ಹಂತದಲ್ಲಿ ನಿಲ್ಲಿಸಿ, ಏಕೆಂದರೆ ಹಿಂದಿನದು ನಿಲ್ಲುವವರೆಗೆ ಪ್ರತಿ ಮುಂದಿನ ಪರಿಶೀಲನೆಯೂ ಗದ್ದಲ.

  1. ಸ್ಥಾಪಿತ ರೂಟ್‌ಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡಿ ಮತ್ತು DNS ಅಲ್ಲದ ಪ್ಯಾಕೆಟ್‌ಗಳು TUN ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಪ್ರವೇಶಿಸುತ್ತವೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.
  2. ಒಂದು ನಿರ್ಬಂಧಿತ ಮತ್ತು ಒಂದು ಅನುಮೋದಿತ ಹೆಸರಿಗೆ ಪ್ರಶ್ನೆ ಹೆಸರು, ನಿರ್ಣಯ ಮತ್ತು ಉತ್ತರ ಸಂಕೇತವನ್ನು ಲಾಗ್ ಮಾಡಿ.
  3. ರೆಸಾಲ್ವರ್ ಸಾಕೆಟ್ ರಕ್ಷಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಮತ್ತು ಆಯ್ಕೆ ಮಾಡಿದ ರೆಸಾಲ್ವರ್ ಸುರಂಗದ ಒಳಗಿನಿಂದ ಉತ್ತರಿಸುತ್ತದೆಯೇ ಎಂದು ಖಚಿತಪಡಿಸಿ.
  4. ಇಂಟರ್‌ಫೇಸ್ MTU ಮತ್ತು ಕೈಯಿಂದ ನಿರ್ಮಿಸಿದ ಒಂದು ಉತ್ತರದ ಚೆಕ್‌ಸಮ್ ಖಚಿತಪಡಿಸಿ.
  5. ಅದೇ ಪುಟವನ್ನು Wi-Fi ಮತ್ತು ಮೊಬೈಲ್ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ವಾಹಕದ ರೆಸಾಲ್ವರ್‌ಗಳು ಮತ್ತು ಮಾರ್ಗ MTU ಭಿನ್ನ.

ಐದೂ ನಿಂತರೂ ಪುಟ ಇನ್ನೂ ನೇತಾಡುತ್ತಿದ್ದರೆ, ಮುಂದಿನ ಸಂಶಯಿತ ಫಾರ್ವರ್ಡರ್ ಸ್ವತಃ: ಸೆರೆಹಿಡಿದ ವಿನಂತಿಯನ್ನು ಸೆರೆಹಿಡಿದ ಉತ್ತರದೊಂದಿಗೆ ಹೋಲಿಸಿ ಮತ್ತು ಕಾಣೆಯಾದ ಬೈಟ್ ಎಣಿಕೆ ಅಥವಾ ಅರ್ಧ ಮುಚ್ಚಿದ ಸಾಕೆಟ್ ಹುಡುಕಿ. VpnService.Builder ಉಲ್ಲೇಖ ರೂಟ್, DNS ಮತ್ತು MTU ಒಪ್ಪಂದಗಳನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ, ಮತ್ತು protect() builder ಆಯ್ಕೆಯಲ್ಲ, ಪ್ರತ್ಯೇಕ VpnService ಕರೆ; ಸಂಪರ್ಕಗೊಂಡ ಇಂಟರ್‌ಫೇಸ್ ಎಂದರೆ ಮೊದಲ ಒಪ್ಪಂದ ಪೂರೈಸಿತು ಎಂದಷ್ಟೇ.

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