ಫೇಲ್‌ಓವರ್ ಪರೀಕ್ಷೆ: ಸ್ಥಾಪಿತ TCP ಸ್ಟ್ರೀಮ್ ಉಳಿಯುತ್ತದೆಯೇ?

ಬ್ಯಾಕಪ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬ ವಾಕ್ಯದೊಳಗೆ ಎರಡು ಫಲಿತಾಂಶಗಳು ಅಡಗಿವೆ. ಹೊಸ ವಿನಂತಿ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಅದು ಮರುಪ್ರಾಪ್ತಿ. ಈಗಾಗಲೇ ನಡೆಯುತ್ತಿರುವ ವರ್ಗಾವಣೆ ಮುಂದುವರಿಯುತ್ತದೆ, ಅದು ನಿರಂತರತೆ. ಇವು ಬೇರೆ ಬೇರೆ ಭರವಸೆಗಳು, ಮತ್ತು ಹೆಚ್ಚಿನ ಫೇಲ್‌ಓವರ್ ವಿನ್ಯಾಸಗಳು ಮೊದಲನೆಯದನ್ನು ನೀಡುತ್ತವೆ ಆದರೆ ಎರಡನೆಯದು ಸದ್ದಿಲ್ಲದೆ ಸಮಯ ಮೀರಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆಯನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ನಿಮಗೆ ಯಾವುದು ಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ, ಮತ್ತು ಅವುಗಳನ್ನು ಪ್ರತ್ಯೇಕಿಸಬಲ್ಲಂತೆ ಪರೀಕ್ಷೆಯನ್ನು ಬರೆಯಿರಿ.

ಒಂದೇ ಯಶಸ್ಸಿನಂತೆ ಕಾಣುವ ಎರಡು ಫಲಿತಾಂಶಗಳು

10.90.0.42 ನಲ್ಲಿರುವ ಕ್ಲೈಂಟ್‌ಗೆ 198.51.100.20:443 ಗೆ ಸಂಪರ್ಕವಿದೆ ಎಂದು ಊಹಿಸಿ. ಪ್ರಾಥಮಿಕ ಎಕ್ಸಿಟ್ ಅದನ್ನು ಒಂದು ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ಗೆ ಅನುವಾದಿಸುತ್ತದೆ, ಮತ್ತು ಬ್ಯಾಕಪ್ ಎಕ್ಸಿಟ್ ಅದನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಅನುವಾದಿಸುತ್ತದೆ. ಕ್ಲೈಂಟ್‌ನ ಆಂತರಿಕ ವಿಳಾಸ ಎಂದಿಗೂ ಬದಲಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಜನರು ಸಂಪರ್ಕ ಉಳಿಯುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುತ್ತಾರೆ.

ಸರ್ವರ್ ಆಂತರಿಕ ವಿಳಾಸವನ್ನು ನೋಡುವುದಿಲ್ಲ. ಅದು ಅನುವಾದಿತ ಅಂತ್ಯಬಿಂದುವನ್ನು ನೋಡುತ್ತದೆ, ಮತ್ತು ಸ್ವಿಚ್ ನಂತರ ಆ ಬಿಂದು ಬೇರೆಯಾಗಿರುತ್ತದೆ.

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

ಎಕ್ಸಿಟ್ ಬದಲಾದಾಗ ಸರ್ವರ್ ಏನನ್ನು ನೋಡುತ್ತದೆ

TCP ಸಂಪರ್ಕವನ್ನು ಅದರ ನಾಲ್ಕು-ಅಂಶಗಳಿಂದ ಗುರುತಿಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಮೂಲ ವಿಳಾಸ ಅಥವಾ ಪೋರ್ಟ್ ಬದಲಾದರೆ ಸ್ವೀಕರಿಸುವ ಹೋಸ್ಟ್‌ಗೆ ಬೇರೆ ಸಂಪರ್ಕ ಉಂಟಾಗುತ್ತದೆ. ಸರ್ವರ್ ಗುರುತಿಸದ ಸಂಪರ್ಕದ ಮೇಲೆ ಹೊಸ ಮೂಲದಿಂದ ಬರುವ ಪ್ಯಾಕೆಟ್‌ಗಳನ್ನು ತಳ್ಳಿಹಾಕಲಾಗುತ್ತದೆ ಅಥವಾ ಮರುಹೊಂದಿಸುವಿಕೆಯಿಂದ ಉತ್ತರಿಸಲಾಗುತ್ತದೆ. VPN ಕ್ಲೈಂಟ್‌ನ ವಿಳಾಸದಲ್ಲಿ ಈ ಬದಲಾವಣೆಯುದ್ದಕ್ಕೂ ಸಂಬಂಧವನ್ನು ಉಳಿಸುವ ಯಾವುದೂ ಇಲ್ಲ.

ಸ್ಥಿತಿಯುಳ್ಳ ಫೇಲ್‌ಓವರ್ ಇದನ್ನು ತಪ್ಪಿಸಲು ಇದೆಯೇ, ಮತ್ತು ಅದು ಮುಂದುಗಡೆ ಮಾಡುವ ಸಾಧನಗಳ ನಡುವೆ ಅನುವಾದ ಸ್ಥಿತಿ ಮತ್ತು ಸಂಪರ್ಕ ಸ್ಥಿತಿಯನ್ನು ವಿನಿಮಯ ಮಾಡುವ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಇದು ಜೋಡಿಯ ಗುಣ, ಸುರಂಗದ್ದಲ್ಲ, ಮತ್ತು ಊಹಿಸುವ ಬದಲು ವಿನ್ಯಾಸ ಮಾಡಿ ಪರೀಕ್ಷಿಸಬೇಕು.

ಯಾರಿಗೂ ನಿರಂತರತೆಯ ಭರವಸೆ ನೀಡುವ ಮೊದಲು ಜೋಡಿ ನಿಜವಾಗಿ ಸ್ಥಿತಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಕೆಳಗಿನ ಆದೇಶಗಳು ಎರಡೂ ಕಡೆಗಳ ಪ್ರಸ್ತುತ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುತ್ತವೆ.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

ಒಂದೇ ಸಾರ್ವಜನಿಕ ವಿಳಾಸ ಏಕೆ ಸಾಕಾಗುವುದಿಲ್ಲ

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

RFC 3022 ವಿಳಾಸ ಅನುವಾದವನ್ನು ವಿವರಿಸುತ್ತದೆ ಮತ್ತು ಅನುವಾದ ಮಾಡುವ ಸಾಧನಗಳ ನಡುವಿನ ಸ್ಥಿತಿ ವಿನಿಮಯವನ್ನು ಬ್ಯಾಕಪ್ ವಿನ್ಯಾಸದ ಭಾಗವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ. ತೇಲುವ ವಿಳಾಸ ಅಥವಾ ನಕಲು ಮಾಡಿದ ಪ್ರೊಫೈಲ್ ಸಂರಚನೆಯನ್ನು ಸರಿಸುತ್ತದೆ, ಸ್ಥಿತಿಯನ್ನು ಸರಿಸುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ಬ್ಯಾಕಪ್ ಮೂಲಕ ಮಾತ್ರ ಪಿಂಗ್ ಮಾಡುವ ಪರೀಕ್ಷೆ ಬಹಳ ಕಡಿಮೆ ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಪಿಂಗ್‌ಗೆ ಕಳೆದುಕೊಳ್ಳಲು ಸಂಪರ್ಕ ಸ್ಥಿತಿ ಇಲ್ಲ.

ಅಗತ್ಯ ಎಷ್ಟು ಬಲವಾಗಿದೆ ಎಂದು ನಿರ್ಧರಿಸಿ

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

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

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

ಹಳೆಯ ಸ್ಟ್ರೀಮ್ ಮತ್ತು ಹೊಸ ವಿನಂತಿಯನ್ನು ಪರಿಶೀಲಿಸಿ

ಪ್ರಾಥಮಿಕ ಮಾರ್ಗದ ಮೂಲಕ ಹಾನಿಕರವಲ್ಲದ ದೀರ್ಘ ವರ್ಗಾವಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸಿ, ನಂತರ ಅದೇ ಸೇವೆಗೆ ಪ್ರತ್ಯೇಕ ಹೊಸ ವಿನಂತಿ ಕಳುಹಿಸಿ. ಅನ್ವಯ ಸಂದರ್ಭ, ಗಮನಿಸಿದ ಎಕ್ಸಿಟ್ ವಿಳಾಸ ಮತ್ತು ಸಮಯವನ್ನು ದಾಖಲಿಸಿ. ಅನುಮೋದಿತ ರೀತಿಯಲ್ಲಿ ಪ್ರಾಥಮಿಕವನ್ನು ಮುರಿಯಿರಿ ಮತ್ತು ಬ್ಯಾಕಪ್ ಮೂಲಕ ಹೊಸ ವಿನಂತಿ ಕಳುಹಿಸುತ್ತಿರುವಾಗ ಮೂಲ ವರ್ಗಾವಣೆಯನ್ನು ಗಮನಿಸುತ್ತಿರಿ.

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

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

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