VPN MTU ಕಟ್ಟುಕಥೆಗಳು: ನಿಮ್ಮ ಪ್ಯಾಕೆಟ್‌ಗಳು ಏಕೆ ಸಂಕುಚಿಸುತ್ತವೆ ಮತ್ತು ಜಾಗ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ

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

ಇದರ ಬಹುಪಾಲನ್ನು ಎರಡು ಕಟ್ಟುಕಥೆಗಳು ಉಂಟುಮಾಡುತ್ತವೆ. ಮೊದಲನೆಯದು ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್‌ನ MTU ಮಾರ್ಗದ MTU ಆಗಿದೆ ಎಂಬುದು. ಎರಡನೆಯದು ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್‌ಗೆ "ಒಂದು ಹೆಡರ್" ವೆಚ್ಚವಾಗುತ್ತದೆ ಮತ್ತು PPPoE ಎಣಿಸಲು ಯೋಗ್ಯವಾದ ಯಾವುದಕ್ಕೂ ವೆಚ್ಚವಾಗುವುದಿಲ್ಲ ಎಂಬುದು. ಎರಡೂ ನೀವು ಆರಿಸುವ ಸಂಖ್ಯೆ ನಿರ್ಧಾರಿತವಾಗಿದ್ದರೂ ಅದು ನಿರಂಕುಶವಾಗಿ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ತಪ್ಪಾಗಿವೆ.

ಮೊದಲ ಕಟ್ಟುಕಥೆ: ಸುರಂಗದ MTU ಮಾರ್ಗದ MTU

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

ಮಾರ್ಗ-MTU ಅನ್ವೇಷಣೆ ಎರಡನ್ನೂ ಸಮನ್ವಯಗೊಳಿಸಲು ಇದೆ, ಮತ್ತು ಅದು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ. IPv4 ನಲ್ಲಿ ಪೂರ್ಣ ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ ಮುಂದೆ ಕಳುಹಿಸಲಾಗದ ರೌಟರ್ ICMP "fragmentation needed" ಸಂದೇಶ ಕಳುಹಿಸಬೇಕು, ಮತ್ತು ಕಳುಹಿಸುವವರು ತಮ್ಮ ಅಂದಾಜನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತಾರೆ. IPv6 ನಲ್ಲಿ ಸಮಾನಾಂತರ Packet Too Big ಸಂದೇಶ, ಮತ್ತು ರೌಟರ್‌ಗಳು ಸಾಗಣೆಯಲ್ಲಿ ಫ್ರ್ಯಾಗ್ಮೆಂಟ್ ಮಾಡುವುದೇ ಇಲ್ಲ. ಆ ಪ್ರತಿಕ್ರಿಯೆ ಫಿಲ್ಟರ್ ಆದಾಗ, ಕಳುಹಿಸುವವರು ಮಾರ್ಗ ಸಾಗಿಸಲಾಗದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತಲೇ ಇರುತ್ತಾರೆ, ಮತ್ತು ಯಾವುದೂ ಅವರಿಗೆ ಏಕೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

ಎರಡನೇ ಕಟ್ಟುಕಥೆ: ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್‌ಗೆ ಒಂದು ಹೆಡರ್ ವೆಚ್ಚ

