OpenVPN TCP ನಲ್ಲಿ: rto_min ಸರದಿಯ ತುದಿಯ ಬ್ಲಾಕಿಂಗ್ ಸರಿಪಡಿಸುವುದಿಲ್ಲ

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

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

ಲಕ್ಷಣ: ಎಲ್ಲವೂ ಒಂದೇ ಬಾರಿಗೆ ನಿಲ್ಲುತ್ತವೆ

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

ಆ ಏನೋ ಟನೆಲ್ನ ಸಾಗಣೆ ಪದರ. TCP ಕ್ರಮದಲ್ಲಿ, OpenVPN ಸುತ್ತಿದ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಪೀರ್ಗೆ ಒಂದೇ TCP ಸಂಪರ್ಕದಲ್ಲಿ ಬರೆಯುತ್ತದೆ, TCP ನ ಒಪ್ಪಂದ ಒಂದೇ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಕ್ರಮವಾಗಿ ತಲುಪಿಸುವುದು. ನಂತರದ ಬೈಟ್ಗಳು ಕಾಣೆಯಾದವುಗಳ ಮೊದಲು ಅಪ್ಲಿಕೇಶನ್ಗೆ ನೀಡಲಾಗುವುದಿಲ್ಲ, ಅವು ಯಾವ ಒಳಗಿನ ಸಂಭಾಷಣೆಗೆ ಸೇರಿದ್ದರೂ.

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

ಒಂದು ಹೊರಗಿನ ಬೈಟ್ ಸ್ಟ್ರೀಮ್, ಅನೇಕ ಒಳಗಿನ ಸಂಭಾಷಣೆಗಳು

ಟನೆಲ್ ಒಂದೇ ಸಮಯದಲ್ಲಿ ಡೌನ್ಲೋಡ್ ಮತ್ತು ಶೆಲ್ ಹೊರುತ್ತದೆ ಎಂದು ಊಹಿಸಿ. ಹೊರಗಿನ ಸಂಪರ್ಕದ ಒಂದು ಸೆಗ್ಮೆಂಟ್ ಕಳೆದುಹೋಗುತ್ತದೆ. ಮುಂದಿನ ಸೆಗ್ಮೆಂಟ್ಗಳು ಸ್ವೀಕರಿಸುವ ಹೋಸ್ಟ್ಗೆ ತಲುಪಬಹುದು, ಸ್ವೀಕರಿಸುವ TCP ಸ್ಟ್ಯಾಕ್ ಅವನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ, ಆದರೆ ಕಿಂಡಿ ತುಂಬುವವರೆಗೆ ಅವನ್ನು ಮೇಲಕ್ಕೆ ಒಪ್ಪಿಸಲಾಗದು. ಆದ್ದರಿಂದ OpenVPN ಗೆ ಶೆಲ್ಗಾಗಿ ಓದಲು ಏನೂ ಇಲ್ಲ, ಶೆಲ್ನ ಸ್ವಂತ ಬೈಟ್ಗಳು ಬಹಳ ಹಿಂದೆಯೇ ಬಂದಿದ್ದರೂ.

ಇದು ಒಂದು ಸಂಪರ್ಕದ ಒಳಗೆ ಸರದಿಯ ತುದಿಯ ಬ್ಲಾಕಿಂಗ್, ಮತ್ತು ಎರಡೂ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಒಳಗಿನ ಸಂಪರ್ಕವನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕೆಂದು ಕೇಳುವುದಿಲ್ಲ. ಅವು ಹೊರಗಿನದನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಅದೇ ಸಾಕು.

ಎರಡನೇ ಹಂತದ ಪರಿಣಾಮ ಅದನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸುತ್ತದೆ. ದೃಢೀಕರಣಗಳು ಕಾಣದ ಒಳಗಿನ ಕಳುಹಿಸುವವನು, ಹೊರಗಿನ ಪದರ ಈಗಾಗಲೇ ಒಪ್ಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಡೇಟಾವನ್ನು ಮತ್ತೆ ಕಳುಹಿಸಬಹುದು. ಆ ಮರುಕಳುಹಿಸುವಿಕೆ ಸೆಗ್ಮೆಂಟ್ಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳಬಹುದೆಂದು ಈಗಷ್ಟೇ ಸಾಬೀತು ಮಾಡಿದ ಮಾರ್ಗದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ಟನೆಲ್ ಸಂಚಾರವಾಗುತ್ತದೆ, ಆದ್ದರಿಂದ ಚೇತರಿಕೆಯ ಕೆಲಸ ಮುಖ್ಯವಾದ ಚೇತರಿಕೆಯೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸುತ್ತದೆ.

ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಕುಸಿತಕ್ಕೆ ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ. ಸಣ್ಣ ಸುತ್ತು ಪ್ರಯಾಣಗಳು, ಉದಾರ ಸರದಿಗಳಿರುವ ಸ್ವಚ್ಛ ಮಾರ್ಗದಲ್ಲಿ ಈ ಏರ್ಪಾಡು ವರ್ಷಗಳ ಕಾಲ ಸಂಪೂರ್ಣವಾಗಿ ಬಳಸಲು ಯೋಗ್ಯವಾಗಿರಬಹುದು. ನಷ್ಟ, ವಿಳಂಬ ಮತ್ತು ಸರದಿಯ ಆಳ ಒಟ್ಟಿಗೆ ಸೇರುವಾಗ ವೈಫಲ್ಯ ಕಾಣಿಸುತ್ತದೆ, ಅದಕ್ಕೇ ವರದಿಗಳು ಚೆನ್ನಾಗಿ ಸಜ್ಜುಗೊಂಡ ಕಚೇರಿಗಳ ಸುತ್ತಲ್ಲ, ದಟ್ಟಣೆಯ ಅಪ್ಲಿಂಕ್ಗಳು ಮತ್ತು ಮೊಬೈಲ್ ಲಿಂಕ್ಗಳ ಸುತ್ತ ಸೇರುತ್ತವೆ.

ಉದ್ದವಾದ ಒಳಗಿನ ಟೈಮರ್ ಏಕೆ ಸಹಾಯ ಮಾಡಲಾಗದು

ಒಂದು ಮಾರ್ಗದಲ್ಲಿ rto_min ಮೂಲಕ ಕನಿಷ್ಠ ಮರುಕಳುಹಿಸುವ ಸಮಯ ಮಿತಿಯನ್ನು ಹೆಚ್ಚಿಸುವುದು, ಆ ಮಾರ್ಗವನ್ನು ಬಳಸುವ ಸ್ಥಳೀಯವಾಗಿ ಉತ್ಪಾದನೆಯಾಗುವ TCP ಸಂಚಾರಕ್ಕೆ ಟೈಮರ್ ಆಧಾರಿತ ಮರುಕಳುಹಿಸುವಿಕೆಯನ್ನು ತಡಮಾಡುತ್ತದೆ. ಇದು ನಿಜವಾದ ಪರಿಣಾಮವಿರುವ ನಿಜವಾದ ನಾಬ್, ಮತ್ತು ಮೊದಲ ಹಂತದ ಸಮಸ್ಯೆಗೆ ಬದಲಾಗಿ ಎರಡನೇ ಹಂತದ ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸುತ್ತದೆ.

ip route show
ip route show cache 2>/dev/null | head
ss -tin dst 10.70.0.1

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

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

ಹನ್ನೆರಡು ಸೆಕೆಂಡುಗಳ ಸ್ಥಿರ ನೆಲ ಈ ವಿಷಯದ ಸಲಹೆಗಳಲ್ಲಿ TCP ಟನೆಲ್ ಇರುವುದೇ ಅದನ್ನು ಕಡ್ಡಾಯ ಮಾಡಿದಂತೆ ಕಾಣಿಸುತ್ತದೆ. RFC 6298 ನಲ್ಲಿ ವಿವರಿಸಿದ ಮರುಕಳುಹಿಸುವ ಟೈಮರ್ ಅಳೆಯಲಾದ ಸುತ್ತು ಪ್ರಯಾಣ ಸಮಯದಿಂದ ಘಾತೀಯ ಹಿಮ್ಮೆಟ್ಟುವಿಕೆಯೊಂದಿಗೆ ಹುಟ್ಟುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ಥಿರ ನೆಲ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಾರ್ಗಕ್ಕೆ ನೀತಿ ಆಯ್ಕೆ, ಪ್ರೋಟೋಕಾಲ್ ಅಗತ್ಯವಲ್ಲ. ವ್ಯಾಪಕವಾಗಿ ಅನ್ವಯಿಸಿದಾಗ ಅದು ಲಕ್ಷಣವನ್ನು ಮರೆಮಾಡಿ, ಆ ಮಾರ್ಗ ಆವರಿಸುವ ಪ್ರತಿ ಹರಿವಿಗೂ ಚೇತರಿಕೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ.

tcp-nodelay ಏನು ಮಾಡುತ್ತದೆ, ಏನು ಮಾಡುವುದಿಲ್ಲ

ಸಾಗಣೆ ಸಾಕೆಟ್ನಲ್ಲಿ Nagle ಶೈಲಿಯ ಬಫರಿಂಗ್ ಆಫ್ ಮಾಡುವ ಟನೆಲ್ ಆಯ್ಕೆಗೆ ಸಣ್ಣ ಉದ್ದೇಶವಿದೆ: ಸಣ್ಣ ಬರವಣಿಗೆಗಳು ಕಳುಹಿಸುವ ಮೊದಲು ಹೆಚ್ಚು ಡೇಟಾಗಾಗಿ ಕಾಯದಂತೆ ತಡೆಯುವುದು. ಇದು ಸಂವಾದಾತ್ಮಕ ಸಂಚಾರವು ಉಳಿದ ವಿಷಯಗಳಲ್ಲಿ ಆರೋಗ್ಯಕರ ಮಾರ್ಗದಲ್ಲಿ ಹೆಚ್ಚುವರಿ ವಿಳಂಬವನ್ನು ತಪ್ಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.

ಇದು ಸಾಗಣೆಯನ್ನು ಅಕ್ರಮವಾಗಿ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಕಳೆದುಹೋದ ಸೆಗ್ಮೆಂಟ್ ನಂತರ ಚೇತರಿಕೆಯನ್ನು ಚಿಕ್ಕದಾಗಿಸುವುದಿಲ್ಲ. ಮರುಕಳುಹಿಸುವ ಸಮಯ ಮಿತಿಗಾಗಿ ನಿಲ್ಲುವ ಶೆಲ್ ಆ ಆಯ್ಕೆ ಆನ್ ಆಗಿದ್ದರೂ ನಿಲ್ಲುತ್ತದೆ, ಏಕೆಂದರೆ ಆಯ್ಕೆ ಕ್ರಮದ ನಿಯಮವನ್ನು ಎಂದೂ ಮುಟ್ಟಿಲ್ಲ.

ಎರಡನ್ನೂ ಗೊಂದಲಿಸುವುದು ಸುಲಭ ಏಕೆಂದರೆ ಎರಡನ್ನೂ ವಿಳಂಬ ಸರಿಪಡಿಸುವಿಕೆಗಳು ಎಂದು ವಿವರಿಸಲಾಗುತ್ತದೆ. ಒಂದು ಬಫರಿಂಗ್ ತಂದ ಕೃತಕ ನಿರೀಕ್ಷೆಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಇನ್ನೊಂದು ಸಾಗಣೆ ಏನು ಖಾತರಿ ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸಬೇಕಾಗುತ್ತದೆ, ಯಾವ ಸಾಕೆಟ್ ಆಯ್ಕೆಯೂ ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ.

