Ubuntu ನವೀಕರಣದ ನಂತರ OpenVPN ಸಂಪರ್ಕವನ್ನು ಏಕೆ ನಿಲ್ಲಿಸಿತು?

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

ಯಾವ ಪದರ ವಿಫಲವಾಯಿತು: ಹ್ಯಾಂಡ್‌ಶೇಕ್, ಸೈಫರ್, ಪ್ಯಾಕೇಜ್ ಅಥವಾ ಲೈಬ್ರರಿ

ಪ್ರೊಫೈಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಕ್ಲೈಂಟ್ ಲಾಗ್ ಓದಿ. ಔಟ್‌ಪುಟ್‌ನ ಮೊದಲ ದೋಷ ಪದರವನ್ನು ಗುರುತಿಸುತ್ತದೆ; ಅದರ ನಂತರ ಮುದ್ರಿಸುವುದೆಲ್ಲ ಸಾಮಾನ್ಯವಾಗಿ ಆ ಮೊದಲ ವೈಫಲ್ಯದ ಪರಿಣಾಮ. ಕ್ಲೈಂಟ್ ಸಂಪೂರ್ಣವಾಗಿ ಪ್ರಾರಂಭವಾಗದಿದ್ದರೆ, VPN ಲಾಗ್ ತೆರೆಯಲು ತಪ್ಪು ಫೈಲ್.

ಪ್ರಮಾಣಪತ್ರಗಳು ಮತ್ತು ಸಹಿಗಳ ಕುರಿತ ದೂರುಗಳು, ಅಥವಾ ಕೀ ಉದ್ದದ ಬಗ್ಗೆ ಸಂದೇಶ, ನಿಯಂತ್ರಣ ಚಾನೆಲ್ ಮತ್ತು ಅದನ್ನು ನಿಯಂತ್ರಿಸುವ ಲೈಬ್ರರಿ ನೀತಿಯಿಂದ ಬರುತ್ತವೆ. ಆದರೆ DEPRECATED OPTION ನಿಂದ ಪ್ರಾರಂಭವಾಗುವ ಎಚ್ಚರಿಕೆ ಡೇಟಾ-ಚಾನೆಲ್ ಮಾತುಕತೆಗೆ ಸೇರುತ್ತದೆ.

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

ಹ್ಯಾಂಡ್‌ಶೇಕ್ ವಿಫಲವಾದಾಗ, TLS ನೀತಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ

Ubuntu 22.04 ವ್ಯವಸ್ಥೆಯನ್ನು OpenSSL 3 ಗೆ ವರ್ಗಾಯಿಸಿತು, ಮತ್ತು ಆ ಶಾಖೆಯ ಡೀಫಾಲ್ಟ್ ಭದ್ರತಾ ಮಟ್ಟವು ಪ್ರಮಾಣಪತ್ರ ಸಹಿಗಳು ಮತ್ತು ಕೀ ಗಾತ್ರಗಳ ಬಗ್ಗೆ 20.04 ಕ್ಕಿಂತ ಕಟ್ಟುನಿಟ್ಟಾಗಿದೆ. ಹಳೆಯ ಡೈಜೆಸ್ಟ್‌ನಿಂದ ಸಹಿ ಮಾಡಿದ CA ಪ್ರಮಾಣಪತ್ರ, ಅಥವಾ ಪ್ರಸ್ತುತ ಮಿತಿಗಿಂತ ಕೆಳಗಿನ ಕೀ, ಈಗ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಮಯದಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ಇನ್ನೂ ಏನೂ ದೃಢೀಕರಣವಾಗದ ಕಾರಣ, ದೋಷವು ತಪ್ಪು ಪಾಸ್‌ವರ್ಡ್ ಅಥವಾ ಸತ್ತ ಸರ್ವರ್‌ನಂತೆ ಓದುತ್ತದೆ.

ಸಣ್ಣ ದುರಸ್ತಿ ಸೈಫರ್ ಸರಣಿಯನ್ನು ಈ ಸಂಪರ್ಕಕ್ಕೆ ಮಾತ್ರ ಜೋಡಿಸುತ್ತದೆ. ಡೆಸ್ಕ್‌ಟಾಪ್ ಸಂಪಾದಕದಲ್ಲಿ ಪ್ರೊಫೈಲ್ ತೆರೆಯಿರಿ, ಸುಧಾರಿತ ಸೆಟ್ಟಿಂಗ್‌ಗಳಿಗೆ ಹೋಗಿ, DEFAULT:@SECLEVEL=0 ಅನ್ನು TLS ಸೈಫರ್ ಕ್ಷೇತ್ರದಲ್ಲಿ ಇರಿಸಿ. NetworkManager ಕೀ ಫೈಲ್ [vpn] ಅಡಿಯಲ್ಲಿ ಅದೇ ಮೌಲ್ಯವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

NetworkManager ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ಏಕೆಂದರೆ ಡೀಮನ್ ವಿಶ್ಲೇಷಿಸಿದ ಪ್ರೊಫೈಲ್‌ಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಇಲ್ಲದಿದ್ದರೆ ಈಗಾಗಲೇ ಹೊಂದಿರುವ ಪ್ರತಿಯನ್ನೇ ಬಳಸುತ್ತದೆ. ಸಾಲನ್ನು ಉಳಿಸಿಕೊಳ್ಳುವ ಮೊದಲು ಅದು ಏನು ಮಾಡುತ್ತದೆ ಎಂದು ತಿಳಿಯಿರಿ: ಆ ಸೆಟ್ಟಿಂಗ್ ಸೈಫರ್ ಹೆಸರಲ್ಲ, ಹಲವು ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಕೀ ನಿಯತಾಂಕಗಳ ಮೇಲಿನ ಮಿತಿ, ಆದ್ದರಿಂದ ಅದನ್ನು ತಗ್ಗಿಸುವುದು ಒಂದೇ ಪ್ರೊಫೈಲ್ ಸ್ವೀಕರಿಸುವ ವ್ಯಾಪ್ತಿಯನ್ನು ಹಿಗ್ಗಿಸುತ್ತದೆ. ಯಾವ ಸರ್ವರ್ ಅದನ್ನು ಬೇಡಿತು ಎಂದು ಬರೆದಿಡಿ ಮತ್ತು ನಿರ್ವಾಹಕರು ಪ್ರಸ್ತುತ ಸಾಮಗ್ರಿಯನ್ನು ಮತ್ತೆ ಬಿಡುಗಡೆ ಮಾಡಿದಾಗ ಸೆಟ್ಟಿಂಗ್ ಬಿಟ್ಟುಬಿಡಿ. ಆದರೆ /etc/ssl/openssl.cnf ಬದಲಿಸುವುದು ಆ ಫೈಲ್ ಓದುವ ಪ್ರತಿ ಪ್ರೋಗ್ರಾಂಗೂ ಅದೇ ಮಿತಿಯನ್ನು ತಲುಪುತ್ತದೆ, ಇದು VPN ಗಿಂತ ಬಹಳ ದೂರ.

OpenVPN 2.6 ಮಾತುಕತೆಗೆ ಸೈಫರ್ ಪಟ್ಟಿ ಮಾಡಬೇಕೆಂದು ಒತ್ತಾಯಿಸುತ್ತದೆ

Ubuntu 22.10 OpenVPN 2.6 ತಂದಿತು, ಮತ್ತು ಆ ಆವೃತ್ತಿಯಲ್ಲಿ --cipher ತಾನೇ ಡೇಟಾ ಚಾನೆಲ್ ಆಯ್ಕೆ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಸೈಫರ್ ಮಾತುಕತೆ ಮಾಡಿದ data-ciphers ಪಟ್ಟಿಯಲ್ಲೂ ಇರಬೇಕು, ಇಲ್ಲದಿದ್ದರೆ ಕ್ಲೈಂಟ್ ಬಳಕೆಯಲ್ಲಿಲ್ಲದ ಎಚ್ಚರಿಕೆ ಮುದ್ರಿಸಿ ನಂತರ ಸುರಂಗವನ್ನು ಮೇಲಕ್ಕೆ ಎತ್ತಲು ವಿಫಲವಾಗುತ್ತದೆ.

ಅದೇ ಅವಧಿಯ NetworkManager ಪ್ಲಗಿನ್ ಇನ್ನೂ ಹಳೆಯ ನಿರ್ದೇಶವನ್ನಷ್ಟೇ ಬರೆಯುತ್ತಿತ್ತು. ಈ ವಿವರ ರೋಗನಿರ್ಣಯವನ್ನು ಒಡೆಯುತ್ತದೆ, ಏಕೆಂದರೆ ಕೈಯಿಂದ ಸರಿಪಡಿಸಿದ ಪ್ರೊಫೈಲ್ ಶೆಲ್‌ನಿಂದ ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು ಡೆಸ್ಕ್‌ಟಾಪ್ ಅಪ್ಲೆಟ್‌ನಿಂದ ಇನ್ನೂ ವಿಫಲವಾಗಬಹುದು. ಪಟ್ಟಿಯನ್ನು ಸಂಪರ್ಕ ಫೈಲ್‌ಗೆ [vpn] ಅಡಿಯಲ್ಲಿ ಸೇರಿಸಿ:

data-ciphers=AES-256-CBC

ಸರ್ವರ್ ಘೋಷಿಸುವ ಮೌಲ್ಯವನ್ನು ಬಳಸಿ, ನೀವು ನೆನಪಿಟ್ಟುಕೊಂಡದ್ದನ್ನು ಅಲ್ಲ; AES-256-GCM ನೀಡುವ ಸರ್ವರ್ CBC ಮಾತ್ರ ಹೆಸರಿಸುವ ಕ್ಲೈಂಟ್ ಪಟ್ಟಿಯೊಂದಿಗೆ ಮಾತುಕತೆ ನಡೆಸುವುದಿಲ್ಲ. ಮ್ಯಾನೇಜರ್ ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತೆ ಸಂಪರ್ಕಿಸಿ, ನಂತರ ಶೆಲ್‌ನಿಂದ ಪ್ರಯತ್ನವನ್ನು ಪುನರಾವರ್ತಿಸಿ ಮತ್ತು ಸೈಫರ್ ಅನ್ನು ಮಾತುಕತೆ ಹಾಗೂ ಫಾಲ್‌ಬ್ಯಾಕ್ ಎರಡಕ್ಕೂ ಸ್ಪಷ್ಟವಾಗಿ ನೀಡಿ:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

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

ಪ್ಯಾಕೇಜ್ ಮತ್ತು ಪ್ಲಗಿನ್ ದೋಷಗಳು VPN ದೋಷಗಳಂತೆ ಕಾಣುತ್ತವೆ

ನವೀಕರಣದ ನಂತರ ಪ್ರತಿ ವೈಫಲ್ಯವೂ ಗೂಢಲಿಪಿ ಸಂಬಂಧಿಯಲ್ಲ. ಬಿಡುಗಡೆ ಬಳಸದ ಕೋಡ್‌ನಾಮ್ ಅಡಿಯಲ್ಲಿ ಸೇರಿಸಿದ OpenVPN ಸಂಗ್ರಹ ಎಂದಿಗೂ ಸ್ಥಾಪನೆಯಾಗದ ಪ್ಯಾಕೇಜ್ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ lsb_release -a ಏನು ವರದಿ ಮಾಡುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಸೇರಿಸಿದ ಪಟ್ಟಿ ಫೈಲ್‌ನೊಂದಿಗೆ ಹೋಲಿಸಿ. ಕಾಣೆಯಾದ universe ಘಟಕ ಅಥವಾ ಭದ್ರತಾ ಜೇಬು ಸಂಪೂರ್ಣವಾಗಿ ಸಿಗದ ಪ್ಯಾಕೇಜ್ ನೀಡುತ್ತದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಮುಟ್ಟದೆ, ಸುರಂಗ ಅಸಾಧ್ಯವಾಗಿ ಉಳಿಯುತ್ತದೆ.

VPN ಲಾಗ್‌ಗಿಂತ ಮೊದಲು ಪ್ಯಾಕೇಜ್ ಮ್ಯಾನೇಜರ್ ದೋಷ ಓದಿ. ಕ್ಲೈಂಟ್ ಎಂದಿಗೂ ಸ್ಥಾಪನೆಯಾಗದಿದ್ದರೆ, ಎಷ್ಟೇ ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆ ಮಾಡಿದರೂ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಬರುವುದಿಲ್ಲ.

ಕೇಳುವುದನ್ನು ನಿಲ್ಲಿಸುವ ಎರಡು-ಅಂಶ ಪ್ರೊಫೈಲ್‌ಗಳು ಅದೇ ಕಥೆಯ ಪ್ಲಗಿನ್ ಆವೃತ್ತಿ. ಸವಾಲು ದೃಢೀಕರಣ ಪ್ಲಗಿನ್‌ನಿಂದ ಬರುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ತೆಗೆದು ಅಥವಾ ಬದಲಿಸಿದ ನವೀಕರಣ ಪ್ರೊಫೈಲ್ ಅನ್ನು ಅಖಂಡವಾಗಿ ಬಿಟ್ಟು ಪ್ರಾಂಪ್ಟ್ ಮಾಯವಾಗುತ್ತದೆ. ಸಂಪರ್ಕ ಕೆಲಸ ಮಾಡಲು ಎರಡನೇ ಅಂಶ ಅಳಿಸುವ ಬದಲು ಬೆಂಬಲಿತ ಪ್ಲಗಿನ್ ಮರುಸ್ಥಾಪಿಸಿ.

ಮಾರಾಟಗಾರ ಲೈಬ್ರರಿ ನೀತಿ ದೋಷದ ಹಿಂದೆ ಅಡಗಬಹುದು

ಒಂದು ಮಾದರಿ ಗುರುತಿಸಲು ಯೋಗ್ಯವಾಗಿದೆ ಏಕೆಂದರೆ ಅದು ಪ್ರತಿ ನೀತಿ ದುರಸ್ತಿಯನ್ನೂ ಸೋಲಿಸುತ್ತದೆ. ಹಾರ್ಡ್‌ವೇರ್ ಮಾರಾಟಗಾರರ ಸಂರಚನಾ ಸಾಧನ ತನ್ನದೇ OpenSSL ಲೈಬ್ರರಿಗಳನ್ನು ಸ್ಥಾಪಿಸಿ ಲೋಡರ್‌ನ ಹುಡುಕಾಟ ಮಾರ್ಗದಲ್ಲಿ ವ್ಯವಸ್ಥೆಯ ಪ್ರತಿಗಳ ಮುಂದೆ ಇಡಬಹುದು. ಆಗ ಕ್ಲೈಂಟ್ ಯಾರೂ ನವೀಕರಿಸದ ಲೈಬ್ರರಿ ವಿರುದ್ಧ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರಾರಂಭ ವೈಫಲ್ಯ ತಿರಸ್ಕೃತ ಪ್ರಮಾಣಪತ್ರದಂತೆಯೇ ಕಾಣುತ್ತದೆ.

VPN ಪ್ಯಾಕೇಜ್ ಮರುಸ್ಥಾಪಿಸುವುದು ಯಾವ ಲೈಬ್ರರಿ ಮೊದಲು ಸಿಗುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ, ಮತ್ತು TLS ಮಟ್ಟವನ್ನು ತಗ್ಗಿಸುವುದು ವ್ಯವಸ್ಥೆಯಿಂದ ಎಂದೂ ಬಾರದ ಲೈಬ್ರರಿಯನ್ನು ತಲುಪಲಾರದು. ಬೈನರಿ ನಿಜವಾಗಿ ಯಾವ ಗೂಢಲಿಪಿ ವಸ್ತುಗಳನ್ನು ಪರಿಹರಿಸುತ್ತದೆ ಎಂದು ಲೋಡರ್‌ಗೆ ಕೇಳಿ:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

ಮಾರಾಟಗಾರರ ಪ್ರತಿಯನ್ನು ತೆಗೆಯಿರಿ ಅಥವಾ ಮರುನಿರ್ದೇಶಿಸಿ, ನಂತರ ಅದೇ ಪರಿಶೀಲನೆಯನ್ನು ಮತ್ತೆ ಚಲಾಯಿಸಿ. ಪ್ರೊಫೈಲ್‌ಗೆ ಮರಳುವ ಮೊದಲು ನಿರೀಕ್ಷಿತ ಆವೃತ್ತಿಯೇ ಬಳಕೆಯಲ್ಲಿರಬೇಕು.

ಹಳೆಯ ಕ್ಲೈಂಟ್ ಪಿನ್ ಮಾಡುವುದು ಸಮಯ ಕೊಳ್ಳುತ್ತದೆ, ಪರಿಹಾರವಲ್ಲ

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

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

ಮುಂದಿನ ಬಾರಿ ಬಿಡುಗಡೆ ನವೀಕರಣದ ನಂತರ VPN ಸಾಯುವಾಗ, ಐದು ಪ್ರಶ್ನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಕೇಳಿ: ಯಾವ ಪದರ ಮೊದಲ ದೋಷ ನೀಡಿತು, TLS ನೀತಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ತಿರಸ್ಕರಿಸಿತೇ, ಸೈಫರ್ ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಮಾತುಕತೆಗೆ ಒಳಪಡುತ್ತದೆಯೇ, ಪ್ಯಾಕೇಜ್ ಮತ್ತು ಅದರ ಪ್ಲಗಿನ್ ನಿಜವಾಗಿ ಸ್ಥಾಪನೆಯಾದವೇ, ಮತ್ತು ಪ್ರಕ್ರಿಯೆ ಯಾವ ಲೈಬ್ರರಿ ಲೋಡ್ ಮಾಡುತ್ತದೆ. ಐದೂ ಸ್ವಚ್ಛವಾಗಿ ಮರಳಿದ ನಂತರವೇ ಆವೃತ್ತಿ ಇಳಿಕೆಗೆ ಅರ್ಥವಿದೆ.