openvpn3 session-start ನಿಮ್ಮ ರುಜುವಾತು ಫೈಲ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ

2.x ಕ್ಲೈಂಟ್ ಜೊತೆಗೆ ಸಂಪರ್ಕಿಸಿದರೆ ಪ್ರೊಫೈಲ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ; ಅದೇ ಫೈಲ್ ಅನ್ನು 3.x ಕ್ಲೈಂಟ್ ಗೆ ನೀಡಿದರೆ ಅದು ಪಾಸ್ವರ್ಡ್ ಪ್ರಾಂಪ್ಟ್ ನಲ್ಲಿ ನಿಲ್ಲುತ್ತದೆ. --auth-user-pass creds.txt ಅನ್ನು openvpn3 session-start ಗೆ ನೀಡಿದರೂ ಫಲಿತಾಂಶ ಅದೇ, ಏಕೆಂದರೆ ಹೊಸ ಕ್ಲೈಂಟ್ ನಲ್ಲಿ ಆ ಫೈಲ್ ಓದುವ ಹಂತವಿಲ್ಲ. ಈ ನಿರಾಕರಣೆ ಉದ್ದೇಶಪೂರ್ವಕ: ರುಜುವಾತುಗಳು ಸೆಷನ್ ಗೆ ಸೇರಿದ್ದು, ಸೆಷನ್ ಅನ್ನು ಟರ್ಮಿನಲ್ ನ ಪ್ರಕ್ರಿಯೆ ಅಲ್ಲ, ಸೇವೆಯು ಸೃಷ್ಟಿಸುತ್ತದೆ. ಸಂವಾದಾತ್ಮಕ ಪ್ರಾಂಪ್ಟ್ ಮತ್ತು autoload ಸಹಾಯಕದ ನಡುವೆ ಆಯ್ಕೆಮಾಡಿ, ಪ್ರತಿಯೊಂದೂ ಏನನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಎಂದು ತಿಳಿಯಿರಿ.

ಉಳಿಸಿದ ಫೈಲ್ ಗೆ ಹೋಗುವ ಜಾಗ ಏಕೆ ಇಲ್ಲ

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

ಹಳೆಯ ಮಾದರಿಯನ್ನು ಹೆಸರಿಸುವುದು ಒಳ್ಳೆಯದು, ಏಕೆಂದರೆ ಅದನ್ನು ಬಿಡುವುದು ಸುಲಭವಾಗುತ್ತದೆ: ಪ್ರೊಫೈಲ್ ರುಜುವಾತು ಫೈಲ್ ಅನ್ನು ಉಲ್ಲೇಖಿಸುತ್ತದೆ, ಟನೆಲ್ ಪ್ರಾರಂಭವಾದಾಗ ಡೀಮನ್ ಅದನ್ನು ಓದುತ್ತದೆ. ಹೊಸ ಮಾದರಿಯಲ್ಲಿ ರುಜುವಾತುಗಳು ಸೆಷನ್ ಗೆ ಸೇರಿದ್ದು, ಆ ಸೆಷನ್ ಪ್ರಾರಂಭವಾದಾಗ ಒದಗಿಸಲಾಗುತ್ತದೆ. openvpn3 session-start --config work.ovpn ಅವನ್ನು ಕೇಳುತ್ತದೆ, --auth-user-pass creds.txt ತಿರಸ್ಕರಿಸಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ಆ ಮಾರ್ಗದಲ್ಲಿ ಫೈಲ್ ತೆರೆಯುವ ಯಾವುದೂ ಇಲ್ಲ. ನೀವು ಕಾಣುವ ಪ್ರತಿ 2.x ಪಾಕವಿಧಾನವೂ ಇನ್ನು ಇಲ್ಲದ ಹಂತವನ್ನು ಊಹಿಸುತ್ತದೆ.

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

ಪ್ರಾಂಪ್ಟ್ ಮಾರ್ಗ ಮತ್ತು ಅದು ಬಿಡುವ ಸೆಷನ್