ಹೊರ ಪದರಗಳನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಎಣಿಸಿ. ಹೊರ IP ಹೆಡರ್ IPv4 ನಲ್ಲಿ 20 ಬೈಟ್ ಅಥವಾ IPv6 ನಲ್ಲಿ 40. NAT ದಾಟಲು UDP ಎನ್ಕ್ಯಾಪ್ಸುಲೇಶನ್ 8 ಸೇರಿಸುತ್ತದೆ. ಸುರಂಗ ಪ್ರೋಟೋಕಾಲ್ ತನ್ನದೇ ಹೆಡರ್, ಇನಿಶಿಯಲೈಸೇಶನ್ ವೆಕ್ಟರ್ ಅಥವಾ ನಾನ್ಸ್, ಸೈಫರ್‌ನ ಬ್ಲಾಕ್ ಅಥವಾ ಜೋಡಣೆ ಮಿತಿಯವರೆಗೆ ಪ್ಯಾಡಿಂಗ್, ಟ್ರೇಲರ್ ಮತ್ತು ಸಮಗ್ರತೆ ಪರಿಶೀಲನಾ ಮೌಲ್ಯವನ್ನು ಸೇರಿಸುತ್ತದೆ. ಪ್ರೋಟೋಕಾಲ್ ಮತ್ತು ಸೈಫರ್ ಆಧರಿಸಿ, ಒಳ ಪ್ಯಾಕೆಟ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ಒಟ್ಟು ಆರಾಮವಾಗಿ ಹತ್ತಾರು ಬೈಟ್‌ಗಳಲ್ಲಿದೆ.

ನಂತರ ಒಳ ಪ್ಯಾಕೆಟ್‌ನ ಸ್ವಂತ ಹೆಡರ್‌ಗಳಿಗೆ ಮತ್ತೆ ಕಳೆಯಿರಿ. ಸುರಂಗದೊಳಗಿನ TCP ವಿಭಾಗವು ತನ್ನದೇ 20 ಬೈಟ್ IP ಹೆಡರ್ ಮತ್ತು 20 ಬೈಟ್ TCP ಹೆಡರ್ ಅನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು TCP ಯ MSS MTU ನಿಂದ ಬರುತ್ತದೆ, ಸುರಂಗದ ನಾಮಮಾತ್ರ ಪೇಲೋಡ್‌ನಿಂದ ಅಲ್ಲ. ಆದ್ದರಿಂದ ping ಚಿಕ್ಕ ಪೇಲೋಡ್‌ನೊಂದಿಗೆ ಯಶಸ್ವಿಯಾಗಬಹುದು, ಆದರೆ ಫೈಲ್ ವರ್ಗಾವಣೆ ನಿಲ್ಲುತ್ತದೆ: ಪರಿಕರಗಳು ಬೇರೆ ಬೇರೆ ವಿಷಯಗಳನ್ನು ಪರೀಕ್ಷಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದೇ ಪೂರ್ಣ ಗಾತ್ರದ TCP ವಿಭಾಗವನ್ನು ಬಳಸುತ್ತದೆ.

ip link show tun0
ping -M do -s 1472 192.0.2.10
ping -M do -s 1400 192.0.2.10

ಮೊದಲ ಆಜ್ಞೆ ಹೊಂದಿಸಿದ ಸುರಂಗ MTU ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಪ್ರೋಬ್‌ಗಳು 1472 ಬೈಟ್ ಪೇಲೋಡ್ ಕಳುಹಿಸುತ್ತವೆ, ಅದು IPv4 ಮತ್ತು ICMP ಹೆಡರ್‌ಗಳ 28 ಬೈಟ್‌ಗಳೊಂದಿಗೆ 1500 ಬೈಟ್ ಪ್ಯಾಕೆಟ್, ನಂತರ ಚಿಕ್ಕದು. ದೊಡ್ಡ ಪ್ರೋಬ್ ಸಂಪೂರ್ಣ ವಿಫಲವಾಗಿ ಚಿಕ್ಕದು ಯಶಸ್ವಿಯಾದರೆ, ನಿಮಗೆ ಗಾತ್ರ-ಅವಲಂಬಿತ ದೋಷವಿದೆ, ಸಾಮಾನ್ಯ ರೌಟಿಂಗ್ ಸಮಸ್ಯೆ ಅಲ್ಲ.

ಮೂರನೇ ಕಟ್ಟುಕಥೆ: PPPoE ಇನ್ನೂ ನಿಮಗೆ ಸ್ವಚ್ಛ 1500 ನೀಡುತ್ತದೆ

ಸಾಂಪ್ರದಾಯಿಕ PPPoE ಪ್ರವೇಶ ಕೊಂಡಿ 1500 ಬೈಟ್‌ನ IP ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸುವುದಿಲ್ಲ. PPPoE ಹೆಡರ್ ಮತ್ತು PPP ಪ್ರೋಟೋಕಾಲ್ ಕ್ಷೇತ್ರವು ಎಥರ್ನೆಟ್ ಫ್ರೇಮ್ ಒಳಗೆ 8 ಬೈಟ್ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ, ಇದು IP ಪ್ಯಾಕೆಟ್‌ಗೆ 1492 ಬಿಡುತ್ತದೆ. ಇದು RFC 2516 ನಲ್ಲಿ ವಿವರಿಸಲಾದ ಸಾಂಪ್ರದಾಯಿಕ ಮಿತಿ. ಅಂತಹ ಕೊಂಡಿಯ ಮೇಲೆ VPN ಚಲಾಯಿಸಿದರೆ, ಸುರಂಗದ ಓವರ್‌ಹೆಡ್ 1500 ರಿಂದ ಅಲ್ಲ, ಆ 1492 ರಿಂದ ಬರುತ್ತದೆ.

RFC 4638 ಪ್ರವೇಶ ಕೇಂದ್ರೀಕರಣ ಮತ್ತು ಗ್ರಾಹಕ ಸಲಕರಣೆ ಎರಡೂ ಬೆಂಬಲಿಸಿದಾಗ ದೊಡ್ಡ PPP ಪೇಲೋಡ್ ಮೇಲೆ ಚರ್ಚಿಸುವ ವಿಧಾನವನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ "ಈ ಸಂಪರ್ಕ PPPoE ಬಳಸುತ್ತದೆ" ಎಂಬುದು ಒಂದೇ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಸ್ಥಳೀಯ ಸೆಟ್ಟಿಂಗ್ ಮಧ್ಯಂತರ ಸಾಧನವು ಎಂದೂ ಸಂರಚಿಸದ ಪ್ಯಾಕೆಟ್ ಸ್ವೀಕರಿಸುವಂತೆ ಒತ್ತಾಯಿಸಲಾಗದು, ಆದ್ದರಿಂದ ಉಪಯುಕ್ತ ಪ್ರಶ್ನೆ ಲೇಬಲ್ ಏನು ಹೇಳುತ್ತದೆ ಎಂಬುದಲ್ಲ, ಕೊಂಡಿ ನಿಜವಾಗಿ ಯಾವುದನ್ನು ಚರ್ಚಿಸಿತು ಎಂಬುದು.

ವೈಫಲ್ಯ ಏಕೆ ಆಯ್ದಂತೆ ಕಾಣುತ್ತದೆ

ಚಿಕ್ಕ ವಿನಂತಿಗಳು ಯಶಸ್ವಿಯಾಗುವುದು ಮತ್ತು ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳು ನಿಲ್ಲುವುದು ಮಾರ್ಗ-MTU ಕಪ್ಪು ಕುಳಿಯ ಸಾಂಪ್ರದಾಯಿಕ ಲಕ್ಷಣ. ಹಸ್ತಲಾಘವ, DNS ಪ್ರಶ್ನೆ ಮತ್ತು API ಕರೆ ಎಲ್ಲವೂ ಹೊಂದುತ್ತವೆ; ಬೃಹತ್ ವರ್ಗಾವಣೆ ಒಂದು ಕೊಂಡಿಯಲ್ಲಿ ಸಾಯುವ ಪೂರ್ಣ ಗಾತ್ರದ ವಿಭಾಗಗಳನ್ನು ಉತ್ಪಾದಿಸುತ್ತದೆ, ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ವರದಿ ಮಾಡಬೇಕಿದ್ದ ICMP ಸಂದೇಶ ಎಂದೂ ತಲುಪುವುದಿಲ್ಲ. ಸಂಪರ್ಕ ಉತ್ತಮವಾಗಿ ಕಾಣುತ್ತದೆ ಮತ್ತು ಡೌನ್‌ಲೋಡ್ ನೇತಾಡುತ್ತದೆ, ಇದು ಜನರನ್ನು ಮಾರ್ಗದ ಬದಲು ಸರ್ವರ್ ನೋಡಲು ಕಳುಹಿಸುತ್ತದೆ.

ಎರಡನೇ, ಸಂಬಂಧಿತ ತಪ್ಪು ಮೂರು ಸಂಖ್ಯೆಗಳನ್ನು ಬೆರೆಸುವುದು: ಇಂಟರ್ಫೇಸ್ MTU, TCP MSS ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್‌ನ ಸ್ವಂತ ಫ್ರ್ಯಾಗ್ಮೆಂಟೇಶನ್ ಅಥವಾ ಪ್ಯಾಡಿಂಗ್ ಸೆಟ್ಟಿಂಗ್. ರೌಟರ್‌ನಲ್ಲಿ MSS ಕ್ಲ್ಯಾಂಪಿಂಗ್ ಘೋಷಿತ MSS ಅನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ, ಇದರಿಂದ ಕಳುಹಿಸುವವರು ಚಿಕ್ಕ ವಿಭಾಗಗಳನ್ನು ನಿರ್ಮಿಸುತ್ತಾರೆ; ಅದು ಸುರಂಗ MTU ಬದಲಾಯಿಸುವುದಿಲ್ಲ ಮತ್ತು UDP ಸಂಚಾರಕ್ಕೆ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಸಂಬಂಧಿತವಾಗಿ ಕಾಣುತ್ತದೆ ಎಂದು ಮೂರಕ್ಕೂ ಒಂದೇ ಸಂಖ್ಯೆ ನೀಡುವುದು, ಒಳ್ಳೆಯ ಉದ್ದೇಶದ ಬದಲಾವಣೆ ಕೆಲಸ ಮಾಡುತ್ತಿರುವ ಸೆಟಪ್ ಮುರಿಯುವ ರೀತಿ.

ಏನನ್ನು ಬದಲಾಯಿಸಬೇಕು, ಯಾವ ಕ್ರಮದಲ್ಲಿ

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

ನಂತರ ಕ್ಲೈಂಟ್ ದಾಖಲಿಸುವ ಚಿಕ್ಕ ಹೊಂದಾಣಿಕೆಯನ್ನು ಅನ್ವಯಿಸಿ. ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಸುರಂಗ MTU ಜೊತೆಗೆ MSS ಸರಿಪಡಿಸುವ ಆಯ್ಕೆ ನೀಡುತ್ತವೆ, ಮತ್ತು MSS ಆಯ್ಕೆ TCP ಗೆ ಹೆಚ್ಚಾಗಿ ಉತ್ತಮ ಹತೋಟಿ ಏಕೆಂದರೆ ಅದು ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಚಿಕ್ಕದಾಗಿಸದೆ ಕಳುಹಿಸುವವರನ್ನು ತಲುಪುತ್ತದೆ. ಅದೇ ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಅದೇ ವರ್ಗಾವಣೆಯನ್ನು ಮತ್ತೆ ಪರೀಕ್ಷಿಸಿ, ಮತ್ತು ನೀವು ನೆಲೆಗೊಂಡ ಸಂಖ್ಯೆಗಳನ್ನು ಗಮನಿಸಿ. ಒಂದು ಪ್ರವೇಶ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಸುರಂಗ ಮೌಲ್ಯ ಸಾರ್ವತ್ರಿಕ ಸ್ಥಿರಾಂಕವಲ್ಲ, ಮುಂದಿನ ಸ್ಥಳಕ್ಕೆ ಅದರದೇ ಬಜೆಟ್ ಇರುತ್ತದೆ.