MTU ಕಪ್ಪು ಕುಳಿ: ಸಣ್ಣ ವಿನಂತಿಗಳು ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ ಆದರೆ ಅಪ್ಲೋಡ್ಗಳು ನಿಲ್ಲುತ್ತವೆ

ಪುಟ ಲೋಡ್ ಆಗುತ್ತದೆ, ಸಣ್ಣ API ಕರೆ ಹಿಂತಿರುಗುತ್ತದೆ, ನಂತರ ಫೈಲ್ ಅಪ್ಲೋಡ್ ಕ್ಲೈಂಟ್ ಸೋಲೊಪ್ಪಿಕೊಳ್ಳುವವರೆಗೆ ನೇತಾಡುತ್ತದೆ. ಸರ್ವರ್ ಲಾಗ್ನಲ್ಲಿ ಇದನ್ನು ವಿವರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮಾರ್ಗದ ಮಧ್ಯದಲ್ಲಿ ಉಪಯುಕ್ತ ಉತ್ತರವನ್ನು ಹಿಂತಿರುಗಿಸದೆ ಬಿಸಾಡಲಾಗಿದೆ. ಆ ಮಾದರಿಯೇ MTU ಕಪ್ಪು ಕುಳಿ: ಕಳುಹಿಸುವವರು ಊಹಿಸುವುದಕ್ಕಿಂತ ಕಿರಿದಾದ ಕೊಂಡಿ, ಜೊತೆಗೆ ಅದನ್ನು ಹೇಳಲು ಮೌನ ನಿರಾಕರಣೆ. ವಿಫಲವಾಗುವ ಗಾತ್ರ ಪುನರಾವರ್ತನೀಯವಾಗಿದೆ, ಮತ್ತು ಅದೇ ಅದನ್ನು ರೋಗನಿರ್ಣಯ ಮಾಡಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ.

ಕುಳಿಯನ್ನು ಕಪ್ಪಾಗಿಸುವುದು ಏನು

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

ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಇದನ್ನು VPN ಸುತ್ತ ಸಾಮಾನ್ಯವಾಗಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಸುರಂಗವು ಈಗಾಗಲೇ ಭೌತಿಕ ಕೊಂಡಿಗೆ ಅಳೆಯಲಾದ ಪ್ಯಾಕೆಟ್ಗೆ ಹೊರ ಹೆಡರ್ ಸೇರಿಸುತ್ತದೆ. ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ 1500 ಬೈಟ್ನಲ್ಲಿ ಕಾನೂನುಬದ್ಧವಾಗಿದೆ ಮತ್ತು ಎನ್ಕ್ಯಾಪ್ಸುಲೇಟೆಡ್ ಪ್ಯಾಕೆಟ್ ಅಲ್ಲ, ಆದ್ದರಿಂದ ಅದು ಗಡಿಯಲ್ಲಿ ಸಾಯುತ್ತದೆ, ಸಣ್ಣ ಪ್ಯಾಕೆಟ್ಗಳು ಹಾದುಹೋಗುತ್ತವೆ. ಪೂರ್ಣಗೊಂಡ ಹ್ಯಾಂಡ್ಶೇಕ್ ಮತ್ತು ಕೆಲಸ ಮಾಡುವ ಲಾಗಿನ್ ಪುಟ ಸಣ್ಣ ಪ್ಯಾಕೆಟ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ಮಾತ್ರ ಸಾಬೀತುಪಡಿಸುತ್ತವೆ. ಅಪ್ಲಿಕೇಶನ್ ಕಳುಹಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಅತಿದೊಡ್ಡ ಪ್ಯಾಕೆಟ್ ಮುಖ್ಯವಾದುದು.

ಅದು ಮುರಿಯುವ ಗಾತ್ರವನ್ನು ಹುಡುಕಿ

