ಕಾರ್ಪೊರೇಟ್ VPN ಹಿಂದಿನ ಕಂಟೇನರ್ ಒಳಗೆ DNS ಬಗೆಹರಿಯುತ್ತದೆ, ಲಾಗಿನ್ ಪುಟ ಲೋಡ್ ಆಗುತ್ತದೆ, ಆರೋಗ್ಯ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಉತ್ತರಿಸುತ್ತದೆ, ನಂತರ HTTPS ವಿನಂತಿ ಸಮಯ ಮೀರುವವರೆಗೆ ನಿಲ್ಲುತ್ತದೆ. ಇಮೇಜ್ ಮರುನಿರ್ಮಿಸುವುದು ಮತ್ತು ಪ್ರಾಕ್ಸಿ ಚರಗಳನ್ನು ಬದಲಿಸುವುದು ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ವಿಫಲವಾದ ಭಾಗ ಇಮೇಜ್‌ನಲ್ಲಿಲ್ಲ. ಕ್ಲೈಂಟ್ ಒಂದು ಸಾಗಣೆಯ ಮೇಲೆ ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ದೊಡ್ಡ ಡೇಟಾವನ್ನು ಇನ್ನೊಂದರ ಮೇಲೆ ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ಮಾತ್ರ ಕೆಟ್ಟಿದೆ.

ಎರಡು ಸಾಗಣೆಗಳು, ಒಂದು ಗೊಂದಲದ ಲಕ್ಷಣ

TLS ಆಧಾರಿತ ಕಾರ್ಪೊರೇಟ್ ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಾಮಾನ್ಯ TLS ಸಂಪರ್ಕದ ಮೇಲೆ ದೃಢೀಕರಿಸುತ್ತದೆ, ನಂತರ ಸೆಷನ್‌ಗಾಗಿ UDP ಆಧಾರಿತ ಎರಡನೇ ಡೇಟಾ ಚಾನಲ್ ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ. ಆ ಎರಡನೇ ಕಾಲು ಕೆಲಸ ಮಾಡಿದಾಗ ಥ್ರೂಪುಟ್ ಮತ್ತು ವಿಳಂಬ ಸುಧಾರಿಸುತ್ತವೆ. ಅದನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿದಾಗ ಅಥವಾ ಮಾರ್ಗದಲ್ಲಿ ಹೊಂದಿಕೊಳ್ಳದಿದ್ದಾಗ, ದೊಡ್ಡ ವರ್ಗಾವಣೆಗೆ ಮೊದಲಿನ ಎಲ್ಲವೂ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ ಮತ್ತು ವರ್ಗಾವಣೆಯೇ ನಿಲ್ಲುತ್ತದೆ, ಅದು ಮೇಲಿನ ಮಾದರಿಯೇ.

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

ಅಂತರ್ಬೋಧೆಯಿಂದಲ್ಲ, ಪ್ರಯೋಗದಿಂದ ನಿರ್ಧರಿಸಿ

ಅಗ್ಗದ ಪ್ರಯೋಗ UDP ಡೇಟಾ ಚಾನಲ್ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿ ವಿನಂತಿಯನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತದೆ. ಡೆಸ್ಕ್‌ಟಾಪ್ ಸುತ್ತುವರಿಕೆಗಿಂತ ಆಜ್ಞಾ ಸಾಲಿನ ಕ್ಲೈಂಟ್ ಬಳಸಿ, ಫ್ಲ್ಯಾಗ್ ನಿಜವಾಗಿ ಅನ್ವಯವಾಗಲಿ: openconnect vpn.example.net --user=you --interface=tun0 --no-dtls. ನಿಂತಿದ್ದ ವಿನಂತಿ ಈಗ ಪೂರ್ಣಗೊಂಡರೆ, DTLS ಕಾಲೇ ಸಮಸ್ಯೆಯಾಗಿತ್ತು ಮತ್ತು ಉಳಿದದ್ದು ಗದ್ದಲ.

