VPN ಮೂಲಕ ಪಾತ್ MTU ಶೋಧನೆ: ಗಾತ್ರ ಮತ್ತು ICMP ಅಂತರ

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

ಪಾತ್ MTU ನಿಜವಾಗಿ ಏನನ್ನು ಅಳೆಯುತ್ತದೆ

ಪಾತ್ MTU ಎರಡು ಹೋಸ್ಟ್ಗಳ ನಡುವಿನ ಮಾರ್ಗದಲ್ಲಿ ಅತ್ಯಂತ ಚಿಕ್ಕ ಕೊಂಡಿ MTU, ನಿಮ್ಮ ಸ್ಥಳೀಯ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಮುದ್ರಿಸಲಾದ MTU ಅಲ್ಲ. ಸ್ಥಳೀಯ ಮೌಲ್ಯವು ಅಂದಾಜು ಪ್ರಾರಂಭವಾಗುವ ಸ್ಥಳ, ಮತ್ತು ಅದು ಎಲ್ಲಿ ಕೊನೆಗೊಳ್ಳಬೇಕೆಂದು ಪಾತ್ ನಿರ್ಧರಿಸುತ್ತದೆ. ಅದಕ್ಕೇ ಒಂದೇ ರೀತಿಯ ಸುರಂಗವು ಒಂದು ಪ್ರವೇಶ ಜಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಲ್ಲಿ ನಿಲ್ಲಬಹುದು: ಮಾರ್ಗ ಬದಲಾಯಿತು, ಸಂರಚನೆ ಅಲ್ಲ. ಒಮ್ಮೆ ಅಳೆದು ಎಲ್ಲೆಡೆ ಊಹಿಸುವುದೇ ಈ ಸಮಸ್ಯೆಯನ್ನು ಜೀವಂತವಾಗಿಡುವ ತಪ್ಪು.

ಸುರಂಗಕ್ಕೆ ಮುಖ್ಯವಾದ ಸಂಖ್ಯೆ ಒಳಗಿನ MTU, ಅದು ಹೊರಗಿನ ಪಾತ್ನ ಅನುಮತಿಯಿಂದ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಖರ್ಚು ಮಾಡುವುದನ್ನು ಕಳೆದದ್ದು. WireGuard ಹೊರಗಿನ IP ಹೆಡರ್ ಮತ್ತು UDP ಹೆಡರ್ ಸೇರಿಸುತ್ತದೆ; ಇತರ ಸಾರಿಗೆಗಳು ತಮ್ಮದನ್ನು ಸೇರಿಸುತ್ತವೆ. ಒಳಗಿನ ಗಾತ್ರವನ್ನು ತುಂಬಾ ಹೆಚ್ಚಿಸಿದರೆ ಪೂರ್ಣ ಗಾತ್ರದ ಪ್ರತಿಯೊಂದು ಪ್ಯಾಕೆಟ್ಗೂ ಎಂದೂ ಸಂಭವಿಸದ ಫ್ರ್ಯಾಗ್ಮೆಂಟೇಶನ್ ಬೇಕಾಗುತ್ತದೆ.

ಸುರಂಗವು ಬಳಸಬಹುದಾದ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಏಕೆ ಚಿಕ್ಕದಾಗಿಸುತ್ತದೆ

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

ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮವೆಂದರೆ ಹ್ಯಾಂಡ್ಶೇಕ್ಗೆ ಹೊಂದಿಕೊಳ್ಳುವ ಆದರೆ ಪೇಲೋಡ್ಗೆ ಹೊಂದಿಕೊಳ್ಳದ ಗಾತ್ರ. TLS ClientHello ಅಥವಾ DNS ಪ್ರಶ್ನೆ ಚಿಕ್ಕದಾದ ಪಾತ್ ಅನ್ನು ಮುಟ್ಟದೆ ದಾಟಲು ಸಾಕಷ್ಟು ಚಿಕ್ಕದು, ಆದರೆ ಬೃಹತ್ ವರ್ಗಾವಣೆ ಹಾಗಲ್ಲ. ಆದ್ದರಿಂದ ಲಕ್ಷಣಗಳು ನಿರ್ದಿಷ್ಟ ಹೋಸ್ಟ್ಗಳ ಸುತ್ತ ಅಲ್ಲ, ನಿರ್ದಿಷ್ಟ ಕ್ರಿಯೆಗಳ ಸುತ್ತ ಸೇರುತ್ತವೆ.

ಪ್ರತಿಕ್ರಿಯೆ ಬಂದಾಗ ಮಾತ್ರ ಶೋಧನೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ

IPv4 ಶೋಧನೆ don't-fragment ಬಿಟ್ ಅನ್ನು ಅವಲಂಬಿಸಿದೆ: ಪ್ಯಾಕೆಟ್ ಮುಂದೆ ಕಳುಹಿಸಲಾಗದ ರೌಟರ್ ಮುಂದಿನ ಹಾಪ್ನ MTU ಜೊತೆಗೆ ICMP fragmentation-needed ಹಿಂತಿರುಗಿಸುತ್ತದೆ, ಮತ್ತು ಕಳುಹಿಸುವವನು ತನ್ನ ಅಂದಾಜನ್ನು ಇಳಿಸುತ್ತಾನೆ. IPv6 ಬದಲಿಗೆ Packet Too Big ಸಂದೇಶಗಳನ್ನು ಬಳಸುತ್ತದೆ, ಏಕೆಂದರೆ ರೌಟರ್ಗಳು ಸಾಗಣೆಯಲ್ಲಿ ಫ್ರ್ಯಾಗ್ಮೆಂಟ್ ಮಾಡುವುದಿಲ್ಲ. ಎರಡೂ ಕಾರ್ಯವಿಧಾನಗಳು ಸಂದೇಶವು ಕಳುಹಿಸುವವನ ಬಳಿಗೆ ಹಿಂತಿರುಗುವ ದಾರಿ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಊಹಿಸುತ್ತವೆ, ಸುರಂಗದ ಮೂಲಕ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗದಲ್ಲಿನ ಯಾವುದೇ ಫೈರ್ವಾಲ್ನ ಆಚೆಗೆ. ಆ ಊಹೆ ವಿಫಲವಾದಾಗ, ಕಳುಹಿಸುವವನು ಪಾತ್ ಒಯ್ಯಲಾಗದ ಗಾತ್ರವನ್ನು ಮತ್ತೆ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸುತ್ತಲೇ ಇರುತ್ತಾನೆ.

echo request ಮತ್ತು echo reply ಗೆ ಅನುಮತಿ ನೀಡುವ ಫೈರ್ವಾಲ್ ಆ ದೋಷ ಪ್ರಕಾರಗಳಿಗೂ ಅನುಮತಿ ನೀಡಿರಬೇಕೆಂದಿಲ್ಲ. ICMP ಒಂದು ಕುಟುಂಬ, ಮತ್ತು ಇಲ್ಲಿ ಮುಖ್ಯವಾದ ಸದಸ್ಯರು ದೋಷಗಳು, ಎಕೊ ಜೋಡಿ ಅಲ್ಲ. ಸುರಂಗದ ಎರಡೂ ತುದಿಗಳಲ್ಲಿ ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಮಾರ್ಗದಲ್ಲಿ ನಿಯಂತ್ರಣ ಸಂಚಾರ ನೀತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಎಲ್ಲೆಡೆ ಪ್ರತಿಯೊಂದು ICMP ಪ್ರಕಾರಕ್ಕೆ ಅನುಮತಿ ನೀಡುವ ಬದಲು ವೇದಿಕೆಯ ಬೆಂಬಲಿತ ಮಾರ್ಗದರ್ಶನವನ್ನು ಅನುಸರಿಸಿ.

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

ಸಂಖ್ಯೆಯನ್ನು ಊಹಿಸುವ ಬದಲು ಪಾತ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ

ಗಮ್ಯಸ್ಥಾನ, ಪ್ರವೇಶ ಜಾಲ ಮತ್ತು ಸುರಂಗವನ್ನು ಸ್ಥಿರವಾಗಿಟ್ಟು, ನಂತರ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರವನ್ನು ಮಾತ್ರ ಬದಲಿಸಿ. MTU ಸುಳಿವಿನೊಂದಿಗೆ ವಿಫಲವಾಗುವ don't-fragment ಪರೀಕ್ಷೆ ನಿಮಗೆ ಮುಂದಿನ ಹಾಪ್ ಮಿತಿಯನ್ನು ನೀಡುತ್ತದೆ; ಒಂದು ಗಾತ್ರ ದಾಟುವವರೆಗೆ ಪುನರಾವರ್ತಿಸಿ, ಮತ್ತು ಗಾತ್ರ ಹಾಗೂ ವಿಳಾಸ ಕುಟುಂಬ ಎರಡನ್ನೂ ದಾಖಲಿಸಿ.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

ಹೊಂದಿಕೊಳ್ಳುವ ping ನಿಜವಾದ ಅಪ್ಲಿಕೇಶನ್ನ ಪೂರ್ಣ ಗಾತ್ರದ ವಿಭಾಗಗಳು ಹೊಂದಿಕೊಳ್ಳುತ್ತವೆ ಎಂದು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ನಿಜವಾಗಿ ವಿಫಲವಾದ ವರ್ಗಾವಣೆಯೊಂದಿಗೆ ಪರೀಕ್ಷೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಅತ್ಯಂತ ದೊಡ್ಡ ಕೆಲಸ ಮಾಡಿದ ಪರೀಕ್ಷೆಯನ್ನು ನೀವು ಸಂರಚಿಸಿದ ಸುರಂಗ MTU ಜೊತೆ ಹೋಲಿಸಿ, ಮತ್ತು ಎರಡೂ ಸಂಖ್ಯೆಗಳನ್ನು ನಿಮ್ಮ ಟಿಪ್ಪಣಿಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ. ಅವು ಸುಮಾರು ಒಂದು ಹೆಡರ್ನಷ್ಟು ಭಿನ್ನವಾಗಿದ್ದರೆ, ನೀವು ದೋಷವಲ್ಲದೆ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಓವರ್ಹೆಡ್ ಅನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.

RFC 4821 ನಲ್ಲಿ ವಿವರಿಸಲಾದ PLPMTUD ಮೇಲಕ್ಕೆ ಪರೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ತಲುಪಿಸಿದ ದೋಷಗಳನ್ನು ನಂಬುವ ಬದಲು ಸಾರಿಗೆ ಸ್ವೀಕೃತಿಗಳನ್ನು ಬಳಸುತ್ತದೆ. ICMP ಫಿಲ್ಟರ್ ಮಾಡುವ ಪಾತ್ಗಳಲ್ಲಿ ಇದು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಬೆಂಬಲ ಸ್ಟ್ಯಾಕ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕಾರ ಬದಲಾಗುತ್ತದೆ. TCP ಹರಿವು ತಾನೇ ಚೇತರಿಸಿಕೊಳ್ಳಬಹುದು, ಆದರೆ ಸ್ಥಿರ ಡೇಟಾಗ್ರಾಮ್ ಗಾತ್ರದ UDP ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತಲೇ ಇರುತ್ತದೆ.

ಮೌಲ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಮತ್ತು ಕಾರಣವನ್ನು ದಾಖಲಿಸಿ

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

IPv4 ಕಾರ್ಯವಿಧಾನವನ್ನು RFC 1191 ನಲ್ಲಿ ಮತ್ತು IPv6 ಪ್ಯಾಕೆಟೈಸೇಶನ್ ಮಾರ್ಗದರ್ಶನವನ್ನು RFC 8201 ನಲ್ಲಿ ವಿವರಿಸಲಾಗಿದೆ; ಎರಡನ್ನೂ ಹೆಸರಿಸುವುದು ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಊಹೆಯನ್ನು ಮತ್ತೆ ಪಡೆಯುವುದನ್ನು ತಪ್ಪಿಸುತ್ತದೆ. ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ಗಾತ್ರದಲ್ಲಿ ವರ್ಗಾವಣೆ ಇನ್ನೂ ನಿಂತರೆ, ಸಂಖ್ಯೆಯನ್ನು ಇಳಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ ಮುಂದಿನ ಪದರವನ್ನು ನೋಡಿ. ಪ್ರತಿಯೊಂದು ಗಾತ್ರದಲ್ಲಿ ವಿಫಲವಾಗುವ ಪಾತ್ MTU ಸಮಸ್ಯೆ ಅಲ್ಲ.