Keyfile ಅಥವಾ Netplan: VPN ಪ್ರೊಫೈಲ್ ನಿಜವಾಗಿ ಎಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿದೆ?
ಉಳಿಸಿದ VPN ಒಂದು keyfile ನಲ್ಲಿ ಅಥವಾ ರಚಿಸಿದ Netplan ಫೈಲ್ನಲ್ಲಿ ಇರಬಹುದು. ಮತ್ತೆ ಬರೆಯಲ್ಪಡುವ ಯಾವುದನ್ನಾದರೂ ಸಂಪಾದಿಸುವ ಮೊದಲು ಸಂಪರ್ಕದ UUID ಅನ್ನು ಅದರ ನಿಜವಾದ ಮಾಲೀಕರೊಂದಿಗೆ ಹೊಂದಿಸಿ.
ನೀವು ಆಮದು ಮಾಡಿದ ಫೈಲ್ ಅನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಸುಲಭ ಭಾಗ ಮತ್ತು ಹಲವು ಬಾರಿ ತಪ್ಪು ಆರಂಭ. ಮುಖ್ಯವಾದುದು NetworkManager ಇಂದು ಯಾವ ಫೈಲ್ ಅನ್ನು ಉಳಿಸಿದ ಸಂಪರ್ಕ ಎಂದು ಓದುತ್ತದೆ ಎಂಬುದು, ಮತ್ತು ಅದು ಸಂಪರ್ಕ ಗುರುತಿಸುವಿಕೆ ಹಾಗೂ ಸ್ಥಾಪಿತ ಪ್ಯಾಕೇಜ್ಗಳು ನಿಜವಾಗಿ ಬಳಸುವ ಸಂರಚನಾ ಬ್ಯಾಕೆಂಡ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ. ಆ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರಿಸುವ ಮೊದಲು ಆಮದನ್ನು ಸಂಪಾದಿಸುವುದೇ ಕಾರ್ಯನಿರ್ವಹಿಸುವ VPN ಎರಡು ಅರ್ಧ-ಸರಿಯಾದ ಸಂರಚನೆಗಳಾಗುವ ದಾರಿ.
ಆಮದು ಮಾಡಿದ ಫೈಲ್ ಉಳಿಸಿದ ಪ್ರೊಫೈಲ್ ಅಲ್ಲ
ಪ್ರತಿ VPN ಸಮಸ್ಯೆಯ ಸುತ್ತ ಮೂರು ಹೆಸರುಗಳು ತಿರುಗುತ್ತವೆ: ಸಂಪರ್ಕದ ಹೆಸರು, ನೀವು ಆಮದು ಮಾಡಿದ ಫೈಲ್ನ ಹೆಸರು, ಮತ್ತು ಸುರಂಗ ಏರಿದಾಗ ಕಾಣಿಸುವ ವರ್ಚುವಲ್ ಇಂಟರ್ಫೇಸ್. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಉಳಿಸಿದ ಸಂರಚನೆಯನ್ನು ಗುರುತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಸಂಪರ್ಕದ ಹೆಸರನ್ನು ಸಂಪಾದಿಸಬಹುದು ಆದರೆ ಅದರ ಹಿಂದಿನ ಫೈಲ್ ತನ್ನ ಮೂಲ ಗುರುತಿಸುವಿಕೆಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ.
ಓದಲು-ಮಾತ್ರ ದಾಸ್ತಾನಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಲೇಬಲ್ ಬದಲು ಗುರುತಿಸುವಿಕೆಯಿಂದ ಉದ್ದೇಶಿತ VPN ಆಯ್ಕೆಮಾಡಿ:
nmcli -f NAME,UUID,TYPE connection show
ಟಿಕೆಟ್ನಲ್ಲಿ ಅಂಟಿಸುವ ಯಾವುದೇ ದಾಸ್ತಾನಿನಿಂದ ಎಂಡ್ಪಾಯಿಂಟ್ ಹೋಸ್ಟ್ಹೆಸರುಗಳು ಮತ್ತು ಗುರುತಿನ ಲೇಬಲ್ಗಳನ್ನು ಹೊರಗಿಡಿ. ಉಪಯುಕ್ತ ಭಾಗ ಪ್ರಕಾರ ಮತ್ತು ಗುರುತಿಸುವಿಕೆ; ಉಳಿದದ್ದು ಅಪರಿಚಿತರಿಗೆ ಬೇಕಿಲ್ಲದ ಸಂದರ್ಭ. ಹಂಚಿಕೊಳ್ಳುವ ಮೊದಲು ಉಳಿದದ್ದನ್ನು ಮರೆಮಾಡಿ ಮತ್ತು ನೀವು ಹಾಗೆ ಮಾಡಿದ್ದೀರಿ ಎಂದು ಹೇಳಿ, ಇಲ್ಲದಿದ್ದರೆ ಖಾಲಿ ಜಾಗಗಳ ಅರ್ಥ ಏನೆಂದು ಯಾರೂ ಯೋಚಿಸಬೇಕಾಗಿಲ್ಲ.
keyfile ಸ್ಥಳಗಳು ಒಂದೇ ಅರ್ಥವನ್ನು ನೀಡುವುದಿಲ್ಲ
ಸ್ಥಳೀಯ keyfile ಪ್ಲಗಿನ್ನೊಂದಿಗೆ, ಸಂಪರ್ಕ ಫೈಲ್ಗಳು ಮೂರು ಡೈರೆಕ್ಟರಿಗಳಲ್ಲಿ ಕಾಣಿಸಬಹುದು, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸ ಸ್ಥಿರತೆ, ಅನುಕೂಲವಲ್ಲ.
| Location | Role |
|---|---|
/etc/NetworkManager/system-connections/ | Administrator-owned persistence |
/usr/lib/NetworkManager/system-connections/ | Package-supplied defaults, replaced on upgrade |
/run/NetworkManager/system-connections/ | Runtime state, regenerated and not durable |
ರನ್ಟೈಮ್ ಪ್ರತಿಯನ್ನು ಸಂಪಾದಿಸುವುದು ಮುಂದಿನ ಆರಂಭದವರೆಗೆ ಯಶಸ್ವಿಯಾಗಿ ಕಾಣುತ್ತದೆ, ಆಗ ಬದಲಾವಣೆ ಆವಿಯಾಗಿ ಫೈಲ್ ನಿಗೂಢವಾಗಿ ಹಿಂತಿರುಗಿಸಲ್ಪಟ್ಟಂತೆ ಕಾಣುತ್ತದೆ. ಪ್ಯಾಕೇಜ್ ಒದಗಿಸಿದ ಪ್ರತಿಯನ್ನು ಸಂಪಾದಿಸುವುದು ಅಪ್ಗ್ರೇಡ್ ಅದನ್ನು ಬದಲಿಸುವವರೆಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅದು ಅದೇ ಪಾಠದ ನಿಧಾನ ಮತ್ತು ಹೆಚ್ಚು ಗೊಂದಲದ ಆವೃತ್ತಿ.
keyfile ದಾಖಲೆ ಗೌರವಿಸಲು ಯೋಗ್ಯವಾದ ವಿವರವನ್ನು ಸೇರಿಸುತ್ತದೆ: ಆ ಫೈಲ್ಗಳಲ್ಲಿ ಖಾಸಗಿ ಕೀಗಳು ಮತ್ತು ಪಾಸ್ಫ್ರೇಸ್ಗಳು ಇರಬಹುದು, ಮತ್ತು root ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಬಳಕೆದಾರರು ಓದಲು ಅಥವಾ ಬರೆಯಲು ಸಾಧ್ಯವಿರುವ ಯಾವುದೇ keyfile ಅನ್ನು NetworkManager ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಸೆಟ್ಟಿಂಗ್ ಹುಡುಕಲು ಡೈರೆಕ್ಟರಿ ಅನುಮತಿಗಳನ್ನು ವಿಸ್ತರಿಸುವುದು ನೀವು ಪರಿಶೀಲಿಸಲು ಬಯಸಿದ ಲೋಡಿಂಗ್ ನಡವಳಿಕೆಯನ್ನು ಮುರಿಯುತ್ತದೆ.
Netplan ಸ್ಥಿರತೆಯನ್ನು ಹೊಂದಿರುವಾಗ
Ubuntu ನಲ್ಲಿ, Netplan ದಾಖಲೆಯಲ್ಲಿ ವಿವರಿಸಲಾದ NetworkManager ಸಂಯೋಜನೆ, 23.10 ರಿಂದ ಲಭ್ಯವಿದೆ, ಬಾಳಿಕೆ ಬರುವ ಪ್ರತಿ ಎಲ್ಲಿ ಇರುತ್ತದೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ. ತಾತ್ಕಾಲಿಕವಲ್ಲದ ಸಂಪರ್ಕಗಳಿಗೆ ಅದು ಬರೆಯುತ್ತದೆ /etc/netplan/90-NM-<connection UUID>.yaml ಮತ್ತು ಇದರ ಅಡಿಯಲ್ಲಿ ತಾತ್ಕಾಲಿಕ NetworkManager ಪ್ರೊಫೈಲ್ ರಚಿಸುತ್ತದೆ: /run/NetworkManager/system-connections/.
ಇದು ವಿತರಣಾ ಸಂಯೋಜನೆ, ಪ್ರತಿ NetworkManager ಸ್ಥಾಪನೆಗೂ ನಿಯಮವಲ್ಲ. YAML ಫೈಲ್ ಹುಡುಕಲು ಹೋಗುವ ಮೊದಲು ಸ್ಥಾಪಿತ ಪ್ಯಾಕೇಜ್ಗಳು ನಿಜವಾಗಿ ಅದನ್ನು ಬಳಸುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ. ರನ್ಟೈಮ್ ಪ್ರೊಫೈಲ್ ಸಂಪಾದಿಸಲು ಯೋಗ್ಯವಾದ ಮೂಲವಲ್ಲದೆ ಬೇರೆ ಯಾವುದೋ ರಚಿಸಿದ ನಿರೂಪಣೆಯಾಗಿರಬಹುದು ಎಂಬುದನ್ನೂ ನೆನಪಿಡಿ. ಎರಡು ಆಜ್ಞೆಗಳ ಪರಿಶೀಲನೆ ತಪ್ಪು ಫೈಲ್ ಸಂಪಾದಿಸುವ ಒಂದು ಗಂಟೆಯನ್ನು ಉಳಿಸುತ್ತದೆ.
ದಾಖಲಿತ ಉದಾಹರಣೆ NetworkManager ಪಾಸ್ಥ್ರೂ ಡೇಟಾದೊಂದಿಗೆ Netplan nm-devices ಪ್ರಕಾರದ ಮೂಲಕ OpenVPN ಸಂಪರ್ಕವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ. Netplan ಗೆ ನಿರ್ದಿಷ್ಟ VPN ಕ್ಷೇತ್ರದ ಸ್ವಂತ ವ್ಯಾಖ್ಯಾನವಿಲ್ಲ ಎಂಬುದು ನಿಮ್ಮ ಉಳಿಸಿದ VPN ಕಳೆದುಹೋಗಿದೆ ಎಂದಲ್ಲ; ಅದು ಕ್ಷೇತ್ರವು ಅಪಾರದರ್ಶಕ ಡೇಟಾದಂತೆ ಪ್ರಯಾಣಿಸುತ್ತದೆ ಎಂದರ್ಥ.
ತಾತ್ಕಾಲಿಕ ಇಂಟರ್ಫೇಸ್ಗಳು ಪ್ರೊಫೈಲ್ಗಳಲ್ಲ
ಸಕ್ರಿಯಗೊಳಿಸುವಿಕೆ ಎಂದೂ ಉಳಿಯಬಾರದಿದ್ದ ತಾತ್ಕಾಲಿಕ ವರ್ಚುವಲ್ ಸಂಪರ್ಕಗಳು ಮತ್ತು ಇಂಟರ್ಫೇಸ್ಗಳನ್ನು ರಚಿಸುತ್ತದೆ. ಸಂಯೋಜನೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಹೊಸ YAML ಫೈಲ್ ಬರೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ /etc/netplan ನಲ್ಲಿ ಅವುಗಳ ಅನುಪಸ್ಥಿತಿ ಪೋಷಕ ಪ್ರೊಫೈಲ್ ಉಳಿಸಲ್ಪಟ್ಟಿದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.
ಕಾಣಿಸಿಕೊಂಡು ಮಾಯವಾಗುವ ಫೈಲ್ ಅನ್ನು ನೀವು ಬೆನ್ನಟ್ಟುತ್ತಿದ್ದರೆ, ನೀವು ಬಹುಶಃ ನಿಮ್ಮ ಸಂರಚನೆಯ ಬದಲು ಇವುಗಳ ಒಂದನ್ನು ನೋಡುತ್ತಿದ್ದೀರಿ. ಅದರ ವಿಷಯದಿಂದ ಯಾವುದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ಅದು ಮರುಆರಂಭವನ್ನು ಉಳಿದುಕೊಳ್ಳುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಮರುಬೂಟ್ನಲ್ಲಿ ಮಾಯವಾಗುವ ರನ್ಟೈಮ್ ಫೈಲ್ ಅದು ಎಂದೂ ಮೂಲವಾಗಿರಲಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಆ ಒಂದೇ ಅವಲೋಕನ ಇಡೀ ತನಿಖೆಯನ್ನು ಬೇರೆ ದಿಕ್ಕಿಗೆ ತಿರುಗಿಸುತ್ತದೆ. ಆಗ ಸಂಪಾದನೆ ಯಶಸ್ವಿಯಾಗಿ ಕಾಣಿಸಿದ್ದೇಕೆ ಎಂಬುದನ್ನೂ ಅದು ವಿವರಿಸುತ್ತದೆ.
ರಹಸ್ಯಗಳು ಮತ್ತು ಮಾಲೀಕತ್ವ
ಪ್ರೊಫೈಲ್ ಸಂಪೂರ್ಣವಾಗಿ ಬೇರೆಡೆ ಸಂಗ್ರಹವಾಗಿರುವ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಕೀಗೆ ಉಲ್ಲೇಖಿಸಬಹುದು, ಮತ್ತು ಪಾಸ್ವರ್ಡ್ NetworkManager ನದ್ದಾಗಿರಬಹುದು, ಬಳಕೆದಾರ-ಅವಧಿಯ ರಹಸ್ಯ ಏಜೆಂಟ್ ಒದಗಿಸಬಹುದು, ಅಥವಾ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಉಳಿಸದಿರಬಹುದು. ಆದ್ದರಿಂದ ಒಂದು ಫೈಲ್ ಪತ್ತೆ ಮಾಡುವುದು ಮೇಲ್ವಿಚಾರಣೆ ಇಲ್ಲದ ಆರಂಭಕ್ಕೆ ಏನು ಬೇಕು ಎಂಬುದರ ಬಗ್ಗೆ ಬಹಳ ಕಡಿಮೆ ನಿರ್ಣಯಿಸುತ್ತದೆ.
ರಹಸ್ಯ ಮೌಲ್ಯಗಳನ್ನು ಮುದ್ರಿಸದೆ ಉಲ್ಲೇಖಗಳು ಮತ್ತು ರಹಸ್ಯ-ಫ್ಲ್ಯಾಗ್ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ಡೆಸ್ಕ್ಟಾಪ್ ಲಾಗಿನ್ ಬೂಟ್ ಸಮಯದಲ್ಲಿ ಇಲ್ಲದಿದ್ದ ಏಜೆಂಟ್ ಅನ್ನು ಲಭ್ಯವಾಗಿಸಬಹುದು, ಮತ್ತು ರಚಿಸಿದ ರನ್ಟೈಮ್ ಫೈಲ್ ನಕಲಿಸುವುದು ಆ ಏಜೆಂಟ್ ಅನ್ನು ಮರುಸೃಷ್ಟಿಸುವುದಿಲ್ಲ. ಪ್ರಾಯೋಗಿಕ ಲಕ್ಷಣ ಎಂದರೆ ವ್ಯಕ್ತಿ ಲಾಗಿನ್ ಆದಾಗ ಸಂಪರ್ಕಗೊಳ್ಳುವ ಮತ್ತು ಯಂತ್ರ ಒಂಟಿಯಾಗಿ ಪ್ರಾರಂಭವಾದಾಗ ವಿಫಲವಾಗುವ ಸುರಂಗ. ಆ ಮಾದರಿ ರೂಟಿಂಗ್ಗಲ್ಲ, ರಹಸ್ಯ ಮಾಲೀಕತ್ವಕ್ಕೆ ಸೂಚಿಸುತ್ತದೆ.
ಅನುಮೋದಿತ ಬದಲಾವಣೆಗಳನ್ನು ಸಂಪರ್ಕವನ್ನು ಹೊಂದಿರುವ ನಿರ್ವಾಹಕರ ಮೂಲಕ ಮಾಡಿ, ನಂತರ ಉಳಿಸಿದ ಗುರುತಿಸುವಿಕೆ ಮತ್ತು ಪರಿಣಾಮಕಾರಿ ಸಂಪರ್ಕ ಎರಡನ್ನೂ ಪರಿಶೀಲಿಸಿ. ಒಂದೇ ಸ್ಥಿರ ಮಾಲೀಕರನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ಏಕೆಂದರೆ ಆಮದು, ರಚಿಸಿದ keyfile ಮತ್ತು YAML ಮೂಲವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಸಂಪಾದಿಸುವುದು ಮುಂದಿನ ಮರುಸಂಪರ್ಕ ಏನನ್ನು ಬಳಸುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಮೂರು ಸ್ಪರ್ಧಾತ್ಮಕ ವಿವರಣೆಗಳನ್ನು ಬಿಡುತ್ತದೆ. ನಿಜವಾಗಿ ಉಳಿಯುವುದನ್ನು ಆರಿಸಿ, ಅದನ್ನಷ್ಟೇ ಸಂಪಾದಿಸಿ, ಮತ್ತು ಯಾವ ಫೈಲ್ ಅನ್ನು ಅಧಿಕೃತವೆಂದು ಪರಿಗಣಿಸಿದಿರಿ ಎಂಬುದನ್ನು ಟಿಕೆಟ್ನಲ್ಲಿ ದಾಖಲಿಸಿ. ಮುಂದಿನ ವ್ಯಕ್ತಿ ಒಂದು ಸಾಲಿನ ಮೂಲಕ್ಕಾಗಿ ನಿಮಗೆ ಕೃತಜ್ಞರಾಗಿರುತ್ತಾರೆ.