ಚಿಕ್ಕ VPN MTU ವೇಗವಾಗಿದೆಯೇ? ನಿಜವಾದ ಸಾಕ್ಷ್ಯವನ್ನು ಹೋಲಿಸಿ
ಕಡಿಮೆ MTU ಮಾರ್ಗದ ಮಿತಿಯನ್ನು ತಪ್ಪಿಸಬಹುದು ಮತ್ತು ಆದರೂ ಥ್ರೂಪುಟ್ ವೆಚ್ಚ ಮಾಡಬಹುದು. ಬದಲಾವಣೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ನಿಜವಾದ ಮಿತಿ, ಪ್ಯಾಕೆಟ್ ಓವರ್ಹೆಡ್ ಮತ್ತು ಕೆಲಸದ ಭಾರವನ್ನು ಹೋಲಿಸಿ.
ಸುರಂಗ ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳನ್ನು ಬೀಳಿಸುತ್ತದೆ ಆದರೆ ಪಿಂಗ್ ಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಸಲಹೆ ಬೇಗ ಬರುತ್ತದೆ: MTU ಕಡಿಮೆ ಮಾಡಿ. ಸರಿಪಡಿಸುವಿಕೆ ಕೆಲವೊಮ್ಮೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಪ್ರತಿ ನೆಟ್ವರ್ಕ್ನ ಪ್ರತಿ ಪ್ರೊಫೈಲ್ಗೆ ಅನ್ವಯಿಸಲಾಗುತ್ತದೆ. ಅಲ್ಲಿಯೇ ಗುರಿಯಿಟ್ಟ ಸರಿಪಡಿಸುವಿಕೆ ಶಾಶ್ವತ ಕಾರ್ಯಕ್ಷಮತೆ ತೆರಿಗೆಯಾಗುತ್ತದೆ. ಮಾಡಬೇಕಾದ ಹೋಲಿಕೆ ಮಾರ್ಗದ ನಿಜವಾದ ಮಿತಿ ಮತ್ತು ಅದರ ಕೆಳಗೆ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಚಿಕ್ಕದಾಗಿಸುವ ವೆಚ್ಚದ ನಡುವೆ ಇದೆ.
MTU ಕಡಿಮೆ ಮಾಡಿದಾಗ ನಿಜವಾಗಿ ಏನು ಸಂಕೋಚಿಸುತ್ತದೆ
ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ ನಿಮ್ಮ ಡೇಟಾವನ್ನು ಸಾಗಿಸುವ ಮೊದಲು ಹೆಡರ್ ಸಾಗಿಸುತ್ತದೆ. 1500 ಬೈಟ್ನ ಇಥರ್ನೆಟ್ ಮಾರ್ಗದಲ್ಲಿ IPv4 ಮತ್ತು TCP 40 ಬೈಟ್ ತೆಗೆದುಕೊಂಡು ಪೇಲೋಡ್ಗೆ 1460 ಬಿಡುತ್ತವೆ; ಎನ್ಕ್ಯಾಪ್ಸುಲೇಷನ್ ಮೇಲೆ ಹೊರಗಿನ IP, UDP ಮತ್ತು ಸುರಂಗ ಹೆಡರ್ಗಳನ್ನು ಸೇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಒಳಗಿನ ಪೇಲೋಡ್ ಬಜೆಟ್ ಮತ್ತೆ ಇಳಿಯುತ್ತದೆ. ಇಂಟರ್ಫೇಸ್ನ MTU ಕಡಿಮೆ ಮಾಡುವುದು ಆ ಬಜೆಟ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಚಿಕ್ಕದಾಗಿಸುತ್ತದೆ.
ವೆಚ್ಚ ಬೈಟ್ಗಳ ಸಂಖ್ಯೆಗೆ ಅಲ್ಲ, ಪ್ಯಾಕೆಟ್ಗಳ ಸಂಖ್ಯೆಗೆ ಅನುಪಾತದಲ್ಲಿದೆ. ಅದೇ ಕಡತವನ್ನು ಹೆಚ್ಚು ಪ್ಯಾಕೆಟ್ಗಳಾಗಿ ವಿಭಜಿಸಿದರೆ ಹೆಚ್ಚು ಅಡ್ಡಿಯಾಗುವಿಕೆ, ಹೆಚ್ಚು ಮಾರ್ಗನಿರ್ಣಯ ಮತ್ತು ಮಾರ್ಗದ ಪ್ರತಿ ಸಾಧನದಲ್ಲಿ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೆ ಹೆಚ್ಚು ಸಂಸ್ಕರಣೆ ಬೇಕು. ಈಗಾಗಲೇ ಸೆಕೆಂಡಿಗೆ ಪ್ಯಾಕೆಟ್ ಮಿತಿಗೆ ಹತ್ತಿರವಿರುವ ರೂಟರ್ನಲ್ಲಿ ಅದು ರೌಂಡಿಂಗ್ ದೋಷವಲ್ಲ, ನಿಜವಾದ ನಿಧಾನಗತಿ. ವರ್ಗಾವಣೆಯೇ ಯಶಸ್ವಿಯಾದರೂ ವೆಚ್ಚ ಕಾಣಿಸುತ್ತದೆ.
ಆದ್ದರಿಂದ ಚಿಕ್ಕ MTU ಮಿತಿಯ ಸುತ್ತಲಿನ ಪರ್ಯಾಯ ಮಾರ್ಗ, ಸಾಮಾನ್ಯ ಆಪ್ಟಿಮೈಸೇಶನ್ ಅಲ್ಲ. ದೊಡ್ಡ ಫ್ರೇಮ್ ಸಾಗಿಸಲಾಗದ ಮಾರ್ಗದ ವಿರುದ್ಧ ಅದು ವಿಶ್ವಾಸಾರ್ಹತೆ ಖರೀದಿಸುತ್ತದೆ ಮತ್ತು ಕಡಿತದ ಅಗತ್ಯವಿಲ್ಲದ ಪ್ರತಿ ಪ್ಯಾಕೆಟ್ಗೆ ಓವರ್ಹೆಡ್ ವಿಧಿಸುತ್ತದೆ.
ಚಿಕ್ಕ MTU ಯಾವಾಗ ಸರಿಯಾದ ಸರಿಪಡಿಸುವಿಕೆ
ಸಾಂಪ್ರದಾಯಿಕ ಲಕ್ಷಣ ನಿರ್ದಿಷ್ಟವಾಗಿದೆ: TCP ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಳ್ಳುತ್ತದೆ, ಸಣ್ಣ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಬರುತ್ತವೆ, ಮತ್ತು ದೊಡ್ಡ ಡೌನ್ಲೋಡ್ ನಿಲ್ಲುತ್ತದೆ ಅಥವಾ ಮರುಹೊಂದಿಸಲ್ಪಡುತ್ತದೆ. 1472 ಬೈಟ್ನಲ್ಲಿ ವಿಭಜಿಸಬೇಡ ಬಿಟ್ನೊಂದಿಗೆ ಪಿಂಗ್ ವಿಫಲವಾಗುತ್ತದೆ ಆದರೆ 1400 ಬೈಟ್ನ ಪಿಂಗ್ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಇದು ಪೂರ್ಣ ಗಾತ್ರದ ಪ್ಯಾಕೆಟ್ ಸಾಗಿಸಲಾಗದ ಮತ್ತು ಕಳುಹಿಸುವವರಿಗೆ ಚಿಕ್ಕದಾಗಿಸಲು ಹೇಳುವ ICMP ಸಂದೇಶವನ್ನು ತಲುಪಿಸದ ಮಾರ್ಗವನ್ನು ಸೂಚಿಸುತ್ತದೆ.
ಮಾರ್ಗ MTU ಪತ್ತೆ ಆ ICMP ವಿಭಜನೆ-ಅಗತ್ಯ ಸಂದೇಶಗಳನ್ನು ಅವಲಂಬಿಸಿದೆ. ಫೈರ್ವಾಲ್ ಅವನ್ನು ಬೀಳಿಸಿದಾಗ, ಕಳುಹಿಸುವವರು ದೊಡ್ಡ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಪುನಃ ಪುನಃ ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ ಮತ್ತು ಸಂಪರ್ಕ ನೇತಾಡುತ್ತಿರುವಂತೆ ಕಾಣುತ್ತದೆ. ಸುರಂಗದ ಬದಿಯಲ್ಲಿ MTU ಕಡಿಮೆ ಮಾಡುವುದು ಪುನರಾವರ್ತನೆಯನ್ನು ತಪ್ಪಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಆ ನೆಟ್ವರ್ಕ್ಗೆ ಕಾನೂನುಬದ್ಧ ಸರಿಪಡಿಸುವಿಕೆ.
ಪ್ರವೇಶ ತಂತ್ರಜ್ಞಾನಗಳು ತಮ್ಮ ಮಿತಿಗಳನ್ನು ವಿಧಿಸುತ್ತವೆ: PPPoE ಸಾಮಾನ್ಯವಾಗಿ 1492ಕ್ಕೆ ಸೀಮಿತವಾಗಿದೆ, ಕೆಲವು ಮೊಬೈಲ್ ಮತ್ತು DSL ಮಾರ್ಗಗಳು ಕಡಿಮೆ, ಮತ್ತು ಒಳಗೊಳಗಿನ ಸುರಂಗಗಳು ಓವರ್ಹೆಡ್ ಅನ್ನು ಎರಡು ಬಾರಿ ಕಳೆಯುತ್ತವೆ. ಮಾರ್ಗದರ್ಶಿಯಿಂದ ಸಂಖ್ಯೆಯನ್ನು ನಕಲಿಸುವ ಬದಲು ನಿಜವಾದ ಮಾರ್ಗವನ್ನು ಅಳೆಯಿರಿ, ಮತ್ತು IPv6 ಅದನ್ನು ಸಾಗಿಸುವ ಪ್ರತಿ ಕೊಂಡಿಗೆ ಕನಿಷ್ಠ 1280 ಬೈಟ್ MTU ಬೇಕು ಎಂದು ನೆನಪಿಡಿ, RFC 8200 ನಿರ್ದಿಷ್ಟಪಡಿಸಿದಂತೆ.
ಒಂದನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಮೂರು ನಿಯಂತ್ರಣಗಳನ್ನು ಹೋಲಿಸಿ
MTU, MSS ಮತ್ತು ವಿಭಜನೆ ಬೇರೆ ಬೇರೆ ಪದರಗಳ ಬೇರೆ ಬೇರೆ ನಿಯಂತ್ರಣಗಳು, ಮತ್ತು ತಪ್ಪಾದದನ್ನು ಬದಲಿಸಿದರೆ ಲಕ್ಷಣ ಅದರ ಜಾಗದಲ್ಲೇ ಉಳಿಯುತ್ತದೆ.
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
MSS ಸೀಮಿತಗೊಳಿಸುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಅತ್ಯಂತ ಕಡಿಮೆ ಆಕ್ರಮಣಕಾರಿ ಸರಿಪಡಿಸುವಿಕೆ, ಏಕೆಂದರೆ ಅದು TCP ಮೇಲೆ ಮಾತ್ರ ಪರಿಣಾಮ ಬೀರುತ್ತದೆ ಮತ್ತು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಇತರ ಸಂಚಾರಕ್ಕೆ ಮುಕ್ತವಾಗಿ ಬಿಡುತ್ತದೆ. ಕಡಿಮೆ ಇಂಟರ್ಫೇಸ್ MTU ಹೆಚ್ಚು ವಿಸ್ತೃತ ಮತ್ತು ಯೋಚಿಸಲು ಸುಲಭ, ಆದ್ದರಿಂದ ಗ್ರಾಹಕ ರೂಟರ್ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ, ಆದರೆ ಅದು ಒಂದು ಪ್ರೋಟೋಕಾಲ್ನ ಸಮಸ್ಯೆಯನ್ನು ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ನಿಂದ ವಸೂಲಿ ಮಾಡುತ್ತದೆ.
ವಿಭಜಿಸಬೇಡ ವರ್ತನೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು ವಿಭಜನೆಗೆ ಅವಕಾಶ ನೀಡಿ ಲಕ್ಷಣವನ್ನು ಮರೆಮಾಡುತ್ತದೆ, ಮತ್ತು ಸರಿಯಾದ ಗಾತ್ರವನ್ನು ಕಂಡುಕೊಳ್ಳುತ್ತಿದ್ದ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮುರಿಯುತ್ತಾ ಸಾಮಾನ್ಯವಾಗಿ ವಿಳಂಬವನ್ನು ಹದಗೆಡಿಸುತ್ತದೆ. ಶಾಶ್ವತ ಪರಿಹಾರವಾಗಿ ಅದನ್ನು ತಪ್ಪಿಸಿ.
ಒಂದು ಸಂಖ್ಯೆಯ ಬದಲು ವಿನಿಮಯವನ್ನು ಅಳೆಯಿರಿ
ವಿಭಜಿಸಬೇಡ ಪ್ರೋಬ್ನಿಂದ ಮಾರ್ಗದ ಮಿತಿ ಕಂಡುಕೊಳ್ಳಿ, ಎತ್ತರದಿಂದ ಪ್ರಾರಂಭಿಸಿ ಉತ್ತರ ಬರುವವರೆಗೆ ಇಳಿಯಿರಿ:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10ನಂತರ ಎರಡೂ ಸೆಟ್ಟಿಂಗ್ಗಳಲ್ಲಿ ನಿಜವಾದ ಕೆಲಸವನ್ನು ಹೋಲಿಸಿ: ಅದೇ ಕಡತ ವರ್ಗಾವಣೆ, ಅದೇ ಎಂಡ್ಪಾಯಿಂಟ್ ಮತ್ತು ಅದೇ ನೆಟ್ವರ್ಕ್. ಪೂರ್ಣಗೊಳ್ಳುವ ಸಮಯ ಮತ್ತು ಮರುಪ್ರೇಷಣೆಗಳನ್ನು ದಾಖಲಿಸಿ, ಉದಾಹರಣೆಗೆ nstat -az TcpRetransSegs ಬಳಸಿ, ಮತ್ತು ಸುರಂಗವು ಸಣ್ಣ ರೂಟರ್ನಲ್ಲಿ ಕೊನೆಗೊಂಡರೆ ಸಾಧನದ CPU ಗಮನಿಸಿ. ಸಣ್ಣ ಕೃತಕ ಥ್ರೂಪುಟ್ ಪರೀಕ್ಷೆ ಕೆಲವು ಮೆಗಾಬೈಟ್ಗಳ ನಂತರ ಮಾತ್ರ ಕಾಣುವ ನಿಲುಗಡೆಯನ್ನು ತಪ್ಪಿಸಿಕೊಳ್ಳಬಹುದು.
ಕಡಿತದ ನಂತರ ಪ್ಯಾಕೆಟ್ ಕೌಂಟರ್ಗಳು ಏರುತ್ತವೆ, ಏಕೆಂದರೆ ಅದೇ ವರ್ಗಾವಣೆ ಈಗ ಹೆಚ್ಚು ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಬಳಸುತ್ತದೆ. ಅದು ನಿರೀಕ್ಷಿತ ಮತ್ತು ಹೆಚ್ಚಿನ ಥ್ರೂಪುಟ್ನ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಪೂರ್ಣಗೊಂಡ ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾ, ಮರುಪ್ರೇಷಣೆ ಸಂಖ್ಯೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯಾಶೀಲತೆಯನ್ನು ಹೋಲಿಸಿ, ಕೇವಲ ಪ್ಯಾಕೆಟ್ ದರವಲ್ಲ.
ಬದಲಾವಣೆಯನ್ನು ಹಂತ ಹಂತವಾಗಿ ತನ್ನಿ ಮತ್ತು ಸೀಮಿತವಾಗಿ ಇರಿಸಿ
ಮೂಲ ಮೌಲ್ಯವನ್ನು ದಾಖಲಿಸಿ, ಒಂದು ನಿಯಂತ್ರಣವನ್ನು ಬದಲಿಸಿ, ಮತ್ತು ಶಾಶ್ವತಗೊಳಿಸುವ ಮೊದಲು ಮಾಪನವನ್ನು ಪುನರಾವರ್ತಿಸಿ. ಸಾಕ್ಷ್ಯವು ಲಾಭ ತೋರಿಸದಿದ್ದರೆ, ಅದನ್ನು ಹೊಂದಿಸಲು ಬಳಸಿದ ಅದೇ ಇಂಟರ್ಫೇಸ್ ಆದೇಶದಿಂದ ಹಿಂದಿನ ಮೌಲ್ಯವನ್ನು ಮರುಸ್ಥಾಪಿಸಿ:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500ಫಲಿತಾಂಶವನ್ನು ಅದು ಬೇಕಿದ್ದ ನೆಟ್ವರ್ಕ್ಗೆ ಸೀಮಿತಗೊಳಿಸಿ. ಹೋಟೆಲ್ Wi-Fi, ಮೊಬೈಲ್ ಹಾಟ್ಸ್ಪಾಟ್ ಮತ್ತು ಕಚೇರಿ LAN ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಬೇಕಾದ ಪ್ರೊಫೈಲ್, ಕ್ಲೈಂಟ್ ಮಾರ್ಗವನ್ನು ಪತ್ತೆ ಮಾಡಲಾಗದಿದ್ದರೆ, ಅವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಬೇಡುವ ಅತ್ಯಂತ ಕಡಿಮೆ ಮೌಲ್ಯವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯಬಾರದು.
ಸರಿಯಾದ ಮೌಲ್ಯ ಮಾರ್ಗದಲ್ಲಿ ಉಳಿಯುವ ಅತಿದೊಡ್ಡ MTU, ಲಕ್ಷಣವನ್ನು ಮಾಯವಾಗಿಸುವ ಅತಿ ಚಿಕ್ಕದಲ್ಲ. ಮಾರ್ಗ, ಪ್ರೋಬ್ನ ಫಲಿತಾಂಶ ಮತ್ತು ಹಿಂಪಡೆಯುವಿಕೆಯನ್ನು ದಾಖಲಿಸಿ, ಮತ್ತು ಪ್ರವೇಶ ನೆಟ್ವರ್ಕ್ ಬದಲಾದಾಗ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಮರುಪರಿಶೀಲಿಸಿ.