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

ಪಟ್ಟಿ ಒಂದು ಇನ್ಪುಟ್, ಕ್ರಿಯೆಯಲ್ಲ

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

ಪಟ್ಟಿಯೇ ಬಿಡುಗಡೆ ದಿನಾಂಕ ಮತ್ತು ಮುಂದಿನ ನವೀಕರಣ ದಿನಾಂಕವಿರುವ ಸಹಿ ಮಾಡಿದ ವಸ್ತು. ಸಂಬಂಧವಿಲ್ಲದ ಪಟ್ಟಿ, ಬೇರೆ ಪ್ರಾಧಿಕಾರ ಸಹಿ ಮಾಡಿದ ಪಟ್ಟಿ ಅಥವಾ ಮುಂದಿನ ನವೀಕರಣ ದಿನಾಂಕ ಕಳೆದಿರುವ ಪಟ್ಟಿ ಪ್ರಸ್ತುತ ಪಟ್ಟಿಗೆ ಬದಲಿಯಲ್ಲ, ಮತ್ತು ಹಳೆಯ ಪಟ್ಟಿಯನ್ನು ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆಯೇ ಅಥವಾ ಸದ್ದಿಲ್ಲದೆ ಸ್ವೀಕರಿಸಲಾಗುತ್ತದೆಯೇ ಎಂಬುದು ನಿಯೋಜನೆಯನ್ನು ಅವಲಂಬಿಸಿದೆ.

ಹೊಸ ಸಂಪರ್ಕ ಮತ್ತು ಚಾಲಿತ ಸೆಷನ್

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

SituationWhat the list doesWhen it applies
Fresh connectionBlocks the handshakeAt verification, immediately
RenegotiationBlocks the new exchangeAt the next renegotiation interval
Established data channelNothingUntil the session ends

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

ಪರಿಶೀಲಕ ನಿಜವಾಗಿ ಓದುವ ಫೈಲ್ ಅನ್ನು ತಲುಪಿಸಿ

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

ca ca.crt
cert server.crt
key server.key
crl-verify /etc/openvpn/crl.pem

ಫೈಲ್ ನಿಜವಾಗಿ ಓದಲ್ಪಡುತ್ತದೆಯೇ ಎಂಬುದನ್ನು ಎರಡು ವಿವರಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ. ಸಾಪೇಕ್ಷ ಮಾರ್ಗ ಕಾನ್ಫಿಗರೇಶನ್ ಡೈರೆಕ್ಟರಿಗೆ ಸಂಬಂಧಿಸಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿರ್ವಾಹಕರ ಮನೆಯಲ್ಲಿ ಬಿಟ್ಟಿರುವ ನಕಲು ಎಂದಿಗೂ ಸಿಗದೇ ಇರಬಹುದು. ಮತ್ತು ಡೀಮನ್ ಸಾಮಾನ್ಯವಾಗಿ ಪ್ರಾರಂಭದ ನಂತರ ಸವಲತ್ತುಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದ್ದರಿಂದ ರನ್ಟೈಮ್ ಖಾತೆಗೆ ಪ್ರತಿ ಪೋಷಕ ಡೈರೆಕ್ಟರಿಯಲ್ಲಿ ಹುಡುಕಾಟ ಅನುಮತಿ ಮತ್ತು ಫೈಲ್ನಲ್ಲಿ ಓದುವ ಅನುಮತಿ ಬೇಕು. ಎರಡನ್ನೂ ರನ್ಟೈಮ್ ಖಾತೆಯಿಂದ ಪರಿಶೀಲಿಸಿ, root ನಿಂದ ಅಲ್ಲ, ಇಲ್ಲದಿದ್ದರೆ ಪರೀಕ್ಷೆ ತಪ್ಪಾದುದನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ.

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

ಕ್ಲೈಂಟ್ನಲ್ಲಿ ಅಲ್ಲ, ಸರ್ವರ್ನಲ್ಲಿ ದೃಢೀಕರಿಸಿ

ಸರ್ವರ್ ಲಾಗ್ ಏನಾಯಿತೆಂದು ಹೆಸರಿಸುತ್ತದೆ: ಪಟ್ಟಿ ತೆರೆಯುವುದು, ಅದನ್ನು ಲೋಡ್ ಮಾಡುವುದು, ಅಥವಾ ರದ್ದಾದ ಕ್ರಮ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ಪರಿಶೀಲನೆ ವಿಫಲವಾಗುವುದು. ಕ್ಲೈಂಟ್ ಸಾಮಾನ್ಯ ಹ್ಯಾಂಡ್ಶೇಕ್ ವೈಫಲ್ಯವನ್ನು ಮಾತ್ರ ವರದಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ರದ್ದತಿ ನಿರ್ಣಯವನ್ನು ಹುಡುಕಲು ಕ್ಲೈಂಟ್ ಲಾಗ್ಗಳು ಕೆಟ್ಟ ಜಾಗ.

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

ಏನನ್ನೂ ರದ್ದು ಮಾಡದಿರುವುದು

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

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು