UDP VPN ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್‌ನಲ್ಲಿ ಮೌನ? ಇದು ಏಕೆ ಸಂಭವಿಸುತ್ತದೆ
WireGuard ಮತ್ತು ಕಠಿಣಗೊಳಿಸಿದ OpenVPN ದೃಢೀಕರಣದಲ್ಲಿ ವಿಫಲವಾದ ಡೇಟಾಗ್ರಾಮ್‌ಗಳನ್ನು ಉತ್ತರಿಸದೆ ಬಿಡುತ್ತವೆ. ಸ್ಕ್ಯಾನರ್‌ನಿಂದ ಮೌನವು ನಿರೀಕ್ಷಿತ ವರ್ತನೆ, ಮುಚ್ಚಿದ ಪೋರ್ಟ್ ಅಲ್ಲ.
ನೀವು VPN ಪೋರ್ಟ್ ಸ್ಕ್ಯಾನ್ ಮಾಡುತ್ತೀರಿ, ಯಾವುದೇ ಉತ್ತರ ಸಿಗುವುದಿಲ್ಲ ಮತ್ತು ಸೇವೆ ನಿಂತಿದೆ ಅಥವಾ ಫೈರ್‌ವಾಲ್ ಮುಚ್ಚಿದೆ ಎಂದು ತೀರ್ಮಾನಿಸುತ್ತೀರಿ. WireGuard ನಲ್ಲಿ ಮತ್ತು ತಮ್ಮದೇ ದೃಢೀಕರಣವನ್ನು ಹೊತ್ತಿರುವ OpenVPN ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ಗಳಲ್ಲಿ ಆ ತೀರ್ಮಾನ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಮಾನ್ಯ ದೃಢೀಕರಣ ಸಾಮಗ್ರಿ ಇಲ್ಲದ ಡೇಟಾಗ್ರಾಮ್ ಯಾವುದೇ ಉತ್ತರವಿಲ್ಲದೆ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೊರಗಿನಿಂದ ಆರೋಗ್ಯಕರ ಸೇವೆ ಈ ರೀತಿ ಮೌನವಾಗಿ ಕಾಣುತ್ತದೆ. ಸುರಂಗ ತಪ್ಪಾಗುವ ಮೊದಲೇ ಪರೀಕ್ಷೆಯೇ ತಪ್ಪು.
ಮೌನವೇ ಪ್ರೋಟೋಕಾಲ್, ದೋಷವಲ್ಲ
UDP ನಲ್ಲಿ ಸಂಪರ್ಕ ಸ್ಥಾಪನೆ ಇಲ್ಲ, ಆದ್ದರಿಂದ ಸ್ಕ್ಯಾನರ್‌ಗೆ ತೆರೆದ ಪೋರ್ಟ್ ಮತ್ತು ಫಿಲ್ಟರ್ ಮಾಡಿದ ಪೋರ್ಟ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ಅನುವು ಮಾಡುವ SYN ಇಲ್ಲ, ಯಾವುದೇ ಅಂಗೀಕಾರವೂ ಇಲ್ಲ. ಪರೀಕ್ಷೆ ಪ್ರತ್ಯೇಕ ಡೇಟಾಗ್ರಾಮ್ ಆಗಿ ಬರುತ್ತದೆ ಮತ್ತು ಸೇವೆ ಅದು ನಿರೀಕ್ಷಿಸುವ ಪ್ರೋಟೋಕಾಲ್‌ಗೆ ಹೊಂದುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ. ಹೊಂದದಿದ್ದರೆ ಪ್ಯಾಕೆಟ್ ತಿರಸ್ಕರಿಸಲ್ಪಡುತ್ತದೆ, ಮತ್ತು ತಿರಸ್ಕರಿಸುವುದು ದಾಖಲಿತ ವರ್ತನೆ, ಕ್ಷಮತೆ ಅಲ್ಲ.
WireGuard ತನ್ನ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಸಂದೇಶಗಳನ್ನು ಗೂಢಲಿಪಿ ರೀತಿಯಲ್ಲಿ ಪರಿಶೀಲಿಸುತ್ತದೆ ಮತ್ತು ವಿಫಲವಾಗುವ ಎಲ್ಲವನ್ನೂ ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. OpenVPN tls-auth ಅಥವಾ tls-crypt ನೊಂದಿಗೆ ತನ್ನ ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ಗೂ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ. ಎರಡೂ ಸಂದರ್ಭಗಳಲ್ಲಿ ಯಾವುದೇ ಅನಿಯತ ಪೇಲೋಡ್ ಬಳಕೆದಾರರ ಕಡೆಗಿನ ಹಂತವನ್ನು ತಲುಪುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಉತ್ತರಿಸಲು ಏನೂ ಇಲ್ಲ ಮತ್ತು ಹಿಂತಿರುಗಿಸಲು ದೋಷವೂ ಇಲ್ಲ.
TCP ಆಗಿದ್ದರೆ ಮುಚ್ಚಿದ ಪೋರ್ಟ್‌ನಿಂದ ನಿಮಗೆ ರೀಸೆಟ್ ಸಿಗುತ್ತಿತ್ತು. UDP ನಿಮ್ಮನ್ನು ಅಸ್ಪಷ್ಟತೆಯಲ್ಲಿ ಬಿಡುತ್ತದೆ, ಅದನ್ನು ಸ್ಕ್ಯಾನರ್‌ಗಳು ಊಹಿಸುವ ಬದಲು ತೆರೆದ ಅಥವಾ ಫಿಲ್ಟರ್ ಮಾಡಿದ ಎಂದು ಮುದ್ರಿಸಿ ಬಗೆಹರಿಸುತ್ತವೆ.
ಸ್ಕ್ಯಾನರ್ ಏನನ್ನು ತೀರ್ಮಾನಿಸಬಹುದು ಮತ್ತು ಏನನ್ನು ಸಾಧ್ಯವಿಲ್ಲ
ಸ್ಕ್ಯಾನ್ ಫಲಿತಾಂಶವು ಅದು ಕಳುಹಿಸಿದ ಪೇಲೋಡ್‌ನಷ್ಟೇ ಮಾಹಿತಿಪೂರ್ಣವಾಗಿರುತ್ತದೆ. ಸಂಭಾವ್ಯ ವೀಕ್ಷಣೆಗಳನ್ನು ಪ್ರತಿಯೊಂದೂ ನಿಜವಾಗಿ ಏನನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂಬುದರ ಆಧಾರದಲ್ಲಿ ಜೋಡಿಸಿ:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
ಪಟ್ಟಿಯಲ್ಲಿ ಏಕೈಕ ಸಕಾರಾತ್ಮಕ ಪರೀಕ್ಷೆಯಾಗಿ ಮೂರನೇ ಸಾಲನ್ನು ಓದಿ. ಅದಕ್ಕೆ ನಿಜವಾದ ಪ್ರೊಫೈಲ್, ನಿಜವಾದ ಕೀ ಮತ್ತು ಸರಿಯಾದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಬೇಕು, ಮತ್ತು ಸಾಮಾನ್ಯ ಸ್ಕ್ಯಾನರ್‌ನಲ್ಲಿ ಇರದ್ದು ಅದೇ.
ಮಾರ್ಗದ ಎರಡೂ ತುದಿಗಳನ್ನು ನೋಡಿ
ನೀವು ನಿರ್ವಹಿಸುವ ಸರ್ವರ್‌ಗೆ, ಯಾವುದೇ ತೀರ್ಮಾನಕ್ಕೆ ಬರುವ ಮೊದಲು ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಸೆರೆಹಿಡಿಯಿರಿ, ನಂತರ ಸೇವೆಯು ಏನು ನೋಡಿತೆಂದು ಕೇಳಿ. ಎರಡೂ ಆದೇಶಗಳಿಗೂ ಗೇಟ್‌ವೇಯಲ್ಲಿ root ಬೇಕು:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಯಾವುದೇ ಪ್ಯಾಕೆಟ್ ಕಾಣದಿದ್ದರೆ, ಸೇವೆ ಏನನ್ನೂ ನೋಡುವ ಮೊದಲೇ ಮಾರ್ಗವು ಅದನ್ನು ತಿರಸ್ಕರಿಸಿದೆ, ಮತ್ತು ಮುಂದಿನ ನಿಲ್ದಾಣ ರೂಟಿಂಗ್ ಮತ್ತು ಫಿಲ್ಟರಿಂಗ್. ಪ್ಯಾಕೆಟ್‌ಗಳು ಬಂದರೂ ಯಾವುದೇ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಪೂರ್ಣಗೊಳ್ಳದಿದ್ದರೆ, ಸೇವೆ ತಲುಪಬಲ್ಲದು ಮತ್ತು ವ್ಯತ್ಯಾಸ ಕೀಗಳಲ್ಲಿ, ಎಂಡ್‌ಪಾಯಿಂಟ್ ಸಂರಚನೆಯಲ್ಲಿ ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ ಆವೃತ್ತಿಯಲ್ಲಿ ಇದೆ. ಆ ಹೋಲಿಕೆಯೇ ಸ್ಕ್ಯಾನರ್‌ಗೆ ನೀಡಲಾಗದ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರ ನೀಡುತ್ತದೆ. ನಿಜವಾದ ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ ಅದನ್ನು ಚಲಾಯಿಸಿ, ಸ್ಕ್ಯಾನರ್ ತನ್ನನ್ನೇ ಪುನರಾವರ್ತಿಸುತ್ತಿರುವಾಗ ಅಲ್ಲ.
ಪರೀಕ್ಷೆಯನ್ನು ಬದಲಿಸಿ, ರಕ್ಷಣೆಯನ್ನಲ್ಲ
ಪ್ರಲೋಭನೆಯ ಸಣ್ಣ ದಾರಿ ಎಂದರೆ ನಿಯಂತ್ರಣ ಚಾನೆಲ್‌ನ ರಕ್ಷಣೆಯನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು, ಇದರಿಂದ ರೋಗನಿರ್ಣಯಕ್ಕೆ ಉತ್ತರ ಸಿಗುತ್ತದೆ. ಅದು ನಿಜವಾದ ಭದ್ರತಾ ಗುಣವನ್ನು ಸುಂದರವಾದ ಸ್ಕ್ಯಾನ್ ಫಲಿತಾಂಶಕ್ಕೆ ಬದಲಿಸುತ್ತದೆ, ಮತ್ತು ಅದು ತಪ್ಪು ದಿಕ್ಕು. ಬದಲಾಗಿ ಅನುಮೋದಿತ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಮಾನ್ಯ ಪ್ರೊಫೈಲ್ ಬಳಸಿ ಮತ್ತು ಹೋಲಿಕೆ ಪುನರಾವರ್ತಿಸಬಲ್ಲದಾಗಿರಲು ಎಂಡ್‌ಪಾಯಿಂಟ್ ಹಾಗೂ ಸಮಯವನ್ನು ದಾಖಲಿಸಿ.
ಅತ್ಯಂತ ಉಪಯುಕ್ತ ಪರೀಕ್ಷೆ ವಿಭೇದಾತ್ಮಕವಾದುದು: ಅದೇ ಪ್ರೊಫೈಲ್ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗದಲ್ಲಿ ಮತ್ತು ಕೆಲಸ ಮಾಡದ ಮಾರ್ಗದಲ್ಲಿ. ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗ ಹ್ಯಾಂಡ್‌ಶೇಕ್ ಉತ್ಪಾದಿಸಿದರೆ ಮತ್ತು ವಿಫಲವಾದ ಮಾರ್ಗ ಇಂಟರ್ಫೇಸ್‌ನಲ್ಲಿ ಏನನ್ನೂ ಉತ್ಪಾದಿಸದಿದ್ದರೆ, ನೀವು ಏನನ್ನೂ ದುರ್ಬಲಗೊಳಿಸದೆ ಮುರಿತದ ಸ್ಥಳವನ್ನು ಕಂಡುಕೊಂಡಿದ್ದೀರಿ.
ಆದ್ದರಿಂದ ಉತ್ತರವಿಲ್ಲದ UDP ಪ್ಯಾಕೆಟ್ ಸರ್ವರ್ ಆಫ್‌ಲೈನ್ ಎಂಬುದನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ, ಅದು ಸುರಕ್ಷಿತ ಎಂಬುದನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. ಅದು ಸಾಬೀತುಪಡಿಸುವುದು ಈ ಪರೀಕ್ಷೆ, ಈ ಮಾರ್ಗದಲ್ಲಿ, ಈ ಕ್ಷಣದಲ್ಲಿ, ಸ್ವೀಕರಿಸಲ್ಪಟ್ಟಿಲ್ಲ ಎಂಬುದನ್ನು.