ಸೆಷನ್ ಪ್ರಾರಂಭವಾದಾಗ ಪಾಸ್ವರ್ಡ್ ಒದಗಿಸುವುದು ಉದ್ದೇಶಿತ ಕೆಲಸದ ಹರಿವು. ಕ್ಲೈಂಟ್ ಒಮ್ಮೆ ಕೇಳಿ, ರುಜುವಾತುಗಳನ್ನು ಸೆಷನ್ ಬ್ಯಾಕೆಂಡ್ ಗೆ ನೀಡಿ ಮುಂದುವರಿಯುತ್ತದೆ:

openvpn3 session-start --config work.ovpn
openvpn3 sessions-list

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

ಮುಂದೆ ಮನುಷ್ಯನಿರುವ ವರ್ಕ್ ಸ್ಟೇಷನ್ ಗೆ ಇದು ಅತ್ಯಂತ ಸುರಕ್ಷಿತ ಆಯ್ಕೆಯೂ ಆಗಿದೆ, ಏಕೆಂದರೆ ರಕ್ಷಿಸಲು ಅಥವಾ ಮರೆಯಲು ಸಂಗ್ರಹಿಸಿದ ರಹಸ್ಯವಿಲ್ಲ. ಯಾರೂ ಟೈಪ್ ಮಾಡಲು ಇಲ್ಲದ ಸ್ಥಳದಲ್ಲಿ ಮಾತ್ರ ಇದು ಸೂಕ್ತವಲ್ಲ.

ಕೀಬೋರ್ಡ್ ಮುಂದೆ ಮನುಷ್ಯನಿಲ್ಲದ ಸ್ವಯಂಚಾಲನೆ

ಯಂತ್ರವು ಮನುಷ್ಯನಿಲ್ಲದೆ ಸಂಪರ್ಕಿಸಬೇಕಾದ ಸ್ಥಳದಲ್ಲಿ ಯೋಜನೆ openvpn3-autoload ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಅದು ಪ್ರೊಫೈಲ್ ಗಳ ಡೈರೆಕ್ಟರಿ ಮತ್ತು ಪ್ರತಿ ಪ್ರೊಫೈಲ್ ಗೆ ಹೊಂದುವ ವಿವರಣಕಾರಕವನ್ನು ಓದುತ್ತದೆ, ವಿವರಣಕಾರಕವು ರುಜುವಾತುಗಳನ್ನು ಸ್ಪಷ್ಟ ಪಠ್ಯದಲ್ಲಿ ಒದಗಿಸುತ್ತದೆ. ಸಹಾಯಕವು ಪ್ರತ್ಯೇಕ ಬೈನರಿ, ಸಾಮಾನ್ಯವಾಗಿ /usr/sbin/openvpn3-autoload ನಲ್ಲಿ, session-start ನ ಫ್ಲ್ಯಾಗ್ ಅಲ್ಲ. ಅದನ್ನು ಸಿದ್ಧಪಡಿಸುವುದು ಎಂದರೆ ಡೈರೆಕ್ಟರಿ ರಚಿಸುವುದು, ವಿವರಣಕಾರಕ ನಿರೀಕ್ಷಿಸುವ ಹೆಸರಿನಲ್ಲಿ ಪ್ರೊಫೈಲ್ ನಕಲಿಸುವುದು ಮತ್ತು ವಿವರಣಕಾರಕ ಬರೆಯುವುದು.

ಬಳಕೆದಾರ ವಾರು ಸಿದ್ಧತೆ ಹೀಗಿರುತ್ತದೆ, ಸೆಷನ್ ನ ಮಾಲೀಕರಾಗುವ ಖಾತೆಯಿಂದ ಚಲಾಯಿಸಿ. ಡೈರೆಕ್ಟರಿ ಮೋಡ್ ಇತರ ಸ್ಥಳೀಯ ಬಳಕೆದಾರರನ್ನು ಹೊರಗಿಡುತ್ತದೆ:

mkdir -m700 -p ~/.openvpn3/autoload
cp work.ovpn ~/.openvpn3/autoload/client.conf
$EDITOR ~/.openvpn3/autoload/client.autoload

ವಿವರಣಕಾರಕ ರುಜುವಾತುಗಳನ್ನು ಹೆಸರಿಸಿ ಸ್ವಯಂ ಪ್ರಾರಂಭವನ್ನು ಕೇಳುತ್ತದೆ. ಪಾಸ್ವರ್ಡ್ ಮೌಲ್ಯವನ್ನು ಆವೃತ್ತಿ ನಿಯಂತ್ರಣದಿಂದ ಹೊರಗಿಡಿ:

{
  "autostart": true,
  "user-auth": {
    "autologin": true,
    "username": "svc-vpn",
    "password": "change-this-value"
  }
}

ನಂತರ ಸಹಾಯಕವನ್ನು ಒಮ್ಮೆ ಕರೆದು ಸೆಷನ್ ಕಾಣಿಸಿಕೊಳ್ಳುವುದನ್ನು ದೃಢೀಕರಿಸಿ. ಎರಡನೇ ಆಜ್ಞೆ ಪರಿಶೀಲನೆ, ಇನ್ನೊಂದು ಸಿದ್ಧತೆ ಹಂತವಲ್ಲ:

/usr/sbin/openvpn3-autoload --directory ~/.openvpn3/autoload
openvpn3 sessions-list

ಬೂಟ್ ಸಮಯದಲ್ಲಿ openvpn3-autoload.service ಎಂಬ ಪ್ಯಾಕೇಜ್ ಮಾಡಿದ ಘಟಕವು ಬಳಕೆದಾರ ವಾರು ಡೈರೆಕ್ಟರಿ ಅಲ್ಲ, ಸಿಸ್ಟಮ್ ವ್ಯಾಪಿ ಡೈರೆಕ್ಟರಿ /etc/openvpn3/autoload ಬಳಸುತ್ತದೆ. ಆ ಸ್ಥಳಕ್ಕೆ root ಮಾಲೀಕತ್ವ ಮತ್ತು ಹೆಚ್ಚು ಕಟ್ಟುನಿಟ್ಟಿನ ಮೋಡ್ ಬೇಕು, ವಿವರಣಕಾರಕವು ಇನ್ನೂ ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಸ್ಪಷ್ಟ ಪಠ್ಯದಲ್ಲಿ ಹೊಂದಿದೆ. ರಾಜಿ ಸ್ಪಷ್ಟ: ಪಾಸ್ವರ್ಡ್ ಈಗ ಡಿಸ್ಕ್ ನಲ್ಲಿದೆ, ಆದ್ದರಿಂದ ಆ ಡೈರೆಕ್ಟರಿಯನ್ನು ರಹಸ್ಯವೆಂದು ಪರಿಗಣಿಸಿ, ಹೋಸ್ಟ್ ನ ಹೊರಗಿನ ಬ್ಯಾಕಪ್ ಗಳಿಂದ ಹೊರಗಿಡಿ, ಮತ್ತು ಮನುಷ್ಯನಿರುವಾಗಲೆಲ್ಲ ಸಂವಾದಾತ್ಮಕ ಮಾರ್ಗವನ್ನು ಆರಿಸಿ.

ಪಾಸ್ವರ್ಡ್ ವೈಫಲ್ಯಗಳಂತೆ ಕಾಣುವ ಬಸ್ ವೈಫಲ್ಯಗಳು

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

ಕೆಳಗಿನ ಆಜ್ಞೆಗಳು ಈ ಎರಡನ್ನೂ ಬೇರ್ಪಡಿಸುತ್ತವೆ. ಮೊದಲನೆಯದು ಬ್ಯಾಕೆಂಡ್ ಚಾಲನೆಯಲ್ಲಿದೆಯೇ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ; ಎರಡನೆಯದು ಇತ್ತೀಚಿನ ಬಸ್ ದೋಷಗಳನ್ನು ತೋರಿಸುತ್ತದೆ:

systemctl status openvpn3-service-client
journalctl -b -u openvpn3-service-client --no-pager | tail -20

