SOCKS5 ಮೇಲೆ OpenVPN: ಆವೃತ್ತಿ, ಸಾಗಣೆ ಮತ್ತು DNS ಹೊಂದಾಣಿಕೆ

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

ಫೈರ್ವಾಲ್ ಮೊದಲು SOCKS ಆವೃತ್ತಿ ಹೊಂದಿಸಿ

ಸಮುದಾಯ OpenVPN socks-proxy ಗಾಗಿ SOCKS5 ಮಾತನಾಡುತ್ತದೆ. SOCKS4 ಮಾತ್ರ ನೀಡುವ ಪ್ರಾಕ್ಸಿಗೆ ಅದನ್ನು ಜೋಡಿಸಿದರೆ TCP ಸಂಪರ್ಕ ತೆರೆದು ನಂತರ ನಿಲ್ಲುತ್ತದೆ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಇನ್ನೊಂದು ತುದಿ ಎಂದೂ ವಿಶ್ಲೇಷಿಸದ ಶುಭಾಶಯಕ್ಕೆ ಉತ್ತರಕ್ಕಾಗಿ ಕಾಯುತ್ತದೆ. ಹೊರಗಿನಿಂದ ಈ ನಿಲುವು ಫಿಲ್ಟರ್ ಆದ ಪೋರ್ಟ್ನಂತೆಯೇ ಕಾಣುತ್ತದೆ, ಆದ್ದರಿಂದ ಆವೃತ್ತಿಯ ಪ್ರಶ್ನೆ ಯಾವುದೇ ಫೈರ್ವಾಲ್ ನಿಯಮಕ್ಕಿಂತ ಮೊದಲು ಬರುತ್ತದೆ. SOCKS ತಿಳಿದಿರುವ ಒಂದು ಫೆಚ್ ಅದನ್ನು ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ ನಿರ್ಣಯಿಸುತ್ತದೆ.

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example

ಪೂರ್ಣಗೊಂಡ ವಿನಂತಿ ಒಟ್ಟಿಗೆ ಎರಡು ವಿಷಯ ಸಾಬೀತುಪಡಿಸುತ್ತದೆ: ಪ್ರಾಕ್ಸಿ SOCKS ವಿನಂತಿ ಸ್ವೀಕರಿಸಿತು ಮತ್ತು ಹೆಸರನ್ನು ವಿಶ್ಲೇಷಿಸಿತು. URL ಸ್ಕೀಮ್ ಬೇಕಿಲ್ಲ, ಏಕೆಂದರೆ curl ಬರಿ ಹೋಸ್ಟ್ ಅನ್ನು HTTP ಎಂದು ಪರಿಗಣಿಸುತ್ತದೆ, ಇದು ಈ ಪರೀಕ್ಷೆಗೆ ಸಾಕು.

ಆ ಫೆಚ್ ಕ್ಲೈಂಟ್ ಲಾಗ್ ಮರೆಮಾಡುವ ವೈಫಲ್ಯವನ್ನೂ ತೆಗೆದುಹಾಕುತ್ತದೆ. ಪ್ರಾಕ್ಸಿ ಬ್ರೌಸರಿಗೆ ಅನುಮತಿ ನೀಡಿಯೂ VPN ಗಮ್ಯವನ್ನು ನಿರಾಕರಿಸಬಹುದು, ಆಗ ನಿರಾಕರಣೆ CONNECT ನಲ್ಲಿ ನಡೆಯುತ್ತದೆ, ಯಾವುದೇ VPN ದೃಢೀಕರಣಕ್ಕೂ ಮೊದಲು. OpenVPN ಕೇವಲ ಕಾಲಮಿತಿ ತಿಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಪ್ರಾಕ್ಸಿಯ ಸ್ವಂತ ಉತ್ತರವೇ ನಿಮಗೆ ಬೇಕಾದ ಸಾಕ್ಷ್ಯ.

ಸಾಗಣೆ ಎರಡೂ ಕಡೆ TCP ಆಗಿರಬೇಕು

