Tor ನ SOCKS ಪೋರ್ಟ್ ಮೂಲಕ UDP: ಯಾವುದು ಹಾದುಹೋಗುವುದಿಲ್ಲ
Tor ನ SOCKS ಇಂಟರ್ಫೇಸ್ ಸ್ಟ್ರೀಮ್ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅನಿಯಂತ್ರಿತ ಡೇಟಾಗ್ರಾಮ್ಗಳನ್ನು ಅಲ್ಲ. ಪರಿಶೀಲನೆಯನ್ನು ಕ್ರಮವಾಗಿ ಚಲಾಯಿಸಿ, ನಂತರ ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಬೆಂಬಲಿಸುವ ಸಾರಿಗೆಯನ್ನು ಆರಿಸಿ.
ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು SOCKS ಪೋರ್ಟ್ಗೆ ತೋರಿಸುವುದು ಬ್ರೌಸರ್ಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಆಟಕ್ಕೆ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಕಾರಣ ಕಾನ್ಫಿಗರೇಶನ್ ಅಲ್ಲ. SOCKS5 ಹಲವು ಆದೇಶಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುತ್ತದೆ, ಮತ್ತು ಒಂದು ಅನುಷ್ಠಾನವು ಅವುಗಳಲ್ಲಿ ಕೆಲವನ್ನು ಮಾತ್ರ ಬೆಂಬಲಿಸಲು ಸ್ವತಂತ್ರವಾಗಿದೆ; Tor ನ ಇಂಟರ್ಫೇಸ್ ಸ್ಟ್ರೀಮ್ ಸಂಪರ್ಕಗಳು ಮತ್ತು ಹೆಸರು ಪರಿಹಾರವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅನಿಯಂತ್ರಿತ ಡೇಟಾಗ್ರಾಮ್ ಫಾರ್ವರ್ಡಿಂಗ್ ಅಲ್ಲ. UDP ಕಳುಹಿಸಿ ಪ್ರಾಕ್ಸಿ ಅದನ್ನು ರಿಲೇ ಮಾಡುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವ ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಅನುಷ್ಠಾನಗೊಳಿಸದ ಆದೇಶವನ್ನು ಕೇಳುತ್ತದೆ. ಕೆಳಗಿನ ಮಾರ್ಗದರ್ಶಿ ಅದನ್ನು ಕೆಲವು ನಿಮಿಷಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿ ನಂತರ ನಿಜವಾಗಿ ಕೆಲಸ ಮಾಡಬಲ್ಲ ಸಾರಿಗೆಯನ್ನು ಆರಿಸುತ್ತದೆ.
ಅಪ್ಲಿಕೇಶನ್ ನಿಜವಾಗಿ ಏನು ಕಳುಹಿಸುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ
ಪ್ರೋಟೋಕಾಲ್ ಹೆಸರಿಗಿಂತ ಸಾರಿಗೆಯನ್ನು ಗುರುತಿಸುವ ಮೂಲಕ ಪ್ರಾರಂಭಿಸಿ. ಧ್ವನಿ ಕ್ಲೈಂಟ್ HTTPS ಮೂಲಕ ಸೈನ್ ಇನ್ ಆಗಿ ನಂತರ ಮಾಧ್ಯಮವನ್ನು UDP ಮೂಲಕ ಸಾಗಿಸಬಹುದು; ಆಟ TCP ಮೂಲಕ ದೃಢೀಕರಿಸಿ UDP ಮೂಲಕ ಆಡಬಹುದು; ಫೈಲ್ ವರ್ಗಾವಣೆ ನಿಯಂತ್ರಣಕ್ಕೆ TCP ಮತ್ತು ಅನ್ವೇಷಣೆಗೆ UDP ಬಳಸಬಹುದು. ಮೊದಲ ಎರಡು ವರ್ತನೆಗಳು ಲಾಗಿನ್ ಯಶಸ್ವಿಯಾದರೂ ಕರೆ ವಿಫಲವಾಗುವವರೆಗೆ ಒಂದೇ ರೀತಿ ಕಾಣುತ್ತವೆ, ಆದ್ದರಿಂದ “ಸಂಪರ್ಕವಾಯಿತು” ಎಂಬುದು ಇಡೀ ಅಪ್ಲಿಕೇಶನ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬ ಸಾಕ್ಷ್ಯವಲ್ಲ. ಕೆಲವು ಕ್ಲೈಂಟ್ಗಳು ತಾವೇ UDP ನಿಂದ TCP ಗೆ ಮರಳುತ್ತವೆ, ಇದು ಭಾಗಶಃ ಕೆಲಸ ಮಾಡುವ ಅವಧಿಯನ್ನು ತಡೆಯಲಾದ ಸಾರಿಗೆಯ ಬದಲು ಅಸ್ಥಿರ ಜಾಲದಂತೆ ಕಾಣಿಸುತ್ತದೆ.
ವಿಫಲವಾಗುವ ಭಾಗಕ್ಕೆ ಗಮ್ಯ ಪೋರ್ಟ್ ಮತ್ತು ಸಾರಿಗೆಯನ್ನು ಬರೆದಿಡಿ. ಆ ಒಂದು ಸಾಲು ಪ್ರಾಕ್ಸಿ ಒಟ್ಟಾರೆ ಸಹಾಯ ಮಾಡಬಹುದೇ ಎಂದು ನಿರ್ಧರಿಸುತ್ತದೆ.
Tor ನ SOCKS ಇಂಟರ್ಫೇಸ್ ಏನನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ
Tor ಸ್ಟ್ರೀಮ್ ಸಂಪರ್ಕಗಳಿಗೆ SOCKS5 CONNECT ಆದೇಶವನ್ನು ಮತ್ತು ಹೆಸರುಗಳನ್ನು ಪರಿಹರಿಸಲು ವಿಸ್ತರಣಾ ಆದೇಶಗಳನ್ನು ಅನುಷ್ಠಾನಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಬ್ರೌಸರ್ ಯಾವುದೇ ಬದಲಾವಣೆ ಇಲ್ಲದೆ ಅದರ ಮೂಲಕ ಕೆಲಸ ಮಾಡುತ್ತದೆ. UDP ASSOCIATE, ಕ್ಲೈಂಟ್ ಡೇಟಾಗ್ರಾಮ್ಗಳನ್ನು ಫಾರ್ವರ್ಡಿಂಗ್ಗಾಗಿ ಪ್ರಾಕ್ಸಿಗೆ ಒಪ್ಪಿಸಲು ಅನುಮತಿಸುವ ಆದೇಶ, Tor ನೀಡುವ ಭಾಗವಲ್ಲ. ವಿಸ್ತರಣೆಗಳ ದಸ್ತಾವೇಜು ಯೋಜನೆಯ SOCKS ವಿಸ್ತರಣೆ ವಿಶೇಷಣ ದಲ್ಲಿದೆ, ಮತ್ತು ಅದು ಚಿಕ್ಕದಾಗಿದೆ. ಡೇಟಾಗ್ರಾಮ್ ಆದೇಶದ ಅನುಪಸ್ಥಿತಿ ಉದ್ದೇಶಪೂರ್ವಕ: ಅನಿಯಂತ್ರಿತ UDP ರಿಲೇ ಮಾಡುವುದು ಜಾಲಕ್ಕೆ ಅದು ಎಂದಿಗೂ ವಿನ್ಯಾಸಗೊಳಿಸದ ಫಾರ್ವರ್ಡಿಂಗ್ ಪಾತ್ರವನ್ನು ನೀಡುತ್ತದೆ.
ಇದು WireGuard ಗೂ ಉತ್ತರ, ಅದು ವಿನ್ಯಾಸದಿಂದ UDP ಮತ್ತು ಅದಕ್ಕೆ TCP ಪರ್ಯಾಯ ಮಾರ್ಗವಿಲ್ಲ. WireGuard ಅನ್ನು SOCKS ಪೋರ್ಟ್ಗೆ ತೋರಿಸುವ ಬೆಂಬಲಿತ ಮಾರ್ಗವಿಲ್ಲ, ಮತ್ತು ವಿರುದ್ಧವಾಗಿ ಹೇಳುವ ಯಾವುದೇ ವಿಷಯ ಎರಡು ಸಾಧನಗಳ ಯಾವುದರ ವೈಶಿಷ್ಟ್ಯವೂ ಅಲ್ಲ, ತನ್ನದೇ ಆದ ವಿಶ್ವಾಸ ಮತ್ತು ನಿರ್ವಹಣಾ ಕಥೆಯನ್ನು ಹೊಂದಿರುವ ಹೊದಿಕೆ.
OpenVPN ಭಾಗಶಃ ಅಪವಾದ, ಏಕೆಂದರೆ ಅದನ್ನು TCP ಮೇಲೆ ಸುರಂಗ ಮಾಡಲು ಸಂರಚಿಸಬಹುದು ಮತ್ತು ಅದು SOCKS ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆಯನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ. ಅದಕ್ಕೆ ಇನ್ನೂ TCP ಗಾಗಿ ಸಂರಚಿಸಿದ ಸರ್ವರ್ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ ಹಾಗೂ ಬೆರಳಚ್ಚಿನ ಪರಿಣಾಮಗಳ ಬಗ್ಗೆ ಜಾಗೃತ ನಿರ್ಧಾರ ಬೇಕು, ಆದ್ದರಿಂದ ಇದು ವಿನ್ಯಾಸದ ಆಯ್ಕೆ, ಹೊಂದಾಣಿಕೆಯ ಪರಿಹಾರವಲ್ಲ.
ಪರಿಶೀಲನೆಯನ್ನು ಕ್ರಮವಾಗಿ ಚಲಾಯಿಸಿ
ಮೊದಲು ಪ್ರಾಕ್ಸಿ ಸ್ಟ್ರೀಮ್ಗಳಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ನಂತರದ ವೈಫಲ್ಯ ತಲುಪಲಾಗದ ಪೋರ್ಟ್ಗೆ ಆರೋಪಿಸಲಾಗದಂತೆ. ನಂತರ ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಸಂಚಾರವನ್ನು ಖಚಿತಪಡಿಸಿ ಮತ್ತು ಅದು ನಿಜವಾಗಿ ಯಾವ ಸಾಕೆಟ್ಗಳನ್ನು ತೆರೆಯುತ್ತದೆ ಎಂದು ಗಮನಿಸಿ.
curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'
ಯಶಸ್ವಿ ಮೊದಲ ಆದೇಶ ಮತ್ತು ಎರಡನೇ ಸಾಲಿನಲ್ಲಿ ಸ್ಥಾಪಿತವಾದ ಸ್ಟ್ರೀಮ್ ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗವು ವಿನ್ಯಾಸದಂತೆ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ ಎಂದು ತೋರಿಸುತ್ತವೆ. ಮೂರನೇ ಆದೇಶ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸೇರಿದ ಸ್ಥಳೀಯ ಡೇಟಾಗ್ರಾಮ್ ಸಾಕೆಟ್ಗಳನ್ನು ಹುಡುಕುತ್ತದೆ; ಕ್ಲೈಂಟ್ ಒಂದನ್ನು ತೆರೆದು ನೇರವಾಗಿ ದೂರದ ವಿಳಾಸಕ್ಕೆ ಕಳುಹಿಸಿದರೆ, ಅದು ಪ್ರಾಕ್ಸಿಯನ್ನು ಎಂದಿಗೂ ಸಂಪರ್ಕಿಸಿಲ್ಲ ಮತ್ತು ಯಾವುದೇ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಅದು ಮೊದಲ ಹಂತದಲ್ಲೇ ವಿಫಲವಾದರೆ, ನಿಲ್ಲಿಸಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ತನಿಖೆಗೆ ಮೊದಲು ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗವನ್ನು ಸರಿಪಡಿಸಿ, ಏಕೆಂದರೆ ಒಟ್ಟಿಗೆ ಎರಡು ದೋಷಗಳು ಯಾರೂ ಕ್ರಮ ಕೈಗೊಳ್ಳಲಾಗದ ವರದಿಯನ್ನು ಉತ್ಪಾದಿಸುತ್ತವೆ.
ಹಿಂದಕ್ಕೆ ತಿರುಗಿಸಿ ಸರಿಯಾದ ಸಾಧನವನ್ನು ಆರಿಸಿ
UDP ಕ್ಲೈಂಟ್ ಅನ್ನು SOCKS ಪೋರ್ಟ್ಗೆ ತೋರಿಸಿದ ಯಾವುದೇ ಪ್ರಾಕ್ಸಿ ಪರಿಸರ ಚರ ಅಥವಾ ಪ್ರತಿ-ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ತೆಗೆದುಹಾಕಿ; ಅವುಗಳನ್ನು ಬಿಟ್ಟರೆ ನಂತರದ ಪರೀಕ್ಷೆಗಳು ಅಸ್ಪಷ್ಟವಾಗುತ್ತವೆ. ನಕಲಿನಿಂದ ಹಿಂದಿನ ಸಂರಚನೆಯನ್ನು ಮರುಸ್ಥಾಪಿಸಿ, ಅಪ್ಲಿಕೇಶನ್ ಮರುಪ್ರಾರಂಭಿಸಿ ಮತ್ತು ಮೂಲ ವರ್ತನೆ ಮರಳಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ, ಹೋಲಿಕೆ ಸ್ವಚ್ಛವಾಗಿರಲು. ಪರಿಶೀಲಿಸದ ರೋಲ್ಬ್ಯಾಕ್ ಸ್ಥಿತಿ ಬದಲಾಗಿದೆ ಎಂಬ ಆಶೆಯಷ್ಟೇ.
UDP ಆಗಿಯೇ ಉಳಿಯಬೇಕಾದ ಸಾರಿಗೆಗೆ, VPN ಸಾಮಾನ್ಯವಾಗಿ ಹೆಚ್ಚು ಸೂಕ್ತ: ಅದು ಅಪ್ಲಿಕೇಶನ್ಗೆ ಪ್ರಾಕ್ಸಿ ಪ್ರೋಟೋಕಾಲ್ ಮಾತನಾಡಲು ಕೇಳದೆ ಅದರ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಸಾಗಿಸುತ್ತದೆ, ಸಂಪೂರ್ಣವಾಗಿ ಭಿನ್ನ ಅನಾಮಧೇಯತೆಯ ಗುಣಗಳ ವೆಚ್ಚದಲ್ಲಿ. ಪ್ರತಿ ಸಾಧನವನ್ನು ಅದು ದಸ್ತಾವೇಜಿಸುವ ಕೆಲಸಕ್ಕೆ ಬಳಸಿ, ಮತ್ತು ಅವುಗಳ ನಡುವಿನ ಯಾವುದೇ ಸೇತುವೆಯನ್ನು ತನ್ನದೇ ಪರಿಶೀಲನೆ ಬೇಕಾಗುವ ಪ್ರತ್ಯೇಕ ವ್ಯವಸ್ಥೆಯಾಗಿ ಪರಿಗಣಿಸಿ. ಅಂತಿಮ ವರದಿಯಲ್ಲಿ ಯಾವ ಪದರ ಯಾವ ಸಾರಿಗೆಯನ್ನು ಸಾಗಿಸುತ್ತದೆ ಎಂದು ಬರೆಯಿರಿ, ಮುಂದಿನ ವ್ಯಕ್ತಿ ಬೇರೆ ಅಪ್ಲಿಕೇಶನ್ನೊಂದಿಗೆ ಅದೇ ಗಡಿಯನ್ನು ಮತ್ತೆ ಕಂಡುಕೊಳ್ಳದಂತೆ.