L2TP/IPsec PSK ತಿರಸ್ಕೃತ: ಮೊದಲು ಸಂವಾದ, ನಂತರ ಫೈಲ್ಗಳ ಸರಣಿ

ನೀವು ನಿರ್ವಾಹಕರ ಸಂದೇಶದಿಂದ ಪೂರ್ವ-ಹಂಚಿಕೆ ಕೀಲಿಯನ್ನು NetworkManager ಸಂವಾದಕ್ಕೆ ಅಂಟಿಸುತ್ತೀರಿ, ಅದನ್ನು ತೋರಿಸಲು ಚೌಕವನ್ನು ಟಿಕ್ ಮಾಡುತ್ತೀರಿ, ಮತ್ತು ಅದು ಅಕ್ಷರಕ್ಕೆ ಅಕ್ಷರ ಹೊಂದುತ್ತದೆ. ಸಂಪರ್ಕವು ಇನ್ನೂ ಟನೆಲ್ ಏಳುವ ಮೊದಲೇ ದೃಢೀಕರಣ ವೈಫಲ್ಯದಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ. ಇದನ್ನು ಮೊದಲ ಬಾರಿ ನೋಡಿದಾಗ ಕೀಲಿ ತಪ್ಪು ಎಂದು ಭಾವಿಸಿದೆ; ಹಾಗಿರಲಿಲ್ಲ. ಡೀಮನ್ ನಿಜವಾಗಿ ಏನನ್ನು ಓದುತ್ತದೆ ಎಂಬುದನ್ನು ಇನ್ನೆರಡು ವಿಷಯಗಳು ನಿರ್ಧರಿಸುತ್ತವೆ: ಪ್ಲಗಿನ್ ಆ ಸಂಪರ್ಕಕ್ಕಾಗಿ ಬರೆಯುವ ರಹಸ್ಯ ಫೈಲ್, ಮತ್ತು ಮೌಲ್ಯವು ಸಂವಾದದ ಮೂಲಕ ಬದಲಾವಣೆಯಿಲ್ಲದೆ ಹಾದುಹೋಯಿತೇ ಎಂಬುದು.

ಕೆಳಗಿನ ದಾರಿ ಕೀಲಿಯನ್ನು ಕ್ಷೇತ್ರದಿಂದ ಫೈಲ್ವರೆಗೆ ಅನುಸರಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಎಲ್ಲಿ ಕಳೆದುಹೋಯಿತು ಎಂದು ಹೇಳುವ ಕ್ರಮ ಅದೇ. ಇದನ್ನು ವಿಫಲವಾಗುವ ಯಂತ್ರದಲ್ಲಿ ಮಾಡಿ, ಕೆಲಸ ಮಾಡುವ ಯಂತ್ರದಲ್ಲಿ ಅಲ್ಲ, ಏಕೆಂದರೆ ಆ ಎರಡು ಯಂತ್ರಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಸಾಮಾನ್ಯವಾಗಿ ಫೈಲ್ ವಿನ್ಯಾಸ, ಕೀಲಿ ಅಲ್ಲ.

ಸಂವಾದದಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಆದರೆ ಕ್ಷೇತ್ರವನ್ನು ನಂಬಬೇಡಿ

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

ಪಾಸ್ವರ್ಡ್ ತೋರಿಸುವ ನಿಯಂತ್ರಣದ ಮೇಲೆ ಕ್ಲಿಕ್ ಮಾಡಿ ಮತ್ತು ಸ್ಟ್ರಿಂಗ್ನ ಕೊನೆಯನ್ನು ನೋಡಿ, ಮಧ್ಯವನ್ನಲ್ಲ. ಕರ್ಸರ್ ಪಠ್ಯದ ಕೆಳಗೆ ಖಾಲಿ ಸಾಲು ಬಿಟ್ಟರೆ ಅದನ್ನು ಅಳಿಸಿ ಕೊನೆಯ ಅಕ್ಷರವನ್ನು ಮತ್ತೆ ಟೈಪ್ ಮಾಡಿ. ಆ ಒಂದೇ ತಿದ್ದುಪಡಿ ಇಂತಹ ವರದಿಗಳ ಆಶ್ಚರ್ಯಕರ ಭಾಗವನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಲಾಗ್ ಓದುವುದಕ್ಕಿಂತ ಕಡಿಮೆ ವೆಚ್ಚವಾಗುತ್ತದೆ.

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

/etc/ipsec.d ಒಳಗೆ ಕೀಲಿಯನ್ನು ಅನುಸರಿಸಿ

ಪ್ಲಗಿನ್ PSK ಅನ್ನು IPsec ಡೀಮನ್ಗೆ ಆದೇಶ ಸಾಲಿನಲ್ಲಿ ಆರ್ಗ್ಯುಮೆಂಟ್ ಆಗಿ ಎಂದಿಗೂ ನೀಡುವುದಿಲ್ಲ. ಬದಲಾಗಿ ಅದು ಮೌಲ್ಯವನ್ನು ರಹಸ್ಯ ಫೈಲ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಡೀಮನ್ ಆ ಫೈಲ್ ಅನ್ನು ಸೇರಿಸಿಕೊಳ್ಳುವಂತೆ ವ್ಯವಸ್ಥೆ ಮಾಡುತ್ತದೆ, ಅಗತ್ಯವಿದ್ದರೆ /etc/ipsec.secrets ಗೆ include ಸಾಲು ಸೇರಿಸುತ್ತದೆ. ಸಂವಾದವು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು ಆ ರಚಿತ ಫೈಲ್ಗೆ ಇನ್ಪುಟ್, ಬಳಕೆಯಲ್ಲಿರುವ ಮೌಲ್ಯವಲ್ಲ.

ಏನನ್ನಾದರೂ ಬದಲಿಸುವ ಮೊದಲು ಏನಿದೆ ಎಂದು ಪಟ್ಟಿ ಮಾಡಿ:

ipsec --version
sudo ls -l /etc/ipsec.d/*.secrets /etc/ipsec.d/ipsec.nm-l2tp.secrets 2>/dev/null
sudo grep -n "include" /etc/ipsec.secrets

ಪ್ಲಗಿನ್ನ ಹಳೆಯ ಆವೃತ್ತಿಗಳು ಪ್ರತಿ ಸಂಪರ್ಕಕ್ಕೆ ಒಂದು ಫೈಲ್ ಬರೆಯುತ್ತಿದ್ದವು, ಸಂಪರ್ಕದ UUID ಹೆಸರಿನಲ್ಲಿ, ಉದಾಹರಣೆಗೆ /etc/ipsec.d/nm-l2tp-ipsec-<uuid>.secrets. ಆ್ಯಪ್ಲೆಟ್ನಲ್ಲಿ ಪ್ರೊಫೈಲ್ ಅಳಿಸುವುದು ಆ ಫೈಲ್ ಅನ್ನು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿ ಅಳಿಸುವುದಿಲ್ಲ. ಹಿಂದಿನ ಸರ್ವರ್ನ ಹಳೆಯ ಫೈಲ್ ಇನ್ನೂ ಡಿಸ್ಕ್ನಲ್ಲಿದ್ದು ಇನ್ನೂ ಸೇರಿಸಲ್ಪಟ್ಟರೆ, ಡೀಮನ್ ನೀವು ಇನ್ನು ಬಳಸದ ಪ್ರೊಫೈಲ್ಗೆ ಸೇರಿದ ರಹಸ್ಯವನ್ನು ಆಯ್ಕೆ ಮಾಡಬಹುದು, ಮತ್ತು ಕಾಣುವ ಕ್ಷೇತ್ರ ಸರಿಯಾಗಿದ್ದರೂ ಸಂಪರ್ಕ ವಿಫಲವಾಗುತ್ತದೆ.

1.2.12 ಬದಲಾವಣೆ ಅಪ್ಗ್ರೇಡ್ಗಳಿಗೆ ಏನು ಮಾಡಿತು ಎಂದು ತಿಳಿಯಿರಿ

ಪ್ಲಗಿನ್ ಆವೃತ್ತಿ 1.2.12 ಪ್ರತಿ-ಸಂಪರ್ಕ ರಹಸ್ಯ ಫೈಲ್ಗಳನ್ನು ಒಂದೇ ಹಂಚಿದ ಫೈಲ್ನಿಂದ ಬದಲಿಸಿತು, /etc/ipsec.d/ipsec.nm-l2tp.secrets. ಅಪ್ಗ್ರೇಡ್ ಹಳೆಯ UUID ಆಧಾರಿತ ಫೈಲ್ಗಳನ್ನು ಸ್ವಚ್ಛಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಇರುವ include /etc/ipsec.d/*.secrets ಸಾಲು ಅವುಗಳನ್ನು ಇನ್ನೂ ಸೇರಿಸುತ್ತದೆ. ಆವೃತ್ತಿ 1.2.16 ಡೀಫಾಲ್ಟ್ ಪ್ರಸ್ತಾವನೆಗಳ ನಿರ್ವಹಣೆಯನ್ನು ಬದಲಿಸಿತು, ರಹಸ್ಯಗಳ ವಿನ್ಯಾಸವನ್ನಲ್ಲ.

ಆ ಇತಿಹಾಸವೇ ಒಂದೇ ರೀತಿ ಕಾಣುವ ಪ್ರೊಫೈಲ್ ಇರುವ ಎರಡು ಯಂತ್ರಗಳು ಬೇರೆ ರೀತಿ ವರ್ತಿಸುವುದಕ್ಕೆ ಕಾರಣ. ಕೀಲಿ ಒಂದೇ; ಡೀಮನ್ ಸೇರಿಸಿಕೊಳ್ಳುವ ಫೈಲ್ಗಳ ಗುಂಪು ಒಂದೇ ಅಲ್ಲ. ಅನಾಥ ಫೈಲ್ ತೆಗೆಯುವಾಗ ಅದನ್ನು ಅಳಿಸುವ ಬದಲು ಪಕ್ಕಕ್ಕೆ ಸರಿಸಿ, ಸಂಪರ್ಕವನ್ನು ದೃಢೀಕರಿಸಿ, ನಂತರ ಕೆಲಸ ಮಾಡುವ ಸ್ಥಿತಿ ದಾಖಲಾದ ಮೇಲೆ ಅದನ್ನು ಅಳಿಸಿ. ಮರುನಾಮಕರಣವು ಹಳೆಯ ಮೌಲ್ಯವನ್ನು ಮರುಪಡೆಯಬಹುದಾದಂತೆ ಇಡುತ್ತದೆ, ದೋಷ ಬೇರೆಡೆ ಇದ್ದರೆ.

ಸಂಗ್ರಹ ಸ್ವರೂಪವು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳಲಾಗದ ಅಕ್ಷರಗಳನ್ನು ಬೇರ್ಪಡಿಸಿ

ಹಂಚಿದ ರಹಸ್ಯ ಸ್ಟ್ರಿಂಗ್ ಬಗ್ಗೆ strongSwan ದಾಖಲೆ ಹೇಳುವುದೇನೆಂದರೆ ಮೌಲ್ಯದಲ್ಲಿ ಹೊಸ ಸಾಲು ಅಥವಾ ಎರಡು ಉದ್ಧರಣ ಚಿಹ್ನೆ ಇರಬಾರದು. ದಾಖಲೆಯಿಂದ ಅಂಟಿಸಿದ ಕೀಲಿ ಸಾಮಾನ್ಯ ಸಂವಾದದಲ್ಲಿ ಯಾವುದೇ ದೃಶ್ಯ ವ್ಯತ್ಯಾಸವಿಲ್ಲದೆ ಎರಡನ್ನೂ ಒಯ್ಯಬಹುದು.

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

ಉದ್ದವು ಇನ್ನೊಂದು ನಿರ್ಬಂಧ. L2TP/IPsec ತಂತ್ರಾಂಶದಾದ್ಯಂತ ಯಾವುದೇ ಸಾರ್ವತ್ರಿಕ ಕನಿಷ್ಠ ಅನ್ವಯಿಸುವುದಿಲ್ಲ: ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು ಇಪ್ಪತ್ತು ಅಕ್ಷರಕ್ಕಿಂತ ಚಿಕ್ಕ ಕೀಲಿಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಕೆಲವು ಗೇಟ್ವೇಗಳು ಕನಿಷ್ಠವನ್ನು ವಿಧಿಸುತ್ತವೆ. ಚಿಕ್ಕ ಕೀಲಿ ತಿರಸ್ಕೃತವಾದರೆ, ನಿಯಮ ಸರ್ವರ್ ನೀತಿ ಅಥವಾ ಆ ಕ್ಲೈಂಟ್ನ ಮೌಲ್ಯೀಕರಣಕ್ಕೆ ಸೇರಿದ್ದು, ಮತ್ತು ಸ್ಥಳೀಯವಾಗಿ ಏನನ್ನಾದರೂ ಹೆಚ್ಚಿಸುವುದರಿಂದ ಅದು ಬದಲಾಗುವುದಿಲ್ಲ.

ಯಾವ ದೃಢೀಕರಣ ಪದರ ವಿಫಲವಾಯಿತು ಎಂದು ಓದಿ

ಮೊದಲು ipsec --version ಚಲಾಯಿಸಿ, ಏಕೆಂದರೆ strongSwan ಮತ್ತು Libreswan ಬೇರೆ ಫೈಲ್ ಹೆಸರುಗಳು ಮತ್ತು ವಾಕ್ಯರಚನೆ ಬಳಸುತ್ತವೆ, ಮತ್ತು ಒಂದಕ್ಕೆ ನೀಡಿದ ಸಲಹೆ ಇನ್ನೊಂದನ್ನು ಹಾನಿಗೊಳಿಸಬಹುದು. ನಂತರ ಕ್ಲೈಂಟ್ನ ಸಂದೇಶ ಅಥವಾ ಡೀಮನ್ ಲಾಗ್ನಿಂದ ವೈಫಲ್ಯದ ಹಂತವನ್ನು ಓದಿ: ಪೂರ್ವ-ಹಂಚಿಕೆ ಕೀಲಿ ಬಗ್ಗೆ ದೂರು ತಿರಸ್ಕೃತ ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ಗಿಂತ ಬೇರೆ ಘಟನೆ.

PSK ಟನೆಲ್ನ ತುದಿಗಳನ್ನು ದೃಢೀಕರಿಸುತ್ತದೆ. ಬಳಕೆದಾರ ಹೆಸರು ಮತ್ತು ಪಾಸ್ವರ್ಡ್ L2TP ಒಳಗಿನ ವ್ಯಕ್ತಿಯನ್ನು ದೃಢೀಕರಿಸುತ್ತವೆ, ಮತ್ತು IPsec ಸಂಘ ಏರಿದ ಮೇಲೆ PPP ಅವುಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ. ಸರಿಯಾದ PSK ತಪ್ಪು ಖಾತೆಯೊಂದಿಗೂ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಖಾತೆ ಬದಲಿಸುವುದರಿಂದ ಡೀಮನ್ ಎಂದಿಗೂ ಸರಿಯಾಗಿ ಓದದ ಕೀಲಿ ಸರಿಪಡಿಸುವುದಿಲ್ಲ.

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