ಪ್ರಮಾಣೀಕರಣದ ಮೂಲಕ ಹಾದು, ping ಅನ್ನು ಸಾಗಿಸಿ ನಂತರ ಮೊದಲ ದೊಡ್ಡ ವರ್ಗಾವಣೆಯಲ್ಲಿ ನಿಲ್ಲುವ ಸುರಂಗವು ಮುರಿದ VPN ಅಲ್ಲ, ಕಾಣೆಯಾದ ICMP ಸಂದೇಶದ ಸಾಂಪ್ರದಾಯಿಕ ಚಿಹ್ನೆ. ಕಳುಹಿಸುವವನಿಗೆ ಪ್ಯಾಕೆಟ್ ತುಂಬಾ ದೊಡ್ಡದಾಗಿತ್ತು ಎಂದು ಎಂದಿಗೂ ತಿಳಿಯುವುದಿಲ್ಲ, ಅದೇ ಗಾತ್ರವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾನೆ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕಾಯುತ್ತದೆ. ಇದನ್ನು ಸರಿಪಡಿಸುವುದು ಫೈರ್ವಾಲ್ ನೀತಿಯ ನಿರ್ಧಾರ, ಕ್ಲೈಂಟ್ ಮರುಸ್ಥಾಪನೆ ಅಲ್ಲ. ಕ್ರಮ ಮುಖ್ಯ: ಗಾತ್ರದ ಮಿತಿ ಎಲ್ಲಿದೆ ಎಂದು ಅಳೆಯಿರಿ, ನಂತರ ವರದಿಯನ್ನು ನುಂಗಿದ ನಿಯಮವನ್ನು ಸಂಕುಚಿಸಿ.

ಈ ಮಾರ್ಗದಲ್ಲಿ ICMP ನಿಜವಾಗಿ ಏನನ್ನು ಸಾಗಿಸುತ್ತದೆ

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

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

ಕೆಲವು ಸಾಗಣೆಗಳು ತಮ್ಮದೇ ಪತ್ತೆಯನ್ನು ಪ್ರೋಬ್ ಪ್ಯಾಕೆಟ್ಗಳಿಂದ ಜಾರಿಗೊಳಿಸುತ್ತವೆ, RFC 4821 ವಿವರಿಸಿದಂತೆ, ಮತ್ತು ಅವು ಈ ಪ್ರತಿಕ್ರಿಯೆಯ ಮೇಲೆ ಕಡಿಮೆ ಅವಲಂಬಿತವಾಗಿವೆ. ಇದು ಯಾವ ಸಾಗಣೆಯನ್ನು ನಡೆಸುತ್ತೀರಿ ಎಂದು ಪರಿಶೀಲಿಸುವ ವಾದ, ಪ್ರತಿ ಸುರಂಗವೂ ಪ್ರತಿರಕ್ಷಿತ ಎಂದು ಊಹಿಸುವುದಲ್ಲ.

ಸಂದೇಶಮಾರ್ಗದಲ್ಲಿ ಉದ್ದೇಶನಿರ್ಬಂಧಿಸಿದರೆ
ICMPv4 ಪ್ರಕಾರ 3 ಕೋಡ್ 4ಮುಂದಿನ ಕೊಂಡಿಗೆ ಪ್ಯಾಕೆಟ್ ತುಂಬಾ ದೊಡ್ಡದಾಗಿತ್ತುಕಳುಹಿಸುವವನು ಪುನರಾವರ್ತಿಸಿ ನಿಲ್ಲುತ್ತಾನೆ
ICMPv6 ಪ್ರಕಾರ 2Packet Too Big, IPv6 ಸಮಾನಅದೇ ನಿಲುಗಡೆ, ಒಡೆಯುವಿಕೆಯ ಬದಲಿ ಮಾರ್ಗವಿಲ್ಲದೆ
ICMP ಪ್ರಕಾರ 11ಸಮಯ ಮೀರಿತು, traceroute ಬಳಸುತ್ತದೆರೋಗನಿರ್ಣಯ ಹಾಪ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ, ಸಂಚಾರ ಹರಿಯುತ್ತದೆ
ICMP ಪ್ರತಿಧ್ವನಿ ವಿನಂತಿ ಮತ್ತು ಉತ್ತರತಲುಪುವಿಕೆ ಪರೀಕ್ಷೆping ವಿಫಲವಾಗುತ್ತದೆ, ಮಾರ್ಗ ಸರಿಯಾಗಿರಬಹುದು

ವೈಫಲ್ಯ ಗಾತ್ರವನ್ನು ಅವಲಂಬಿಸಿದೆ

ವೈಫಲ್ಯವು ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಕ್ಕೆ ಸಂಬಂಧಿಸಿದೆಯೇ ಎಂದು ಕೇಳಿ. ಲಾಗಿನ್ ಪುಟ, DNS ಪ್ರಶ್ನೆ ಮತ್ತು ಸಣ್ಣ API ಕರೆ ಯಶಸ್ವಿಯಾಗುತ್ತವೆ, ಆದರೆ ಫೈಲ್ ಅಪ್ಲೋಡ್, ದೊಡ್ಡ ಪ್ರತಿಕ್ರಿಯೆ ಅಥವಾ ಚಿತ್ರ ಡೌನ್ಲೋಡ್ ನಿಲ್ಲುತ್ತದೆ. ಈ ಮಾದರಿ ಎರಡು ತುದಿಗಳ ನಡುವೆ ಎಲ್ಲೋ ಗಾತ್ರದ ಮಿತಿಯತ್ತ ಸೂಚಿಸುತ್ತದೆ, ಪ್ರಮಾಣೀಕರಣ ಅಥವಾ ರೌಟಿಂಗ್ನತ್ತ ಅಲ್ಲ. ಯಶಸ್ವಿ ಸಣ್ಣ ping ಆ ಮಿತಿ ಎಲ್ಲಿದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಬಹುತೇಕ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

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

ನಿಯಮಗಳನ್ನು ಸಂಪಾದಿಸುವ ಮೊದಲು ಅಳೆಯಿರಿ

don't-fragment ಬಿಟ್ ಮತ್ತು ನೀವು ಆಯ್ಕೆ ಮಾಡುವ ಪೇಲೋಡ್ ಗಾತ್ರದೊಂದಿಗೆ ಪ್ರೋಬ್ ಮಾಡಿ, ವಿಫಲವಾದ ಕ್ಲೈಂಟ್ನಿಂದ ಸಂರಕ್ಷಿತ ವಿಳಾಸದತ್ತ:

ping -M do -s 1472 10.20.5.7
ping -M do -s 1300 10.20.5.7

1472 ಬೈಟ್ ಪೇಲೋಡ್ ಜೊತೆಗೆ 28 ಬೈಟ್ ಹೆಡರ್ 1500 ಬೈಟ್ ಪ್ಯಾಕೆಟ್ ಆಗುತ್ತದೆ. ದೊಡ್ಡ ಪ್ರೋಬ್ ಒಡೆಯುವಿಕೆ ದೋಷದಿಂದ ವಿಫಲವಾಗಿ ಸಣ್ಣದು ಹಾದುಹೋದರೆ, ನೀವು ಮಿತಿಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ; ಸುರಂಗದ ಹೆಚ್ಚುವರಿ ಭಾರಕ್ಕೆ ಹೊಂದಿಸಿ ಮತ್ತು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಗಾತ್ರ ಸ್ಥಿರವಾಗುವವರೆಗೆ ಪುನರಾವರ್ತಿಸಿ.

ನಂತರ ಅಂತರವೇ ವರದಿ ಎಂದು ಖಚಿತಪಡಿಸಿ. ಪ್ರೋಬ್ ಮೌನವಾಗಿ ವಿಫಲವಾದರೆ, ದೋಷ ಮತ್ತು ಉತ್ತರವಿಲ್ಲದೆ, ಸಂದೇಶವು ತಲುಪಿಸುವ ಬದಲು ಬಿಡಲ್ಪಡುತ್ತಿದೆ, ಮತ್ತು ಶಂಕಿತ ನಿಯಮ.

ನಿಯಮವನ್ನು ಸಂಕುಚಿಸಿ, ನಂತರ ಕಾರ್ಯವನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ

ಸರಿಪಡಿಸುವಿಕೆ ನಿರ್ದಿಷ್ಟ ನಿಯಂತ್ರಣ ಸಂದೇಶಗಳಿಗೆ ಅನುಮತಿ ನೀಡಬೇಕು, ಇಡೀ ಪ್ರೋಟೋಕಾಲ್ಗೆ ಅಲ್ಲ. iptables ಹೋಸ್ಟ್ನಲ್ಲಿ ರೂಪ ಪ್ರಕಾರ-ನಿರ್ದಿಷ್ಟ ಸ್ವೀಕಾರ; ನಿಮ್ಮ ಪ್ಲಾಟ್ಫಾರ್ಮ್ನಲ್ಲಿ ಫೈರ್ವಾಲ್ ನಿರ್ವಹಿಸುವುದಕ್ಕೆ ವಾಕ್ಯರಚನೆಯನ್ನು ಹೊಂದಿಸಿ:

iptables -I INPUT -p icmp --icmp-type fragmentation-needed -j ACCEPT
ip6tables -I INPUT -p icmpv6 --icmpv6-type packet-too-big -j ACCEPT

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

ಸಂದೇಶಗಳಿಗೆ ಅನುಮತಿ ನೀಡಿದ ನಂತರವೂ ದೊಡ್ಡ ವರ್ಗಾವಣೆ ನಿಂತರೆ, ಉಳಿದ ಮಿತಿ ಬೇರೆಡೆ ಇದೆ: ತುಂಬಾ ಎತ್ತರಕ್ಕೆ ಹೊಂದಿಸಿದ ಸುರಂಗ MTU, ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮತ್ತೆ ಬರೆಯುವ ಪ್ರಾಕ್ಸಿ, ಅಥವಾ ವರದಿ ಮಾಡುವ ಬದಲು ಬಿಡುವ ಮಧ್ಯಮ ಪೆಟ್ಟಿಗೆ. ICMP ನಿಯಮ ಅಗತ್ಯವಿತ್ತು, ಸಾಕಾಗಲಿಲ್ಲ.

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