HTTPS ಮೂಲಕ ಮೂಲ ದೃಢೀಕರಣ ಮತ್ತು IPsec: ಪ್ರತಿಯೊಂದೂ ಏನನ್ನು ರಕ್ಷಿಸುತ್ತದೆ

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

ಮೊದಲ ಪರಿಶೀಲನಾ ಬಿಂದು: ನೀವು ಮಾತನಾಡಲು ಬಯಸಿದ ಸರ್ವರ್ ಇದೇನಾ

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

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

ಎರಡನೇ ಪರಿಶೀಲನಾ ಬಿಂದು: 401 ವಿನಿಮಯದಲ್ಲಿ ವಾಸ್ತವವಾಗಿ ಏನು ಪ್ರಯಾಣಿಸುತ್ತದೆ

HTTP ಮೂಲ ದೃಢೀಕರಣವು ಬಳಕೆದಾರ ಗುರುತು ಮತ್ತು ಗುಪ್ತಪದವನ್ನು ಹೆಡರ್ನಲ್ಲಿ ಕಳುಹಿಸುತ್ತದೆ, Base64 ನಿಂದ ಎನ್ಕೋಡ್ ಮಾಡಲಾಗಿದೆ, ವಿವರಿಸಿದಂತೆ RFC 7617 ನಲ್ಲಿ. Authorization: Basic dXNlcjpwYXNz ಅದರ ರೂಪ; ಎನ್ಕೋಡಿಂಗ್ ಅನ್ನು ವಿನಂತಿಯನ್ನು ಓದಬಲ್ಲ ಯಾರಾದರೂ ಹಿಂತಿರುಗಿಸಬಹುದು, ಆದ್ದರಿಂದ ಎಲ್ಲಾ ಗೋಪ್ಯತೆ ಕೆಳಗಿನ ಸಾಗಣೆಯಿಂದ ಬರುತ್ತದೆ. curl -v WWW-Authenticate: Basic ಸವಾಲು ಮತ್ತು ನೀವು ಹಿಂತಿರುಗಿಸುವ ಹೆಡರ್ ಎರಡನ್ನೂ ತೋರಿಸುತ್ತದೆ.

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

ಆ ಮಾರ್ಗದಲ್ಲಿ IPsec ಸುರಂಗ ಎಲ್ಲಿ ಕುಳಿತಿದೆ

ಈಗ ಬ್ರೌಸರ್ನಿಂದ ಹೊರಕ್ಕೆ ನಡೆಯಿರಿ. ಗೇಟ್ವೇಯಿಂದ ಗೇಟ್ವೇವರೆಗಿನ IPsec ಸುರಂಗ ಎರಡು ಭದ್ರತಾ ಗೇಟ್ವೇಗಳ ನಡುವಿನ ಆಯ್ದ ಸಂಚಾರವನ್ನು ರಕ್ಷಿಸುತ್ತದೆ, ನಿಮ್ಮ ಲ್ಯಾಪ್ಟಾಪ್ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಕ್ರಿಯೆಯ ನಡುವೆ ಅಲ್ಲ. ಸುರಂಗ ಮೋಡ್ನ ESP ಮೂಲ ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸುತ್ತುತ್ತದೆ, ಗೇಟ್ವೇಗಳು ಅದನ್ನು ಗೂಢಲಿಪೀಕರಿಸಿ ದೃಢೀಕರಿಸುತ್ತವೆ, ಮತ್ತು ಒಳಗಿನ ವಿಳಾಸಗಳು ಉಳಿಯುತ್ತವೆ ಇದರಿಂದ ದೂರದ ಬದಿ ವಿನಂತಿಯನ್ನು ಅಪ್ಲಿಕೇಶನ್ಗೆ ರೂಟ್ ಮಾಡಬಹುದು.

ಆಯ್ಕೆಯೇ ಜನರು ಎಡವುವ ಭಾಗ. ನೀತಿ ಆಧಾರಿತ ಸುರಂಗಗಳು ಸಂಚಾರ ಆಯ್ಕೆಗಾರರನ್ನು ಬಳಸುತ್ತವೆ, ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ ಪಟ್ಟಿಗಳಾಗಿ ವ್ಯಕ್ತಪಡಿಸಲಾಗುತ್ತದೆ, ಯಾವ ಪ್ಯಾಕೆಟ್ಗಳು ಸುರಂಗವನ್ನು ಪ್ರವೇಶಿಸುತ್ತವೆ ಎಂದು ನಿರ್ಧರಿಸಲು. ಮಾರ್ಗ ಆಧಾರಿತ ಸುರಂಗಗಳು ಬದಲಿಗೆ ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್ ಮತ್ತು ರೂಟಿಂಗ್ ಕೋಷ್ಟಕವನ್ನು ಬಳಸುತ್ತವೆ. Linux ನಲ್ಲಿ ip xfrm policy ಆಯ್ಕೆಗಾರರನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು ip xfrm state ಸ್ಥಾಪಿತ ಭದ್ರತಾ ಸಂಘಗಳನ್ನು ತೋರಿಸುತ್ತದೆ; ಫೈರ್ವಾಲ್ ಸಾಧನದಲ್ಲಿ ಸಮಾನವಾದದ್ದು ಸುರಂಗದ SA ಕೋಷ್ಟಕ ಮತ್ತು ಪ್ಯಾಕೆಟ್ ಟ್ರೇಸರ್.

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

ವಿಫಲತೆಯನ್ನು ವರದಿ ಮಾಡಿದ ಪದರದಲ್ಲೇ ಓದಿ

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

ಪ್ರತಿ ಪದರವು ಉತ್ಪಾದಿಸುವ ಸಾಕ್ಷ್ಯವನ್ನು ಬಳಸಿ: ಸ್ಥಿತಿ ಮತ್ತು ಹೆಡರ್ಗಳಿಗೆ ಬ್ರೌಸರ್ನ ನೆಟ್ವರ್ಕ್ ಪ್ಯಾನೆಲ್, ಪ್ರಮಾಣಪತ್ರ ಸರಪಳಿಗೆ openssl s_client -connect host:443, ಸುರಂಗ ಸಂಚಾರಕ್ಕೆ ಗೇಟ್ವೇಯ SA ಕೌಂಟರ್ಗಳು ಮತ್ತು ಲಾಗ್ಗಳು, ಮತ್ತು ಖಾತೆ ನಿರ್ಧಾರಕ್ಕೆ ಅಪ್ಲಿಕೇಶನ್ ಲಾಗ್. ಎರಡು ಪದರಗಳು ಒಟ್ಟಿಗೆ ದೋಷಗಳನ್ನು ವರದಿ ಮಾಡಿದಾಗ, ಮೊದಲು ಕೆಳಗಿನದನ್ನು ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಸತ್ತ ಸುರಂಗ ದೃಢೀಕರಣ ವಿಫಲತೆಯನ್ನು ಸುಲಭವಾಗಿ ಮುಚ್ಚಿಡಬಹುದು ಮತ್ತು ಇದಕ್ಕೆ ವಿರುದ್ಧವೂ ಸಹ.

ಒಂದು ಸೇವೆಯನ್ನು ಆರಂಭದಿಂದ ಕೊನೆಯವರೆಗೆ ನಕ್ಷೆ ಮಾಡಿ

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

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

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