ಅದೇ ಕಂಟೇನರ್‌ನಿಂದ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಫಲಿತಾಂಶ ದೃಢೀಕರಿಸಿ: ಫ್ಲ್ಯಾಗ್‌ನೊಂದಿಗೆ ಒಂದು ದೊಡ್ಡ ವಿನಂತಿ ಮತ್ತು ಅದಿಲ್ಲದೆ ಒಂದು. ಫ್ಲ್ಯಾಗ್‌ನ್ನು ಅನುಸರಿಸುವ ನಡವಳಿಕೆ ಬದಲಾವಣೆ ಸಾಕ್ಷ್ಯ; ಕೊನೆಗೆ ಲೋಡ್ ಆಗುವ ಪುಟ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಫ್ಲ್ಯಾಗ್ ಸರಿಪಡಿಸಿದರೆ, ಏಕೆ ಎಂದು ನಿರ್ಧರಿಸಿ

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

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

ಪರ್ಯಾಯ ಮಾರ್ಗ ಉಳಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಪ್ಯಾಕೆಟ್ ಗಾತ್ರ ಪರಿಶೀಲಿಸಿ

ಗಾತ್ರವೇ ಕಾರಣವಾದರೆ, ಟನೆಲ್ ಇಂಟರ್‌ಫೇಸ್ ಮಾರ್ಗ ಹೊರಲಾರದ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಪೇಲೋಡ್ ಬೆಳೆದ ಕೂಡಲೇ ಸಮಸ್ಯೆ ಯಾವುದೇ ಸಾಗಣೆಯಲ್ಲಿ ಮರಳುತ್ತದೆ. ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ಹೋಲಿಸಿ: ಹೋಸ್ಟ್‌ನಲ್ಲಿ ip link show tun0, ನಂತರ ನೆಟ್‌ವರ್ಕ್ ಆಯ್ಕೆಗಳಲ್ಲಿ ದಾಖಲಾದ MTU ಓದಲು docker network inspect bridge. ಕಡಿಮೆ ಹೊರುವ ಟನೆಲ್ ಅಡಿಯಲ್ಲಿ ಇನ್ನೂ 1500 ಬೈಟ್‌ನಲ್ಲಿರುವ ಕಂಟೇನರ್ ಸೇತುವೆ ಸಾಮಾನ್ಯ ಸಂಶೋಧನೆ.

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

ಏನನ್ನು ಬದಲಾಯಿಸಲು ಸಿದ್ಧರಿದ್ದೀರಿ ಎಂದು ನಿರ್ಧರಿಸಿ

ಡೇಟಾ ಚಾನಲ್ ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದಾಗ ಟನೆಲ್ ತನ್ನ ಹೊರೆಯನ್ನು TCP ಸಂಪರ್ಕದ ಒಳಗೆ ಸಾಗಿಸುತ್ತದೆ. ಸ್ವಚ್ಛ ಮಾರ್ಗದಲ್ಲಿ ಅದು ಕೇವಲ ನಿಧಾನ; ನಷ್ಟಪೂರ್ಣ ಮಾರ್ಗದಲ್ಲಿ ಒಂದು ಕಳೆದುಹೋದ ವಿಭಾಗವು ಅದರ ಹಿಂದಿನ ಎಲ್ಲವನ್ನೂ ವಿಳಂಬಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಹೊರಗಿನ ಮರುಪ್ರೇಷಣೆ ಒಳಗಿನದರೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸುತ್ತದೆ. ಆ ವಿನಿಮಯ ಸಂವಾದಾತ್ಮಕ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಸಣ್ಣ API ಕರೆಗಳಿಗೆ ಹೊಂದುತ್ತದೆ, ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳಿಗೆ ಅಥವಾ ಮೊಬೈಲ್ ಲಿಂಕ್‌ಗಳಲ್ಲಿ ದೀರ್ಘ ಅವಧಿಗಳಿಗೆ ಕೆಟ್ಟದಾಗಿ ಹೊಂದುತ್ತದೆ.

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

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