ಒಡೆಯದ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಪೇಲೋಡ್ ಗಾತ್ರವನ್ನು ದ್ವಿಗುಣ ಹುಡುಕಾಟದಿಂದ ಹುಡುಕಿ, ಸುರಂಗದ ಒಂದು ಬದಿಯ ಹೋಸ್ಟ್ನಿಂದ ಇನ್ನೊಂದು ಬದಿಯ ಹೋಸ್ಟ್ಗೆ. ಯಶಸ್ವಿಯಾಗುವ ಅತಿದೊಡ್ಡ ಪೇಲೋಡ್ ನಿಮ್ಮ ಬಳಸಬಹುದಾದ ಮಾರ್ಗ MTU ಮೈನಸ್ ಹೆಡರ್ ಓವರ್ಹೆಡ್.

ping -M do -s 1400 -c 2 192.0.2.20
ping -M do -s 1200 -c 2 192.0.2.20
ping -f -l 1372 192.0.2.20

1472 ಬೈಟ್ನ ಪೇಲೋಡ್ ಸ್ವಚ್ಛ 1500 ಬೈಟ್ನ Ethernet ಮಾರ್ಗದಲ್ಲಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, IPv4 ಮತ್ತು ICMP ಹೆಡರ್ಗಳ 28 ಬೈಟ್ ಸೇರಿಸಿದಾಗ. ಅದೇ ಪರೀಕ್ಷೆ ಸುರಂಗ ಏರಿದ ನಂತರ ಚಿಕ್ಕ ಪೇಲೋಡ್ನಲ್ಲಿ ಮಾತ್ರ ಯಶಸ್ವಿಯಾದರೆ, ವ್ಯತ್ಯಾಸ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಓವರ್ಹೆಡ್, ಮತ್ತು ಸುರಂಗದ ಗಡಿಯೇ ನಿರಾಕರಣ ಸಂದೇಶವನ್ನು ಉತ್ಪಾದಿಸಬೇಕಿದ್ದ ಸ್ಥಳ. ಸಂಪರ್ಕದ ಮೊದಲು ಮತ್ತು ನಂತರ ಎರಡೂ ಸಂಖ್ಯೆಗಳನ್ನು ದಾಖಲಿಸಿ, ಆ ಜೋಡಿಯೇ ಸಾಕ್ಷ್ಯ. ಅಪ್ಲಿಕೇಶನ್ IPv6 ಬಳಸಿದಾಗ ಅದಕ್ಕೂ ಪರೀಕ್ಷೆ ಪುನರಾವರ್ತಿಸಿ, ಏಕೆಂದರೆ ಹೆಡರ್ ದೊಡ್ಡದಾಗಿದೆ ಮತ್ತು ವೈಫಲ್ಯದ ಮಿತಿ ಜರಿಯುತ್ತದೆ.

ಸುರಂಗವನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಸಾಕ್ಷ್ಯ ಓದಿ

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

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

ಎರಡೂ ಸಾರಿಗೆಗಳಲ್ಲಿ ದುರಸ್ತಿ ಪರಿಶೀಲಿಸಿ

ಬೆಂಬಲಿತ ದುರಸ್ತಿ ಎಂದರೆ ಗಡಿಯು ನಿಜವಾದ ಮಿತಿಯನ್ನು ವರದಿ ಮಾಡಲು ಬಿಡುವುದು, ಅಥವಾ ಅಲ್ಲಿ TCP ಯ ಗರಿಷ್ಠ ವಿಭಾಗ ಗಾತ್ರವನ್ನು ಬಿಗಿಗೊಳಿಸುವುದು, ಇದರಿಂದ ಅತಿ ದೊಡ್ಡ ವಿಭಾಗವನ್ನು ಪ್ರಯತ್ನಿಸಲಾಗದು. ನೆಟ್ವರ್ಕ್ನ ಪ್ರತಿ MTU ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು, ಅಥವಾ ಫೈರ್ವಾಲ್ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು, ಲಕ್ಷಣವನ್ನು ಮರೆಮಾಡಿ ನಂತರ ಯಾರೂ ವಾದಿಸಲಾಗದ ಸಂರಚನೆಯನ್ನು ಬಿಡುತ್ತದೆ.

ip link show dev tun0
sudo nft list ruleset | grep -i -E 'mtu|mss'
sysctl net.ipv4.tcp_mtu_probing
ping -M do -s 1400 -c 2 192.0.2.20

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