Linux ನಿಮ್ಮ VPN ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಎಲ್ಲಿ ಇಡಬೇಕು? ಪ್ರೊಫೈಲ್ನಲ್ಲಿ ಅಲ್ಲ
NetworkManager ನ ಸೀಕ್ರೆಟ್ ಫ್ಲಾಗ್ಗಳು ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಪ್ರೊಫೈಲ್, ಕೀರಿಂಗ್ ಏಜೆಂಟ್ ಅಥವಾ ಯಾರೂ ಇಟ್ಟುಕೊಳ್ಳುತ್ತಾರೆಯೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತವೆ. ಉತ್ತರವು ಸಂಪರ್ಕವು ಯಾವಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಅವಲಂಬಿಸಿದೆ.
VPN ಪಾಸ್ವರ್ಡ್ ಎಲ್ಲೋ ಇರಲೇಬೇಕು: ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್ನಲ್ಲಿ, ಡೆಸ್ಕ್ಟಾಪ್ ತೆರೆಯುವ ಕೀರಿಂಗ್ನಲ್ಲಿ, ಅಥವಾ ಎಲ್ಲಿಯೂ ಇಲ್ಲ. NetworkManager ಆ ಆಯ್ಕೆಯನ್ನು ಸೀಕ್ರೆಟ್ ಫ್ಲಾಗ್ ಎಂದು ಕರೆಯುತ್ತದೆ, ಮತ್ತು ತಪ್ಪಾದದನ್ನು ಆರಿಸುವುದೇ ಸಂಪರ್ಕವು ಲಾಗಿನ್ ನಂತರ ಕೆಲಸ ಮಾಡಿ ಸೇವೆಯಾಗಿ ವಿಫಲವಾಗುವ ಕಾರಣ. ಫ್ಲಾಗ್ ಸಂರಚನೆಯ ಒಂದು ಸಾಲು, ಮತ್ತು ಆ ಮೂರು ಫಲಿತಾಂಶಗಳಲ್ಲಿ ಯಾವುದು ಸಿಗುತ್ತದೆ ಎಂದು ಅದು ನಿರ್ಧರಿಸುತ್ತದೆ.
ಮೂರು ಫ್ಲಾಗ್ಗಳು ಬಹುತೇಕ ಎಲ್ಲಾ ಸಂದರ್ಭಗಳನ್ನು ಆವರಿಸುತ್ತವೆ, ಮತ್ತು ನಿರ್ಧಾರವು ಸಂಪರ್ಕವು ಯಾವಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ.
ಮೂರು ಸೀಕ್ರೆಟ್ ಫ್ಲಾಗ್ಗಳು, ಮೂರು ವರ್ತನೆಗಳು
ಫ್ಲಾಗ್ 0 ಎಂದರೆ ಸೀಕ್ರೆಟ್ ಸಂಪರ್ಕದೊಂದಿಗೆ ಸಂಗ್ರಹವಾಗುತ್ತದೆ, ಪ್ರೊಫೈಲ್ ಯಾವ ಸ್ಟೋರ್ನಲ್ಲಿದ್ದರೂ. ಫ್ಲಾಗ್ 1 ಅದನ್ನು ಏಜೆಂಟ್-ಮಾಲೀಕತ್ವ ಮಾಡುತ್ತದೆ: ಸೀಕ್ರೆಟ್ ಸೀಕ್ರೆಟ್ ಏಜೆಂಟ್ನಿಂದ ಬರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ ಡೆಸ್ಕ್ಟಾಪ್ ಕೀರಿಂಗ್, ಮತ್ತು NetworkManager ಸಕ್ರಿಯಗೊಳಿಸುವಾಗ ಅದನ್ನು ಕೇಳುತ್ತದೆ. ಫ್ಲಾಗ್ 2 ಎಂದರೆ ಸಂಗ್ರಹವಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಸೀಕ್ರೆಟ್ ಎಂದಿಗೂ ಬರೆಯುವುದಿಲ್ಲ ಮತ್ತು ಪ್ರತಿ ಬಾರಿ ನೀಡಬೇಕು. ಫ್ಲಾಗ್ 4 ಸೀಕ್ರೆಟ್ ಅನ್ನು ಅನಗತ್ಯ ಎಂದು ಗುರುತಿಸುತ್ತದೆ, ನಿಜವಾಗಿಯೂ ಯಾವುದನ್ನೂ ಬೇಕಾಗಿಲ್ಲದ ಸಂಪರ್ಕಗಳಿಗೆ.
| Flag | Where it lives | Works unattended |
|---|---|---|
| 0 saved | Connection profile | Yes, if the store is readable |
| 1 agent-owned | Secret agent or keyring | Only if that agent is available |
| 2 not-saved | Nowhere | No |
ಫ್ಲಾಗ್ಗಳನ್ನು ಸಂಪರ್ಕಕ್ಕೆ ಬದಲಾಗಿ ಪ್ರತಿ ಸೀಕ್ರೆಟ್ಗೆ ಹೊಂದಿಸಿ. ಒಂದು ಸಂಪರ್ಕದಲ್ಲಿ ಏಜೆಂಟ್-ಮಾಲೀಕತ್ವದ ಪಾಸ್ವರ್ಡ್ ಮತ್ತು ಸಂಗ್ರಹವಾದ ಖಾಸಗಿ ಕೀ ಪಾಸ್ಫ್ರೇಜ್ ಎರಡೂ ಇರಬಹುದು.
ಸಂಪರ್ಕವು ಯಾವಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಎಂಬುದರ ಮೇಲೆ ನಿರ್ಧರಿಸಿ
ಲಾಗಿನ್ ಆದ ಬಳಕೆದಾರರು ಸಂಪರ್ಕವನ್ನು ಪ್ರಾರಂಭಿಸಿದರೆ, ಏಜೆಂಟ್-ಮಾಲೀಕತ್ವ ಸೂಕ್ತ ಡೀಫಾಲ್ಟ್: ಲಾಗಿನ್ನಿಂದ ಕೀರಿಂಗ್ ತೆರೆಯುತ್ತದೆ ಮತ್ತು ಸೀಕ್ರೆಟ್ ಎಂದಿಗೂ ಫೈಲ್ನಲ್ಲಿ ಕುಳಿತುಕೊಳ್ಳುವುದಿಲ್ಲ. ಯಾರಾದರೂ ಲಾಗಿನ್ ಮಾಡುವ ಮೊದಲು ಸಂಪರ್ಕ ಮೇಲೇರಬೇಕಿದ್ದರೆ, ಏಜೆಂಟ್-ಮಾಲೀಕತ್ವ ತಪ್ಪು ಆಯ್ಕೆ, ಏಕೆಂದರೆ ತೆರೆಯಲು ಯಾವುದೇ ಸೆಷನ್ ಕೀರಿಂಗ್ ಇಲ್ಲ.
ಅದೇ ಇಡೀ ನಿರ್ಧಾರ. ಉಳಿದದ್ದೆಲ್ಲ ಅದರ ಒಂದು ರೂಪಾಂತರ.
ಲಾಗಿನ್ ಮೊದಲು ಚಾಲನೆಯಾಗುವ ಸೇವೆಗೆ ಸಿಸ್ಟಮ್-ಮಟ್ಟದ ಸ್ಟೋರ್ ಅಥವಾ ಸಂರಕ್ಷಿತ ಕೀ ಫೈಲ್ ಬೆಂಬಲಿತ ಮಾದರಿ, ಮತ್ತು ಫೈಲ್ ಅನುಮತಿಗಳೇ ಸಂರಕ್ಷಣೆಯಾಗುತ್ತವೆ. ಬೂಟ್ನಲ್ಲಿ ಚಾಲನೆಯಾಗುವ ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್ಗೆ ಪಾಸ್ವರ್ಡ್ ಅಂಟಿಸಿ ಸಮಸ್ಯೆ ಬಗೆಹರಿಸಬೇಡಿ.
ಕೀರಿಂಗ್ ಏನು ನೀಡುತ್ತದೆ ಮತ್ತು ಏನು ನೀಡುವುದಿಲ್ಲ
ಕೀರಿಂಗ್ ಸೀಕ್ರೆಟ್ ಅನ್ನು ಸಂಪರ್ಕ ಪ್ರೊಫೈಲ್ನಿಂದ ಹೊರಗಿಡುತ್ತದೆ ಮತ್ತು ಬಳಕೆದಾರ ಸೆಷನ್ಗೆ ಬಿಗಿಯುತ್ತದೆ. ಸೆಷನ್ ಇಲ್ಲದ ಸೇವೆಗೆ ಸೀಕ್ರೆಟ್ ಲಭ್ಯವಾಗುವಂತೆ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ತಂತಿಯ ಮೇಲೆ ಏನನ್ನೂ ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡುವುದಿಲ್ಲ. ಇವು ಜನರು ಹೆಚ್ಚಾಗಿ ಕಲಸುವ ಪ್ರತ್ಯೇಕ ಗುಣಗಳು. ಅದು ನಿಜವಾಗಿ ಕೊಳ್ಳುವುದು ಪ್ರೊಫೈಲ್ ಫೈಲ್ ಸೋರಿದಾಗ ಸಣ್ಣ ಹಾನಿ ತ್ರಿಜ್ಯ.
ಪ್ರೊಫೈಲ್ ಉಲ್ಲೇಖಿಸುವ ಖಾಸಗಿ ಕೀಗೆ ತನ್ನದೇ ಅನುಮತಿಗಳು ಬೇಕು, ಪಾಸ್ವರ್ಡ್ ಎಲ್ಲಿದ್ದರೂ ಸರಿ.
ಸೀಕ್ರೆಟ್ಗಳನ್ನು ಸುರಿಯದ ರೋಗನಿರ್ಣಯ
ಸಂಪರ್ಕ ಹೆಸರುಗಳು, UUID ಮತ್ತು ಫ್ಲಾಗ್ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ವೈಫಲ್ಯ ವಿವರಿಸಲು ಸಾಕು. nmcli connection show ಪ್ರೊಫೈಲ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಸೀಕ್ರೆಟ್ ಫ್ಲಾಗ್ಗಳು ಪಾಸ್ವರ್ಡ್ ಎಲ್ಲಿಂದ ಬರಬೇಕಿತ್ತು ಎಂದು ಹೇಳುತ್ತವೆ.
ತಪ್ಪಿಸಿ --show-secrets ಟಿಕೆಟ್ ಮತ್ತು ಚಾಟ್ನಲ್ಲಿ. ಒಮ್ಮೆ ಅಂಟಿಸಿದರೆ ಅದು ಟ್ರಾನ್ಸ್ಕ್ರಿಪ್ಟ್ನಲ್ಲಿ ರುಜುವಾತು.
ಸಂಗ್ರಹವು ರದ್ದತಿ ಅಲ್ಲ
ಒಂದು ಕೀರಿಂಗ್ನಿಂದ ಸೀಕ್ರೆಟ್ ತೆಗೆದರೆ ದೂರದ ನಿರ್ವಾಹಕರು ಈಗಾಗಲೇ ಸ್ವೀಕರಿಸಿದ ರುಜುವಾತು ಅಮಾನ್ಯವಾಗುವುದಿಲ್ಲ. ಖಾತೆ ರದ್ದತಿ ಸರ್ವರ್-ಬದಿಯ ಕ್ರಿಯೆ, ಮತ್ತು ಸ್ಥಳೀಯ ಸಂಗ್ರಹ ಪ್ರತ್ಯೇಕ ಮಾಲೀಕನ ಪ್ರತ್ಯೇಕ ವಿಷಯ.
ಎರಡನ್ನೂ ಘಟನೆಯ ಮೊದಲು ನಿರ್ಧರಿಸಿ, ಘಟನೆಯ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ. ಸಂವಾದಾತ್ಮಕ ಬಳಕೆದಾರ ಸಂಪರ್ಕ ಮತ್ತು ಲಾಗಿನ್-ಪೂರ್ವ ಸೇವೆಗೆ ವಿಭಿನ್ನ ಉತ್ತರಗಳು ಬೇಕು, ಮತ್ತು ಹಂಚಿದ ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್ ಎರಡೂ ಅಲ್ಲ. NetworkManager ನ ಸೀಕ್ರೆಟ್ ಫ್ಲಾಗ್ ದಾಖಲೆ ಮೌಲ್ಯಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ.