ನೀತಿ ರೂಟಿಂಗ್ ಮತ್ತು SOCKS: ಯಾವ ಪದರವು ನಿಜವಾಗಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪ್ರಾಕ್ಸಿ ಮಾಡುತ್ತದೆ

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

ರೂಟಿಂಗ್, DNAT ಮತ್ತು SOCKS ಬೇರೆ ಬೇರೆ ವಸ್ತುಗಳನ್ನು ಬದಲಿಸುತ್ತವೆ

ನೀತಿ ಮಾರ್ಗವು ಪದರ 3 ರ ನಿರ್ಧಾರವನ್ನು ಮರುಬರೆಯುತ್ತದೆ. ಒಂದು ಕ್ಲೈಂಟ್ನ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ ಮುಂದಿನ ಹಾಪ್ಗೆ ಕಳುಹಿಸಲು ಎರಡು ಸಾಲುಗಳು ಸಾಕು:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

ಅದರ ನಂತರ ಕರ್ಣೆಲ್ ಪ್ಯಾಕೆಟ್ ಅನ್ನು 10.50.0.2 ಗೆ ಒಪ್ಪಿಸುತ್ತದೆ, ಮೂಲ ಗಮ್ಯಸ್ಥಾನ ಇನ್ನೂ IP ಹೆಡರ್ನಲ್ಲಿರುತ್ತದೆ. 10.50.0.2 ರೌಟರ್ ಆಗಿದ್ದರೆ, ಅದು ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ. ಅದು 1080 ರಲ್ಲಿ SOCKS ಡೀಮನ್ ಇರುವ ಹೋಸ್ಟ್ ಆಗಿದ್ದರೆ, ಪ್ಯಾಕೆಟ್ ಅನ್ನು ಸ್ವೀಕರಿಸಬಲ್ಲ ಯಾವುದಕ್ಕೂ ಸಂಬೋಧಿಸಲಾಗಿಲ್ಲ, ಮತ್ತು ಪೋರ್ಟ್ 1080 ಗೆ DNAT ಕೂಡ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅನುವಾದಿತ ಪ್ಯಾಕೆಟ್ ಇನ್ನೂ SOCKS ಅಭಿವಾದನೆಯ ಬದಲು ಮೂಲ ಅಪ್ಲಿಕೇಶನ್ ಪೇಲೋಡ್ ಅನ್ನು ಹೊತ್ತೊಯ್ಯುತ್ತದೆ.

SOCKS5 ಒಂದು ಆವೃತ್ತಿ ಬೈಟ್, ವಿಧಾನಗಳ ಪಟ್ಟಿ, ದೃಢೀಕರಣ ವಿನಿಮಯ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹೆಸರಿಸುವ ವಿನಂತಿಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಅದು ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾ. ಯಾವುದೇ ರೂಟಿಂಗ್ ನಮೂದು ಅಥವಾ netfilter ಗುರಿ ಅದನ್ನು ಉತ್ಪಾದಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಒಂದೇ ಸಾಲಿನಲ್ಲಿ ಹೋಲಿಕೆ ಇದು: ರೂಟಿಂಗ್ ಮಾರ್ಗವನ್ನು ಆರಿಸುತ್ತದೆ, SOCKS ಸರ್ವರ್ಗೆ ಎರಡನೇ ಸಂಪರ್ಕ ಮಾಡಲು ಹೇಳುತ್ತದೆ.

ಮೊದಲ ಪ್ರಕರಣ: ಅಪ್ಲಿಕೇಶನ್ ತಾನೇ SOCKS ಮಾತನಾಡಬಲ್ಲದು

ಪ್ರೋಗ್ರಾಂಗೆ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಇದ್ದರೆ, ಇದು ಅತಿ ಚಿಕ್ಕ ಮಾರ್ಗ ಮತ್ತು ಕರ್ಣೆಲ್ ಬದಲಾವಣೆ ಬೇಕಿಲ್ಲ. ಅದನ್ನು ಶ್ರೋತೃಗೆ ತೋರಿಸಿ, ಸರ್ವರ್ ಕೇಳಿದರೆ ರುಜುವಾತುಗಳನ್ನು ಒದಗಿಸಿ, ಮತ್ತು ಹೆಸರುಗಳು ಸ್ಥಳೀಯವಾಗಿ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆಯೇ ಅಥವಾ ಪ್ರಾಕ್ಸಿಗೆ ರವಾನೆಯಾಗುತ್ತವೆಯೇ ಎಂದು ನಿರ್ಧರಿಸಿ. curl ನಲ್ಲಿ ಇವು ಬೇರೆ ಬೇರೆ ಫ್ಲ್ಯಾಗ್ಗಳು, ಮತ್ತು ಗಮ್ಯಸ್ಥಾನವು ಪ್ರಾಕ್ಸಿ ಕಡೆಯಿಂದ ಮಾತ್ರ ಪರಿಹರಿಸಲ್ಪಡುವಾಗ ವ್ಯತ್ಯಾಸ ಮುಖ್ಯ:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

ಪ್ರಾಕ್ಸಿ ಪರಿಸರ ಚರಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಅಥವಾ ಕಚ್ಚಾ ಸಾಕೆಟ್ಗಳನ್ನು ತೆರೆಯುವ ಅಪ್ಲಿಕೇಶನ್ಗಳಿಗೆ ಈ ರೀತಿ ಸಹಾಯ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಬ್ರೌಸರ್ಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ HTTP ಪರಿಕರಗಳು ಸರಿ; ಆಟದ ಕ್ಲೈಂಟ್, ಮೇಲ್ ಡೀಮನ್ ಅಥವಾ ಯಾವುದೇ ವಿಕ್ರೇತೃ ಬೈನರಿ ಸಾಮಾನ್ಯವಾಗಿ ಅಲ್ಲ. ಗಡಿ ಪ್ರತಿ ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಪ್ರತಿ ಪ್ರೋಟೋಕಾಲ್ಗೆ, ಆದ್ದರಿಂದ ಈ ಆಯ್ಕೆ ಪರೀಕ್ಷೆಗೆ ಅತ್ಯುತ್ತಮ ಮತ್ತು ಇಡೀ VPN ಗೆ ಉತ್ತರವಾಗಿ ದುರ್ಬಲ.

ಎರಡನೇ ಪ್ರಕರಣ: IP ಹರಿವುಗಳನ್ನು ಪ್ರಾಕ್ಸಿ ಸೆಷನ್ಗಳಾಗಿ ಪರಿವರ್ತಿಸುವ ಅಡಾಪ್ಟರ್

SOCKS ಮಾತನಾಡಲಾಗದ ಪ್ರೋಗ್ರಾಂಗಳಿಗೆ, ಪರಿವರ್ತನೆ IP ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸುವ ಮತ್ತು ಅವರ ಪರವಾಗಿ ಪ್ರಾಕ್ಸಿ ಸೆಷನ್ಗಳನ್ನು ತೆರೆಯುವ ಯಾವುದೋ ಒಂದರಲ್ಲಿ ನಡೆಯಬೇಕು. ಆ ಘಟಕಕ್ಕೆ ಸುರಂಗ ಇಂಟರ್ಫೇಸ್ ಇದೆ, ನೀತಿ ರೂಟಿಂಗ್ ಆಯ್ಕೆ ಮಾಡಿದ ಹರಿವುಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ SOCKS ಹ್ಯಾಂಡ್ಶೇಕ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಉತ್ತರಗಳನ್ನು ಮರುನಿರ್ಮಿಸುತ್ತದೆ. ಮಾರ್ಗವು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಅದರ ಕಡೆಗೆ ನಿರ್ದೇಶಿಸುತ್ತದೆ; ಸೆಷನ್ ಅನ್ನು ಸೃಷ್ಟಿಸುವುದು ಅಡಾಪ್ಟರ್.

ಸಂಪೂರ್ಣ ಉಪಜಾಲಕ್ಕೆ ಅದನ್ನು ಒಪ್ಪಿಸುವ ಮೊದಲು ಅದರ ದಾಖಲೆ ಓದಿ. ಅನೇಕ ಅಡಾಪ್ಟರ್ಗಳು TCP ಯನ್ನು ಚೆನ್ನಾಗಿ ಸಾಗಿಸುತ್ತವೆ ಮತ್ತು UDP ಯನ್ನು SOCKS5 UDP ಸಂಘದ ಮೂಲಕ ಮಾತ್ರ ನಿರ್ವಹಿಸುತ್ತವೆ, ಮತ್ತು ಅವುಗಳಲ್ಲಿ ಯಾವುದೂ ICMP ಯನ್ನು ಪ್ರಾಕ್ಸಿ ಟ್ರಾಫಿಕ್ ಆಗಿ ಪರಿವರ್ತಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಶಸ್ವಿ ping ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. DNS ಇನ್ನೊಂದು ಬಲೆ: ಅಡಾಪ್ಟರ್ ಹೆಸರುಗಳನ್ನು ಸ್ಥಳೀಯವಾಗಿ ಪರಿಹರಿಸಿದರೆ, ಒಳಗಿನ ರೆಕಾರ್ಡ್ಗಳು ತಪ್ಪು ಉತ್ತರಕ್ಕೆ ಅಥವಾ ಸಂಪೂರ್ಣ ಏನೂ ಇಲ್ಲದಿರುವುದಕ್ಕೆ ಪರಿಹರಿಸಲ್ಪಡುತ್ತವೆ.

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

ಮೂರನೇ ಪ್ರಕರಣ: ಹೋಸ್ಟ್ ನಿಜವಾಗಿಯೂ ರೂಟ್ ಮಾಡಿದ ಗೇಟ್ವೇ

ಕೆಲವೊಮ್ಮೆ ಕೆಲಸ ಮಾಡುವ ಸೆಟಪ್ನಲ್ಲಿ SOCKS ಇಲ್ಲದೇ ಇರುತ್ತದೆ. ದೂರದ ಹೋಸ್ಟ್ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆ ಅಥವಾ ಅವುಗಳಿಗೆ NAT ಮಾಡುತ್ತದೆ, ಮತ್ತು ಮೂಲ ಆಧಾರಿತ ನಿಯಮ ಅದನ್ನು ನಿರ್ಗಮನವಾಗಿ ಆರಿಸುತ್ತದೆ. ಆ ವಿನ್ಯಾಸ ಕಾನೂನುಬದ್ಧ, ಮತ್ತು ನಕಲಿಸಿದ ಸಂರಚನೆ ಒಂದು ಜಾಲದಲ್ಲಿ ಕೆಲಸ ಮಾಡಿ ಇನ್ನೊಂದರಲ್ಲಿ ಏಕೆ ವಿಫಲವಾಗುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ: ನಿಯಮ ಒಂದೇ, ಕಾಣೆಯಾದ ಭಾಗ ಆಚೆ ಬದಿಯಲ್ಲಿ ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುವ ಸೇವೆ.

ಮೂರು ಪ್ರಕರಣಗಳು ಬೇಗ ಬೇರ್ಪಡುತ್ತವೆ. ನಿಜವಾಗಿ ಯಾವುದು ಕೇಳುತ್ತಿದೆ ಎಂದು ಪರಿಶೀಲಿಸಿ, ನಂತರ ಹೋಸ್ಟ್ ತಲುಪುವ ಮೊದಲ ಬೈಟ್ಗಳನ್ನು ನೋಡಿ:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

ನಿಜವಾದ SOCKS ಕ್ಲೈಂಟ್ನ ಮೊದಲ ಪೇಲೋಡ್ ಬೈಟ್ 0x05, ಅಭಿವಾದನೆಯಲ್ಲಿನ ಆವೃತ್ತಿ. ಸೆರೆಹಿಡಿಯುವಿಕೆ ಬದಲಾಗಿ ಮೂಲ ಅಪ್ಲಿಕೇಶನ್ ಡೇಟಾವನ್ನು ತೋರಿಸಿದರೆ, ಯಾವುದೇ SOCKS ಡೀಮನ್ ಉತ್ತರಿಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಮಾತುಕತೆ ಎಂದಿಗೂ ಪ್ರಾರಂಭವಾಗಿಲ್ಲ. 1080 ರಲ್ಲಿ ಏನೂ ಕೇಳದಿದ್ದರೆ, ಹೋಸ್ಟ್ ಗೇಟ್ವೇ, ಮತ್ತು ಪ್ರಶ್ನೆ ಅದು ಮುಂದಕ್ಕೆ ಕಳುಹಿಸುತ್ತದೆಯೇ ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗ ಇದೆಯೇ ಎಂಬುದಾಗುತ್ತದೆ.

ನಾಲ್ಕು ಪ್ರಶ್ನೆಗಳಿಂದ ಪದರವನ್ನು ಆರಿಸಿ

ಪ್ರೋಗ್ರಾಂಗೆ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಇದೆಯೇ? ಅದನ್ನು ಬಳಸಿ ಮತ್ತು ಅಲ್ಲೇ ನಿಲ್ಲಿ. ಟ್ರಾಫಿಕ್ನಲ್ಲಿ ಉಳಿಯಬೇಕಾದ UDP ಅಥವಾ ICMP ಇದೆಯೇ? ICMP ಯನ್ನು ರೂಟ್ ಮಾಡಿದ ಅಥವಾ NAT ಗೇಟ್ವೇ ಮಾತ್ರ ಸಾಗಿಸುತ್ತದೆ, ಮತ್ತು UDP ಗೆ ಎರಡೂ ತುದಿಗಳು ಬೆಂಬಲಿಸುವ SOCKS5 ಸಂಘ ಬೇಕು. ಯಂತ್ರದ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು, ನೀವು ಸಂರಚಿಸಲಾಗದವುಗಳೂ ಸೇರಿ, ಆವರಿಸಬೇಕೇ? ಹಾಗಿದ್ದರೆ ಇಂಟರ್ಫೇಸ್ ಹೊಂದಿರುವ ಮತ್ತು ಹರಿವುಗಳನ್ನು ಕೊನೆಗೊಳಿಸುವ ಅಡಾಪ್ಟರ್ ಬೇಕು. ಅದರ ರೂಟಿಂಗ್, DNS ಮತ್ತು ಲೂಪ್ ತಡೆ ವಿನಾಯಿತಿಗಳನ್ನೂ ನೀವು ತೆಗೆದುಕೊಳ್ಳಬಹುದೇ? ಇಲ್ಲದಿದ್ದರೆ ಸಾಮಾನ್ಯ ಗೇಟ್ವೇ ನಿರ್ವಹಣೆಗೆ ಕಡಿಮೆ ವೆಚ್ಚವಾಗುತ್ತದೆ.

ಒಂದು ಭೇದವನ್ನು ನೇರವಾಗಿ ಇಟ್ಟುಕೊಳ್ಳುವುದು ಯೋಗ್ಯ. VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ socks-proxy ಆಯ್ಕೆ ಹೊರಗಿನ ಸುರಂಗ ಸಂಪರ್ಕವು ತನ್ನ ಸರ್ವರ್ ಅನ್ನು ಹೇಗೆ ತಲುಪುತ್ತದೆ ಎಂದು ವಿವರಿಸುತ್ತದೆ, ಮತ್ತು ಒಳಗಿನ ಕ್ಲೈಂಟ್ ಹರಿವುಗಳ ಪರಿವರ್ತನೆಯ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳುವುದಿಲ್ಲ. ಎರಡನ್ನೂ ಒಂದೇ ಟಿಕೆಟ್ನಲ್ಲಿ ಪದೇ ಪದೇ ಗೊಂದಲ ಮಾಡಲಾಗುತ್ತದೆ. ಮಾರ್ಗವನ್ನು ಮುಟ್ಟುವ ಮೊದಲು ನಿಮಗೆ ಯಾವ ಸಂಬಂಧ ಬೇಕೆಂದು ನಿರ್ಧರಿಸಿ.