ಇನ್ನೊಂದು ಸಾಮಾನ್ಯ ತಪ್ಪು ಓದು ಎಂದರೆ ಕಾಣಿಸಿಕೊಂಡು ತಕ್ಷಣ ಮಾಯವಾಗುವ ಸೆಷನ್. ಆ ಮಾದರಿ ಸಾಮಾನ್ಯವಾಗಿ ಸೈಟ್ ಸ್ಥಳೀಯ ಸೆಟ್ಟಿಂಗ್ ಗಳು ಎಂದಿಗೂ ಅನ್ವಯವಾಗಿಲ್ಲ ಎಂದು ಅರ್ಥ, ಆದ್ದರಿಂದ ಟನೆಲ್ ಅದನ್ನು ಉಪಯುಕ್ತಗೊಳಿಸುವ ರೂಟ್ ಗಳು ಮತ್ತು ರಿಸಾಲ್ವರ್ ಬದಲಾವಣೆಗಳಿಲ್ಲದೆ ಮೇಲೆದ್ದಿತು. ಕೊನೆಯ ಸಾಲಲ್ಲ, ಕ್ರಮವನ್ನು ಓದಿ: ಸೆಷನ್ ರಚಿಸಲಾಗಿದೆಯೇ, ಸಂಪರ್ಕಿತ ಸ್ಥಿತಿ ತಲುಪಿದೆಯೇ, ಉಳಿದುಕೊಂಡಿದೆಯೇ ಎಂಬುದು ಮೂರು ಪ್ರತ್ಯೇಕ ಸತ್ಯಗಳು.

ಹಳೆಯ ಕ್ಲೈಂಟ್ ಇನ್ನೂ ಬಳಕೆಯಲ್ಲಿದ್ದಾಗ

2.x ಕ್ಲೈಂಟ್ ಇನ್ನೂ ರುಜುವಾತು ಫೈಲ್ ಸ್ವೀಕರಿಸುತ್ತದೆ, ಮತ್ತು ಕೀರಿಂಗ್ ರಹಸ್ಯ ಡಿಸ್ಕ್ ತಲುಪದೆಯೇ ಅದರ ಪ್ರಾಂಪ್ಟ್ ಗೆ ಉತ್ತರಿಸಬಲ್ಲದು. ರ್ಯಾಪರ್ ನಮೂದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಫೈಲ್ ಪಾಸ್ವರ್ಡ್ ಬದಲು ಹುಡುಕಾಟವನ್ನು ಹೆಸರಿಸುತ್ತದೆ. ಈ ವ್ಯವಸ್ಥೆ ಅನ್ಲಾಕ್ ಆದ ಕೀರಿಂಗ್ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಲಾಗಿನ್ ಸೆಷನ್ ಇಲ್ಲದ ಕಂಟೇನರ್ ಅಥವಾ ಯಾರಾದರೂ ಸೈನ್ ಇನ್ ಮಾಡುವ ಮೊದಲು ಪ್ರಾರಂಭವಾಗುವ ಘಟಕ ಅದನ್ನು ಒದಗಿಸಲಾರದು. ಆಗ ಹುಡುಕಾಟ ಸಾಧನವು ಬರೆಯಲಾಗದ ಸಂಗ್ರಹವನ್ನು ವರದಿ ಮಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಕೀರಿಂಗ್ ದೋಷವು ರುಜುವಾತು ದೋಷದಂತೆ ಕಾಣುತ್ತದೆ.

ಅಂತಹದ್ದನ್ನು ನಿರ್ಮಿಸುವ ಮೊದಲು, ಪ್ರೊಫೈಲ್ ನಲ್ಲಿನ keepalive ಸೆಟ್ಟಿಂಗ್ ಮರುಪ್ರಾರಂಭದ ಅಗತ್ಯವನ್ನೇ ತೆಗೆದುಹಾಕುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಚಾಲನೆಯಲ್ಲಿರುವ ಸೆಷನ್ ನೀವು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಪ್ರಾಂಪ್ಟ್ ಅನ್ನು ಎಂದಿಗೂ ತಲುಪುವುದಿಲ್ಲ.