FreeBind ಹಾಗೂ After=: systemd ಸಾಕೆಟ್ ಅನ್ನು VPN ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸುವುದು

ಬೂಟ್ ಸಮಯದಲ್ಲಿ ಸ್ಥಿರ VPN ವಿಳಾಸಕ್ಕೆ ಬಂಧಿಸುವ ಸಾಕೆಟ್ ಘಟಕವು ಟನೆಲ್ ಅದನ್ನು ನಿಗದಿಪಡಿಸುವ ಮೊದಲೇ ವಿಫಲವಾಗಬಹುದು, ಮತ್ತು ಅದರ ಹಿಂದಿನ ಸೇವೆ ಎಂದಿಗೂ ಪ್ರಾರಂಭವಾಗುವುದಿಲ್ಲ. ಎರಡು ಸ್ವಿಚ್‌ಗಳು ಪರಿಹಾರದಂತೆ ಕಾಣುತ್ತವೆ ಮತ್ತು ಆ ಸಮಸ್ಯೆಯ ಬೇರೆ ಬೇರೆ ಅರ್ಧಗಳನ್ನು ಪರಿಹರಿಸುತ್ತವೆ. ವಿಳಾಸ ಇನ್ನೂ ಇಲ್ಲದಿರುವಾಗಲೇ FreeBind systemd ಗೆ ಆಲಿಸುವವನನ್ನು ರಚಿಸಲು ಅನುಮತಿಸುತ್ತದೆ. After= ಕೇವಲ ಕೆಲಸಗಳನ್ನು ಜೋಡಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ವಸ್ತುಗಳು ಯಾವಾಗ ಪ್ರಾರಂಭವಾಗುತ್ತವೆ ಎಂಬುದನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದರೆ ವಿಳಾಸ ಬೇಗ ಬರುವಂತೆ ಮಾಡುವುದಿಲ್ಲ.

ಎರಡು ಬೇರೆ ಸಮಸ್ಯೆಗಳು, ಎರಡು ಬೇರೆ ಸ್ವಿಚ್‌ಗಳು

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

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

FreeBind: ವಿಳಾಸಕ್ಕಿಂತ ಮೊದಲು ಆಲಿಸುವವನು

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

[Socket]
ListenStream=
ListenStream=10.8.0.1:8443
FreeBind=yes

ಖಾಲಿ ನಿಗದಿ ಹೊಸ ನಮೂದನ್ನು ಸೇರಿಸುವ ಮೊದಲು ವಿಕ್ರೇತ ಘಟಕದಿಂದ ಬಂದ ಆಲಿಸುವ ನಮೂದುಗಳನ್ನು ಅಳಿಸುತ್ತದೆ, ಇದು ಪ್ರತಿ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲೂ ಉತ್ತರಿಸುವ ಉಳಿದ wildcard ಆಲಿಸುವವನನ್ನು ತಡೆಯುತ್ತದೆ. ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ನಿಮ್ಮದರಿಂದ ಬದಲಿಸಿ ಮತ್ತು ಕೇವಲ drop-in ಫೈಲ್ ಅಲ್ಲ, ಪರಿಣಾಮಕಾರಿ ಘಟಕವನ್ನು ಪರಿಶೀಲಿಸಿ. ಪ್ಯಾಕೇಜ್ ಫೈಲ್ ಅನ್ನು ಅಲ್ಲೇ ಸಂಪಾದಿಸುವ ಬದಲು ಘಟಕದ ಹೆಸರಿನಲ್ಲಿ drop-in ಬಳಸಿ, ಏಕೆಂದರೆ ಮುಂದಿನ ಪ್ಯಾಕೇಜ್ ನವೀಕರಣ ಸಂಪಾದನೆಯನ್ನು ಮೇಲೆ ಬರೆಯುತ್ತದೆ ಮತ್ತು ಉದ್ದೇಶದ ಯಾವುದೇ ಗುರುತು ಉಳಿಯುವುದಿಲ್ಲ. ನಂತರ ಸಾಕೆಟ್ ಘಟಕ ನಿರೀಕ್ಷಿಸುವ ಮರುಲೋಡ್ ಮತ್ತು ಮರುಪ್ರಾರಂಭ ಕಾರ್ಯವಿಧಾನದ ಮೂಲಕ ಅನ್ವಯಿಸಿ.

systemd ಸಾಕೆಟ್ ಉಲ್ಲೇಖ ಈ ಆಯ್ಕೆಯ ಹಿಂದಿನ IPv4 ಮತ್ತು IPv6 ನಡವಳಿಕೆಯನ್ನು ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಮುಖ್ಯ ವಿವರವೆಂದರೆ ಅದು ಬಂಧನಕ್ಕೆ ಅನ್ವಯಿಸುತ್ತದೆ, ರೂಟಿಂಗ್‌ಗೆ ಅಲ್ಲ. ಅದರಲ್ಲಿ ಯಾವುದೂ ವಿಳಾಸ ನಿಗದಿಪಡಿಸುವುದಿಲ್ಲ ಅಥವಾ VPN ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. FreeBind ಆಲಿಸುವವನಿಗೆ ನೀಡಿದ ಅನುಮತಿ, ಇಂಟರ್ಫೇಸ್‌ನ ಬದಲಿ ಅಲ್ಲ.

After= ಮತ್ತು Wants=: ಕ್ರಮವೇ ಸಿದ್ಧತೆ ಅಲ್ಲ

ಕ್ರಮ ಮತ್ತು ಅಗತ್ಯ ಬೇರೆ ಬೇರೆ ಅಕ್ಷಗಳು, ಮತ್ತು ಅವನ್ನು ಬೆರೆಸುವುದು ಸರಿಯಾದ ಕ್ರಮದಲ್ಲಿ ಪ್ರಾರಂಭವಾಗಿಯೂ ವಿಫಲವಾಗುವ ಘಟಕಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ. After=vpn-client.service ಎಂದರೆ ಎರಡೂ ಕೆಲಸಗಳು ಪ್ರಾರಂಭವಾದರೆ ಇದು ಇನ್ನೊಂದು ಪ್ರಾರಂಭವಾಗುವವರೆಗೆ ಕಾಯುತ್ತದೆ ಎಂದಷ್ಟೇ. ಅದು VPN ಅನ್ನು ಎಳೆಯುವುದಿಲ್ಲ, ಮತ್ತು VPN ಸಂಪರ್ಕ ಮುಗಿಸುವವರೆಗೆ ಕಾಯುವುದಿಲ್ಲ.

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

systemctl cat ಮತ್ತು systemctl show -p After -p Wants -p Requires ಬಳಸಿ ಘಟಕ ನಿಜವಾಗಿ ಏನನ್ನು ಘೋಷಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ. ಮೂರು ಬೇರೆ ಡೈರೆಕ್ಟರಿಗಳ drop-in ನೀವು ಎಂದೂ ಬರೆಯದ ಸೂಚನೆಗಳನ್ನು ಸೇರಿಸಬಹುದು, ಮತ್ತು systemd ಪರಿಣಾಮಕಾರಿ ಘಟಕವನ್ನು ಮಾತ್ರ ಓದುತ್ತದೆ.

network-online.target ಮಾಡದಿರುವುದು

network-online.target ನಂತರ ಜೋಡಿಸಿದ ಘಟಕ ನೆಟ್‌ವರ್ಕ್ ವ್ಯವಸ್ಥಾಪಕ ನೆಟ್‌ವರ್ಕ್ ಬಳಸಬಹುದು ಎಂದು ಘೋಷಿಸುವವರೆಗೆ ಕಾಯುತ್ತದೆ, ಇದು ಬೂಟ್‌ನ ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಬಿಂದು, ನಿರಂತರ ಷರತ್ತಲ್ಲ. ನಿರ್ದಿಷ್ಟ ಟನೆಲ್ ಮೇಲಿದೆಯೇ ಎಂದು ಅದು ಹೇಳುವುದಿಲ್ಲ, ಮತ್ತು ಮಧ್ಯಾಹ್ನದ ನಂತರ VPN ಮತ್ತೆ ಸಂಪರ್ಕಗೊಂಡಾಗ ಅದು ಮತ್ತೆ ಪ್ರಚೋದನೆಯಾಗುವುದಿಲ್ಲ. ಅದನ್ನು ಮರುಸಂಪರ್ಕ ಮಾನಿಟರ್ ಎಂದು ಪರಿಗಣಿಸುವುದು ಆ ಗುರಿಯ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ತಪ್ಪು ಓದು.

systemd ಯೋಜನೆ ಆ ವ್ಯತ್ಯಾಸವನ್ನು ನೇರವಾಗಿ ದಾಖಲಿಸುತ್ತದೆ, ಮತ್ತು ಪ್ರಾಯೋಗಿಕ ಪರಿಣಾಮವೆಂದರೆ ಟನೆಲ್ ವಿಳಾಸ ಬೇಕಾದ ಯಾವುದೂ ಅವಲಂಬನೆಯನ್ನು ತಾನೇ ಹೊಂದಿರಬೇಕು. network-online ಗಾಗಿ ಕಾಯ್ದು ನಂತರ ಟನೆಲ್ ವಿಳಾಸ ಬಂಧಿಸುವ ಘಟಕ ಟನೆಲ್ ಆಕಸ್ಮಿಕವಾಗಿ ಮೊದಲು ಮೇಲೇರಿದಾಗ ಮಾತ್ರ ಸರಿ, ಮತ್ತು ಅದು ಆಕಸ್ಮಿಕ, ವಿನ್ಯಾಸವಲ್ಲ.

ನೀವು ನಿಜವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿದ ಜೀವನಚಕ್ರವನ್ನು ಪರೀಕ್ಷಿಸಿ

ಸ್ವಚ್ಛ ಬೂಟ್, ವಿಳಾಸ ಕಾಣಿಸಿದ ನಂತರದ ವಿನಂತಿ, ಮತ್ತು VPN ಬಿದ್ದು ಮರಳಿದ ನಂತರದ ನಡವಳಿಕೆಯನ್ನು ಪರೀಕ್ಷಿಸಿ. ಆ ಮೂರು ಸಂದರ್ಭಗಳು ಕೆಲಸ ಮಾಡುವ ಆಲಿಸುವವನನ್ನು ಕೆಲಸ ಮಾಡುವ ಸೇವೆಯಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ.

systemd-analyze verify myapp.socket
systemctl cat myapp.socket
ss -ltn "sport = :8443"

ಮೊದಲ ಆಜ್ಞೆ ಮರುಪ್ರಾರಂಭಕ್ಕೆ ಮೊದಲು ಘಟಕ ಫೈಲ್ ದೋಷಗಳನ್ನು ಹಿಡಿಯುತ್ತದೆ, ಎರಡನೆಯದು ವಿಲೀನಗೊಂಡ ಘಟಕವನ್ನು ತೋರಿಸುತ್ತದೆ, ಮೂರನೆಯದು ಆಲಿಸುವವನು ಇದೆಯೇ ಮತ್ತು ಯಾವ ವಿಳಾಸದಲ್ಲಿ ಎಂದು ಸಾಬೀತು ಮಾಡುತ್ತದೆ. ಟನೆಲ್ ವಿಳಾಸ ನಿರೀಕ್ಷಿಸಿದ ಸ್ಥಳದಲ್ಲಿ wildcard ವಿಳಾಸದಲ್ಲಿ ಆಲಿಸುವವನು ಇರುವುದು ಖಾಲಿ ListenStream ತೆಗೆದುಹಾಕಬೇಕಿದ್ದ ಅದೇ ಉಳಿಕೆ. ವಿಳಾಸ ಸರಿದಿದೆಯೇ ಎಂದು ನೋಡಲು VPN ಮರುಸಂಪರ್ಕದ ನಂತರ ಮೂರನೇ ಆಜ್ಞೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ.

ಜೀವನಚಕ್ರವನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಆಯ್ಕೆ ಮಾಡಿ: ಸ್ಥಿರ ವಿಳಾಸ ಮರಳುವವರೆಗೆ ಕಾಯುವ ಮುಕ್ತವಾಗಿ ಬಂಧಿತ ಆಲಿಸುವವನು, ಅಥವಾ ಟನೆಲ್ ಜೊತೆ ನಿಲ್ಲುವ ಮತ್ತು ಚೇತರಿಕೆಯಲ್ಲಿ ಮತ್ತೆ ಪ್ರಾರಂಭವಾಗುವ ಸೇವೆ. ಇವು ಬೇರೆ ಬೇರೆ ವಿನ್ಯಾಸಗಳು ಮತ್ತು ಬೇರೆ ಬೇರೆ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ. ನಂತರ ಪ್ರವೇಶ ನೀತಿಯನ್ನು ನೀವು ಉದ್ದೇಶಿಸಿದ ಮೂಲಗಳು ಮತ್ತು ಮಾರ್ಗಗಳಿಗೆ ಬಂಧಿಸಿ ಇರಿಸಿ, ಏಕೆಂದರೆ ಗಮ್ಯ ವಿಳಾಸವನ್ನು ಬಂಧಿಸುವುದು ಸ್ವೀಕೃತ ಪ್ಯಾಕೆಟ್‌ಗಳು ವಿಶ್ವಾಸಾರ್ಹ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಬಂದಿರಬೇಕೆಂದು ಒತ್ತಾಯಿಸುವುದಿಲ್ಲ.