nc -uz ಏಕೆ OpenVPN ಸರ್ವರ್ ಸಿದ್ಧವಿದೆ ಎಂದು ಸಾಬೀತುಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ

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

UDP ಪರಿಶೀಲನೆ ಏನನ್ನು ಗಮನಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ

nc -uz ಒಂದು ಡೇಟಾಗ್ರಾಮ್ ಕಳುಹಿಸಿ ನಿರ್ಗಮಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ಹಿಂತಿರುಗಿಸುವ ಸ್ಥಿತಿ ಸ್ಥಳೀಯ ಕಳುಹಿಸುವಿಕೆಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಮುಚ್ಚಿದ ಪೋರ್ಟ್ ICMP port unreachable ನೊಂದಿಗೆ ಉತ್ತರಿಸಬಹುದು, ಆದರೆ ಈ ಸ್ಕ್ಯಾನ್ ಕ್ರಮದ ದಾಖಲಿತ ವರ್ತನೆ ಅದನ್ನು ವೈಫಲ್ಯವಾಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಫಿಲ್ಟರ್ ಆದ ಪೋರ್ಟ್ ಯಾವುದೇ ಉತ್ತರವನ್ನು ನೀಡುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಮೌನ ಮತ್ತು ಯಶಸ್ಸು ಕರೆ ಮಾಡುವವರಿಗೆ ಒಂದೇ ಅರ್ಥ.

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

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

ಮೂರು ಕರೆ ಮಾಡುವವರು, ಮೂರು ವಿಭಿನ್ನ ಪ್ರಶ್ನೆಗಳು

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

ಇವು ಒಂದೇ ಪರಿಶೀಲನೆ ಅಲ್ಲ, ಮತ್ತು ಒಂದು ಪರಿಶೀಲನೆ ಮೂರನ್ನೂ ಪ್ರಾಮಾಣಿಕವಾಗಿ ಆವರಿಸಲಾರದು. ಮೊದಲು ಕರೆ ಮಾಡುವವರನ್ನು ಆರಿಸಿ, ನಂತರ ಸಾಕ್ಷ್ಯವನ್ನು.

ಪ್ರಸ್ತುತ ಸಂದರ್ಭದಿಂದ ಪರಿಶೀಲನೆಯನ್ನು ನಿರ್ಮಿಸಿ

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

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

systemctl is-active openvpn@server
sudo journalctl -u openvpn@server -b --no-pager | grep "Initialization Sequence Completed"
ss -lunp | grep 1194

ಮೂರು ಔಟ್ಪುಟ್ಗಳು, ಮೂರು ಹೇಳಿಕೆಗಳು: ಘಟಕ ಸಕ್ರಿಯವಾಗಿದೆ, ಈ ಬೂಟ್ ಆರಂಭಿಕರಣ ಸಾಲನ್ನು ಉತ್ಪಾದಿಸಿತು, ಮತ್ತು ಯಾವುದೋ UDP ಪೋರ್ಟ್ ಹಿಡಿದಿದೆ. ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಬಹುದು ಎಂದು ಹೇಳುವುದಿಲ್ಲ. ಸ್ಥಿತಿ ಪುಟದಲ್ಲಿ ಅವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿಡಿ, ಘಟನೆ ಒಂದೇ ಹಸಿರು ಚುಕ್ಕೆಗೆ ಕುಸಿಯದಂತೆ.

ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮುರಿಯಿರಿ ಮತ್ತು ಪರಿಶೀಲನೆಯನ್ನು ಗಮನಿಸಿ

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

sudo systemctl stop openvpn@server
nc -uz 203.0.113.10 1194; echo "exit=$?"
ss -lunp | grep 1194
sudo systemctl start openvpn@server
ss -lunp | grep 1194

ಬ್ಲಾಕ್ ಅನ್ನು ಸಾಲಿನಿಂದ ಸಾಲಿಗೆ ಓದಿ. netcat ಆಜ್ಞೆ ಮುದ್ರಿಸುತ್ತದೆ exit=0 ಆದರೆ ಏನೂ ಬಂಧಿಸಲಾಗಿಲ್ಲ, ಮತ್ತು ಇಡೀ ಸಮಸ್ಯೆ ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಇದೆ. ಮೊದಲ ss ಏನನ್ನೂ ಮುದ್ರಿಸುವುದಿಲ್ಲ, ಮರುಪ್ರಾರಂಭ ಯಶಸ್ವಿಯಾಗುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು ss ಮತ್ತೆ ಶ್ರೋತೃವನ್ನು ತೋರಿಸುತ್ತದೆ. ನಿಲ್ಲಿಸಿದ ಸರ್ವರ್ ವಿರುದ್ಧ ನಿಮ್ಮ ಪರಿಶೀಲನೆ ಉತ್ತೀರ್ಣವಾದರೆ, ಅದು ಸ್ಥಳೀಯ ಸ್ಟಾಕ್ ಅನ್ನು ಅಳೆಯುತ್ತಿದೆ, ಬೇರೆ ಏನನ್ನೂ ಅಲ್ಲ.

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

ಸ್ಥಿತಿ ಸಾಲು ಏನು ಹೇಳಬೇಕು

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

ಆ ಗುರುತನ್ನು ನಿಜವಾದ ಬಳಕೆದಾರರಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿಡಿ ಮತ್ತು ಪರಿಶೀಲನೆಗೆ ಬೇಕಾದ ಕನಿಷ್ಠ ಅನುಮತಿಗಳನ್ನು ನೀಡಿ. ವಿಶಾಲ ಪ್ರವೇಶದ ಸಿದ್ಧತಾ ಪರಿಶೀಲನೆ ಅನುಕೂಲಕ್ಕಾಗಿ ಸೇರಿಸಿದ ಹೊಸ ದಾಳಿ ಮೇಲ್ಮೈ. ಅದರ ರುಜುವಾತುಗಳನ್ನು ಬೇರೆ ಯಾವುದೇ ಖಾತೆಯಂತೆ ತಿರುಗಿಸಿ, ಏಕೆಂದರೆ ದೃಢೀಕರಣ ನಿಲ್ಲಿಸುವ ಪರಿಶೀಲನೆ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಸ್ವೀಕರಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ ಸರ್ವರ್ನಂತೆಯೇ ಕಾಣುತ್ತದೆ.

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