OpenConnect ಲಾಗಿನ್ ಕುಕಿಯನ್ನು ಸುರಂಗವಾಗಿ ಹೇಗೆ ಬದಲಿಸುತ್ತದೆ?

OpenConnect ಎರಡು ಪ್ರತ್ಯೇಕ ವಿನಿಮಯಗಳನ್ನು ಒಂದೇ ಅಲ್ಪಾಯುಷಿ ಮೌಲ್ಯದಿಂದ ಬೆಸೆಯುತ್ತದೆ: ವೆಬ್ ಲಾಗಿನ್ ಮತ್ತು VPN ಸುರಂಗ. ಮೊದಲ ವಿನಿಮಯ ಸಾಮಾನ್ಯ HTTPS: ರುಜುವಾತುಗಳು, SAML ಪ್ರಯಾಣ ಅಥವಾ ಟೋಕನ್ ಗೇಟ್ವೇಗೆ ಹೋಗುತ್ತವೆ ಮತ್ತು ಉತ್ತರವು ದೃಢೀಕರಣ ಕುಕಿಯನ್ನು ತರುತ್ತದೆ. ಎರಡನೇ ವಿನಿಮಯ ಆ ಕುಕಿಯನ್ನು ಅದೇ ಗೇಟ್ವೇಗೆ ವೆಬ್ ಹಂತ ಈಗಾಗಲೇ ನಡೆದಿದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಾಗಿ ಒಪ್ಪಿಸುತ್ತದೆ, ಮತ್ತು ಆಗಷ್ಟೇ ಸುರಂಗ ಮೇಲೆದ್ದು ಬರುತ್ತದೆ.

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

ಕ್ಲೈಂಟ್ ಮತ್ತು ಗೇಟ್ವೇ ಕ್ರಮವಾಗಿ ಏನನ್ನು ವಿನಿಮಯ ಮಾಡುತ್ತವೆ

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

ಎರಡನೇ ಹಂತ ಆ ಕುಕಿಯನ್ನು ಜೋಡಿಸಿಕೊಂಡು ಗೇಟ್ವೇಯ VPN ಅಂತ್ಯಬಿಂದುವಿಗೆ ಕಳುಹಿಸುವ CONNECT ವಿನಂತಿ. ಗೇಟ್ವೇ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ ವಿಳಾಸ ನೀಡುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ TLS ಮೇಲೆ CSTP ಆರಂಭಿಸುತ್ತದೆ, ಸೆಷನ್ ಇದ್ದಾಗ DTLS ಐಚ್ಛಿಕ ವೇಗದ ದತ್ತಾಂಶ ಮಾರ್ಗವಾಗಿರುತ್ತದೆ. ಸುರಂಗದ ನಿಯತಾಂಕಗಳು, ಮಾರ್ಗಗಳು, DNS ಸಂಯೋಜನೆಗಳು ಮತ್ತು ಸೆಷನ್ನ ಸಂಚಾರ ಕೀಲಿಗಳು ಸ್ಥಾಪನೆಯಾಗುವುದು ಈ ಹಂತದಲ್ಲೇ. ಕುಕಿ ಕ್ಲೈಂಟನ್ನು ಬಾಗಿಲಿನ ಮೂಲಕ ದಾಟಿಸಿತು; ಅದು ಏನನ್ನೂ ಗೂಢಲಿಪೀಕರಿಸಲಿಲ್ಲ.

ಈ ಕ್ರಮವೇ openconnect --authenticate ಏಕೆ ಇದೆ ಎಂಬುದನ್ನು ವಿವರಿಸುತ್ತದೆ. ಅದನ್ನು ಚಲಾಯಿಸಿ, ಅದು ವೆಬ್ ಹಂತವನ್ನು ನಿರ್ವಹಿಸಿ, COOKIE, HOST, CONNECT_URL ಮತ್ತು FINGERPRINT ಮುಂತಾದ ಶೆಲ್ ಚರಗಳ ಸಣ್ಣ ಬ್ಲಾಕ್ ಮುದ್ರಿಸಿ, ಯಾವುದೇ ಸುರಂಗ ನಿರ್ಮಾಣವಾಗುವ ಮೊದಲೇ ನಿರ್ಗಮಿಸುತ್ತದೆ. ನಂತರ ಸುತ್ತು ಸ್ಕ್ರಿಪ್ಟ್ ಆ ಮೌಲ್ಯಗಳೊಂದಿಗೆ ನಿಜವಾದ ಸಂಪರ್ಕ ಆರಂಭಿಸಬಹುದು, ಮತ್ತು ತಲೆ ಇಲ್ಲದ ಅಥವಾ ಎರಡು ಕಂಟೇನರ್ ನಿಯೋಜನೆಗೆ ಬೇಕಾಗುವ ವಿಭಜನೆ ಅದೇ.

ಕುಕಿ ಸೆಷನ್ನ ವಾಹಕ, ಕೀಲಿ ಅಲ್ಲ

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

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

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

ಪ್ರತಿಗಳನ್ನು ಬಿಡದೆ ಕುಕಿ ರವಾನಿಸುವುದು

Linux ನಲ್ಲಿ ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ಯಾಂತ್ರಿಕ ಹಸ್ತಾಂತರ ಪ್ರಮಾಣಿತ ಇನ್ಪುಟ್. --cookie-on-stdin ಮೌಲ್ಯವನ್ನು stdin ನಿಂದ ಓದುತ್ತದೆ, ಆದ್ದರಿಂದ ಕುಕಿ ಪ್ರಕ್ರಿಯೆಯ ಆರ್ಗ್ಯುಮೆಂಟ್ ಪಟ್ಟಿಯಲ್ಲಿ ಎಂದೂ ಕಾಣಿಸುವುದಿಲ್ಲ, ಅಲ್ಲಿ ಯಾವುದೇ ಸ್ಥಳೀಯ ಬಳಕೆದಾರರು ಅದನ್ನು ps ನಿಂದ ಓದಬಹುದು. ಒಂದು ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ದೃಢೀಕರಿಸಿ ಇನ್ನೊಂದರಲ್ಲಿ ಸುರಂಗಕ್ಕೆ ಆಹಾರ ನೀಡುವ ಪೈಪ್ಲೈನ್ ಮೌಲ್ಯವನ್ನು ಕಡತ ಅಥವಾ ಪರಿಸರ ಚರದಲ್ಲಿ ಅಲ್ಲ, ಪೈಪ್ನಲ್ಲಿ ಇಡುತ್ತದೆ.

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

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

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

ಎರಡನೇ ಹಂತದಲ್ಲಿ ಪರಿಶೀಲನೆ ಮತ್ತು ಅವಧಿ ಮುಗಿಯುವಿಕೆ

ಎರಡನೇ ಹಂತ ಇನ್ನೂ ಸರ್ವರ್ ಅನ್ನು ಪರಿಶೀಲಿಸಬೇಕು. --authenticate ಮುದ್ರಿಸುವ FINGERPRINT pin-sha256: ರೂಪದ ಪ್ರಮಾಣಪತ್ರ ಪಿನ್, ಮತ್ತು ಅದನ್ನು --servercert ಜೊತೆ ಸುರಂಗದ ಕರೆಗೆ ನೀಡಿದರೆ ಪರಿಶೀಲನೆ ನೀವು ದೃಢೀಕರಿಸಿದ ಗೇಟ್ವೇಗೆ ಲಂಗರು ಹಾಕಿಕೊಂಡಿರುತ್ತದೆ. ಸ್ಕ್ರಿಪ್ಟ್ ಸರಳಗೊಳಿಸಲು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ನಿಲ್ಲಿಸುವುದು ಕುಕಿ ಉದ್ದೇಶಿತ ಹೋಸ್ಟ್ಗೆ ಹಸ್ತಾಂತರವಾಗುತ್ತಿದೆ ಎಂಬ ಏಕೈಕ ಸಾಕ್ಷ್ಯವನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.

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

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