IPv6 ಪ್ಯಾಕೆಟ್ ತುಂಬ ದೊಡ್ಡದು: ದೊಡ್ಡ VPN ವರ್ಗಾವಣೆಗಳು ಏಕೆ ನಿಲ್ಲುತ್ತವೆ

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

ಸಣ್ಣ ಕೋರಿಕೆಗಳು, ದೊಡ್ಡ ನಿಲುಗಡೆಗಳು

ಸುರಂಗ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಇನ್ನೊಂದು ಹೆಡರ್‌ನಲ್ಲಿ ಸುತ್ತುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಳಗಿನ ಬಳಸಬಹುದಾದ ಗಾತ್ರ ಹೊರಗಿನ ಗಾತ್ರಕ್ಕಿಂತ ಚಿಕ್ಕದು. ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್‌ಗೆ ಮೊದಲು ಭೌತಿಕ ಕೊಂಡಿಗೆ ಅಳೆಯಲಾದ ಪ್ಯಾಕೆಟ್ ನಂತರ ತುಂಬ ದೊಡ್ಡದಾಗುತ್ತದೆ. IPv4 ರೌಟರ್‌ಗಳು ಮಾರ್ಗದಲ್ಲಿ ಒಡೆಯಬಹುದು, ಆದರೆ IPv6 ರೌಟರ್‌ಗಳು ಕಳುಹಿಸುವವನ ಪರವಾಗಿ ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕಳುಹಿಸುವವನೇ ಹೊಂದಿಕೊಳ್ಳಬೇಕು. ಮತ್ತು ಆ ಹೊಂದಾಣಿಕೆ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರತಿಕ್ರಿಯೆ ಸಿಗುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ.

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

Packet Too Big ಪ್ರತಿಕ್ರಿಯೆ, ಸಂಚಾರವಲ್ಲ

ICMPv6 Packet Too Big ಸಂದೇಶ ಮುಂದಿನ ಹಾಪ್ ಸ್ವೀಕರಿಸಬಹುದಾದ ಗಾತ್ರವನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಕಳುಹಿಸುವವನು ತನ್ನ ಅಂದಾಜನ್ನು ತಗ್ಗಿಸಲು ಅದನ್ನು ಬಳಸುತ್ತಾನೆ. ಅದನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುವುದು ರಸ್ತೆ ಚಿಹ್ನೆಯನ್ನು ತೆಗೆದು ನಂತರ ಚಾಲಕರನ್ನು ದೂಷಿಸಿದಂತೆ. ಎಲ್ಲಾ ICMPv6 ಅನ್ನು ಬಿಸಾಡುವ ನಿಯಮ ಕಠಿಣವಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಅದು ಬೇಕಾದ ಪ್ರತಿ ಕೊಂಡಿಯಲ್ಲಿ ಮಾರ್ಗ ಶೋಧವನ್ನು ಮುರಿಯುತ್ತದೆ. ಸಂದೇಶವು ಮಾರ್ಗದ ಬಗ್ಗೆ ನಿಯಂತ್ರಣ ಮಾಹಿತಿ, ಅಪ್ಲಿಕೇಶನ್ ಪೇಲೋಡ್ ಅಲ್ಲ.

ಆಯ್ದ ಫಿಲ್ಟರಿಂಗ್ ಇನ್ನೂ ಸಮಂಜಸ. ಪ್ರತಿಧ್ವನಿ ವಿನಂತಿಗಳು ಮತ್ತು ನೆರೆಹೊರೆಯ ಶೋಧ ದೋಷ ಸಂದೇಶಗಳಿಗಿಂತ ಬೇರೆ ಪಾತ್ರ ವಹಿಸುತ್ತವೆ, ಮತ್ತು ನೀತಿಯು ಅವನ್ನು ಬೇರೆ ರೀತಿಯಲ್ಲಿ ನೋಡಬಹುದು. ಇಡೀ ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಅಥವಾ ಬಿಸಾಡುವ ಬದಲು ವೇದಿಕೆಯ ದಾಖಲಿತ ಫಿಲ್ಟರಿಂಗ್ ಮಾರ್ಗದರ್ಶನವನ್ನು ಅನುಸರಿಸಿ, ಏಕೆಂದರೆ RFC 8201 ಆ ಪ್ರತಿಕ್ರಿಯೆ ಶೋಧವನ್ನು ಹೇಗೆ ನಡೆಸುತ್ತದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಎರಡೂ ವಿಳಾಸ ಕುಟುಂಬಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರೀಕ್ಷಿಸಿ

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

ping -6 -M do -s 1400 host.internal
ip -6 route get 2001:db8:2::10
sudo tcpdump -ni any 'icmp6 and ip6[40] == 2'

ಪ್ರೋಬ್ do-not-fragment ಬಿಟ್ ಸೆಟ್ ಮಾಡಿ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು ಅದು ವಿಫಲವಾಗುವ ಗಾತ್ರವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಅದೇ ಸುರಂಗವು ಇರಿಸಿಕೊಳ್ಳಬೇಕಾದ ಸಂಖ್ಯೆ. ಮಾರ್ಗ ಪ್ರಶ್ನೆ ಗಮ್ಯವನ್ನು ಒಯ್ಯುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಹೆಸರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಾವ ಕೊಂಡಿಯ MTU ಅನ್ವಯವಾಗುತ್ತದೆ ಎಂದು ನಿಮಗೆ ತಿಳಿಯುತ್ತದೆ. ಸೆರೆ ICMPv6 ಪ್ರಕಾರ 2, ಅಂದರೆ Packet Too Big ಸಂದೇಶವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅದು ಈ ಹೋಸ್ಟ್‌ಗೆ ತಲುಪುತ್ತದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಸಂದೇಶ ಸೆರೆಯಲ್ಲಿ ಕಾಣಿಸಿ ವರ್ಗಾವಣೆ ಇನ್ನೂ ನಿಂತರೆ, ಕಳುಹಿಸುವವನು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತಿದ್ದಾನೆ, ಇದು ತನಿಖೆಯನ್ನು ಜಾಲದಿಂದ ಸ್ಟ್ಯಾಕ್‌ಗೆ ಸರಿಸುತ್ತದೆ.

ಸಾಕ್ಷ್ಯದ ನಂತರವೇ ಸುರಂಗದ ಗಾತ್ರವನ್ನು ಬದಲಿಸಿ

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

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