ipsec.conf ಅಥವಾ swanctl.conf? ಒಂದು strongSwan ಫ್ರಂಟೆಂಡ್ ಆಯ್ಕೆಮಾಡಿ

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

ಎರಡು ಫೈಲ್ಗಳು, ಎರಡು ಲೋಡರ್ಗಳು, ಒಂದು ಡೀಮನ್

ಹಳೆಯ starter ವ್ಯವಸ್ಥೆ ipsec.conf ಓದುತ್ತದೆ ಮತ್ತು ತನ್ನ ಹಳೆಯ ನಿರ್ವಹಣಾ ಏಕೀಕರಣದ ಮೂಲಕ ಸಂಪರ್ಕಗಳನ್ನು charon ಗೆ ಒಪ್ಪಿಸುತ್ತದೆ. ಅದರ ಕಾರ್ಯಾಚರಣಾ ಪ್ರವೇಶ ಬಿಂದು ipsec ಆಜ್ಞೆ.

swanctl ವ್ಯವಸ್ಥೆ VICI ಮೂಲಕ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಲೋಡ್ ಮಾಡುತ್ತದೆ, swanctl.conf ಓದುತ್ತದೆ ಮತ್ತು swanctl ಆಜ್ಞೆಯಿಂದ ನಡೆಯುತ್ತದೆ. systemd ನ ಸ್ಥಳೀಯ charon ಡೀಮನ್ ಈ ವಿಧಾನದೊಂದಿಗೆ ಏಕೀಕರಣಗೊಳ್ಳುತ್ತದೆ.

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

ಸ್ಥಾಪಿತ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು unit ಗಳನ್ನು ಓದಿ

ಓದಲು-ಮಾತ್ರ ಸ್ಥಿತಿಯಲ್ಲಿ ಪ್ರಾರಂಭಿಸಿ. Ubuntu 24.04 ನಲ್ಲಿ ಪ್ಯಾಕೇಜ್ ಹೆಸರುಗಳು ಬೇರೆ ಬೇರೆ: strongswan-starter, strongswan-swanctl ಮತ್ತು charon-systemd. ಕಾಣೆಯಾದ ಪ್ಯಾಕೇಜ್ ಉಪಯುಕ್ತ ಮಾಹಿತಿ, ಅದನ್ನು ಸ್ಥಾಪಿಸುವ ಸೂಚನೆ ಅಲ್ಲ.

ಒಂದೇ ಹಂತದಲ್ಲಿ ಪ್ಯಾಕೇಜುಗಳು ಮತ್ತು unit ಗಳ ಪಟ್ಟಿ ಮಾಡಿ:

dpkg-query -W strongswan-starter strongswan-swanctl charon-systemd
systemctl list-unit-files '*strongswan*'

ನಂತರ ಸಕ್ರಿಯ unit ಮತ್ತು ಅದರ ಪ್ರಾರಂಭ ಆಜ್ಞೆಯನ್ನು ಪರಿಶೀಲಿಸಿ. unit ನ ಹೆಸರು ಯಾವ ಡೀಮನ್ ಸಂರಚನೆಯನ್ನು ಹೊಂದಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಆಜ್ಞಾ ಸಾಲು ಯಾವ ಫೈಲ್ಗಳನ್ನು ಓದಲು ಹೇಳಲಾಗಿತ್ತು ಎಂದು ದೃಢೀಕರಿಸುತ್ತದೆ. ಸಕ್ರಿಯಗೊಳಿಸಿದ ಆದರೆ ನಿಷ್ಕ್ರಿಯವಾಗಿರುವ unit ಈಗ ಚಾಲನೆಯಲ್ಲಿರುವ ಒಂದಕ್ಕಿಂತ ಬೇರೆ ಕಥೆ ಹೇಳುತ್ತದೆ.

ಸಕ್ರಿಯ unit strongswan-starter ಆಗಿದ್ದರೆ, ಮುಖ್ಯವಾದ ಫೈಲ್ ipsec.conf. ಅದು swanctl ಜೊತೆಗಿನ charon-systemd ಆಗಿದ್ದರೆ, ipsec.conf ಕೇವಲ ಅಲಂಕಾರ.

ಹೊಂದಿಕೆಯಾಗುವ ನಿಯಂತ್ರಣ ಮಾರ್ಗ ಬಳಸಿ

ಪ್ರತಿ ಫ್ರಂಟೆಂಡ್ಗೂ ಸಂಪರ್ಕಗಳು ಮತ್ತು ಸಂಘಗಳ ಬಗ್ಗೆ ತನ್ನದೇ ನೋಟವಿದೆ. swanctl --list-conns ಲೋಡ್ ಆದ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ತೋರಿಸುತ್ತದೆ ಮತ್ತು swanctl --list-sas ಸಕ್ರಿಯ ಸಂಘಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ಹಳೆಯ ಮಾರ್ಗ ipsec statusall ಬಳಸುತ್ತದೆ.

ಎರಡನ್ನೂ ಬೆರೆಸಿದರೆ ದಾರಿ ತಪ್ಪಿಸುವ ದೋಷಗಳಾಗುತ್ತವೆ. ಕಾಣೆಯಾದ VICI ಸಾಕೆಟ್ ಅಥವಾ ನಿರಾಕರಿಸಲಾದ ನಿಯಂತ್ರಣ ವಿನಂತಿ ನಿರ್ವಹಣಾ ಮಾರ್ಗದ ಸಮಸ್ಯೆ, ಪ್ರತಿಸ್ಪರ್ಧಿ ದೃಢೀಕರಣವನ್ನು ನಿರಾಕರಿಸಿದ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ.

ಚಾಲನೆಯಲ್ಲಿರುವ ಡೀಮನ್ಗೆ ಸೇರಿದ ನೋಟವನ್ನು ಓದಿ, ನಂತರ ಫಲಿತಾಂಶವನ್ನು ಅರ್ಥೈಸಿ. ಆ ನೋಟದಲ್ಲಿ ಸಂಪರ್ಕ ಇಲ್ಲದಿದ್ದರೆ, ಸಮಸ್ಯೆ ಲೋಡಿಂಗ್ನಲ್ಲಿದೆ, ಮಾತುಕತೆಯಲ್ಲಲ್ಲ.

ಸ್ವರೂಪ ಎಂದರೆ IKE ಆವೃತ್ತಿ ಅಲ್ಲ

ಹಳೆಯ ಪ್ರೊಫೈಲ್ keyexchange=ikev1 ಮೂಲಕ IKEv1 ಆಯ್ಕೆಮಾಡುತ್ತದೆ. swanctl ಸಂಪರ್ಕ ಆವೃತ್ತಿ ಸೆಟ್ಟಿಂಗ್ ಬಳಸುತ್ತದೆ, ಅಲ್ಲಿ 1 IKEv1 ಆಯ್ಕೆಮಾಡುತ್ತದೆ. ಇವು ಒಂದೇ ಕಲ್ಪನೆಯ ಎರಡು ಶಬ್ದಕೋಶಗಳು, ಪರಿವರ್ತನೆ ಅಲ್ಲ.

ಪ್ರತಿಸ್ಪರ್ಧಿಯ ವಿಳಾಸಗಳು, ಸ್ಥಳೀಯ ಮತ್ತು ದೂರದ ಗುರುತುಗಳು, ರುಜುವಾತು ಮೂಲಗಳು, ಪ್ರಸ್ತಾವಗಳು ಮತ್ತು child ಆಯ್ಕೆಕಾರಕಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ನಕ್ಷೆ ಮಾಡಬೇಕು. left/right ಬ್ಲಾಕ್ ಅನ್ನು swanctl ವಾಕ್ಯರಚನೆಗೆ ಅಂಟಿಸುವುದರಿಂದ ಇವುಗಳಲ್ಲಿ ಏನೂ ಆಗುವುದಿಲ್ಲ.

ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿಯನ್ನು ಮಾತ್ರ ಬದಲಿಸುವುದು ಅತಿ ಸಾಮಾನ್ಯ ಅರ್ಧ-ವಲಸೆ. ಅದು ಲೋಡ್ ಆಗಿ, ನಂತರ ಆವೃತ್ತಿಗೆ ಸಂಬಂಧಿಸದ ಕಾರಣಗಳಿಂದ ದೃಢೀಕರಣದಲ್ಲಿ ವಿಫಲವಾಗುವ ಫೈಲ್ ಅನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ. IKEv1 ಸ್ವತಃ RFC 9395 ಮೂಲಕ ಹಳೆಯದಾಗಿದೆ, ಆದ್ದರಿಂದ ಇನ್ನೂ ಅದನ್ನು ಬೇಡುವ ಇರುವ ಪ್ರತಿಸ್ಪರ್ಧಿಗೆ ದಾಖಲಿತ ಹೊಂದಾಣಿಕೆ ಮಿತಿ ಮತ್ತು ವಲಸೆ ಮಾರ್ಗ ಯೋಗ್ಯ, ಹೊಸ ಡೀಫಾಲ್ಟ್ ಅಲ್ಲ.

ಪ್ರೊಫೈಲ್ ಮುಟ್ಟುವ ಮೊದಲು ಲೋಡರ್ ಪರಿಶೀಲಿಸಿ

ಮೊದಲು ಲೋಡರ್ ಪರಿಶೀಲನೆ ನಡೆಸಿ, ನಂತರ ಉದ್ದೇಶಿತ ಸಂಪರ್ಕ ಲೋಡ್ ಮಾಡಿ, ನಂತರ ಮಾತುಕತೆ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿ, ಕೊನೆಗೆ ಸಂರಕ್ಷಿತ ಸಂಚಾರ ಮಾರ್ಗ. ಪ್ರತಿ ಹಂತಕ್ಕೂ ಬೇರೆ ವಿಫಲತೆಯ ಗುರುತು ಇರುತ್ತದೆ.

ಎರಡು ನಿಯಂತ್ರಣ ಮಾರ್ಗಗಳು ಲೋಡಿಂಗ್ ಪ್ರಶ್ನೆಗೆ ನೇರವಾಗಿ ಉತ್ತರಿಸುತ್ತವೆ:

swanctl --list-conns
ipsec statusall

ಈ ಆಜ್ಞೆಗಳಲ್ಲಿ ಒಂದೇ ನಿಮ್ಮ ಹೋಸ್ಟ್ಗೆ ಸೇರಿದ್ದು. ಎರಡನ್ನೂ ಚಲಾಯಿಸಿ ಔಟ್ಪುಟ್ ಹೋಲಿಸುವುದು ಯಾವುದು ನಿಮಗೆ ಸುಳ್ಳು ಹೇಳುತ್ತಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯುವ ದಾರಿ, ರೋಗನಿರ್ಣಯ ವಿಧಾನ ಅಲ್ಲ.

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