ಪೋರ್ಟ್ 1194 ಈಗಾಗಲೇ ಬಳಕೆಯಲ್ಲಿದೆ: ಈ OpenVPN ಸಾಕೆಟ್ ಯಾರದು?

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

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

ನಿಖರವಾದ ಬೈಂಡ್ ದೋಷವನ್ನು ಓದಿ

ಈ ಕುಟುಂಬದ ಎರಡು ದೋಷಗಳು ವಿಭಿನ್ನ ಅರ್ಥಗಳನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಅವುಗಳನ್ನು ಬೆರೆಸುವುದು ನಿಮ್ಮನ್ನು ತಪ್ಪು ಪದರಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. «ವಿಳಾಸ ಈಗಾಗಲೇ ಬಳಕೆಯಲ್ಲಿದೆ» ಎಂದರೆ ನೀವು ಕೇಳಿದ ಅಂತಿಮ ಬಿಂದುವನ್ನು ಇನ್ನೊಂದು ಸಾಕೆಟ್ ಹಿಡಿದಿದೆ. «ವಿಳಾಸ ಲಭ್ಯವಿಲ್ಲ» ಎಂದರೆ ನೀವು ಕೇಳಿದ ವಿಳಾಸವು ಈ ಹೋಸ್ಟ್ನಲ್ಲಿ ಇನ್ನೂ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ, ಇದು ಸಿದ್ಧತೆಯ ಸಮಸ್ಯೆ, ನಕಲು ಅಲ್ಲ.

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

ಸಾಕೆಟ್ ಅನ್ನು ಪಟ್ಟಿ ಮಾಡಿ, ಪೋರ್ಟ್ ಅಲ್ಲ

ಪೋರ್ಟ್ ಸಂಖ್ಯೆ ಅಪೂರ್ಣ ಪಟ್ಟಿ. ಅಂತಿಮ ಬಿಂದು ಸಾರಿಗೆ, ವಿಳಾಸ ಕುಟುಂಬ, ಸ್ಥಳೀಯ ವಿಳಾಸ ಮತ್ತು ಪೋರ್ಟ್, ಎಲ್ಲವೂ ಒಂದೇ ನೆಟ್ವರ್ಕ್ ಹೆಸರಿನ ಜಾಗದ ಒಳಗೆ. ಒಂದೇ ಸಂಖ್ಯೆಯಲ್ಲಿ UDP ಶ್ರೋತ ಮತ್ತು TCP ಶ್ರೋತ ವಿಭಿನ್ನ ಸಾಕೆಟ್ಗಳು, ಮತ್ತು ವಿಭಿನ್ನ ಹೆಸರಿನ ಜಾಗಗಳಲ್ಲಿ ಒಂದೇ ಸಂಖ್ಯೆಯಲ್ಲಿ ಎರಡು ಪ್ರಕ್ರಿಯೆಗಳು ಎಂದಿಗೂ ಭೇಟಿಯಾಗುವುದಿಲ್ಲ.

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

ಯಾವ ಪ್ರಕ್ರಿಯೆ ಅದನ್ನು ಹೊಂದಿದೆ ಎಂದು ಕಂಡುಹಿಡಿಯಿರಿ

ಸಂಖ್ಯಾತ್ಮಕ ಅಂತಿಮ ಬಿಂದುಗಳ ಜೊತೆಗೆ ಪ್ರಕ್ರಿಯೆ ಮಾಹಿತಿಯು ನಿಮ್ಮ ಸವಲತ್ತುಗಳು ಅನುಮತಿಸಿದಾಗ ಮಾಲೀಕರನ್ನು ಗುರುತಿಸುತ್ತದೆ, ಮತ್ತು ನಿಮಗೆ ಬೇಕಾಗಿರುವುದು ಮಾಲೀಕರು, ಪ್ರೋಗ್ರಾಂ ಹೆಸರಲ್ಲ. ಎರಡು OpenVPN ಪ್ರಕ್ರಿಯೆಗಳು ವಿಭಿನ್ನ ಪ್ರೊಫೈಲ್ಗಳನ್ನು ಚಲಾಯಿಸಬಹುದು, ಮತ್ತು ಶ್ರೋತವನ್ನು ಹಿಡಿದಿರುವ ಪ್ರಕ್ರಿಯೆಯು ನೀವು ಅತಿ ಕಡಿಮೆ ನಿರೀಕ್ಷಿಸಿದ್ದಾಗಿರಬಹುದು.

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

ಒಬ್ಬ ಮಾಲೀಕ, ಅಥವಾ ಎರಡು ವಿನ್ಯಾಸಗೊಳಿಸಿದ ಇನ್ಸ್ಟಾನ್ಸ್ಗಳು

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

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

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

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

ಎಲ್ಲದಕ್ಕೂ ಮೊದಲು ಬೈಂಡ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿ

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

ಸಾಕೆಟ್ ಇದ್ದರೆ ಮತ್ತು ಗ್ರಾಹಕರು ಇನ್ನೂ ವಿಫಲವಾದರೆ, ಉಳಿದ ಸಮಸ್ಯೆ ಕೆಳಮುಖವಾಗಿದೆ ಮತ್ತು ಬೈಂಡ್ ದೋಷ ಈಗ ಇತಿಹಾಸ. ಈ ಬೇರ್ಪಡಿಕೆಯೇ ನಿಖರ ಸಂದೇಶವನ್ನು ಮೊದಲು ಓದುವ ಸಂಪೂರ್ಣ ಅರ್ಥ: ಒಂದು ದೋಷ, ಒಂದು ಪದರ, ಒಬ್ಬ ಮಾಲೀಕ. ಹಾಗೆ ಓದಿ ಮತ್ತು ಮುಂದಿನ ಲಕ್ಷಣವು ಊಹೆಯಿಂದ ಅಲ್ಲ, ತಿಳಿದ ಸ್ಥಿತಿಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.