SOCKS5 ಇಲ್ಲಿ TCP ಸ್ಟ್ರೀಮ್ ಒಯ್ಯುತ್ತದೆ, ಆದ್ದರಿಂದ ಸುರಂಗಕ್ಕೇ proto tcp-client ಬೇಕು. ಇನ್ನೂ UDP ನಲ್ಲಿ ಇರುವ ಪ್ರೊಫೈಲ್ ಈ ಮಾರ್ಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಕ್ಲೈಂಟ್ ಪ್ರೋಟೋಕಾಲ್ನ UDP ಸಂಘ ಮೋಡ್ ಬಳಸುವುದಿಲ್ಲ. ಪ್ರೊಫೈಲ್ ತಿರುಗಿಸುವುದು ನಿಜವಾದ ಬದಲಾವಣೆ, ಔಪಚಾರಿಕತೆ ಅಲ್ಲ: ದೂರ ತುದಿ ಅದೇ ಪೋರ್ಟ್ನಲ್ಲಿ TCP ಮೇಲೆ ಕೇಳಬೇಕು. ನಂತರ ಪೇಲೋಡ್ TCP ಒಳಗೆ TCP ಆಗುತ್ತದೆ, ಅಲ್ಲಿ ಕಳೆದುಹೋದ ವಿಭಾಗ ಎರಡು ಬಾರಿ ಮರುಕಳುಹಿಸಲ್ಪಡುತ್ತದೆ ಮತ್ತು ವೇಗ ಇಳಿಯುತ್ತದೆ, ಇದನ್ನು ಸಂವಾದಾತ್ಮಕ ಅವಧಿಗಳು ದೊಡ್ಡ ವರ್ಗಾವಣೆಗಳಿಗಿಂತ ಹೆಚ್ಚು ಗಮನಿಸುತ್ತವೆ.

proto tcp-client
remote gw.lab.example 8443
socks-proxy 127.0.0.1 9050

ಈ ಸೂಚನೆ ಪ್ರಾಕ್ಸಿ ಹೋಸ್ಟ್, ಐಚ್ಛಿಕ ಪೋರ್ಟ್ ಮತ್ತು ಐಚ್ಛಿಕ ರುಜುವಾತು ಕಡತವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಅವನ್ನು ಪ್ರೊಫೈಲ್ನಲ್ಲೇ ಇರಿಸಿ, ಬೇರೆಡೆ ಇರಿಸಿದ ಪ್ರತಿ ಅದೇ ರೀತಿ ವರ್ತಿಸುತ್ತದೆ.

ಇಡೀ ಸರಪಳಿಯನ್ನು ಒಂದು ಕಂಟೇನರಿಗೆ ಸೀಮಿತಗೊಳಿಸಿ

ಸರಪಳಿಯನ್ನು ಹೋಸ್ಟ್ನಲ್ಲಿ ಮಾಡುವುದು ಎಂದರೆ ಅದರ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ವಶಪಡಿಸಿಕೊಳ್ಳುವುದು ಮತ್ತು resolver ಅನ್ನು ನಂತರ ಯಾರೂ ವಿವರಿಸಲಾಗದ ಸ್ಥಿತಿಯಲ್ಲಿ ಬಿಡುವುದು. ಹೆಸರಿನ ಜಾಗ ಅಥವಾ ಕಂಟೇನರ್ ಅದನ್ನು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೋಸ್ಟ್ ತನ್ನ ಮಾರ್ಗವನ್ನು ಇಟ್ಟುಕೊಳ್ಳುತ್ತದೆ, SOCKS ಹಾಪ್ ಮತ್ತು ಸುರಂಗ ಜೊತೆಯಾಗಿ ಇರುತ್ತವೆ. ಅದರೊಳಗೆ ಸುರಂಗ ಸಾಧನ, ಆ ಸಾಧನವನ್ನು ಸಂರಚಿಸುವ ಹಕ್ಕುಗಳು, ತಲುಪಬಹುದಾದ ಪ್ರಾಕ್ಸಿ ಇಲ್ಲದೆ ಏನೂ ಏಳುವುದಿಲ್ಲ. Compose ಸೇವೆ ಇದನ್ನು cap_add: NET_ADMIN ಮತ್ತು bind-ಮೌಂಟ್ ಆದ /dev/net/tun ಮೂಲಕ ಪಡೆಯುತ್ತದೆ.

