ಸಂಪರ್ಕ ನಿರಾಕರಣೆ ಪ್ರಮಾಣಪತ್ರದ ಸಮಸ್ಯೆ ಅಲ್ಲ: VPN ರನ್‌ಬುಕ್

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

ಎರಡು ತಪಾಸಣೆಗಳು ಪ್ರಕರಣಗಳನ್ನು ಒಂದು ನಿಮಿಷಕ್ಕಿಂತ ಕಡಿಮೆ ಸಮಯದಲ್ಲಿ ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ವಿಶ್ವಾಸ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಮುಟ್ಟುವುದಿಲ್ಲ.

ದೋಷವನ್ನು ಸೃಷ್ಟಿಸಿದ ಪದರದಲ್ಲೇ ಓದಿ

connect ನಿಂದ ECONNREFUSED ಎಂದರೆ ಸಾರಿಗೆ ಪ್ರಯತ್ನ ನಿರಾಕರಿಸಲಾಗಿದೆ: ಏನೋ reset ನಿಂದ ಉತ್ತರಿಸಿತು, ಅಥವಾ ಸ್ಟಾಕ್ ತಲುಪಲಾಗದ ಪೋರ್ಟ್ ವರದಿ ಮಾಡಿತು. ಪ್ರಮಾಣಪತ್ರದ ಸಮಸ್ಯೆ ಆ ದೋಷವನ್ನು ಉಂಟುಮಾಡಲಾರದು, ಏಕೆಂದರೆ ಸಾರಿಗೆ ಸಂಪರ್ಕವಿಲ್ಲದೆ TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಎಂದಿಗೂ ಆರಂಭವಾಗುವುದಿಲ್ಲ. ನಿರಾಕರಣೆ ಕಂಡರೆ, ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಸ್ತುತಪಡಿಸುವ ಹಂತಕ್ಕೂ ತಲುಪಿಲ್ಲ. ಆ ಒಂದೇ ಸತ್ಯವು ರದ್ದತಿಯನ್ನು ಕಾರಣವಾಗಿ ಹೊರಗಿಡುತ್ತದೆ.

ವಿರುದ್ಧವೂ ನಿಜ. ರದ್ದುಗೊಳಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಪೂರ್ಣಗೊಂಡ TCP ಸಂಪರ್ಕ ಮತ್ತು ವಿಫಲ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಉಂಟುಮಾಡುತ್ತದೆ, ಅದು ಸರ್ವರ್‌ನಲ್ಲಿ ಪರಿಶೀಲನಾ ದೋಷವಾಗಿ ದಾಖಲಾಗುತ್ತದೆ.

TCP ನಿರಾಕರಣೆ: ಯಾರೂ ಆಲಿಸುತ್ತಿಲ್ಲ

TCP ಗೆ, ಉದ್ದೇಶಿತ ಇನ್‌ಸ್ಟೆನ್ಸ್ ಚಾಲನೆಯಲ್ಲಿದೆಯೇ ಮತ್ತು ಪ್ರೊಫೈಲ್‌ನ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್‌ಗೆ ಬದ್ಧವಾಗಿದೆಯೇ ಪರಿಶೀಲಿಸಿ. ss -lntp ಆಲಿಸುವವರನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಒಂದು ಇಲ್ಲದಿರುವುದೇ ಸಾಮಾನ್ಯ ವಿವರಣೆ. ಬಿಟ್ಟುಬಿಡುವ ಬದಲು ನಿರಾಕರಿಸುವ ಫೈರ್‌ವಾಲ್ ಕ್ಲೈಂಟ್ ಬದಿಯಲ್ಲಿ ಅದೇ ಸಂದೇಶವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸುತ್ತೀರಿ.

ವಿಳಾಸ ಕುಟುಂಬವನ್ನೂ ಪರಿಶೀಲಿಸಿ. 127.0.0.1 ಅಥವಾ IPv6 ಗೆ ಮಾತ್ರ ಬದ್ಧವಾದ ಸೇವೆ ಇನ್ನೊಂದಕ್ಕೆ ಪರಿಹರಿಸುವ ಕ್ಲೈಂಟ್ ಅನ್ನು ನಿರಾಕರಿಸುತ್ತದೆ.

ನಂತರ ಊಹಿಸುವ ಬದಲು ಸೇವಾ ಲಾಗ್ ಓದಿ. CA ನಿರ್ವಹಣೆಯ ನಂತರ ಮರುಪ್ರಾರಂಭ ಓದಲಾಗದ ಅಥವಾ ಕಾಣೆಯಾದ ಫೈಲ್‌ನಲ್ಲಿ ವಿಫಲವಾಗಬಹುದು ಮತ್ತು ಆಲಿಸುವ ಸ್ಥಿತಿಯನ್ನು ಎಂದಿಗೂ ತಲುಪದೇ ಇರಬಹುದು, ಮತ್ತು ಲಾಗ್ ಫೈಲ್ ಹೆಸರನ್ನು ಹೇಳುತ್ತದೆ. ಅದು ಸ್ಟಾರ್ಟಪ್ ವೈಫಲ್ಯ, ನಿರಾಕರಿಸಿದ ಪ್ರಮಾಣಪತ್ರಕ್ಕಿಂತ ಬೇರೆ ದೋಷ.

UDP ಗೆ ನಿರಾಕರಿಸಲು ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಇಲ್ಲ

UDP ಮೇಲೆ OpenVPN TCP ಅರ್ಥದಲ್ಲಿ ಸಂಪರ್ಕ ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ connect ಸಮಯದಲ್ಲಿ ನಿರಾಕರಿಸಲು ಏನೂ ಇಲ್ಲ. Linux ನಲ್ಲಿ, UDP ಸಾಕೆಟ್ ತೋರಿಸುವ ದೋಷವು ಹಿಂದಿನ ಡೇಟಾಗ್ರಾಮ್ ಸೃಷ್ಟಿಸಿದ ICMP port-unreachable ನಿಂದ ಬರಬಹುದು. udp(7) ಮ್ಯಾನ್ ಪುಟ ಆ ಅಸಮಕಾಲಿಕ ನಡವಳಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ UDP ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಪ್ರಕ್ರಿಯೆ ಚಾಲನೆಯಲ್ಲಿದ್ದರೂ ನಿರೀಕ್ಷಿತ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾಗಿಲ್ಲದಿದ್ದಾಗ ನಿರಾಕರಣೆಯನ್ನು ಮುದ್ರಿಸಬಹುದು.

CRL ವಾಸ್ತವವಾಗಿ ಎಲ್ಲಿ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ

CRL ಅನ್ನು TLS ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಯದಲ್ಲಿ, ಎದುರು ಪಕ್ಷ ತನ್ನ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿದ ನಂತರ, ಮತ್ತು ಸರ್ವರ್ ಸಂರಚನೆ ಅನುಮತಿಸಿದರೆ ಮಾತ್ರ ಸಂಪರ್ಕಿಸಲಾಗುತ್ತದೆ. OpenVPN ನ crl-verify ಆಯ್ಕೆಯು ಫೈಲ್‌ಗೆ ತೋರಿಸುತ್ತದೆ, ಮತ್ತು ವೈಫಲ್ಯವು ಸರ್ವರ್ ಲಾಗ್‌ನಲ್ಲಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಹೆಸರಿಸುವ ಪರಿಶೀಲನಾ ದೋಷವಾಗಿ ಕಾಣಿಸುತ್ತದೆ.

ಆದ್ದರಿಂದ ರದ್ದುಗೊಳಿಸಿದ ಕ್ಲೈಂಟ್ ಸಾರಿಗೆ ಪದರದಲ್ಲಿ ಸಂಪರ್ಕಗೊಂಡು ನಂತರ ದೃಢೀಕರಣದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಅದೇ ಸರ್ವರ್, ಅದೇ ಪೋರ್ಟ್, ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆ ಸಂದೇಶ.

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

ಮುಂದಿನ ಬಾರಿಗೆ ಸಣ್ಣ ರನ್‌ಬುಕ್

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

ಸಾರಿಗೆ, ಪರಿಹರಿಸಿದ ಗಮ್ಯಸ್ಥಾನ, ಪೋರ್ಟ್ ಮತ್ತು ದೋಷದ ನಿಖರ ಪಠ್ಯವನ್ನು ಬರೆದಿಡಿ. ಕ್ಲೈಂಟ್ ಮರುಸ್ಥಾಪನೆ ಆ ಸಾಕ್ಷ್ಯವನ್ನು ನಾಶಮಾಡುತ್ತದೆ ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ.