OpenConnect ಲಾಗಿನ್ ತಪ್ಪು ಪುಟಕ್ಕೆ ಬೀಳುತ್ತಿದೆಯೇ? ಮೊದಲು ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ
ಸಂಪೂರ್ಣ VPN URL ಸೈನ್-ಇನ್ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಆರಿಸುವ ಮಾರ್ಗವನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ. ಅದನ್ನು ಫಾರ್ಮ್ ಗುಂಪಿನಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ, ಮತ್ತು ಪ್ರೊಫೈಲ್ ಸಂಪಾದಿಸುವ ಮೊದಲು ಮರುನಿರ್ದೇಶನವನ್ನು ಪರಿಶೀಲಿಸಿ.
ನೀವು ಆನ್ಬೋರ್ಡಿಂಗ್ ಮೇಲ್ನಿಂದ ವಿಳಾಸವನ್ನು ಅಂಟಿಸುತ್ತೀರಿ, ಕ್ಲೈಂಟ್ ಗೇಟ್ವೇ ತಲುಪುತ್ತದೆ, ಮತ್ತು ಕಾಣಿಸಿಕೊಳ್ಳುವ ಲಾಗಿನ್ ಫಾರ್ಮ್ ಆಪರೇಟರ್ ವಿವರಿಸಿದ ಪಾಲುದಾರ ಪೋರ್ಟಲ್ ಅಲ್ಲ, ಸಾಮಾನ್ಯ ಪೋರ್ಟಲ್. ಯಾವುದೇ ದೋಷ ಕಾಣಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದೇ ಗೊಂದಲಕ್ಕೆ ಕಾರಣ: ಸುರಂಗವು ಮೇಲಕ್ಕೆ ಬರಬಹುದು ಕೂಡ, ಆದರೆ ತಪ್ಪು ಪ್ರವೇಶ ಬಿಂದುವಿನ ಹಿಂದೆ. ಆ URL ನಲ್ಲಿನ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತಿತ್ತು, ಮತ್ತು ಅದನ್ನು ಯಾವುದೇ ಬದಲಿಸಿದರೂ ಆ ಕೆಲಸವನ್ನು ಬಿಟ್ಟುಬಿಟ್ಟಿತು.
ಟಿಕೆಟ್ನಲ್ಲಿ ಒಂದೇ ಸ್ಟ್ರಿಂಗ್ ಆಗಿ ಬರುವ ಎರಡು ವಿಷಯಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ: ಸೇವೆಯನ್ನು ತಲುಪುವ ವಿಳಾಸ, ಮತ್ತು ದೃಢೀಕರಣ ಎಲ್ಲಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವ ಇನ್ಪುಟ್. ಮೊದಲನೆಯದನ್ನು ಸರಿಪಡಿಸಿ ಎರಡನೆಯದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು ಸರಿಯಾದ ಹೋಸ್ಟ್ಹೆಸರೂ ತಪ್ಪು ಲಾಗಿನ್ ನೀಡುವ ರೀತಿ.
ಫಾರ್ಮ್ ನೋಡುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಏನು ಕಳುಹಿಸುತ್ತದೆ
https://vpn.example.net/partners ನಂತಹ ವಿಳಾಸದೊಂದಿಗೆ ಕ್ಲೈಂಟ್ನ ಮೊದಲ ಕ್ರಿಯೆ ಬರಿಯ ಹೋಸ್ಟ್ಗೆ ಅಲ್ಲ, ಆ ಮಾರ್ಗಕ್ಕೆ HTTPS ವಿನಂತಿ. ಹಿಂತಿರುಗಿ ಬರುವುದು ಸಾಮಾನ್ಯವಾಗಿ ಸೈನ್-ಇನ್ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಮರುನಿರ್ದೇಶನ, ಅಥವಾ ಫಾರ್ಮ್ ಸ್ವತಃ. ಕೇವಲ vpn.example.net ಪಡೆದ ಕ್ಲೈಂಟ್ ಯಾವ ಡಿಫಾಲ್ಟ್ ಲ್ಯಾಂಡಿಂಗ್ ಪುಟವಿದ್ದರೂ ಅಲ್ಲಿಂದಲೇ ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಅದು ಬೇರೆ ಪೋರ್ಟಲ್, ಬೇರೆ ಗುಂಪು ಪಟ್ಟಿ, ಅಥವಾ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್ ನಿರೀಕ್ಷಿಸುವ ಪುಟವಾಗಿರಬಹುದು. ವ್ಯತ್ಯಾಸವು ಯಾವುದೇ ರುಜುವಾತು ಟೈಪ್ ಆಗುವ ಮೊದಲೇ ಪ್ರತಿಕ್ರಿಯೆ ಹೆಡರ್ಗಳಲ್ಲಿ ಕಾಣುತ್ತದೆ.
ಅದಕ್ಕೇ ಕೆಲಸ ಮಾಡುವ ಬ್ರೌಸರ್ ಟ್ಯಾಬ್ ಮತ್ತು ವಿಫಲವಾಗುವ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ ಒಂದೇ ಗೇಟ್ವೇಯನ್ನು ಹೆಸರಿಸಿಯೂ ಭಿನ್ನಾಭಿಪ್ರಾಯ ಹೊಂದಬಹುದು. ಬ್ರೌಸರ್ ಮಾರ್ಗವನ್ನು ಅನುಸರಿಸಿತು; ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಅದು ಎಂದೂ ಇರಲಿಲ್ಲ.
ಪರಸ್ಪರ ಬದಲಾಯಿಸಬಹುದಾದಂತೆ ಕಾಣುವ ಮತ್ತು ಇಲ್ಲದ ಎರಡು ಇನ್ಪುಟ್ಗಳು
OpenConnect ಆರಂಭಿಕ HTTPS ಮಾರ್ಗವನ್ನು --usergroup ಆಗಿ ಬಹಿರಂಗಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಕೈಪಿಡಿ ಪುಟ ಆ ಮಾರ್ಗವನ್ನು ಹೊತ್ತ ಸಂಪೂರ್ಣ URL ಅನ್ನು ಅದೇ ವಿನಂತಿಯ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಬರೆದ ರೂಪವೆಂದು ಪರಿಗಣಿಸುತ್ತದೆ. --authgroup ಪ್ರತ್ಯೇಕ ಆಯ್ಕೆ: ಅದು ಲಾಗಿನ್ ಫಾರ್ಮ್ ಒಳಗೆ ಗೇಟ್ವೇ ತೋರಿಸುವ ಪಟ್ಟಿಯಿಂದ ಒಂದು ನಮೂದನ್ನು ಆರಿಸುತ್ತದೆ. ಕೆಲವು ಪ್ರೋಟೋಕಾಲ್ಗಳು ಆ ನಮೂದನ್ನು ಗುಂಪು ಎನ್ನುತ್ತವೆ, ಇನ್ನು ಕೆಲವು ಡೊಮೇನ್ ಅಥವಾ ಗೇಟ್ವೇ ಎನ್ನುತ್ತವೆ, ಮತ್ತು ಅಲ್ಲಿಯೇ ಎರಡು ಫ್ಲ್ಯಾಗ್ಗಳು ಗೊಂದಲಕ್ಕೀಡಾಗುತ್ತವೆ.
ಸೇವೆಗೆ ಕಾನೂನುಬದ್ಧವಾಗಿ ಎರಡೂ ಬೇಕಾಗಬಹುದು. ಮಾರ್ಗ ನಿಮ್ಮನ್ನು ಸರಿಯಾದ ಪೋರ್ಟಲ್ಗೆ ಕರೆದೊಯ್ಯಬಹುದು, ಆದರೆ ಫಾರ್ಮ್ ಇನ್ನೂ ಅದರ ಒಳಗಿನ ಗುಂಪುಗಳಲ್ಲಿ ಒಂದನ್ನು ಆರಿಸಲು ಕೇಳುತ್ತದೆ. ಪೋರ್ಟಲ್ ಹೆಸರನ್ನು ಗುಂಪಿನ ಹೆಸರಾಗಿ ನೀಡುವುದು, ಅಥವಾ ಅದಕ್ಕೆ ವಿರುದ್ಧವಾಗಿ, ಸ್ವೀಕರಿಸಿದಂತೆ ಕಾಣುವ ಮತ್ತು ನಂತರ ಅಧಿಕಾರ ನೀಡದ ಲಾಗಿನ್ ಉಂಟುಮಾಡುತ್ತದೆ, ಏಕೆಂದರೆ ಮೌಲ್ಯವು ವ್ಯಾಕರಣದೃಷ್ಟಿಯಿಂದ ಸರಿ ಮತ್ತು ಅರ್ಥದೃಷ್ಟಿಯಿಂದ ತಪ್ಪಾಗಿತ್ತು.
ಆಪರೇಟರ್ನಿಂದ ಪ್ರತಿ ಮೌಲ್ಯವನ್ನು ಅದರದೇ ಸಾಲಿನಲ್ಲಿ ಕೇಳಿ: ಪ್ರವೇಶ ಮಾರ್ಗ, ಫಾರ್ಮ್ ಆಯ್ಕೆ, ಮತ್ತು ಎರಡೂ ಅಗತ್ಯವೇ. ಲೇಬಲ್ಗಳು ಒಂದೇ ರೀತಿ ಕೇಳಿಸುತ್ತವೆ ಎಂದು ಒಂದರಿಂದ ಇನ್ನೊಂದನ್ನು ಅನುಮಾನಿಸಬೇಡಿ.
ಮಾರ್ಗವನ್ನು ಕತ್ತರಿಸುವುದು ಫಲಿತಾಂಶವನ್ನು ಏಕೆ ಬದಲಾಯಿಸುತ್ತದೆ
ಕೇವಲ ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ ಸ್ವೀಕರಿಸುವ ಕ್ಲೈಂಟ್ಗಳು ಹಲವು ಬಾರಿ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಲಕ್ಷಣವು ಅಪರೂಪವಾಗಿ ಕಠಿಣ ವೈಫಲ್ಯ. ಬದಲಾಗಿ ನೀವು ತಪ್ಪು ಲಾಗಿನ್ ಪುಟ, ಖಾಲಿ ಗುಂಪು ಪಟ್ಟಿ, ಆಪರೇಟರ್ ಪ್ರಕಟಿಸಿದ ಹೆಸರಿಗೆ ಇನ್ನು ಹೊಂದಿಕೆಯಾಗದ ಪ್ರಮಾಣಪತ್ರ ಹೆಸರು, ಅಥವಾ ನೀವು ಬಯಸಿದ ಸೇವೆಗೆ ಮಾರ್ಗವಿಲ್ಲದೆ ಮೇಲಕ್ಕೆ ಬರುವ ಸುರಂಗ ಪಡೆಯುತ್ತೀರಿ. ಇವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ ಬೇರೆ ಪದರದಲ್ಲಿ ಕುಳಿತಿದೆ, ಮತ್ತು ಹೋಸ್ಟ್ಹೆಸರೆಂದು ದಾಖಲಾದ ಕ್ಷೇತ್ರದಲ್ಲಿ ಉದ್ದವಾದ ಸ್ಟ್ರಿಂಗ್ ಅಂಟಿಸಿ ಯಾವುದೂ ಸರಿಯಾಗುವುದಿಲ್ಲ. ಅವುಗಳಲ್ಲಿ ಎರಡನ್ನು ಹೊರಗಿನಿಂದ ಪ್ರತ್ಯೇಕಿಸಲೂ ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಎರಡೂ ಸರಳವಾಗಿ ಮುಂದುವರಿಯದ ಲಾಗಿನ್ ಫಾರ್ಮ್ ಆಗಿ ಬರುತ್ತವೆ.
ಹೋಸ್ಟ್ಹೆಸರನ್ನು IP ವಿಳಾಸದಿಂದ ಬದಲಾಯಿಸುವುದು ಪ್ರತ್ಯೇಕ ತಪ್ಪು, ಅದು ಹೆಚ್ಚಾಗಿ ಇದರೊಂದಿಗೆ ಪ್ರಯಾಣಿಸುತ್ತದೆ. ಹೆಸರಾಧಾರಿತ ಸೇವೆ ಆಯ್ಕೆ ಮತ್ತು ಪ್ರಮಾಣಪತ್ರ ಪರಿಶೀಲನೆ ಎರಡೂ ಹೆಸರನ್ನು ಅವಲಂಬಿಸಿವೆ, ಆದ್ದರಿಂದ ಸಂಖ್ಯಾತ್ಮಕ ವಿಳಾಸವು ಮಾರ್ಗ ಸ್ವರೂಪದ ಸಮಸ್ಯೆಯನ್ನು TLS ದೋಷವಾಗಿ ಪರಿವರ್ತಿಸಬಹುದು.
ಬ್ರೌಸರ್ ವಿಳಾಸಗಳು ಮಾರ್ಗಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನೂ ಹೊತ್ತೊಯ್ಯುತ್ತವೆ. ಸೆಷನ್ ಗುರುತಿಸುವಿಕೆಗಳು, ಮರುನಿರ್ದೇಶನ ಗುರಿಗಳು, ಭಾಷಾ ಪೂರ್ವಪ್ರತ್ಯಯಗಳು ಮತ್ತು ತಾತ್ಕಾಲಿಕ ಸೈನ್-ಇನ್ ನಿಯತಾಂಕಗಳು ಎಲ್ಲವೂ ವಿಳಾಸ ಪಟ್ಟಿಯಲ್ಲಿ ಕಾಣಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಉಳಿಸಿದ ಕ್ಲೈಂಟ್ ಪ್ರೊಫೈಲ್ಗೆ ಸೇರಿದ್ದಲ್ಲ.
ಬೇರೆ ಏನನ್ನೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ದೃಢೀಕರಿಸಿ
ನಿಮಗೆ ನೀಡಿದ ಮಾರ್ಗದ ಹೆಡರ್ಗಳನ್ನು ಓದಿ. curl -sS -o /dev/null -D - https://vpn.example.net/partners ನಂತಹ ವಿನಂತಿ ಮರುನಿರ್ದೇಶನವನ್ನು ಅನುಸರಿಸದೆ ಸ್ಥಿತಿ ಸಾಲು ಮತ್ತು ಯಾವುದೇ Location ಹೆಡರ್ ಅನ್ನು ಮುದ್ರಿಸುತ್ತದೆ. ಹೆಸರಿಸಿದ ಸೈನ್-ಇನ್ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ತೋರಿಸುವ 302 ಮಾರ್ಗವು ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ; 404 ಎಂದರೆ ಆಪರೇಟರ್ನ ವಿಳಾಸ ಬಳಕೆಯಲ್ಲಿಲ್ಲ.
ನಂತರ ಅದೇ ಪ್ರವೇಶ ಬಿಂದುವನ್ನು ಅನುಮೋದಿತ ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಮರುಸೃಷ್ಟಿಸಿ, ಉದಾಹರಣೆಗೆ openconnect --usergroup=partners vpn.example.net, ಮತ್ತು ಯಾವ ಫಾರ್ಮ್ ಕಾಣಿಸುತ್ತದೆ ಎಂದು ನೋಡಿ. ಫಾರ್ಮ್ ಸರಿಯಾಗಿದ್ದರೂ ಸುರಂಗ ವಿಫಲವಾದರೆ, ಮಾರ್ಗ ಎಂದೂ ಸಮಸ್ಯೆಯಾಗಿರಲಿಲ್ಲ ಮತ್ತು ಮುಂದಿನ ನಿಲ್ದಾಣ ನೀತಿ ಅಥವಾ ಮಾರ್ಗನಿರ್ದೇಶನ.
ಟಿಕೆಟ್ನಲ್ಲಿ ಹೋಸ್ಟ್ಹೆಸರು, ಪೋರ್ಟ್, ಪ್ರೋಟೋಕಾಲ್, ಪ್ರವೇಶ ಮಾರ್ಗ ಮತ್ತು ಫಾರ್ಮ್ ಆಯ್ಕೆಯನ್ನು ಐದು ಪ್ರತ್ಯೇಕ ಕ್ಷೇತ್ರಗಳಾಗಿ ದಾಖಲಿಸಿ. ಆ ಪಟ್ಟಿಯೇ ಮುಂದಿನ ಎಂಜಿನಿಯರ್ಗೆ ತಲುಪಲಾಗದ ಸರ್ವರ್, TLS ನಿರಾಕರಣೆ, ನಿರಾಕರಿಸಿದ ಆಯ್ಕೆ ಮತ್ತು ಅಗತ್ಯ ಮಾರ್ಗಗಳಿಲ್ಲದೆ ಮೇಲಕ್ಕೆ ಬಂದ ಸುರಂಗವನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.