VPN ಪಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ ಸೈಟ್ ನಿಲ್ಲುತ್ತದೆ: ಗಾತ್ರ ಪರಿಶೀಲಿಸಿ

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

ಅತಿ ಚಿಕ್ಕ ಪ್ರಶ್ನೆಯಿಂದ ಅತಿ ದೊಡ್ಡ ಪ್ರಶ್ನೆಯತ್ತ ಹೋಗಿ, ಪ್ರತಿ ಹಂತವು ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಬೀತುಪಡಿಸಿತು ಎಂದು ಬರೆಯಿರಿ.

ಎಕೋ ಪ್ರತಿಕ್ರಿಯೆ ಬಹಳ ಚಿಕ್ಕ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ

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

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

ಸಂಪರ್ಕ ಪ್ರಾರಂಭವಾಯಿತೇ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

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

curl -v --max-time 10 https://internal.example/ -o /dev/null
ss -tn state established '( dport = :443 )'

MTU ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಆ ಮೂರರಲ್ಲಿ ಯಾವುದನ್ನು ಗಮನಿಸಿದಿರಿ ಎಂದು ಬರೆಯಿರಿ. ನಿರಾಕರಿಸಿದ ಸಂಪರ್ಕವನ್ನು ಸರಿಪಡಿಸಲು ಟನೆಲ್ ಗಾತ್ರ ಬದಲಾಯಿಸುವುದು ಆ ಬದಲಾವಣೆಯನ್ನು ವ್ಯರ್ಥ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಜವಾದ ಕಾರಣವನ್ನು ಸ್ವಲ್ಪ ಕಾಲ ಮುಚ್ಚಿಡುತ್ತದೆ.

ಹೇಳಿದ ಸಂಖ್ಯೆಯಿಂದ ಗಾತ್ರ ಅಳೆಯಿರಿ

ಹೊರೆಯಲ್ಲಿ ನಿಲ್ಲುವಿಕೆ ಕಾಣಿಸಿದಾಗ, ಭಾಗೀಕರಣ ನಿಷೇಧದ ಬಿಟ್ ಸೇರಿಸಿ ಒಂದು ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ ಮತ್ತು ಫಲಿತಾಂಶಕ್ಕೆ ಅರ್ಥ ಬರುವಂತೆ ಲೆಕ್ಕಾಚಾರವನ್ನು ತಿಳಿಸಿ. iputils ಇರುವ Linux ನಲ್ಲಿ, 1392 ಬೈಟ್ ಪೇಲೋಡ್ ಜೊತೆಗೆ 8 ಬೈಟ್ ICMP ಹೆಡರ್ ಮತ್ತು 20 ಬೈಟ್ IPv4 ಹೆಡರ್ ಸೇರಿ ನಿಖರವಾಗಿ 1420 ಬೈಟ್ ಒಳ ಪ್ಯಾಕೆಟ್ ಆಗುತ್ತದೆ. ಆ ಲೆಕ್ಕಾಚಾರವನ್ನು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಬರೆಯಿರಿ, ಏಕೆಂದರೆ ಗೇಟ್‌ವೇ ತಲುಪುವ ಬರೀ ping ಅಪ್ಲಿಕೇಶನ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.

ping -4 -M do -s 1392 10.44.0.10
ping -4 -M do -s 1372 10.44.0.10

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

ಹೊರ ಮಾರ್ಗವನ್ನು ಲೆಕ್ಕಕ್ಕೆ ತೆಗೆದುಕೊಳ್ಳಿ

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

IPv4 ನಲ್ಲಿ ಮಾರ್ಗ MTU ಪತ್ತೆ ಭಾಗೀಕರಣವಿಲ್ಲದೆ ಮುಂದೆ ಕಳುಹಿಸಲಾಗದ ಪ್ಯಾಕೆಟ್‌ಗಳ ಬಗ್ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು IPv6 Packet Too Big ಸಂದೇಶಗಳನ್ನು ಬಳಸುತ್ತದೆ. IPv4 ವಿಶೇಷಣ ಆ ಕಾರ್ಯವಿಧಾನವನ್ನು ವಿವರಿಸುತ್ತದೆ. ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದು ಕಳುಹಿಸುವವರ ಕಲಿಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಮುರಿಯುತ್ತದೆ, ಮತ್ತು ಎಂದೂ ಹಿಡಿಸದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಅವರು ಮತ್ತೆ ಮತ್ತೆ ಕಳುಹಿಸುವಂತೆ ಮಾಡುತ್ತದೆ. ಆದ್ದರಿಂದಲೇ ಕೆಲಸ ಮಾಡುವ ಸಣ್ಣ ವಿನಂತಿ ಮತ್ತು ವಿಫಲವಾಗುವ ದೊಡ್ಡ ವಿನಂತಿ ಅಷ್ಟು ಆರಾಮವಾಗಿ ಜೊತೆಯಾಗಿ ಇರುತ್ತವೆ.

ಒಂದು ಸಂಖ್ಯೆ ಬದಲಿಸಿ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ

ಟನೆಲ್‌ನ MTU ಕಡಿಮೆ ಮಾಡಿ, ಅಥವಾ TCP ಗಾಗಿ ಗರಿಷ್ಠ ವಿಭಾಗ ಗಾತ್ರವನ್ನು ಮಿತಿಗೊಳಿಸಿ, ನಂತರ ಪರೀಕ್ಷೆಯ ಬದಲು ಮೂಲ ಅಪ್ಲಿಕೇಶನ್ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಬದಲಾವಣೆಯ ನಂತರ ಯಶಸ್ವಿಯಾಗುವ ಪರೀಕ್ಷೆ ಮತ್ತು ಇನ್ನೂ ನಿಲ್ಲುವ ಅಪ್ಲಿಕೇಶನ್ ಒಂದೇ ರೀತಿಯ ಆಕಾರದ ಬೇರೆ ಸಮಸ್ಯೆ, ಮತ್ತು ಅವನ್ನು ಅಪ್ಲಿಕೇಶನ್ ಪರೀಕ್ಷೆಯಷ್ಟೇ ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.

ಬದಲಾವಣೆಯ ದಾಖಲೆಯಲ್ಲಿ ಲೆಕ್ಕಾಚಾರವನ್ನು ಇರಿಸಿ: ಅಳೆದ ಗಾತ್ರ, ನೀವು ಊಹಿಸಿದ ಹೆಚ್ಚುವರಿ ಭಾರ, ಮತ್ತು ನೀವು ಸೆಟ್ ಮಾಡಿದ ಮೌಲ್ಯ. ನಂತರ ಅದನ್ನು ಪರಿಶೀಲಿಸುವ ಯಾರಾದರೂ ping ನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ನಿಂದ ಮತ್ತೆ ಪಡೆಯುವ ಬದಲು ಊಹೆಯನ್ನು ಪರಿಶೀಲಿಸಬಹುದು.

ನೀವು ಪ್ರಯತ್ನಿಸಿದ ಪ್ರತಿ ಗಾತ್ರದಲ್ಲೂ ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡಿದರೆ, ಸಂಖ್ಯೆಗಳನ್ನು ಸರಿಹೊಂದಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಸೇವೆಯನ್ನು ವಿಫಲವಾಗುವ ಸೇವೆಯಿಂದ ಬೇರ್ಪಡಿಸುವ ನೀತಿಯನ್ನು ನೋಡಿ.