ಸಾಗಣೆ ಪದರಗಳನ್ನು ನ್ಯಾಯಯುತವಾಗಿ ಹೋಲಿಸುವುದು ಹೇಗೆ

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

ಥ್ರೂಪುಟ್ ಸಂಖ್ಯೆಗೆ ಬದಲಾಗಿ ಹಂಚಿಕೆಯ ವಿರಾಮವನ್ನು ಗಮನಿಸಿ. ಹೊರಗಿನ ನಷ್ಟದ ಸಮಯದಲ್ಲಿ ಹಲವು ಒಳಗಿನ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಒಟ್ಟಿಗೆ ಸಿಕ್ಕಿಹಾಕಿಕೊಳ್ಳುವುದೇ ಸರದಿಯ ತುದಿಯ ಬ್ಲಾಕಿಂಗ್ ಅನ್ನು ಗುರುತಿಸುವ ವೀಕ್ಷಣೆ; ವೇಗ ಪರೀಕ್ಷೆಯ ಒಂದು ಕಡಿಮೆ ಸಂಖ್ಯೆ ಅದನ್ನು ಮಾಡುವುದಿಲ್ಲ.

ಟನೆಲ್ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಅಧಿಕೃತ ಸೆರೆಗಳು ಎರಡು ಪದರಗಳನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ಒಳಗಿನ ಮತ್ತು ಹೊರಗಿನ ಮರುಕಳುಹಿಸುವಿಕೆಗಳು ಬೇರೆ ಬೇರೆ ಕ್ರಮ ಪ್ರದೇಶಗಳಿರುವ ಬೇರೆ ಬೇರೆ ಸಂಪರ್ಕಗಳಿಗೆ ಸೇರುತ್ತವೆ. ಹೊರಗಿನ ಸ್ಟ್ರೀಮ್ ಕಿಂಡಿ ತೋರಿಸುತ್ತಿರುವಾಗ ಒಳಗಿನ ಮರುಕಳುಹಿಸುವಿಕೆಗಳನ್ನು ನೋಡುವುದೇ ನೇರ ಸಾಕ್ಷ್ಯ.

UDP ಗೆ ಬದಲಾಗುವುದು ಹೆಚ್ಚುವರಿ ವಿಶ್ವಾಸಾರ್ಹ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ತೆಗೆದುಹಾಕಿ, ಒಳಗಿನ TCP ತನ್ನದೇ ಚೇತರಿಕೆ ಮಾಡಲು ಬಿಡುತ್ತದೆ. ಇದು ಶೂನ್ಯ ನಷ್ಟ ಅಥವಾ ಕಡಿಮೆ ವಿಳಂಬಕ್ಕೆ ಖಾತರಿ ನೀಡುವುದಿಲ್ಲ, ತುಂಬಿದ ಅಪ್ಲಿಂಕ್, ಮಿತಿಮೀರಿದ ಸರದಿಗಳು ಅಥವಾ MTU ಸಮಸ್ಯೆ ಇನ್ನೂ ಸರಿಪಡಿಸಬೇಕು. ಟನೆಲ್ನ ಹೊರಗಿನ ಸಂಚಾರ ಟನೆಲ್ನ ಕ್ರಮ ಕಿಂಡಿಯ ಹಿಂದೆ ಎಂದೂ ತಡೆಯಲ್ಪಡುವುದಿಲ್ಲ, ಎರಡೂ ಮಾರ್ಗಗಳು ಒಂದೇ ದಟ್ಟಣೆಯ ಲಿಂಕ್ ಹಂಚಿಕೊಂಡಾಗ ಅದು ಇನ್ನೂ ಬಳಲಬಹುದು, ಆ ಹಂಚಿಕೆಯ ಅಡಚಣೆ ಇದರಲ್ಲಿ ಮಡಚಿಕೊಳ್ಳದೆ ತನ್ನದೇ ತನಿಖೆಗೆ ಅರ್ಹ.