Tor ರಿಲೇ ಮತ್ತು VPN ಸರ್ವರ್: ಏಕೆ ಇವು ಪರಸ್ಪರ ಬದಲಿಯಲ್ಲ
Tor ರಿಲೇ ಮೇಲಿನ ತೆರೆದ ಪೋರ್ಟ್ VPN ಎಂಡ್ಪಾಯಿಂಟ್ ಅಲ್ಲ. ಮೊದಲು ಪೋರ್ಟ್ ಏನು ಸೇವೆ ನೀಡುತ್ತದೆ, ರಿಲೇಯ ಪಾತ್ರ, SOCKS ಆಲಿಸುವವರ ವ್ಯಾಪ್ತಿ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಪರಿಶೀಲಿಸಿ.
ನಿಮ್ಮ ಬಳಿ ಒಂದು ವಿಳಾಸವಿದೆ, ಪೋರ್ಟ್ ಉತ್ತರಿಸುತ್ತದೆ, ಮತ್ತು ಕ್ಲೈಂಟ್ ಯಾವುದೇ ದೂರಿಲ್ಲದೆ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ. ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ Tor ರಿಲೇಯನ್ನು VPN ಎಂಡ್ಪಾಯಿಂಟ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ತಪ್ಪು ದುಬಾರಿಯಾಗಿದೆ ಏಕೆಂದರೆ ಪ್ರೊಫೈಲ್ ಸ್ವಚ್ಛವಾಗಿ ಆಮದಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಹ್ಯಾಂಡ್ಶೇಕ್ನಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ. ನಾನು ಕೆಳಗಿನ ನಾಲ್ಕು ಪರಿಶೀಲನೆಗಳನ್ನು ಕ್ರಮವಾಗಿ ಬಳಸುತ್ತೇನೆ; ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಿಲ್ಲಿಸುವ ಷರತ್ತು ಇದೆ, ಮತ್ತು ಬೇಗ ನಿಲ್ಲಿಸುವುದೇ ಮುಖ್ಯ ಅಂಶ. ಮೊದಲ ಪರಿಶೀಲನೆ ವಿಫಲವಾದರೆ, ಉಳಿದವು ನಿಮಗೆ ಸಹಾಯ ಮಾಡಲಾರವು.
ಪೋರ್ಟ್ ನಿಜವಾಗಿ ಏನು ಸೇವೆ ನೀಡುತ್ತದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ
ತೆರೆದ ಪೋರ್ಟ್ ಆಲಿಸುವವರ ಇರುವಿಕೆಯನ್ನು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ, ಅಷ್ಟೇ. ರಿಲೇಯ ORPort TLS ಹ್ಯಾಂಡ್ಶೇಕ್ ನಂತರ Tor ನ ಸ್ವಂತ ಕೋಶಗಳೊಂದಿಗೆ ಮಾತನಾಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಯಶಸ್ವಿ TLS ಪರೀಕ್ಷೆ ಅಲ್ಲಿ VPN ಪ್ರೋಟೋಕಾಲ್ ಸ್ವೀಕರಿಸಲ್ಪಡುತ್ತದೆಯೇ ಎಂಬುದರ ಬಗ್ಗೆ ಬಹುತೇಕ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ:
nc -vz 203.0.113.20 443
openssl s_client -connect 203.0.113.20:443 -brief < /dev/null
ಪ್ರಮಾಣಪತ್ರ ಇದೆಯೇ ಎಂಬುದಲ್ಲ, ಪ್ರಮಾಣಪತ್ರವನ್ನೇ ಓದಿ. ರಿಲೇಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಗಮನಸೆಳೆಯದ ಹೆಸರಿನ ಸ್ವಯಂ-ಸಹಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸುತ್ತವೆ, ಏಕೆಂದರೆ ರಿಲೇ ಸಂಚಾರ ಸಾಮಾನ್ಯ HTTPS ನಂತೆ ಕಾಣಬೇಕು; VPN ಸರ್ವರ್ನ ಪ್ರಮಾಣಪತ್ರ ನಿಮ್ಮ ಪ್ರೊಫೈಲ್ ನಿರೀಕ್ಷಿಸುವ ಹೆಸರನ್ನು ಹೊಂದಿರುತ್ತದೆ. ಎದುರಿನ ಪಕ್ಷವು VPN ಪ್ರೋಟೋಕಾಲ್ನ ಮೊದಲ ಪ್ಯಾಕೆಟ್ಗೆ ಎಂದಿಗೂ ಉತ್ತರಿಸದಿದ್ದರೆ, ಪ್ರೊಫೈಲ್ ಸಂಪಾದನೆ ಎಷ್ಟೇ ಮಾಡಿದರೂ ಫಲಿತಾಂಶ ಬದಲಾಗುವುದಿಲ್ಲ.
ವಿಳಾಸವು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಕಳುಹಿಸುವ ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸದಿದ್ದರೆ ಇಲ್ಲೇ ನಿಲ್ಲಿಸಿ. ಅದು ಪ್ರೋಟೋಕಾಲ್ನ ಉತ್ತರ, ಸಂರಚನೆಯ ಸಮಸ್ಯೆ ಅಲ್ಲ, ಮತ್ತು ಆಮದಾದ ಪ್ರೊಫೈಲ್ ಶಾಶ್ವತವಾಗಿ 'connecting' ನಲ್ಲಿ ಉಳಿಯುವ ಅತ್ಯಂತ ಸಾಮಾನ್ಯ ಕಾರಣ ಅದೇ.
ಜಾಲಬಂಧದ ಗಾತ್ರವಲ್ಲ, ರಿಲೇಯ ಪಾತ್ರವನ್ನು ಪರಿಶೀಲಿಸಿ
ರಿಲೇ ಪಾತ್ರಗಳು ಬೇರೆ ಬೇರೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ. Guard ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಮೊದಲ ಹೆಜ್ಜೆ, ಮಧ್ಯ ರಿಲೇ ಇತರ ರಿಲೇಗಳ ನಡುವೆ ಸರ್ಕ್ಯೂಟ್ಗಳನ್ನು ಮುಂದೆ ಕಳುಹಿಸುತ್ತದೆ, exit ಗಮ್ಯಸ್ಥಾನಗಳನ್ನು ಸ್ಪರ್ಶಿಸುವ ಪಾತ್ರ, ಮತ್ತು ಸೇತುವೆ BridgeDB ಮೂಲಕ ಹಂಚಲ್ಪಡುವ ಸಾರ್ವಜನಿಕವಲ್ಲದ ಪ್ರವೇಶ ಬಿಂದು. Tor ನ ಪದಕೋಶ ಈ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ತಲುಪಬಹುದಾಗಿರುವುದು ಪ್ರತಿ ಪಾತ್ರದ ಭಾಗವಾದರೆ ಅನಿಯತ ಕ್ಲೈಂಟ್ಗಳಿಗೆ ಸೇವೆ ನೀಡುವ ಅನುಮತಿ ಯಾವುದರ ಭಾಗವೂ ಅಲ್ಲ.
exit ನೀತಿಯನ್ನು ಓದುವುದು ಯೋಗ್ಯ ಏಕೆಂದರೆ ಅದು ಮುಂದೆ ಕಳುಹಿಸುವ ನಿಯಮವನ್ನು ಹೋಲುವ ಏಕೈಕ ಭಾಗ, ಮತ್ತು exit ಯಾವ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಹೊರಹೋಗಲು ಅನುಮತಿ ನೀಡುತ್ತದೆ ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ, ಒಳಬರಲು ಅನುಮತಿಸುವ ಕ್ಲೈಂಟ್ಗಳನ್ನಲ್ಲ. ಪೋರ್ಟ್ 25 ಅನ್ನು ತಡೆಯುವ ಕಟ್ಟುನಿಟ್ಟಿನ exit ನೀತಿ ಹೊರಹೋಗುವ ದುರುಪಯೋಗದ ನಿಯಂತ್ರಣದ ಬಗ್ಗೆ ಏನೋ ಹೇಳುತ್ತದೆ, OpenVPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಯಂತ್ರದ ಕಡೆಗೆ ತೋರಿಸಬಹುದೇ ಎಂಬುದರ ಬಗ್ಗೆ ಅಲ್ಲ.
ಖ್ಯಾತಿಯಿಂದ ತರ್ಕಿಸುತ್ತಿದ್ದರೆ ನಿಲ್ಲಿಸಿ: ರಿಲೇಗಳು ಸಂಚಾರವನ್ನು ಮುಂದೆ ಕಳುಹಿಸುವುದರಿಂದ, ವಿಳಾಸವು ನಿಮ್ಮದನ್ನು ಸ್ವೀಕರಿಸಬೇಕು. Tor ಸಮ್ಮತಿ ಮತ್ತು ತನ್ನದೇ ಪ್ರೋಟೋಕಾಲ್ ಮೂಲಕ ಮಾರ್ಗಗಳನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ; VPN ಕ್ಲೈಂಟ್ ಭಾಗಿಯಲ್ಲ ಮತ್ತು ಸೇರಲು ಸರ್ಕ್ಯೂಟ್ ಇಲ್ಲ.
SOCKS ಆಲಿಸುವವರು ಸ್ಥಳೀಯರೇ ಅಥವಾ ಸಾರ್ವಜನಿಕರೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
Tor ನ ಕ್ಲೈಂಟ್ ಅದೇ ಯಂತ್ರದ ಅನ್ವಯಗಳಿಗೆ SOCKS ಇಂಟರ್ಫೇಸ್ ಒದಗಿಸುತ್ತದೆ, ಡೀಫಾಲ್ಟ್ ಆಗಿ loopback ನಲ್ಲಿ. ಆ ಆಲಿಸುವವರು ಸ್ಥಳೀಯ ಸೌಲಭ್ಯ, ರಿಲೇ ಇಂಟರ್ನೆಟ್ಗೆ ನೀಡುವ ಸೇವೆ ಅಲ್ಲ, ಮತ್ತು ಅದನ್ನು ಸಾರ್ವಜನಿಕ ಪ್ರಾಕ್ಸಿ ಎಂದು ಪರಿಗಣಿಸುವುದೇ ಜನರು ಉದ್ದೇಶಿಸದೆ ತೆರೆದ ರಿಲೇ ನಡೆಸಲು ತಲುಪುವ ದಾರಿ:
ss -ltnp | grep 9050
curl --socks5-hostname 127.0.0.1:9050 https://check.torproject.org
ಬೈಂಡ್ ವಿಳಾಸವೇ ಸುಳಿವು. 127.0.0.1:9050 ನಲ್ಲಿನ SocksPort ತನ್ನ ಕೆಲಸ ಮಾಡುತ್ತಿದೆ; 0.0.0.0 ನಲ್ಲಿ ಆಲಿಸಿ ಹೊರಗಿನಿಂದ ತಲುಪಬಹುದಾದ್ದು ತೆರೆದ ಪ್ರಾಕ್ಸಿ, ಮತ್ತು Tor ನ ಸ್ವಂತ ಪ್ರವೇಶ ನೀತಿ ನಿಯಂತ್ರಣಗಳು ಇರುವುದೇ ಆ ಒಡ್ಡುವಿಕೆ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ, ಸಮಸ್ಯೆ ಎಂಬ ಕಾರಣಕ್ಕೆ.
Tor ಬೇಕಾಗುವ ಅನ್ವಯಕ್ಕೆ ಅದನ್ನು loopback ಪೋರ್ಟ್ಗೆ ತೋರಿಸಿ ಮತ್ತು ಹೆಸರುಗಳನ್ನು Tor ಬಿಡಿಸಲಿ, ಮೇಲಿನ socks5h ರೂಪ ಅದನ್ನೇ ಮಾಡುತ್ತದೆ. ಆ ಪೋರ್ಟ್ಗೆ ರಿಲೇಯ ವಿಳಾಸವನ್ನು ಬದಲಿಸಬೇಡಿ; ನಿಮ್ಮ ಅನ್ವಯ ಕೇಳುವ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ರಿಲೇ ಒದಗಿಸುವುದಿಲ್ಲ.
VPN ಪ್ರೊಫೈಲ್ ನಿಜವಾದ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಹೊಂದುತ್ತದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ
VPN ಪ್ರೊಫೈಲ್ ನಿರೀಕ್ಷೆಗಳ ಕಟ್ಟು: OpenVPN ಗೆ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ CA, ಕ್ಲೈಂಟ್ ಪ್ರಮಾಣಪತ್ರ ಮತ್ತು ಕೀ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ TLS ಕೀ ಬೇಕು, ಆದರೆ WireGuard ಗೆ ಎದುರಿನ ಪಕ್ಷದ ಸಾರ್ವಜನಿಕ ಕೀ, ಎಂಡ್ಪಾಯಿಂಟ್ ಮತ್ತು ಅನುಮತಿಸಿದ IP ಬೇಕು. ಇವುಗಳಲ್ಲಿ ಯಾವುದನ್ನೂ ವಿಳಾಸ ಮತ್ತು ತೆರೆದ ಪೋರ್ಟ್ನಿಂದ ಪಡೆಯಲಾಗದು, ಆದ್ದರಿಂದ ಹೀಗೆ ನಿರ್ಮಿಸಿದ ಪ್ರೊಫೈಲ್ ಸಂಪರ್ಕದಲ್ಲಿ ಅಲ್ಲ, ಮೊದಲ ವಿನಿಮಯದಲ್ಲೇ ವಿಫಲವಾಗುತ್ತದೆ.
ನಿಮಗೆ ಪ್ರೊಫೈಲ್ ನೀಡಿದಾಗ, ನೀವು ನಿಯಂತ್ರಿಸುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಅಥವಾ ಗುರುತಿಸಬಹುದಾದ ಪೂರೈಕೆದಾರರ ವಿರುದ್ಧ ಅದನ್ನು ಪರಿಶೀಲಿಸಿ:
wg show
openvpn --config client.ovpn --verb 4
OpenVPN ಲಾಗ್ನಲ್ಲಿ TLS ಮಾತುಕತೆಯ ದೋಷ ಅಸಮಂಜಸತೆಯನ್ನು ನೇರವಾಗಿ ಹೆಸರಿಸುತ್ತದೆ; wg show ನಲ್ಲಿ ಹ್ಯಾಂಡ್ಶೇಕ್ ಸಾಲಿಲ್ಲದ ಎದುರಿನ ಪಕ್ಷ ಎಂದೂ ಒಂದನ್ನು ಪೂರ್ಣಗೊಳಿಸಿಲ್ಲ. ಎರಡೂ ಕ್ಲೈಂಟ್ನ ತಿರುಗುವ ಸೂಚಕಕ್ಕಿಂತ ಹೆಚ್ಚು ಮಾಹಿತಿ ನೀಡುತ್ತವೆ, ಮತ್ತು ಎರಡೂ Tor ನ ಕಡೆಗಲ್ಲ, ಕೀ ಸಾಮಗ್ರಿ ಅಥವಾ ಪ್ರೋಟೋಕಾಲ್ನ ಕಡೆಗೆ ಸೂಚಿಸುತ್ತವೆ.
ನಿಜವಾಗಿ ಯಾವ ರಕ್ಷಣೆ ಬೇಕು ಎಂದು ಪರಿಶೀಲಿಸಿ
ಇದೇ ವಾಸ್ತುಶಿಲ್ಪವನ್ನು ನಿರ್ಧರಿಸುವ ಪರಿಶೀಲನೆ. Tor ಬ್ರೌಸರ್ VPN ನೀಡದ ಸರ್ಕ್ಯೂಟ್ ಪ್ರತ್ಯೇಕತೆ ಮತ್ತು ಬೆರಳಚ್ಚು ವಿರುದ್ಧ ರಕ್ಷಣೆ ನೀಡುತ್ತದೆ; VPN ಗಮ್ಯಸ್ಥಾನ ಕಾಣುವ ವಿಳಾಸವನ್ನು ಬದಲಿಸಿ ನಿಮ್ಮನ್ನು ಪೂರೈಕೆದಾರರ ಮುಂದೆ ದೃಢೀಕರಿಸುತ್ತದೆ. ಇವುಗಳ ನಡುವೆ ಆಯ್ಕೆ ಸುಸಂಗತತೆಯ ಪ್ರಶ್ನೆಯಲ್ಲ, ಅಪಾಯ ಮಾದರಿಯ ಪ್ರಶ್ನೆ, ಮತ್ತು ಎರಡನ್ನೂ ಬೆರೆಸುವುದು ಖಾಸಗಿ ತೋರುವ ಮತ್ತು ಹಾಗಿಲ್ಲದ ಸಂರಚನೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
ಸರಪಳಿಗೆ ಒಂದು ಕ್ರಮವಿದೆ. Tor ಸಂಚಾರವನ್ನು ಹೊತ್ತೊಯ್ಯುವ VPN ಬೆಂಬಲಿತ ವ್ಯವಸ್ಥೆ, ಏಕೆಂದರೆ Tor ನ ಕ್ಲೈಂಟ್ಗೆ ಹೊರಹೋಗುವ TCP ಮಾತ್ರ ಬೇಕು. Tor ನ ಒಳಗೆ ಸುರಂಗ ಮಾಡಿದ VPN ಕ್ಲೈಂಟ್ ಅದೇ ವಸ್ತುವಲ್ಲ ಮತ್ತು Tor ಕ್ಲೈಂಟ್ ಜಾರಿಗೊಳಿಸುವುದೂ ಅದಲ್ಲ, ಆದ್ದರಿಂದ ಅದನ್ನು ಆಧರಿಸಿ ಯೋಜಿಸಬೇಡಿ.
ಏನನ್ನಾದರೂ ಆಮದು ಮಾಡುವ ಮೊದಲು, ನಾಲ್ಕನ್ನೂ ಖಚಿತಪಡಿಸಿ:
- ಪೋರ್ಟ್ ನಿಮ್ಮ ಪ್ರೋಟೋಕಾಲ್ನ ಹ್ಯಾಂಡ್ಶೇಕ್ ಪೂರ್ಣಗೊಳಿಸುತ್ತದೆ, ಕೇವಲ TCP ಸಂಪರ್ಕವಲ್ಲ.
- ನೀವು ಹೋಸ್ಟ್ನ ಪಾತ್ರವನ್ನು ತಿಳಿದಿದ್ದೀರಿ ಮತ್ತು ಮುಂದೆ ಕಳುಹಿಸುವುದನ್ನು ಅನುಮತಿ ಎಂದು ಪರಿಗಣಿಸುವುದಿಲ್ಲ.
- ನೀವು ಬಳಸುವ SOCKS ಆಲಿಸುವವರು loopback ಮತ್ತು ನಿಮ್ಮದು, ಬೇರೊಬ್ಬರ ರಿಲೇ ಮೇಲಿನ ಸಾರ್ವಜನಿಕ ಪೋರ್ಟ್ ಅಲ್ಲ.
- ಪ್ರೊಫೈಲ್ನ ಕೀಗಳು ಅಥವಾ ಪ್ರಮಾಣಪತ್ರಗಳು ನೀವು ಸಂಪರ್ಕಿಸುವ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಸೇರಿವೆ.