DNS ಬಗೆಹರಿಯುತ್ತದೆ, SSH ಸೆಷನ್ ಉಳಿಯುತ್ತದೆ, ನಂತರ ದೊಡ್ಡ ಅಪ್ಲೋಡ್ ಸ್ತಬ್ಧವಾಗುತ್ತದೆ, ಆದರೆ ಅದೇ ಹೋಸ್ಟ್ಗೆ ping ಇನ್ನೂ ಉತ್ತರಿಸುತ್ತದೆ. ಆ ವಿಭಜನೆ ಮುರಿದ ಟನೆಲ್ಗಲ್ಲ, ಪ್ಯಾಕೆಟ್ ಗಾತ್ರಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ. ನೆಸ್ಟ್ ಮಾಡಿದ ಟನೆಲ್ಗಳು ಯಾವುದೇ ಒಂದು ಟನೆಲ್ ಒಂಟಿಯಾಗಿ ತಲುಪದ ಗಾತ್ರಗಳಲ್ಲಿ ಅದನ್ನು ತಲುಪುತ್ತವೆ. ಒಳಗಿನ ಸೆಷನ್ ಸರಿಯಾಗಿದೆ; ಅದಕ್ಕೆ ಇನ್ನು ಸರಿಹೊಂದದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ನೀಡಲಾಗುತ್ತಿದೆ.

ಪಥದ MTU ವಾಸ್ತವವಾಗಿ ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ

ಪ್ರತಿ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಷನ್ ಮುಂದಿನ ಪದರಕ್ಕೆ ಸರದಿ ಬರುವ ಮೊದಲು ಬೈಟ್ಗಳನ್ನು ಖರ್ಚು ಮಾಡುತ್ತದೆ. Ethernet ಪಥ ಹೊರಗಿನ ಪ್ಯಾಕೆಟ್ಗೆ 1500 ಬೈಟ್ ನೀಡುತ್ತದೆ, ಮತ್ತು ಹೊರಗಿನ ಟನೆಲ್ ತನ್ನ ಒಳಗಿನ ಯಾವುದನ್ನೂ ವಿಳಾಸ ಮಾಡುವ ಮೊದಲು ತನ್ನ ಪಾಲನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಒಂದು ಊಹಿಸಿದ ಓವರ್ಹೆಡ್ ಮೌಲ್ಯವು ಮುಖ್ಯವಾದಷ್ಟೇ ಪ್ರಮಾಣದಲ್ಲಿ ತಪ್ಪಾಗಿರುತ್ತದೆ.

ಪದರಗಳನ್ನು ಕ್ರಮವಾಗಿ ಪಟ್ಟಿ ಮಾಡಿ: ಪ್ರವೇಶ ಪಥ, ಹೊರಗಿನ ಸಾಗಣೆ, ಹೊರಗಿನ ಟನೆಲ್, ಒಳಗಿನ ಸಾಗಣೆ, ಒಳಗಿನ ಟನೆಲ್, ಅನ್ವಯ. ಪ್ರತಿ ಹೆಡರ್ ಅನ್ನು ಒಮ್ಮೆ ಎಣಿಸಿ, ಮತ್ತು UDP ಅನ್ನು ಟನೆಲ್ನ ಸ್ವಂತ ಹೆಡರ್ ಮತ್ತು ಟ್ಯಾಗ್ನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಇರಿಸಿ.

ಎರಡು WireGuard ಪದರಗಳು, ಒಮ್ಮೆ ಎಣಿಸಲಾಗಿದೆ

ಒಂದು IPv4 ಪ್ರವೇಶ ಪಥವನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ, ಅದರೊಳಗೆ ಇನ್ನೊಂದು WireGuard ಟನೆಲ್ ಇದೆ. ಹೊರಗಿನ ಪದರವು 20 ಬೈಟ್ IPv4, 8 ಬೈಟ್ UDP ಮತ್ತು WireGuard ಡೇಟಾ ಹೆಡರ್ ಹಾಗೂ ಅದರ ದೃಢೀಕರಣ ಟ್ಯಾಗ್ಗೆ 32 ಬೈಟ್ ಖರ್ಚು ಮಾಡುತ್ತದೆ. ಅದರೊಳಗೆ ಒಳಗಿನ ಟನೆಲ್ಗೆ ತನ್ನದೇ 20 ಬೈಟ್ IPv4 ಹೆಡರ್ ಮತ್ತು 8 ಬೈಟ್ UDP ಹೆಡರ್ ಬೇಕು, ಅದರ ಎರಡನೇ 32 ಬೈಟ್ WireGuard ಓವರ್ಹೆಡ್ಗಿಂತ ಮೊದಲು. ಉಳಿದದ್ದು IPv4 ಹೆಡರ್, TCP ಹೆಡರ್ ಮತ್ತು ಡೇಟಾವನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಹೊರಗಿನ IPv6 ಪಥವು 20 ಬದಲು 40 ಖರ್ಚು ಮಾಡಿ 1320 ಬಿಡುತ್ತದೆ.

LayerBytes
Path MTU1500
Outer IPv4 header20
Outer UDP header8
Outer WireGuard header and tag32
Inner transport IPv4 header20
Inner UDP header8
Inner WireGuard header and tag32
Innermost IPv4 header20
TCP header20
Payload that fits1340

ಗಣನೆ 1340 ಬೈಟ್ಗೆ ಬರುತ್ತದೆ. ಅದೇ ನಿಯಮಗಳಲ್ಲಿ ಒಂದು ಪದರವು TCP ಪೇಲೋಡ್ಗೆ 1400 ಬಿಡುತ್ತದೆ, ಅಂದರೆ 1500 ಮೈನಸ್ 20, 8, 32, 20 ಮತ್ತು 20, ಮತ್ತು 60 ಬೈಟ್ ವ್ಯತ್ಯಾಸವು ಎರಡನೇ ಟನೆಲ್ ಸೇರಿಸುವ ಒಳಗಿನ ಎನ್ಕ್ಯಾಪ್ಸುಲೇಷನ್.

1400 ಅನ್ನು ನೆಸ್ಟ್ ಮಾಡಿದ ಪಥಕ್ಕೆ ಅನ್ವಯಿಸಿ, ಒಳಗಿನ ಟನೆಲ್ಗೆ 60 ಬೈಟ್ ಕಡಿಮೆ ಬರುತ್ತದೆ, ಪ್ಯಾಕೆಟ್ ಅವುಗಳನ್ನು ಬೇಕಾಗುವಷ್ಟು ದೊಡ್ಡವಾಗುವವರೆಗೆ ಕಾಣಿಸುವುದಿಲ್ಲ. ಪ್ಯಾಡಿಂಗ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ನ ಸ್ವಂತ ಫ್ರ್ಯಾಗ್ಮೆಂಟೇಶನ್ ಆಯ್ಕೆ ಸಂಖ್ಯೆಗಳನ್ನು ಮತ್ತೆ ಸರಿಸುತ್ತವೆ, ಆದ್ದರಿಂದ ಕೋಷ್ಟಕವನ್ನು ನಂಬಿ.

MTU, MSS ಮತ್ತು ಫ್ರ್ಯಾಗ್ಮೆಂಟೇಶನ್ ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ

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

ಸೇತುವೆಯ ಮತ್ತು ಮಾರ್ಗಸೂಚಿತ ಟನೆಲ್ಗಳು ವಿಭಿನ್ನ ಫ್ರೇಮ್ಗಳನ್ನು ಒಯ್ಯುತ್ತವೆ, ಆದ್ದರಿಂದ ಇನ್ನೊಂದು ನಿಯೋಜನೆಯ ಸಂಖ್ಯೆಗಳು ಅಪರೂಪಕ್ಕೆ ವರ್ಗಾವಣೆಯಾಗುತ್ತವೆ. ಪಥ MTU ಶೋಧನೆ, ಅದನ್ನು ವಿವರಿಸಲಾಗಿದೆ RFC 8201 ನಲ್ಲಿ, ಅದು ಅವಲಂಬಿಸಿರುವ ICMP ಸಂದೇಶಗಳನ್ನು ಹಾದುಹೋಗಲು ಬಿಟ್ಟಾಗ ಮಾತ್ರ ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಕಡಿಮೆ ಬಿದ್ದ ಪದರವನ್ನು ಕಂಡುಹಿಡಿಯುವುದು

ಅಗತ್ಯಗಳು ಹೋಲಿಕೆಗೆ ಅವಕಾಶ ನೀಡಿದರೆ, ನೆಸ್ಟ್ ಮಾಡುವ ಮೊದಲು ಪ್ರತಿ ಟನೆಲ್ ಅನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ. ಸ್ಥಿರ ಗಾತ್ರದ ಪ್ರೋಬ್ ಅದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ: ping -M do -s 1472 -c 3 10.8.0.1 ಆ ಪದರದೊಳಗೆ ಪೂರ್ಣ 1500 ಬೈಟ್ IPv4 ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸುತ್ತದೆ. ಎರಡನೇ ಪದರ ಸೇರಿಸಿ ಅದೇ ಪ್ರೋಬ್ ಪುನರಾವರ್ತಿಸಿ, ಆಗ ಯಾವುದೇ ವೈಫಲ್ಯ ತಿಳಿದ ಬದಲಾವಣೆಗೆ ಸೇರುತ್ತದೆ.

ವರ್ಗಾವಣೆ ನಿಂತಾಗ, ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ದಾಖಲಿತ ಪ್ಯಾರಾಮೀಟರ್ ಬದಲಾಯಿಸಿ ಮತ್ತು ವಿಫಲವಾಗುವ ಗಾತ್ರವನ್ನು ದಾಖಲಿಸಿ. ಹಿಂತಿರುಗುವ ಪಥವನ್ನೂ ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ನೆಸ್ಟ್ ಮಾಡಿದ ಮಾರ್ಗ ಮರುಕಳಿಕೆ ಪ್ಯಾಕೆಟ್ ಗಾತ್ರದ ಸಮಸ್ಯೆಯನ್ನು ಒಂದು ಮಧ್ಯಾಹ್ನ ವೆಚ್ಚವಾಗುವಷ್ಟು ನಿಖರವಾಗಿ ಅನುಕರಿಸಬಲ್ಲದು. ಫಿಲ್ಟರ್ ಮಾಡಿದ ICMP ಉತ್ತರವು ನಿಜವಾದ ಮಿತಿಯನ್ನು ಮರೆಮಾಡಬಲ್ಲದು, ಆದ್ದರಿಂದ ಪ್ರೋಬ್ ತರ್ಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಮುಖ್ಯ.

ಮುಂದಿನ ವ್ಯಕ್ತಿ ಕಂಡುಕೊಳ್ಳುವ ಸ್ಥಳದಲ್ಲಿ ಬಜೆಟ್ ಬರೆಯಿರಿ

ಪ್ರತಿ ಪದರಕ್ಕೆ ಒಂದು ಸಾಲಿನ ಕೋಷ್ಟಕವು ಹೆಬ್ಬೆರಳ ನಿಯಮಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ಉಳಿಯುತ್ತದೆ. ಟನೆಲ್ ರೇಖಾಚಿತ್ರದ ಪಕ್ಕದಲ್ಲಿ ಇರಿಸಿ, ಒತ್ತಡದಲ್ಲಿ ಯಾರೂ ಗಣನೆಯನ್ನು ಮತ್ತೆ ಮಾಡದಂತೆ.

ಹೆಚ್ಚು ಟನೆಲ್ಗಳು ಎಂದರೆ ಹೆಚ್ಚು ಅವಲಂಬನೆಗಳು, ಆದ್ದರಿಂದ ರೋಲ್ಬ್ಯಾಕ್ ಯೋಜನೆ ಬಜೆಟ್ನ ಪಕ್ಕದಲ್ಲಿ ತನ್ನ ಸ್ಥಾನವನ್ನು ಗಳಿಸುತ್ತದೆ. ಸಂಖ್ಯೆಗಳು ಇನ್ನೂ ಹೊಂದದಿದ್ದರೆ, ಮತ್ತೆ ಊಹಿಸುವ ಬದಲು ಪಥವನ್ನು ಅಳೆಯಿರಿ. ಗುರಿ ಎಂದರೆ ನೀವು ಸಮರ್ಥಿಸಬಹುದಾದ ಸಂಖ್ಯೆ, ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವುದಲ್ಲ.

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