UDP ಸ್ಕ್ಯಾನ್ ಫಿಲ್ಟರ್ ಆಗಿದೆ ಎಂದು ಹೇಳುತ್ತದೆ: ನಿಮ್ಮ WireGuard ಸಹವರ್ತಿ ನಿಜವಾಗಿಯೂ ನಿಂತಿದೆಯೇ?

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

ಬದಲಾಗಿ ಕ್ಲೈಂಟ್‌ನಿಂದ ಹೊರಮುಖವಾಗಿ ಕೆಲಸ ಮಾಡಿ, ಮತ್ತು ಸ್ಕ್ಯಾನ್ ಅನ್ನು ಹಲವು ದುರ್ಬಲ ಡೇಟಾ ಬಿಂದುಗಳಲ್ಲಿ ಒಂದೆಂದು ಪರಿಗಣಿಸಿ.

ಸ್ಕ್ಯಾನರ್ ಏನನ್ನು ನೋಡಬಹುದು ಮತ್ತು ಏನನ್ನು ನೋಡಲಾಗದು

UDP ಸ್ಕ್ಯಾನರ್ ಒಂದು ಪೇಲೋಡ್ ಕಳುಹಿಸಿ ಕಾಯುತ್ತದೆ. ICMP port-unreachable ಹಿಂತಿರುಗಿದರೆ, ಅದು ಪೋರ್ಟ್ ಅನ್ನು ಮುಚ್ಚಿದೆ ಎಂದು ವರದಿ ಮಾಡಬಹುದು. ಏನೂ ಹಿಂತಿರುಗದಿದ್ದರೆ, ಫಲಿತಾಂಶ ವಿನ್ಯಾಸದಿಂದಲೇ ಅಸ್ಪಷ್ಟವಾಗಿದೆ: ಫಿಲ್ಟರ್ ಆದ ಮಾರ್ಗ, ಇಲ್ಲದ ಹೋಸ್ಟ್ ಮತ್ತು ಪೇಲೋಡ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಿದ ಚಾಲನೆಯಲ್ಲಿರುವ ಸೇವೆ ಎಲ್ಲವೂ ಒಂದೇ ಮೌನವನ್ನು ಉಂಟುಮಾಡುತ್ತವೆ. ಮೂರು ವಿಭಿನ್ನ ಸ್ಥಿತಿಗಳು, ಒಂದೇ ಔಟ್‌ಪುಟ್ ಸ್ಟ್ರಿಂಗ್.

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

ಅದೇ ಪೋರ್ಟ್ ಸಂಖ್ಯೆಯಲ್ಲಿ TCP ಪರೀಕ್ಷೆ ಸಂಬಂಧಿತ ಯಾವುದನ್ನೂ ಪರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಅದು ಇರದಿರಬಹುದಾದ ಇನ್ನೊಂದು ಶ್ರೋತೆಯನ್ನು ಚಲಾಯಿಸುತ್ತದೆ, ಮತ್ತು ಅದರ ನಿರಾಕರಣೆ UDP ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ.

ಆದ್ದರಿಂದ ತೆರೆದ ಫಿಲ್ಟರ್ ಸ್ಥಿತಿಗಳು ನಿಮ್ಮ ಸರ್ವರ್‌ಗಿಂತ ಸ್ಕ್ಯಾನರ್‌ನ ಅನಿಶ್ಚಿತತೆಯನ್ನು ಹೆಚ್ಚು ನಿಖರವಾಗಿ ವಿವರಿಸುತ್ತವೆ.

ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಅನ್ನು ಪ್ರೊಫೈಲ್‌ನಿಂದ ಒಳಕ್ಕೆ ನಡೆಯಿರಿ

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

ನಂತರ ಮೂರನೇ ಸ್ಥಳದಿಂದ ಪ್ರತ್ಯೇಕ ಸ್ಕ್ಯಾನ್ ಚಲಾಯಿಸುವ ಬದಲು, ಒಂದು ಅಧಿಕೃತ ಪ್ರಯತ್ನ ನಡೆಯುತ್ತಿರುವಾಗ ಸರ್ವರ್ ಬದಿಯನ್ನು ಗಮನಿಸಿ:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

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

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

ನೀವು ಸರ್ವರ್ ನಿರ್ವಹಿಸುವಾಗ ಅಲ್ಲೇ ಪರಸ್ಪರ ಸಂಬಂಧ ಕಲ್ಪಿಸಿ

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

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

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

ಸ್ಕ್ಯಾನ್ ಫಲಿತಾಂಶವನ್ನು ಪ್ರಾಮಾಣಿಕವಾಗಿ ಓದುವುದು

ಸ್ಕ್ಯಾನ್ ಎಂಬುದು ಹೋಸ್ಟ್ ಇದೆಯೇ ಮತ್ತು ಪೋರ್ಟ್ ಅನ್ನು ಮಧ್ಯವರ್ತಿ ಸಾಧನ ಸ್ಪಷ್ಟವಾಗಿ ತಡೆಯುತ್ತಿಲ್ಲವೇ ಎಂದು ಪರಿಶೀಲಿಸುವ ಅಗ್ಗದ ದಾರಿ. ಇದು ದೃಢೀಕೃತ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ತಲುಪುವಿಕೆಯ ಸಾಕ್ಷ್ಯವಲ್ಲ, ಮತ್ತು ಖಂಡಿತವಾಗಿಯೂ ಕಾನ್ಫಿಗರೇಶನ್ ಪರೀಕ್ಷೆಯಲ್ಲ.

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

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