VPN ಗೇಟ್‌ವೇಯಲ್ಲಿ MSS ಕ್ಲ್ಯಾಂಪಿಂಗ್: ಅದು ಏನನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ ಮತ್ತು ಏನನ್ನು ಇಲ್ಲ
ಕ್ಲ್ಯಾಂಪಿಂಗ್ TCP ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ಗಳಲ್ಲಿ MSS ಅನ್ನು ಮತ್ತೆ ಬರೆಯುತ್ತದೆ, ಇದರಿಂದ ವಿಭಾಗಗಳು ಸುರಂಗದಲ್ಲಿ ಹೊಂದುತ್ತವೆ. ಅದು ಎಂದಿಗೂ UDP ಅಥವಾ ಮುರಿದ path-MTU ಪರಿಶೀಲನೆಯನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ. ಮೂರು ಪರಿಶೀಲನೆಗಳು, ಕ್ರಮವಾಗಿ.
ಸಣ್ಣ ವಿನಂತಿಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ, ದೊಡ್ಡ ಡೌನ್‌ಲೋಡ್‌ಗಳು ನಿಂತುಹೋಗುತ್ತವೆ, ಮತ್ತು ಯಾರೋ MSS ಕ್ಲ್ಯಾಂಪಿಂಗ್ ಸೂಚಿಸುತ್ತಾರೆ. ಆ ಸೂಚನೆ ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಪ್ರಯತ್ನಿಸಲು ಯೋಗ್ಯವಾಗುವಷ್ಟು ಬಾರಿ ಸರಿ, ಮತ್ತು ಕುರುಡಾಗಿ ಅನ್ವಯಿಸಿದರೆ ಅರ್ಧ ದಿನ ವ್ಯರ್ಥವಾಗುವಷ್ಟು ಬಾರಿ ತಪ್ಪು. ಕೆಳಗಿನ ಮೂರು ಪರಿಶೀಲನೆಗಳು ನಿಜವಾದ TCP ಗಾತ್ರದ ಸಮಸ್ಯೆಯನ್ನು UDP ಸಮಸ್ಯೆ, ಮುರಿದ path-MTU ಪತ್ತೆ ಮತ್ತು ಮರುಬರೆಯಬೇಕಾದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ಎಂದಿಗೂ ನೋಡದ ಕ್ಲ್ಯಾಂಪ್‌ನಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ.
ವೈಫಲ್ಯದ ಆಕಾರದಿಂದ ಪ್ರಾರಂಭಿಸಿ
ಗಾತ್ರದ ವೈಫಲ್ಯಕ್ಕೆ ಒಂದು ಸಹಿ ಇದೆ: ಸಂಪರ್ಕ ಸ್ಥಾಪನೆಯಾಗುತ್ತದೆ, ದೃಢೀಕರಣ ಮತ್ತು ಸಣ್ಣ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಯಶಸ್ವಿಯಾಗುತ್ತವೆ, ನಂತರ ಪೂರ್ಣ ಗಾತ್ರದ ವಿಭಾಗ ಬೇಕಾದಾಗ ವರ್ಗಾವಣೆ ಅನಿರ್ದಿಷ್ಟವಾಗಿ ನಿಲ್ಲುತ್ತದೆ. ಪಠ್ಯವನ್ನು ಲೋಡ್ ಮಾಡಿ ಚಿತ್ರವನ್ನು ಎಂದಿಗೂ ಪೂರ್ಣಗೊಳಿಸದ ಪುಟಗಳು ಸಣ್ಣ ಪ್ರಮಾಣದಲ್ಲಿ ಅದೇ ವೈಫಲ್ಯ. ಏನೂ ಸಂಪರ್ಕಗೊಳ್ಳದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಮಾರ್ಗದಲ್ಲಿ ಮೊದಲೇ ಇದೆ ಮತ್ತು ಕ್ಲ್ಯಾಂಪಿಂಗ್ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಎಂದಿಗೂ ಬಾರದ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಅನ್ನು ಕ್ಲ್ಯಾಂಪ್ ಸರಿಪಡಿಸಲಾರದು.
ಈ ಸಹಿ ಇರುವುದು ವಿಭಾಗದ ಗಾತ್ರವನ್ನು ಹ್ಯಾಂಡ್‌ಶೇಕ್‌ನಲ್ಲಿಯೇ ಒಪ್ಪಿಕೊಳ್ಳುವುದರಿಂದ. ಪ್ರತಿ ಕಡೆ TCP ಆಯ್ಕೆಯಾಗಿ ಗರಿಷ್ಠ ವಿಭಾಗ ಗಾತ್ರವನ್ನು ಘೋಷಿಸುತ್ತದೆ, ಮತ್ತು ಕಳುಹಿಸುವವರು ಎದುರು ಕಡೆಯ ಘೋಷಣೆಯನ್ನು ಗೌರವಿಸುತ್ತಾರೆ. ಮಾರ್ಗವು ಅಷ್ಟು ದೊಡ್ಡ ವಿಭಾಗವನ್ನು ಹೊತ್ತೊಯ್ಯಲಾಗದಿದ್ದರೆ, ವೈಫಲ್ಯ ನಂತರ, ಕಳುಹಿಸುವವನು ಕೊನೆಗೂ ಒಂದನ್ನು ಪ್ರಯತ್ನಿಸಿದಾಗ ಕಾಣಿಸುತ್ತದೆ.
ಈ ಲಕ್ಷಣವನ್ನು ಓದುವಾಗ ಸಾಗಣೆಯನ್ನು ನೋಡುವಿಕೆಯಲ್ಲಿ ಇಟ್ಟುಕೊಳ್ಳಿ. ಕ್ಲ್ಯಾಂಪಿಂಗ್ TCP ಆಯ್ಕೆಯ ಮರುಬರವಣಿಗೆ, ಆದ್ದರಿಂದ ಅದೇ ಸುರಂಗದ ಕೆಳಗೆ ನಿಲ್ಲುವ ಧ್ವನಿ ಅಥವಾ ವೀಡಿಯೊ ಕರೆ MSS ಸಮಸ್ಯೆ ಅಲ್ಲ ಮತ್ತು ಅದರಿಂದ ಸುಧಾರಿಸುವುದಿಲ್ಲ. TCP ಆಯ್ಕೆಯನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ಸಾಗಣೆಯನ್ನು ಬರೆದಿಡಿ.
ಮಾರ್ಗದ ಬೆಲೆ ಕಟ್ಟಿ, ನಂತರ ಸುರಂಗದೊಂದಿಗೆ ಹೋಲಿಸಿ
ಎರಡು ಸಂಖ್ಯೆಗಳು ಮುಖ್ಯ ಮತ್ತು ಅವು ಪದೇ ಪದೇ ಗೊಂದಲಕ್ಕೊಳಗಾಗುತ್ತವೆ. path-MTU ಎಂಬುದು ಮಾರ್ಗವು ಚೂರುಮಾಡದೆ ಸಾಗಿಸುವ ಅತಿ ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್, ಮತ್ತು IPv4 ಗಾಗಿ ಘೋಷಿಸಿದ MSS ಎಂಬುದು ಆ ಮೌಲ್ಯದಿಂದ IP ಮತ್ತು TCP ಶೀರ್ಷಿಕೆಗಳ 40 ಬೈಟ್ ಕಳೆದದ್ದು, ಅಥವಾ IPv6 ಗಾಗಿ 60 ಕಳೆದದ್ದು. ಸುರಂಗದ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಒಳಗಿನ ಪ್ಯಾಕೆಟ್ ಪ್ರಾರಂಭವಾಗುವ ಮೊದಲೇ ಬಜೆಟ್‌ನ ಒಂದು ಭಾಗವನ್ನು ತಿಂದುಬಿಡುತ್ತದೆ.
ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20do-not-fragment ಬಿಟ್‌ನೊಂದಿಗಿನ ping ಆ ಪೇಲೋಡ್ ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ ಉಳಿಯುತ್ತದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ; ವಿಫಲವಾಗುವವರೆಗೆ ಗಾತ್ರ ಬದಲಿಸಿ, ಮತ್ತು ಮಾರ್ಗದ ಮಿತಿಯನ್ನು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಕಂಡುಕೊಂಡಿದ್ದೀರಿ. tracepath ಔಟ್‌ಪುಟ್ ಮಾರ್ಗದುದ್ದಕ್ಕೂ ಪತ್ತೆಯಾದ MTU ಅನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಅದು ಕೆಲಸ ಮಾಡಿದಾಗ ವೇಗವಾಗಿರುತ್ತದೆ ಮತ್ತು ಮಧ್ಯಂತರ ಹಾಪ್ ಪ್ರೋಬ್‌ಗಳನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿದಾಗ ಕಡಿಮೆ ವಿಶ್ವಾಸಾರ್ಹವಾಗಿರುತ್ತದೆ.
ಈಗ ಸುರಂಗದ ಓವರ್‌ಹೆಡ್ ಕಳೆಯಿರಿ. ಹೊರಗಿನ IP ಶೀರ್ಷಿಕೆ, UDP ಶೀರ್ಷಿಕೆ ಮತ್ತು ಸುರಂಗ-ನಿರ್ದಿಷ್ಟ ಶೀರ್ಷಿಕೆ ಎಲ್ಲವೂ ಅದೇ 1500 ಬೈಟ್‌ನಿಂದ ಬರುತ್ತವೆ, ಆದ್ದರಿಂದ ಸಾಮಾನ್ಯ ಎಥರ್ನೆಟ್ ತಳಹದಿಯಲ್ಲಿ ಬಳಸಬಹುದಾದ ಒಳಗಿನ MTU ಭೌತಿಕ ಕೊಂಡಿ ಸೂಚಿಸುವುದಕ್ಕಿಂತ ಕಡಿಮೆಯಿರುತ್ತದೆ. ಲೆಕ್ಕಿಸಿದ ಒಳಗಿನ MTU ನಿಮ್ಮ ಸಹಚರರು ಘೋಷಿಸುವುದಕ್ಕಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ, ನೀವು ಊಹೆ ಅಲ್ಲ, ನಿಜವಾದ ಕ್ಲ್ಯಾಂಪ್ ಅಭ್ಯರ್ಥಿಯನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ. ಲೆಕ್ಕಿಸಿದ ಮೌಲ್ಯ ಈಗಾಗಲೇ ಸಹಚರರ ಘೋಷಣೆಗಿಂತ ಮೇಲಿದ್ದರೆ, ಇಲ್ಲೇ ನಿಲ್ಲಿಸಿ ಬೇರೆಡೆ ನೋಡಿ.
ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಹಾದುಹೋಗುವಲ್ಲಿ ಕ್ಲ್ಯಾಂಪ್ ಇರಿಸಿ
ಕ್ಲ್ಯಾಂಪ್ ಗೇಟ್‌ವೇಯನ್ನು ದಾಟುವಾಗ SYN ಮತ್ತು SYN-ACK ಪ್ಯಾಕೆಟ್‌ಗಳಲ್ಲಿ MSS ಆಯ್ಕೆಯನ್ನು ಮರುಬರೆಯುವ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಿಯಮವು ಯಾವುದೇ ದಿಕ್ಕೂ ಎಂದಿಗೂ ದಾಟದ ಇಂಟರ್‌ಫೇಸ್‌ನಲ್ಲಿ ಕುಳಿತರೆ, ಸಂಧಾನ ಬದಲಾವಣೆಯಿಲ್ಲದೆ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಲಕ್ಷಣ ಉಳಿಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಮೌಲ್ಯಕ್ಕಿಂತ ಇರಿಸುವಿಕೆಯೇ ಫಲಿತಾಂಶವನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ.
| Symptom | What it points to | Next check |
|---|---|---|
| Handshake completes, large transfer stalls | Segment size larger than the path can carry | Path MTU against the tunnel's effective MTU |
| Nothing connects, small or large | Routing, firewall or keying failure | Not MSS; look at the tunnel state |
| Only UDP applications stall | Datagram size or a dropped ICMP error | Platform-specific UDP handling, not clamping |
| Fixed after reconnect, returns later | Clamp applied to one direction or one interface | Rule placement and the handshake path |
ದಿಕ್ಕು ಇನ್ನೊಂದು ಅರ್ಧ. ಒಂದು ದಿಕ್ಕಿನ ಕ್ಲ್ಯಾಂಪಿಂಗ್ ಅರ್ಧದಷ್ಟು ಹರಿವುಗಳನ್ನು ಸರಿಪಡಿಸಿ ಉಳಿದವನ್ನು ಮಧ್ಯೆ ಮಧ್ಯೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗಲು ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಸಂಚಾರದ ಎರಡೂ ದಿಕ್ಕುಗಳಿಗೂ ಅನ್ವಯಿಸಿ. ಸುರಂಗ ಇಂಟರ್‌ಫೇಸ್‌ಗೆ Linuxನ ಸಾಂಪ್ರದಾಯಿಕ ರೂಪ SYN ಪ್ಯಾಕೆಟ್‌ಗಳಿಗೆ ಹೊಂದುವ mangle ನಿಯಮ:
iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu--clamp-mss-to-pmtu ವಾಸ್ತವವಾಗಿ ಏನು ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: ಅದು ಮೌಲ್ಯವನ್ನು ಮಾರ್ಗದ MTU ನಿಂದ ಪಡೆಯುತ್ತದೆ, ಅದು ಯಾವಾಗಲೂ ಸುರಂಗದ ನಿಜವಾದ ಪೇಲೋಡ್ ಬಜೆಟ್ ಅಲ್ಲ. ಒಳಗಿನ ಮಾರ್ಗ ಮತ್ತು ಹೊರಗಿನ ಮಾರ್ಗ ಭಿನ್ನವಾಗಿರುವ ಮಾರ್ಗ-ಆಧಾರಿತ ಸುರಂಗದಲ್ಲಿ, ಹಿಂದಿನ ಪರಿಶೀಲನೆಯಲ್ಲಿ ಲೆಕ್ಕಿಸಿದ ಸ್ಪಷ್ಟ ಮೌಲ್ಯ ಸ್ವಯಂಚಾಲಿತ ಮೌಲ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಊಹಿಸಬಹುದಾದದ್ದು.
ಹೊಸ ಸಂಪರ್ಕದೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಜೀವಂತವಾಗಿರಿಸಿ
ಸ್ಥಾಪಿತ ಸಂಪರ್ಕವು ಸಂಧಾನಿಸಿದ MSS ಅನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಆದ್ದರಿಂದ ಅದೇ ಅವಧಿಯಲ್ಲಿ ಪರೀಕ್ಷಿಸುವುದು ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಬದಲಾವಣೆಯ ನಂತರ ಹೊಸ ಸಂಪರ್ಕ ತೆರೆದು ಸಂಧಾನಿಸಿದ ಮೌಲ್ಯವನ್ನು ನೇರವಾಗಿ ಓದಿ, ಆಕಸ್ಮಿಕವಾಗಿ ಮುಗಿಯುವ ವರ್ಗಾವಣೆಯಿಂದ ಊಹಿಸುವ ಬದಲು.
ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSSಮೊದಲ ಆಜ್ಞೆ ಸಾಕೆಟ್‌ನ MSS ಅನ್ನು ಅದರ ದಟ್ಟಣೆ ಸ್ಥಿತಿಯೊಂದಿಗೆ ವರದಿ ಮಾಡುತ್ತದೆ, ಅದು ಕ್ಲ್ಯಾಂಪ್ ಪರಿಣಾಮ ಬೀರಿದ ಎಂಬುದಕ್ಕೆ ಅತ್ಯಂತ ವೇಗದ ದೃಢೀಕರಣ. ಎರಡನೆಯದು ನೀವು ಸೇರಿಸಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸುವ ನಿಯಮವೇ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಿಯಮ ಎಂದು, ಅದನ್ನು ಇರಿಸಿದ ಕೋಷ್ಟಕದಲ್ಲಿ ದೃಢೀಕರಿಸುತ್ತದೆ.
ನಂತರ ನೀವು ಸರಿಪಡಿಸದ ಕಾರ್ಯವಿಧಾನವನ್ನು ರಕ್ಷಿಸಿ. path-MTU ಪತ್ತೆ ICMP fragmentation-needed ಸಂದೇಶಗಳು ಕಳುಹಿಸುವವರನ್ನು ತಲುಪುವುದನ್ನು ಅವಲಂಬಿಸಿದೆ, ಆದ್ದರಿಂದ ಅವನ್ನು ಬಿಸಾಡುವ ಫೈರ್‌ವಾಲ್ ಸರಿಯಾದ ಕ್ಲ್ಯಾಂಪ್ ಇದ್ದರೂ ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳನ್ನು ಮುರಿಯುತ್ತಲೇ ಇರುತ್ತದೆ. ಸುರಂಗ ಮಾರ್ಗಕ್ಕೆ ಆ ಸಂದೇಶಗಳನ್ನು ಅನುಮತಿಸಿ, ಅಥವಾ ಕ್ಲ್ಯಾಂಪಿಂಗ್ ನೀವು ಆಯ್ಕೆ ಮಾಡಿದ ನೀತಿಗೆ ಪರಿಹಾರ ನೀಡುತ್ತಿದೆ ಎಂದು ಒಪ್ಪಿಕೊಳ್ಳಿ.
ಕೊನೆಯದಾಗಿ, ಕ್ಲ್ಯಾಂಪ್ ಅನ್ನು ಟ್ಯೂನಿಂಗ್ ನಾಬ್ ಎಂದು ಪರಿಗಣಿಸುವ ಪ್ರಲೋಭನೆಯನ್ನು ಎದುರಿಸಿ. ಅದು ವಿಭಾಗದ ಗಾತ್ರವನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ, ಅದು ಅದರ ಅಗತ್ಯವೇ ಇಲ್ಲದ ಮಾರ್ಗಗಳಲ್ಲಿ ಥ್ರೂಪುಟ್ ವೆಚ್ಚ ಮಾಡುತ್ತದೆ. ಮೂರು ಪರಿಶೀಲನೆಗಳ ನಂತರ ಅನ್ವಯಿಸಿದರೆ ಅದು ಗುರಿಯಿಟ್ಟ ರಿಪೇರಿ; ಮೊದಲು ಅನ್ವಯಿಸಿದರೆ ಅದು ಮೂಲ ದೋಷವನ್ನು ಮುಚ್ಚಿ ಪ್ರತಿ ಮುಂದಿನ ಪರೀಕ್ಷೆಗೆ ಎರಡನೇ ಚರವನ್ನು ಸೇರಿಸುವ ಬದಲಾವಣೆ. ಆ ವಿನಿಮಯವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮಾಡುವುದು ಯೋಗ್ಯ, ಡೀಫಾಲ್ಟ್ ಆಗಿ ಅಲ್ಲ.
ನೀವು ಅಳೆದ path-MTU, ಕಳೆದ ಸುರಂಗ ಓವರ್‌ಹೆಡ್, ಸೇರಿಸಿದ ನಿಯಮ ಮತ್ತು ನಂತರ ಕಂಡ MSS ಬರೆದಿಡಿ. ನಾಲ್ಕು ಸಂಖ್ಯೆಗಳು ಮುಂದಿನ ಘಟನೆಯನ್ನು ತನಿಖೆಯ ಬದಲು ಹುಡುಕಾಟವಾಗಿಸುತ್ತವೆ.