cap_add:
  - NET_ADMIN
devices:
  - /dev/net/tun:/dev/net/tun

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

ಹೆಸರು ವಿಶ್ಲೇಷಣೆಯೇ ಪ್ರತ್ಯೇಕತೆ ವಿಫಲವಾಗುವ ಸ್ಥಳ

ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಒಯ್ಯುತ್ತಲೇ ಹೋಸ್ಟ್ನ resolver ಅನ್ನು ಕೇಳುವ ಸುರಂಗ ಏನನ್ನೂ ಪ್ರತ್ಯೇಕಿಸಿಲ್ಲ. ಎರಡು ವಿಷಯಗಳು ಪ್ರತ್ಯೇಕತೆಯನ್ನು ನಿಜವಾಗಿಸುತ್ತವೆ: ಹೆಸರಿನ ಜಾಗಕ್ಕೆ ಸ್ವಂತ resolver ಇರುವುದು, ಮತ್ತು ಅದರ ಪ್ರಶ್ನೆಗಳು ಪ್ರಾಕ್ಸಿ ಅಥವಾ ಸುರಂಗದ ಮೂಲಕ ಹೋಗುವುದು, ಎಂದೂ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕ ಹೋಗದಿರುವುದು. ಪರೀಕ್ಷೆಗೆ ಎರಡು ಹೆಸರುಗಳನ್ನು ಬಳಸಿ: ಒಂದು ಸುರಂಗದ ಹಿಂದೆ ಮಾತ್ರ ಇರುತ್ತದೆ, ಇನ್ನೊಂದು ಅದೇ ಮಾರ್ಗ ತೆಗೆದುಕೊಳ್ಳಬೇಕಾದ ಸಾರ್ವಜನಿಕ ಹೆಸರು.

docker compose exec vpn cat /etc/resolv.conf
docker compose exec vpn getent hosts internal.lab.example

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

ಪ್ರತಿ ಹಾಪ್ ಅನ್ನು ಕ್ರಮವಾಗಿ ಸಾಬೀತುಪಡಿಸಿ

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

curl --socks5-hostname 127.0.0.1:9050 gw.lab.example
docker compose exec vpn ip route get 203.0.113.10
docker compose exec vpn getent hosts internal.lab.example

ಕೆಲಸ ಮಾಡಿದ ಸಂಯೋಜನೆಯನ್ನು ಬರೆದಿಡಿ: SOCKS ಆವೃತ್ತಿ, ಸಾಗಣೆ, resolver ಮತ್ತು ಹೆಸರಿನ ಜಾಗದ ಸೆಟ್ಟಿಂಗ್ಗಳು. ಈ ಸರಪಳಿಯನ್ನು ಎರಡನೇ ಬಾರಿ ನೆನಪಿನಿಂದ ಪರಿಹರಿಸುವುದು ಟಿಪ್ಪಣಿಗಿಂತ ದುಬಾರಿ. ಆ ನಾಲ್ಕು ಸತ್ಯಗಳನ್ನು ಟಿಕೆಟ್ನಲ್ಲಿ ಇರಿಸಿ, ಚಾಟ್ ಥ್ರೆಡ್ನಲ್ಲಿ ಅಲ್ಲ.

ಸಂಪರ್ಕಗೊಂಡಿದೆ ಎಂದು ಹೇಳಿ ಏನನ್ನೂ ರವಾನಿಸದ ಸರಪಳಿ, ನೀವು ಇನ್ನೂ ಸಾಬೀತುಪಡಿಸದ ಹಾಪ್ನಲ್ಲೇ ಸಾಮಾನ್ಯವಾಗಿ ವಿಫಲವಾಗಿರುತ್ತದೆ. ಇನ್ನೊಂದು ಪದರ ಸೇರಿಸುವ ಮೊದಲು ಆ ಹಾಪ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ.