Android VpnService ಕೆಲವು ಟ್ರಾಫಿಕ್ ಮಾತ್ರ ಹಿಡಿಯುತ್ತದೆ, ಎಲ್ಲವನ್ನೂ ಏಕೆ ಅಲ್ಲ

VpnService ನಲ್ಲಿ ಯಾವುದೂ ತಾನಾಗಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಇದು ಸಿಸ್ಟಮ್‌ನಿಂದ tun ಇಂಟರ್‌ಫೇಸ್ ಕೇಳುತ್ತದೆ, ಆ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ವಿಳಾಸಗಳು ಮತ್ತು ರೂಟ್‌ಗಳ ಗುಂಪನ್ನು ನೀಡುತ್ತದೆ, ಮತ್ತು ಆ ಕ್ಷಣದಿಂದ ಕರ್ಣೆಲ್ ಆ ರೂಟ್‌ಗಳಿಗೆ ಹೊಂದುವ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಅಪ್ ಓದಬಲ್ಲ ಫೈಲ್ ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗೆ ನಕಲಿಸುತ್ತದೆ. ಅಪ್‌ನ ಕೋಡ್ ರೂಟ್‌ಗಳು ಆಯ್ಕೆ ಮಾಡದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಎಂದಿಗೂ ನೋಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಟನೆಲ್‌ನ ವ್ಯಾಪ್ತಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಪ್ರಶ್ನೆಯಾಗುವ ಮೊದಲು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದ ಪ್ರಶ್ನೆ. ಆದ್ದರಿಂದಲೇ ಅದೇ ಸೇವಾ ಅನುಷ್ಠಾನ ಒಂದು ಫೋನ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಹರಿವನ್ನು ನುಂಗಬಲ್ಲದು ಮತ್ತು ಇನ್ನೊಂದರಲ್ಲಿ ಕೇವಲ ಒಂದು ಭಾಗವನ್ನು, ಮತ್ತು ಆದ್ದರಿಂದಲೇ ರೂಟ್ ಸೇರಿಸುವುದು ಕೆಲವೊಮ್ಮೆ ಮುರಿದಂತೆ ಕಂಡ ಟನೆಲ್ ಅನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ. ನೀವು ಪಡೆಯುವುದು ನೀವು ಘೋಷಿಸಿದ್ದೇ, ನಿರ್ಮಾತೃ ಮೌನವಾಗಿ ನಿರಾಕರಿಸಿದ ಎಲ್ಲವನ್ನು ಕಳೆದು.

ಯಾವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಬರುತ್ತವೆ ಎಂಬುದನ್ನು ರೂಟ್‌ಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ

Builder.addRoute(prefix, prefixLength) VPN ನೆಟ್‌ವರ್ಕ್‌ನ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕದಲ್ಲಿ ಪ್ರಿಫಿಕ್ಸ್ ಸ್ಥಾಪಿಸುತ್ತದೆ. ಸಿಸ್ಟಮ್ ಆ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ವ್ಯಾಪ್ತಿಯಲ್ಲಿನ ಅಪ್‌ಗಳಿಗೆ ಡಿಫಾಲ್ಟ್ ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದರ ನಮೂದುಗಳನ್ನು ಭೌತಿಕ ನೆಟ್‌ವರ್ಕ್‌ನ ಡಿಫಾಲ್ಟ್ ರೂಟ್‌ಗಿಂತ ಮೊದಲು ನೋಡಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಂದುವ ಪ್ರಿಫಿಕ್ಸ್ ಹರಿವನ್ನು ಬಳಸಲು ಸಾಕು. ಆದ್ದರಿಂದ 0.0.0.0/0 ಗಾಗಿ ರೂಟ್ IPv4 ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ, ಮುದ್ರಕ, cast ಗುರಿ ಮತ್ತು ರೂಟರ್‌ನ ನಿರ್ವಾಹಕ ಪುಟ ಸೇರಿದಂತೆ.

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

ವಿಳಾಸಗಳು ಮತ್ತು DNS ನಮೂದುಗಳು ಒಂದೇ ನಿರ್ಮಾತೃಯಿಂದ ಬರುತ್ತವೆ ಮತ್ತು ಬೇರೆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತವೆ. addAddress ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಪ್ರಿಫಿಕ್ಸ್ ಉದ್ದದೊಂದಿಗೆ ವಿಳಾಸ ನೀಡುತ್ತದೆ, ಮತ್ತು addDnsServer ವ್ಯಾಪ್ತಿಯ ಅಪ್‌ಗಳು ಇಂಟರ್‌ಫೇಸ್ ಮೂಲಕ ಕೇಳುವ ಪರಿಹಾರಕವನ್ನು ಸ್ಥಾಪಿಸುತ್ತದೆ. ಎರಡೂ ಕುಟುಂಬಗಳು ಒಂದೇ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಇರಬಹುದು, ಆದ್ದರಿಂದ IPv6 ವಿಳಾಸದ ಪಕ್ಕದಲ್ಲಿ IPv4 ಮಾತ್ರ ರೂಟ್‌ಗಳ ಸಮೂಹವು ಸರಿಯಾಗಿ ಓದಲ್ಪಡುವ ಮತ್ತು ಆದರೂ ಸೋರುವ ಸಂರಚನೆ. ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ವಿಳಾಸವಿಲ್ಲದ ಕುಟುಂಬವನ್ನು ರೂಟ್ ಮಾಡಿದರೆ, ಕರ್ಣೆಲ್‌ಗೆ ಆ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಮೂಲ ವಿಳಾಸವಿರುವುದಿಲ್ಲ ಮತ್ತು ಅವು ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ನಲ್ಲಿ ಎಂದಿಗೂ ಕಾಣಿಸುವುದಿಲ್ಲ.

establish() ಏನನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ

establish() ParcelFileDescriptor ಅನ್ನು ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಅಥವಾ ಅಪ್ ಅಧಿಕೃತವಾಗಿಲ್ಲದಿದ್ದಾಗ null. null ನೆಟ್‌ವರ್ಕ್ ದೋಷವಲ್ಲ, ಒಪ್ಪಿಗೆಯ ಸ್ಥಿತಿ: VpnService.prepare() ಈಗಾಗಲೇ null ಹಿಂತಿರುಗಿಸಿರಬೇಕು, ಅಥವಾ ಬಳಕೆದಾರರು ಕರೆಗಿಂತ ಮೊದಲು ಸಿಸ್ಟಮ್ ಸಂವಾದವನ್ನು ಅನುಮೋದಿಸಿರಬೇಕು. ಸೇವೆ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಒಪ್ಪಿಗೆ ಹಿಂಪಡೆಯಬಹುದು, ಮತ್ತು ಇಂಟರ್‌ಫೇಸ್ ನಿಮ್ಮ ಓದುವ ಲೂಪ್‌ಗೆ ಯಾವುದೇ ಕಾಲ್‌ಬ್ಯಾಕ್ ಇಲ್ಲದೆ ನಿಮ್ಮ ಕಾಲಿನ ಕೆಳಗೆ ಮುಚ್ಚುತ್ತದೆ.

ನೀವು ಬೇರೆ ಹೇಳದಿದ್ದರೆ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಬ್ಲಾಕ್ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಓದುವಿಕೆ ಥ್ರೆಡ್ ಅನ್ನು ನಿಲ್ಲಿಸುವ ಬದಲು ಡೇಟಾ ಇಲ್ಲದೆ ತಕ್ಷಣ ಹಿಂತಿರುಗುತ್ತದೆ. ಬ್ಲಾಕಿಂಗ್ ಸಾಕೆಟ್‌ಗಾಗಿ ಬರೆದ ಲೂಪ್ ಒಂದು ಕೋರ್ ಅನ್ನು ಸುಡುತ್ತದೆ, ಮತ್ತು ಖಾಲಿ ಓದುವಿಕೆಯನ್ನು ಮಾರಕ ಎಂದು ಪರಿಗಣಿಸುವ ಲೂಪ್ ನಿಷ್ಕ್ರಿಯ ಸೆಕೆಂಡಿನಲ್ಲಿ ಟನೆಲ್ ಅನ್ನು ಹರಿದು ಹಾಕುತ್ತದೆ. Builder.setBlocking(true) ಆ ವರ್ತನೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಬೆಲೆ ಓದುವಿಕೆಯ ಒಳಗೆ ಕಾಯುವ ಥ್ರೆಡ್.

ರೂಟ್ ಮತ್ತು ವಿಳಾಸದ ವಾದಗಳು LinkAddress ಮೌಲ್ಯಗಳಾಗಿ ಮೌಲ್ಯೀಕರಿಸಲ್ಪಡುತ್ತವೆ, ಮತ್ತು 224.0.0.0/4 ನಂತಹ ಮಲ್ಟಿಕಾಸ್ಟ್ ಗಮ್ಯಸ್ಥಾನಗಳು ನೇರವಾಗಿ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತವೆ. ಪಾಯಿಂಟ್-ಟು-ಪಾಯಿಂಟ್ tun ಇಂಟರ್‌ಫೇಸ್‌ಗೆ ಬ್ರಾಡ್‌ಕಾಸ್ಟ್ ಡೊಮೇನ್ ಕೂಡ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಅದರ ಮೂಲಕ ಮಲ್ಟಿಕಾಸ್ಟ್ ಅನ್ವೇಷಣೆಗೆ ಇನ್ನೊಂದು ರೂಟ್ ಅಲ್ಲ, ಬೇರೆ ವಿನ್ಯಾಸ ಬೇಕು. ಪರಿಶೀಲಿಸಬೇಕಾದ ಪಟ್ಟಿ VpnService.Builder ಆಗಿದೆ, ಕರೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುವ ಮೊದಲು.

ಅಪ್-ವಾರು ವ್ಯಾಪ್ತಿ ಗುಂಪನ್ನು ಸಂಕುಚಿಸುತ್ತದೆ, ಟನೆಲ್ ಅನ್ನಲ್ಲ

API 21 ರಿಂದ ನಿರ್ಮಾತೃ addAllowedApplication ಮತ್ತು addDisallowedApplication ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡೂ ಪಟ್ಟಿಗಳು ಒಂದೇ ನಿರ್ಮಾತೃಯಲ್ಲಿ ಪರಸ್ಪರ ವರ್ಜಿಸುತ್ತವೆ. ಅನುಮತಿ ಪಟ್ಟಿ ಆ ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಟನೆಲ್ ಇರುವಂತೆ ಮಾಡುತ್ತದೆ, ಉಳಿದೆಲ್ಲವೂ ಭೌತಿಕ ನೆಟ್‌ವರ್ಕ್ ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ; ನಿಷೇಧ ಪಟ್ಟಿ ಹೆಸರಿಸಿದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಹೊರತು ಎಲ್ಲವನ್ನೂ ಹಿಡಿಯುತ್ತದೆ, ಅದನ್ನು ಕ್ಲೈಂಟ್ ವಿಭಜಿತ ಟನೆಲಿಂಗ್ ಎಂದು ನೀಡುತ್ತದೆ. API 21 ಕ್ಕಿಂತ ಮೊದಲು ವೇದಿಕೆಯ ಯಾವುದೇ ಕಾರ್ಯವಿಧಾನವಿಲ್ಲ, ಮತ್ತು ಅಪ್-ವಾರು ವರ್ತನೆ ತಮ್ಮ ಮುಂದೂಡುವಿನ ಒಳಗೆ UID ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡುವ ತೃತೀಯ ಪಕ್ಷದ ಕ್ಲೈಂಟ್‌ಗಳಿಂದ ಬಂದಿತು. ಡೀಬಗ್ ಮಾಡುವಾಗ ಈ ಭೇದ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಒಂದು ಪ್ಯಾಕೆಟ್‌ನ ಅನುಮತಿ ಪಟ್ಟಿಯಿರುವ ಅಪ್-ವಾರು ಟನೆಲ್ ಬಹುತೇಕ ಯಾವುದೇ ಟ್ರಾಫಿಕ್ ಉತ್ಪಾದಿಸುವುದಿಲ್ಲ ಮತ್ತು ಅದು ಸರಿಯಾದ ವರ್ತನೆ, ಮುರಿದ ರೂಟ್ ಅಲ್ಲ.

ವ್ಯಾಪ್ತಿ ಏನೇ ಇರಲಿ, ನಿಮ್ಮ ಅಪ್ VPN ಸರ್ವರ್‌ಗೆ ತೆರೆಯುವ ಸಾಕೆಟ್ ಅದು ನಿರ್ಮಿಸುತ್ತಿರುವ ಟನೆಲ್ ಮೂಲಕ ಹೋಗಬಾರದು. VpnService.protect(socket) ಆ ಸಾಕೆಟ್ ಅನ್ನು ಮೂಲ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಬಂಧಿಸುತ್ತದೆ, ಇದರಿಂದ ಅದರ ಪ್ಯಾಕೆಟ್‌ಗಳು tun ಸಾಧನವನ್ನು ಬಿಟ್ಟು ಹೋಗುತ್ತವೆ. ಕರೆಯನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟರೆ, ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ಅದನ್ನು ಎತ್ತಬೇಕಿದ್ದ ಇಂಟರ್‌ಫೇಸ್ ನುಂಗುತ್ತದೆ.

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

ಚೆಕ್‌ಸಮ್‌ಗಳು ಮತ್ತು MTU: ಸರಿಯಾದ ರೂಟ್ ಕೂಡ ವಿಫಲವಾಗುವ ಸ್ಥಳ

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

ಎರಡನೆಯದು ಚೆಕ್‌ಸಮ್‌ನ ವ್ಯಾಪ್ತಿ. ಅಪ್ ತಾನೇ TCP ಅಥವಾ UDP ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ನಿರ್ಮಿಸಿದಾಗ, ಚೆಕ್‌ಸಮ್ ಮೂಲ ವಿಳಾಸ, ಗಮ್ಯ ವಿಳಾಸ, ಪ್ರೋಟೋಕಾಲ್ ಸಂಖ್ಯೆ ಮತ್ತು ಸಾಗಣೆ ಉದ್ದವನ್ನು ಹೊಂದಿರುವ ಸ್ಯೂಡೊ-ಶೀರ್ಷಿಕೆಯನ್ನು ಆವರಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಬಿಟ್ಟರೆ ಬಂದು ಬಿಸಾಡಲ್ಪಡುವ ಪ್ಯಾಕೆಟ್‌ಗಳು ಸಿಗುತ್ತವೆ. ಆ ವೈಫಲ್ಯ ಎಂದಿಗೂ ಬಾರದ ಉತ್ತರದ ನಂತರದ ಕಾಲಾವಧಿ ಮುಗಿದಂತೆ ಕಾಣುತ್ತದೆ, ಮತ್ತು ಅದು ಬಹುತೇಕರನ್ನು ರೂಟ್‌ಗಳಿಗೆ ಮರಳಿಸುತ್ತದೆ. setMtu ಇಂಟರ್‌ಫೇಸ್‌ನ MTU ಅನ್ನು ಸ್ಥಿರಗೊಳಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಓದುವಿಕೆ ನಿಖರವಾಗಿ ಒಂದು ಪೂರ್ಣ IP ಪ್ಯಾಕೆಟ್ ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಬೈಟ್ ಹರಿವಿಗಾಗಿ ಬರೆದ ಬಫರ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನಲ್ಲ, ನಿಮ್ಮ ಪಾರ್ಸಿಂಗ್ ಅನ್ನು ಚೂರುಚೂರಾಗಿಸುತ್ತದೆ.

ಪದರಗಳನ್ನು ಬೇರ್ಪಡಿಸುವ ಪರಿಶೀಲನಾ ಸುತ್ತು

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

ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗೆ ಏನೂ ತಲುಪದಿದ್ದರೆ, ಸಂದೇಹಾಸ್ಪದ ಓದುಗನಲ್ಲ, ರೂಟ್‌ಗಳ ಗುಂಪು: ಪ್ರಿಫಿಕ್ಸ್‌ಗಳನ್ನು ಖಚಿತಪಡಿಸಿ, ಅದೇ ಕುಟುಂಬದಲ್ಲಿ ವಿಳಾಸವಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಮತ್ತು ಅಪ್ ನೀವು ನಿಗದಿಪಡಿಸಿದ ವ್ಯಾಪ್ತಿಯೊಳಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಪ್ಯಾಕೆಟ್‌ಗಳು ಡಿಸ್ಕ್ರಿಪ್ಟರ್‌ಗೆ ತಲುಪಿ ಏನೂ ಹಿಂತಿರುಗದಿದ್ದರೆ, ಮತ್ತೆ ರೂಟ್ ಮುಟ್ಟುವ ಮೊದಲು protect() ಮತ್ತು ಮೂಲ ನೆಟ್‌ವರ್ಕ್‌ನ ಮೌಲ್ಯವನ್ನು ಪರಿಶೀಲಿಸಿ. ದೂರದ ತುದಿ ವಿಕೃತ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ವರದಿ ಮಾಡಿದರೆ, ಚೆಕ್‌ಸಮ್ ಮತ್ತು MTU ನೋಡಬೇಕಾದ ಸ್ಥಳಗಳು. ಪ್ರತಿ ಪದರಕ್ಕೆ ಒಂದು ಪರೀಕ್ಷೆ ಅರ್ಧ ದಿನದ ಊಹೆಯನ್ನು ಉಳಿಸುತ್ತದೆ.