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

ಟನೆಲ್ ಅನ್ನು ದೂರುವ ಮೊದಲು ನಿಲುಗಡೆಯನ್ನು ವರ್ಗೀಕರಿಸಿ

ನಾಲ್ಕು ಫಲಿತಾಂಶಗಳು ಬಳಕೆದಾರನಿಗೆ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ ಮತ್ತು ಎಂಜಿನಿಯರ್‌ಗೆ ಸಂಪೂರ್ಣ ವಿಭಿನ್ನ ಅರ್ಥ ನೀಡುತ್ತವೆ.

What the client seesWhat it rules out
Connection refusedNothing is listening on the address and port the client reached
Timeout before the handshakeA filter, a missing route, or the wrong address
Handshake completes, query hangsThe session exists, so look at inspection, MTU and packet order
Stalls that recover on retryOften reordering, or a state table entry expiring

ಕೊನೆಯ ಎರಡು ಸಾಲುಗಳು ಮಾತ್ರ ಟನೆಲ್‌ನಲ್ಲಿ ಸಮಯ ಕಳೆಯುವುದನ್ನು ಸಮರ್ಥಿಸುತ್ತವೆ. VPN ಮೂಲಕ ನಿರಾಕರಿಸಲಾದ ಸಂಪರ್ಕ ಸಾಮಾನ್ಯವಾಗಿ ಡೇಟಾಬೇಸ್ ಕೇವಲ loopback ನಲ್ಲಿ ಕೇಳುತ್ತಿರುವುದು, ಇದು ಶ್ರೋತೃ ಸಮಸ್ಯೆ, ಮತ್ತು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಮೊದಲು ಸಮಯ ಮೀರುವುದು ಫಿಲ್ಟರ್ ಅಥವಾ ಮಾರ್ಗ. ಎರಡೂ ಎನ್‌ಕ್ಯಾಪ್ಸುಲೇಶನ್ ಬದಲಾಯಿಸುವುದರಿಂದ ಸುಧಾರಿಸುವುದಿಲ್ಲ.

ವರ್ಗೀಕರಣವನ್ನು ಮೊದಲು ಟಿಕೆಟ್‌ನಲ್ಲಿ ಬರೆಯಿರಿ. ಅದು ಅಗ್ಗದ ಹೆಜ್ಜೆ ಮತ್ತು ಹುಡುಕಾಟದ ಹೆಚ್ಚಿನ ಭಾಗವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

UDP ಮತ್ತು TCP ನಡುವೆ ನಿರ್ಧರಿಸುವ ಮೂರು ಷರತ್ತುಗಳು

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

ಮಾರ್ಗ ಸರಿಪಡಿಸುವುದು ಅಥವಾ TCP ಗೆ ಹಿಂತಿರುಗುವುದು ಮೂರು ಅಂಶಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಮೊದಲನೆಯದಾಗಿ, ಮಾರ್ಗದಲ್ಲಿ ನಿಜವಾದ ಪ್ಯಾಕೆಟ್ ನಷ್ಟವಿದೆಯೇ, ಅಥವಾ ಕೇವಲ ಮರುಕ್ರಮಣವೇ? ಎರಡನೆಯದಾಗಿ, ಪರಿಶೀಲನೆ ಎಲ್ಲಿ ನಡೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಾಯಿಸಬಹುದೇ, ಅಥವಾ ಈ ಟನೆಲ್ ಅನ್ನು ಮರುಕ್ರಮಗೊಳಿಸುವ ಘಟಕದಿಂದ ಹೊರಗಿಡಬಹುದೇ? ಮೂರನೆಯದಾಗಿ, ಕೆಲಸದ ಹೊರೆ ನಿಲುಗಡೆಯ ಮಾದರಿಗೆ ಸಂವೇದನಶೀಲವೇ, ಉದಾಹರಣೆಗೆ ಒಂದು ಲಿಂಕ್ ಹಂಚಿಕೊಳ್ಳುವ ಅನೇಕ ಮಲ್ಟಿಪ್ಲೆಕ್ಸ್ ಸೆಷನ್‌ಗಳು?

ಮೊದಲ ಉತ್ತರ ನಷ್ಟವಾಗಿದ್ದು ಎರಡನೆಯದು ಇಲ್ಲ ಎಂದಾದರೆ,443 ರಲ್ಲಿ TCP ವ್ಯಾವಹಾರಿಕ ಪರ್ಯಾಯವಾಗಿದೆ. ಎರಡನೆಯ ಉತ್ತರ ಹೌದು ಎಂದಾದರೆ, ಮಾರ್ಗ ಸರಿಪಡಿಸಿ ಮತ್ತು UDP ಉಳಿಸಿಕೊಳ್ಳಿ.

ಅಪ್ಲಿಕೇಶನ್ ದೋಷವಲ್ಲ, ಫೈರ್‌ವಾಲ್ ದಾಖಲೆಯನ್ನು ಓದಿ

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

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

ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸುವ ಮೊದಲು ಎರಡೂ ತುದಿಗಳನ್ನು ಹೋಲಿಸಿ, ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಸಂಖ್ಯೆಗಳಲ್ಲ, ಆಗಮನ ಕ್ರಮವನ್ನು ಹೋಲಿಸಿ:

tcpdump -ni any udp port 4500 -w /tmp/encap.pcap
tcpdump -ni any tcp port 5432 -w /tmp/inner.pcap

443 ರಲ್ಲಿ TCP ನಿಮಗೆ ನಿಜವಾಗಿ ಎಷ್ಟು ವೆಚ್ಚ ಮಾಡುತ್ತದೆ

ಟನೆಲ್ ಅನ್ನು TCP ಗೆ ಸರಿಸುವುದು ಮರುಕ್ರಮಣದ ಲಕ್ಷಣವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ, ಏಕೆಂದರೆ ಮಧ್ಯಂತರ ಬಾಕ್ಸ್ ಈಗ ಕ್ರಮಬದ್ಧ ಸ್ಟ್ರೀಮ್ ನೋಡುತ್ತದೆ. ಅದು TCP-over-TCP ಸಹ ಸೃಷ್ಟಿಸುತ್ತದೆ. ಹೊರಗಿನ ಸಂಪರ್ಕವು ಒಳಗಿನ ಸಂಪರ್ಕ ಈಗಾಗಲೇ ಮರುಕಳುಹಿಸಿದ್ದನ್ನು ಮತ್ತೆ ಕಳುಹಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದೇ ನಷ್ಟವು ಎಲ್ಲಾ ಮಲ್ಟಿಪ್ಲೆಕ್ಸ್ ಸೆಷನ್‌ಗಳನ್ನು ಒಟ್ಟಿಗೆ ನಿಲ್ಲಿಸಬಹುದು. ಸ್ವಚ್ಛ ಮಾರ್ಗದಲ್ಲಿ ಇದು ಕಾಣುವುದಿಲ್ಲ. ನಷ್ಟವಿರುವ ಮಾರ್ಗದಲ್ಲಿ ಪರಿಹಾರ ಲಕ್ಷಣಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿದೆ.

ಪರ್ಯಾಯವು ಸಂಪರ್ಕವಿಲ್ಲದಿರುವಾಗ ಈ ವಿನಿಮಯ ಸ್ವೀಕಾರಾರ್ಹ, ಮತ್ತು ಅದನ್ನು ಸಾಮಾನ್ಯವೆಂದು ಸ್ವೀಕರಿಸುವ ಬದಲು ಮಾಲೀಕರೊಂದಿಗೆ ವಿನಾಯಿತಿಯಾಗಿ ದಾಖಲಿಸಬೇಕು.

ಸಾಗಣೆ, ಪೋರ್ಟ್, ಮಾದರಿ ಕ್ವೆರಿ ಮತ್ತು ಅಳೆದ ಫಲಿತಾಂಶವನ್ನು, ಜೊತೆಗೆ ದಿನಾಂಕವನ್ನು ದಾಖಲಿಸಿ. ಆ ದಾಖಲೆ ಇಲ್ಲದೆ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ ಪ್ರಯೋಗವನ್ನು ಪುನರಾವರ್ತಿಸುತ್ತಾನೆ, ಮತ್ತು ವಿನಾಯಿತಿ ಶಾಂತವಾಗಿ ವಾಸ್ತುಶಿಲ್ಪವಾಗುತ್ತದೆ.

ನಿರ್ಧಾರವನ್ನು ಪುನರಾವಲೋಕನ ಮಾಡಬಹುದಾದಂತೆ ಇರಿಸಿ

ಮಾರ್ಗ ನಿದಾನನವು ಬೇಗ ಹಳೆಯದಾಗುತ್ತದೆ. ಮಧ್ಯಂತರ ಬಾಕ್ಸ್ ಬದಲಾಗುತ್ತದೆ, ಬ್ಲೇಡ್ ಸಂರಚನೆ ಬದಲಾಗುತ್ತದೆ, ಲಿಂಕ್ ಅಪ್‌ಗ್ರೇಡ್ ಆಗುತ್ತದೆ, ಮತ್ತು 443 ರಲ್ಲಿ TCP ಯ ಕಾರಣ ಮಾಯವಾಗುತ್ತದೆ ಆದರೆ ಸಂರಚನೆ ಉಳಿಯುತ್ತದೆ. ವಿನಾಯಿತಿಗೆ ಪುನರಾವಲೋಕನ ದಿನಾಂಕ ಹಾಕಿ ಮತ್ತು UDP ಗೆ ಹಿಂತಿರುಗಲು ಅನುಮತಿಸುವ ಷರತ್ತನ್ನು ಹೆಸರಿಸಿ.

ಸಣ್ಣ ಕ್ವೆರಿ ಮತ್ತು ದೊಡ್ಡ ಫಲಿತಾಂಶ ಗುಂಪಿನೊಂದಿಗೆ ಎರಡೂ ಸಾಗಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಿ. ಮರುಕ್ರಮಣ ಗಾತ್ರ-ಅವಲಂಬಿತ ನಿಲುಗಡೆಗಳಾಗಿ ಕಾಣುತ್ತದೆ, ಆದರೆ ಶ್ರೋತೃ ದೋಷ ಎರಡೂ ಗಾತ್ರಗಳನ್ನು ಸಮಾನವಾಗಿ ನಿಲ್ಲಿಸುತ್ತದೆ.

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