OpenConnect ಕಡಿತಗೊಂಡ VPN ಅನ್ನು ಎಷ್ಟು ಕಾಲ ಮತ್ತೆ ಪ್ರಯತ್ನಿಸಬೇಕು?

--reconnect-timeout ಒಂದು ಸಂಕುಚಿತ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುತ್ತದೆ: ಸುರಂಗ ಬಿದ್ದ ನಂತರ, ಈ ಕ್ಲೈಂಟ್ ಪ್ರಕ್ರಿಯೆ ಬಿಟ್ಟು ಹೊರಡುವ ಮೊದಲು ಎಷ್ಟು ಕಾಲ ಪ್ರಯತ್ನಿಸುತ್ತದೆ. OpenConnect ಕೈಪಿಡಿ ಪುಟ ಆ ಆಯ್ಕೆಯನ್ನು ಕಳೆದುಹೋದ ಲಿಂಕ್ ಅಥವಾ ಉತ್ತರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಪೀರ್ ನಂತರದ ಮರುಪ್ರಯತ್ನಗಳಿಗೆ 300 ಸೆಕೆಂಡುಗಳ ದಾಖಲಿತ ಡೀಫಾಲ್ಟ್ ಜೊತೆ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಈ ಸಂಖ್ಯೆ ಒಂದು ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ಗೆ ಗಡುವು, VPN ತಲುಪಬಹುದಾಗಿ ಉಳಿಯುತ್ತದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಇದು ಪ್ರಕ್ರಿಯೆಯನ್ನು ಜೀವಂತವಾಗಿಡುವ ನೀತಿಯೂ ಅಲ್ಲ, ಮತ್ತು ಹೆಚ್ಚಿನ ಗೊಂದಲ ಇಲ್ಲಿಂದಲೇ ಆರಂಭವಾಗುತ್ತದೆ.

ಎರಡನೇ ಕಾರ್ಯವಿಧಾನ ಮೇಲೆ ಕುಳಿತಾಗ ಗೊಂದಲ ಹೆಚ್ಚುತ್ತದೆ. ಕ್ಲೈಂಟ್ ಮರುಪ್ರಾರಂಭಿಸುವ ಮೇಲ್ವಿಚಾರಕ, ಗೇಟ್ವೇಗೆ ಪಿಂಗ್ ಮಾಡುವ ಪರೀಕ್ಷಕ ಮತ್ತು ಒಳಗೊಂಡ ಮರುಪ್ರಯತ್ನ ಕಿಟಕಿ ಎಲ್ಲವೂ ಒಂದೇ ವೈಫಲ್ಯಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು, ನಂತರ ಘಟನೆ ಯಾರೂ ಸರಿಪಡಿಸಲಾಗದ ಮೂರು ಕಾಲರೇಖೆಗಳನ್ನು ನೀಡುತ್ತದೆ.

ಮರುಸಂಪರ್ಕ ಕಿಟಕಿ ವಾಸ್ತವವಾಗಿ ಏನನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತದೆ

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

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

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

ಮೇಲ್ವಿಚಾರಕ ಮರುಪ್ರಾರಂಭಗಳು ಮತ್ತು ಕ್ಲೈಂಟ್ ಮರುಪ್ರಯತ್ನಗಳು ಎರಡು ಪದರಗಳು

ಚಾಲನೆಯಲ್ಲಿರುವ ಕ್ಲೈಂಟ್ ತನ್ನ ಕಿಟಕಿಯನ್ನು ಖರ್ಚು ಮಾಡಲಿ, ಮತ್ತು ಸೇವಾ ನಿರ್ವಾಹಕ ನಿರ್ಗಮನಕ್ಕೆ ಪ್ರತಿಕ್ರಿಯಿಸಲಿ. systemd ಅಡಿಯಲ್ಲಿ ಮರುಪ್ರಾರಂಭ ನೀತಿಯೊಂದಿಗೆ ಮುಂಭಾಗದ ಕ್ಲೈಂಟ್ ನಿಖರವಾಗಿ ಆ ವಿಭಜನೆಯನ್ನು ನೀಡುತ್ತದೆ: ಸೀಮಿತ ಅವಧಿಗೆ ಪ್ರಯತ್ನಗಳು, ನಂತರ ಒಂದು ಮರುಪ್ರಾರಂಭ ನಿರ್ಧಾರ. ಫಲಿತಾಂಶವು ನಂತರವೂ ಮರುನಿರ್ಮಿಸಬಹುದಾದ ಒಂದೇ ಕಾಲರೇಖೆ.

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

sudo openconnect --background --pid-file=/run/openconnect/vpn.pid \
  --reconnect-timeout=180 \
  --user=<account> https://vpn.example.edu

ಆ ಸಾಲಿನಲ್ಲಿ ಎರಡು ವಿವರಗಳಿಗೆ ತೂಕವಿದೆ. --background ಪ್ರಕ್ರಿಯೆಯನ್ನು ಬೇರ್ಪಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ pid ಫೈಲ್ ಅದರ ಮೇಲಿನ ಏಕೈಕ ನಂಬಲರ್ಹ ಹಿಡಿತವಾಗುತ್ತದೆ, ಮತ್ತು ಕಾಲಮಿತಿ ಅದೇ ಪ್ರಕ್ರಿಯೆ ಬದುಕಿರುವವರೆಗೆ ಮಾತ್ರ ಖರ್ಚಾಗುತ್ತದೆ; ಅದನ್ನು ಕೊಲ್ಲುವ ಮೇಲ್ವಿಚಾರಕ ಮುಂದುವರಿಯಲು ಯಾವುದೇ ಬಜೆಟ್ ಬಿಡುವುದಿಲ್ಲ.

ಉದ್ದೇಶಪೂರ್ವಕ ಸಂಪರ್ಕ ಕಡಿತಗಳಿಗೆ ತಮ್ಮದೇ ಸಂಕೇತ ಬೇಕು. ಯೋಜಿತ ವಿರಾಮ ಮತ್ತು ನಿಜವಾದ ಅಡಚಣೆ ಮುಗ್ಧ ವೀಕ್ಷಕನಿಗೆ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಎರಡೂ «ಸಂಪರ್ಕವಿಲ್ಲ» ಎಂದು ಓದಲ್ಪಡುತ್ತವೆ. ವಿರಾಮವನ್ನು ಮೇಲ್ವಿಚಾರಕದ ನಿಲ್ಲಿಸುವ ಕಾರ್ಯಾಚರಣೆ ಅಥವಾ ಸುತ್ತುಗಟ್ಟುವಿಕೆ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವ ಗುರುತಿನ ಮೂಲಕ ನಡೆಸಿ, ಉದ್ದೇಶಪೂರ್ವಕ ನಿಲುಗಡೆ ಯಾರೂ ಕೇಳದ ಮರುಪ್ರಾರಂಭವನ್ನು ಪ್ರಚೋದಿಸದಂತೆ.

ಹಸ್ತಾಂತರವು ಮರುಪ್ರಯತ್ನ ಲೂಪ್ನೊಂದಿಗೆ ಸ್ಪರ್ಧಿಸದಂತೆ ತಡೆಯುವುದು

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

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

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

ಅಡಚಣೆಯ ಸಮಯದಲ್ಲಿ ಮತ್ತು ನಂತರ ಏನನ್ನು ಪರಿಶೀಲಿಸಬೇಕು

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

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

curl -sS --max-time 5 -o /dev/null -w '%{http_code}\n' https://intranet.example.internal/health
cat /run/openconnect/vpn.pid
ps -o pid,etime,cmd -p "$(cat /run/openconnect/vpn.pid)"

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

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