ಇಡೀ ಯಂತ್ರವಿಲ್ಲದೆ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು VPN ಮೂಲಕ ಕಳುಹಿಸುವುದು ಹೇಗೆ
ಯಾವುದೇ ನಿರ್ವಹಣೆ ಮಾಡದ ಡೆಸ್ಕ್ಟಾಪ್ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೆ VPN ಸ್ವಿಚ್ ನೀಡುವುದಿಲ್ಲ। ಸಂಚಾರವನ್ನು ಆರಿಸುವ ಪದರವನ್ನು ಆರಿಸಿ: ಬದ್ಧ ಸಾಕೆಟ್, UID ನಿಯಮ, ಫೈರ್ವಾಲ್ ಪ್ರೊಫೈಲ್ ಅಥವಾ SOCKS ಜಿಗಿತ।
VPN ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಗೊಳ್ಳುತ್ತದೆ, ಬ್ರೌಸರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು ನಿಜವಾಗಿ ಮುಖ್ಯವಾದ ಒಂದೇ ಆದೇಶ ಇನ್ನೂ ನಿಮ್ಮ ಮನೆಯ ಸಂಪರ್ಕದ ಮೂಲಕವೇ ಹೊರಹೋಗುತ್ತದೆ। ಅಥವಾ ವಿರುದ್ಧವಾಗಿ ನಡೆಯುತ್ತದೆ: ಸುರಂಗ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಹಿಡಿಯುತ್ತದೆ ಮತ್ತು ಸ್ಥಳೀಯ ಫೈಲ್ ಸರ್ವರ್ ಡೆಸ್ಕ್ಟಾಪ್ನಿಂದ ಮಾಯವಾಗುತ್ತದೆ। ನಾನು ಇದನ್ನು ಒಂದು ಬಿಲ್ಡ್ ಏಜೆಂಟ್ನಲ್ಲಿ ಎದುರಿಸಿದೆ, ಅದು ಒಳಗಿನ ಆರ್ಟಿಫ್ಯಾಕ್ಟ್ ಕನ್ನಡಿಯನ್ನು ತಲುಪಬೇಕಿತ್ತು, ಉಳಿದ ಹೋಸ್ಟ್ ಕಚೇರಿ LAN ನಲ್ಲೇ ಇತ್ತು, ಮತ್ತು ಕ್ಲೈಂಟ್ ನಿಖರವಾಗಿ ಎರಡು ಆಯ್ಕೆಗಳನ್ನು ನೀಡಿತು: ಎಲ್ಲಾ ಸಂಚಾರ ಅಥವಾ ಏನೂ ಇಲ್ಲ। ಎರಡೂ ದಿಕ್ಕುಗಳಲ್ಲಿ ಕೋರಿಕೆ ಒಂದೇ, ಈ ಪ್ರೋಗ್ರಾಂ ಮತ್ತು ಇಡೀ ಯಂತ್ರ ಅಲ್ಲ, ಮತ್ತು ಹೆಚ್ಚಿನ ಕ್ಲೈಂಟ್ಗಳಲ್ಲಿ ಇದಕ್ಕೆ ಚೆಕ್ ಬಾಕ್ಸ್ ಇಲ್ಲ, ಏಕೆಂದರೆ ಮಾರ್ಗ ಕೋಷ್ಟಕಕ್ಕೆ ಪ್ರೋಗ್ರಾಂ ಎಂದರೇನು ಎಂದು ಎಂದೂ ತಿಳಿದಿಲ್ಲ।
ಮಾರ್ಗ ಕೋಷ್ಟಕ ನಿಮ್ಮ ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಏಕೆ ನೋಡಲಾರದು
ಪ್ರಕ್ರಿಯೆ ಪ್ಯಾಕೆಟ್ ಕಳುಹಿಸಿದಾಗ, ಸ್ಟಾಕ್ ಮಾರ್ಗ ಕೋಷ್ಟಕದಲ್ಲಿ ಗಂತವ್ಯ ವಿಳಾಸವನ್ನು ಹುಡುಕುತ್ತದೆ। ಕಾರ್ಯನಿರ್ವಾಹಕ ಕಡತದ ಹೆಸರೂ ಪೋರ್ಟೂ ಆ ಹುಡುಕಾಟಕ್ಕೆ ಸೇರುವುದಿಲ್ಲ। ಡೊಮೇನ್ ಹೆಸರುಗಳು ಅದೇ ಕಾರಣಕ್ಕೆ ವಿಫಲವಾಗುತ್ತವೆ: ಸುರಂಗ ಸಂಚಾರವನ್ನು ವಿಳಾಸಕ್ಕೆ ಕೊಂಡೊಯ್ಯುತ್ತದೆ, ಮತ್ತು ಹೆಸರು ವಿಳಾಸವಾಗಿ ಪರಿವರ್ತನೆಯಾದಾಗ ಮಾರ್ಗನಿರ್ದೇಶನವೇ ಕರ್ಣಲ್ನ ಬಳಿ ಉಳಿದಿರುವ ಏಕೈಕ ತಳ್ಳುಗೋಲು। ಆದ್ದರಿಂದ «VPN ಕೇವಲ ಈ ಸೈಟ್ಗೆ» ಕೊನೆಗೆ ಪ್ರಾಕ್ಸಿ ಎಂದರ್ಥ, ಮತ್ತು «VPN ಕೇವಲ ಈ ಪ್ರೋಗ್ರಾಂಗೆ» ಸಣ್ಣ ಯಂತ್ರವ್ಯವಸ್ಥೆಗಳ ಗುಂಪಿನಲ್ಲಿ ಒಂದು ಎಂದರ್ಥ।
| Mechanism | What selects | Covers | On tunnel drop |
|---|---|---|---|
| Socket bind | source address | a client you control | connections fail |
| UID rule (Linux) | owning user | every process of one account | connections fail |
| Firewall profile (Windows) | adapter profile | one program | fails closed |
| Network namespace | namespace membership | everything started inside | connections fail |
| SOCKS hop | app proxy setting | one app or one browser profile | connections fail |
ಇವುಗಳಲ್ಲಿ ಯಾವುದೂ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯ ಮಾರ್ಗವಲ್ಲ। ಪ್ರತಿಯೊಂದೂ ನಿರ್ಣಯವನ್ನು ಪ್ರೋಗ್ರಾಂ, ಬಳಕೆದಾರ ಅಥವಾ ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಸಂರಚನೆಯನ್ನು ನೋಡಬಲ್ಲ ಪದರಕ್ಕೆ ಸರಿಸುತ್ತದೆ।
ಒಂದೇ ಗಂತವ್ಯ ಇನ್ನೂ ಒಂದು ಮಾರ್ಗ, ಪ್ರೋಗ್ರಾಂ ನಿಯಮ ಅಲ್ಲ। macOS ನಲ್ಲಿ ಸಾಮಾನ್ಯ ವಿಧಾನ «VPN ಮೂಲಕ ಎಲ್ಲಾ ಸಂಚಾರ ಕಳುಹಿಸು» ಎಂಬ ಟಿಕ್ ತೆಗೆದು ಹೋಸ್ಟ್ ಮಾರ್ಗ ಸೇರಿಸುವುದು: sudo route add -host internal-tuner.example -interface ppp0, ಅದನ್ನು ಮತ್ತೆ sudo route delete -host internal-tuner.example -interface ppp0 ನಿಂದ ತೆಗೆಯಲಾಗುತ್ತದೆ। ಮೊದಲು ifconfig ನಿಂದ ಇಂಟರ್ಫೇಸ್ ಹೆಸರನ್ನು ಓದಿ, ಏಕೆಂದರೆ ppp0 ಕೇವಲ ಉದಾಹರಣೆ। ಹೋಸ್ಟ್ ಮಾರ್ಗದಲ್ಲಿ ವೈಲ್ಡ್ ಕಾರ್ಡ್ಗಳು ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಹಲವು ಹೆಸರುಗಳೊಂದಿಗೆ ಮಾತನಾಡುವ ಸೇವೆಗೆ ಪ್ರತಿ ಹೆಸರಿಗೆ ಒಂದು ನಮೂದು ಬೇಕು, ಮತ್ತು ನಿಯಮವು ಯಂತ್ರದ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಆವರಿಸುತ್ತದೆ, ನೀವು ಉದ್ದೇಶಿಸಿದ ಒಂದನ್ನು ಅಲ್ಲ।
ಸಾಕೆಟ್ ಅನ್ನು ಸುರಂಗದ ವಿಳಾಸಕ್ಕೆ ಬಿಗಿಯಿರಿ
ಕ್ಲೈಂಟ್ ನಿಮ್ಮ ನಿಯಂತ್ರಣದಲ್ಲಿದ್ದಾಗ, ಬಂಧನವೇ ಅಗ್ಗದ ಆಯ್ಕೆಗಾರ। ಸುರಂಗದ ಸ್ಥಳೀಯ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಸಾಕೆಟ್ ಆ ಇಂಟರ್ಫೇಸ್ ಮೂಲಕವೇ ಹೊರಹೋಗುತ್ತದೆ, ಅಲ್ಲಿ ಗಂತವ್ಯಕ್ಕೆ ಮಾರ್ಗ ಇರುವವರೆಗೆ, ಮತ್ತು ಯಂತ್ರದ ಉಳಿದ ಎಲ್ಲವೂ ತನ್ನ ಸಾಮಾನ್ಯ ದಾರಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ। ಸೂಕ್ಷ್ಮತೆ ಎಂದರೆ ಬಂಧನವು ಮೂಲ ವಿಳಾಸವನ್ನು ಆರಿಸುತ್ತದೆ, ಆದರೆ ಮಾರ್ಗ ಕೋಷ್ಟಕ ಇನ್ನೂ ನಿರ್ಗಮನವನ್ನು ಆರಿಸುತ್ತದೆ। ಬಂಧನ ಮಾತ್ರ ಸುರಂಗಕ್ಕೆ ಮಾರ್ಗವಿಲ್ಲದ ಸಂಚಾರವನ್ನು ಸರಿಸುವುದಿಲ್ಲ, ಮತ್ತು «ಬಿಗಿದೆ, ಆದರೂ ತಪ್ಪು ಕಡೆಯಿಂದಲೇ ಹೊರಹೋಗುತ್ತದೆ» ಎಂಬ ಹೆಚ್ಚಿನ ದೂರುಗಳ ಹಿಂದೆ ಈ ತಪ್ಪಿದೆ।
import socket
s = socket.socket()
s.bind(("10.8.0.2", 0))
s.connect(("build.internal.example", 443))ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಪರಿಕರಗಳು ಅದೇ ಕಲ್ಪನೆಯನ್ನು ನೀಡುತ್ತವೆ: curl --interface 10.8.0.2, PHP ನಲ್ಲಿ CURLOPT_INTERFACE, ಮತ್ತು Python ನ HTTP ಕ್ಲೈಂಟ್ಗಳಲ್ಲಿ source_address ಆರ್ಗ್ಯುಮೆಂಟ್। ವಿಳಾಸವು ಸುರಂಗಕ್ಕೇ ಸೇರಿರಬೇಕು, ಮತ್ತು ಇಲ್ಲಿನ ಟೈಪೊ ಮಾರ್ಗನಿರ್ದೇಶನ ದೂರಲ್ಲ, ಸಾಮಾನ್ಯ ಸಂಪರ್ಕ ದೋಷವಾಗಿ ವಿಫಲವಾಗುತ್ತದೆ। ವಿಳಾಸದ ಬದಲು ಸಾಧನದ ಹೆಸರಿಗೆ ಬಿಗಿಯುವುದು Linux ನ ವಿಶೇಷಾಧಿಕಾರ ಮತ್ತು Windows ಅಥವಾ macOS ಗೆ ವರ್ಗಾವಣೆಯಾಗುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸಾಗಿಸಬಲ್ಲ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ವಿಳಾಸವನ್ನು ನೀಡುತ್ತವೆ।
Linux: ಮಾಲೀಕರನ್ನು ಹೊಂದಿಸಿ, ಪ್ರೋಗ್ರಾಂ ಹೆಸರನ್ನಲ್ಲ
ಕರ್ಣಲ್ ಸಾಕೆಟ್ನ ಮಾಲೀಕ ಬಳಕೆದಾರನನ್ನು ಹೊಂದಿಸಬಲ್ಲದು, ಆದ್ದರಿಂದ ಮೀಸಲಾದ ಖಾತೆ ಆಯ್ಕೆಗಾರನಾಗುತ್ತದೆ। ಸುರಂಗವನ್ನು ಅದರದೇ ಮಾರ್ಗ ಕೋಷ್ಟಕದಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಅಲ್ಲಿಗೆ ಆ ಖಾತೆಯ ಸಂಚಾರವನ್ನು ಮಾತ್ರ ಕಳುಹಿಸಿ:
ip rule add uidrange 1001-1001 lookup 100
ip route add default dev tun0 table 100ಇದು ಸುರಂಗ ಈಗಾಗಲೇ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವಾಗಿಲ್ಲದಿದ್ದರೆ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ। ಕ್ಲೈಂಟ್ ಅನ್ನು --route-nopull ನಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಅಥವಾ --pull-filter ignore "redirect-gateway" ನಿಂದ OpenVPN 2.4 ಮತ್ತು ನಂತರದ ಆವೃತ್ತಿಗಳಲ್ಲಿ ತಳ್ಳಲಾದ ಮರುನಿರ್ದೇಶನವನ್ನು ಫಿಲ್ಟರ್ ಮಾಡಿ, ನಂತರ ಕೋಷ್ಟಕ ನಮೂದನ್ನು ನೀವೇ ಸೇರಿಸಿ। ಇಲ್ಲದಿದ್ದರೆ ಎರಡೂ ಡೀಫಾಲ್ಟ್ಗಳು ಇರುತ್ತವೆ ಮತ್ತು ಕಡಿಮೆ ಆದ್ಯತೆಯದು ಗೆಲ್ಲುತ್ತದೆ। ಅದರ ಉದ್ದೇಶಪೂರ್ವಕ ಆವೃತ್ತಿ ಎಂದರೆ ಡೀಫಾಲ್ಟ್ ಮಾರ್ಗವನ್ನು ಸುರಂಗದ ಗೇಟ್ವೇಗೆ ತಿರುಗಿಸುವುದು, ಅಥವಾ ಅದನ್ನು ಸಂಪರ್ಕ ಕಡಿತ ಸ್ಕ್ರಿಪ್ಟ್ನಿಂದ ಮಾಡುವುದು: ಸುರಂಗ ಬಿದ್ದಾಗ ಸಂಚಾರವನ್ನು ಇಂಟರ್ನೆಟ್ನಿಂದ ದೂರ ಇಡುತ್ತದೆ, ಆದರೆ ಅದು ಕಿಲ್ ಸ್ವಿಚ್, ಆಯ್ಕೆಗಾರ ಅಲ್ಲ, ಮತ್ತು ಯಾರಾದರೂ ತೆಗೆಯುವವರೆಗೆ ಉಳಿಯುತ್ತದೆ।
ಬಲವಾದ ಆವೃತ್ತಿ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್। ಅದನ್ನು ರಚಿಸಿ, ಕ್ಲೈಂಟ್ ಅನ್ನು ಒಳಗೆ ಚಲಾಯಿಸಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ip netns exec ನಿಂದ ಪ್ರಾರಂಭಿಸಿ। ನೇಮ್ಸ್ಪೇಸ್ನ ಹೊರಗೆ ಯಾವುದೂ ಸುರಂಗದ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನೋಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್ ಆಕಸ್ಮಿಕವಾಗಿ ಹೋಸ್ಟ್ ಮಾರ್ಗಕ್ಕೆ ಹಿಂತಿರುಗಲಾರದು। ಬೆಲೆ ನಿಜವಾದದ್ದು: ನೇಮ್ಸ್ಪೇಸ್ಗೆ ಭೌತಿಕ ನೆಟ್ವರ್ಕ್ ತಲುಪಲು veth ಜೋಡಿ ಮತ್ತು ತನ್ನದೇ ಪರಿಹಾರಕ ಕಡತ ಬೇಕು, ಏಕೆಂದರೆ ಮೌಂಟ್ ನೇಮ್ಸ್ಪೇಸ್ ಹೋಸ್ಟ್ನ ಪರಿಹಾರ ಸಂಯೋಜನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುವುದಿಲ್ಲ।
ಎರಡು ವೈಫಲ್ಯ ವಿಧಾನಗಳು ಹೆಚ್ಚಿನ ಸೋರಿಕೆಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ। ಹೆಸರು ಪರಿಹಾರ ಇನ್ನೂ ಹೋಸ್ಟ್ನ ಪರಿಹಾರಕದಲ್ಲೇ ನಡೆಯುತ್ತದೆ, ಆದ್ದರಿಂದ TCP ಸಂಪರ್ಕ ಒಳಗೆ ಹೋದರೂ ಪ್ರಶ್ನೆ ಸುರಂಗದ ಹೊರಗೆ ಹೋಗುತ್ತದೆ। ಮತ್ತು IPv6 ಗೆ ತನ್ನದೇ ip -6 rule ಬೇಕು, ಏಕೆಂದರೆ v4 ನಿಯಮ ಅದನ್ನು ಆವರಿಸುವುದಿಲ್ಲ।
Windows ಮತ್ತು macOS: ಫೈರ್ವಾಲ್ ಅನ್ನು ಮಿತಿಗೊಳಿಸಿ ಅಥವಾ ಪ್ರಾಕ್ಸಿ ಒಪ್ಪಿಸಿ
Windows ನಲ್ಲೂ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರತಿ ಮಾರ್ಗ ಆಯ್ಕೆಗಾರ ಇಲ್ಲ, ಆದರೆ ಅದರ ಫೈರ್ವಾಲ್ ನಿಯಮಗಳನ್ನು ಪ್ರೊಫೈಲ್ಗೆ ಮಿತಿಗೊಳಿಸಬಹುದು, ಮತ್ತು VPN ಅಡಾಪ್ಟರ್ ಅನ್ನು «ಸಾರ್ವಜನಿಕ» ಎಂದು ವರ್ಗೀಕರಿಸಬಹುದು, ಮನೆಯ LAN «ಖಾಸಗಿ» ಆಗಿಯೇ ಉಳಿಯುತ್ತದೆ। «ಖಾಸಗಿ» ಮತ್ತು «ಡೊಮೇನ್» ಪ್ರೊಫೈಲ್ಗಳಲ್ಲಿ ಪ್ರೋಗ್ರಾಂಗೆ ಹೊರಹೋಗುವ ಬ್ಲಾಕ್ ನಿಯಮಗಳನ್ನು ರಚಿಸಿ, «ಸಾರ್ವಜನಿಕ» ತೆರೆದಿಡಿ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಸುರಂಗದ ಮೂಲಕವೇ ನೆಟ್ವರ್ಕ್ ತಲುಪುತ್ತದೆ। ಮೊದಲು ಸಂಪರ್ಕದ ನೆಟ್ವರ್ಕ್ ವರ್ಗವನ್ನು ಹೊಂದಿಸಿ, ನಂತರ ಫೈರ್ವಾಲ್ನ ಮೇಲ್ವಿಚಾರಣಾ ಫಲಕದಲ್ಲಿ ನಿಯಮ ಹೊಂದಿಕೆಯಾದುದನ್ನು ದೃಢೀಕರಿಸಿ। ಇದು ಬ್ಲಾಕ್, ಮಾರ್ಗ ಅಲ್ಲ: ಸುರಂಗ ಬಿದ್ದಾಗ ಮುಚ್ಚಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಫೈರ್ವಾಲ್ ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ತಡೆಯಲಾರದು।
macOS ಬೇರೆ ಪರಿಕರಗಳೊಂದಿಗೆ ಅದೇ ತರ್ಕವನ್ನು ಅನುಸರಿಸುತ್ತದೆ। SSH ಮೂಲಕ ತಲುಪುವ SOCKS ಶ್ರೋತೃವೇ ಅತ್ಯಂತ ಕಡಿಮೆ ಹಸ್ತಕ್ಷೇಪದ ಆಯ್ಕೆ, ಏಕೆಂದರೆ ssh -D 1080 user@host ಒಂದು ಸ್ಥಳೀಯ ಪೋರ್ಟ್ ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಬಳಸಲು ಸಂರಚಿಸಿದ ಅಪ್ಲಿಕೇಶನ್ಗಳಷ್ಟೇ ಆ ದಾರಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತವೆ। pf ನಿಯಮವು ಪ್ರೋಗ್ರಾಂ ಅನ್ನು ಬಳಕೆದಾರ ಅಥವಾ ಗುಂಪಿನ ಪ್ರಕಾರ ಬ್ಲಾಕ್ ಮಾಡಬಹುದು, ಆದರೆ ಇನ್ನೂ ಆ ಪ್ರೋಗ್ರಾಂಗೆ ಮಾತ್ರ ಸುರಂಗವನ್ನು ಆರಿಸಲಾರದು। Tunnelblick ಡೊಮೇನ್ ಪ್ರಕಾರ ಫಿಲ್ಟರ್ ಮಾಡಲೇ ಆಗದು, ಏಕೆಂದರೆ ಮಾರ್ಗಗಳು ವಿಳಾಸಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ; OpenConnect ಬಳಕೆದಾರರು ಸರ್ವರ್ ತುಂಬಾ ಅಗಲವಾದ ಪೂರ್ವಪ್ರತ್ಯಯ ಪಟ್ಟಿಯನ್ನು ತಳ್ಳಿದಾಗ vpn-slice ಗೆ ಮೊರೆ ಹೋಗುತ್ತಾರೆ।
ಎರಡು ಪರ್ಯಾಯ ಮಾರ್ಗಗಳು ವೇದಿಕೆಯ ಪರಿಕರಗಳು ತಪ್ಪಿಸಿಕೊಳ್ಳುವುದನ್ನು ಆವರಿಸುತ್ತವೆ। ಡೊಮೇನ್ ಪ್ರಕಾರ ಪ್ರಾಕ್ಸಿ ಬದಲಿಸುವ ಬ್ರೌಸರ್ ವಿಸ್ತರಣೆಗಳು «ಕೇವಲ ಈ ಸೈಟ್» ಗೆ ಪ್ರಾಯೋಗಿಕ ಉತ್ತರ, ಏಕೆಂದರೆ ಅವು ಹೆಸರುಗಳು ಇನ್ನೂ ಇರುವ ಅಪ್ಲಿಕೇಶನ್ ಪದರದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತವೆ; ಅವು ಒಂದು ಬ್ರೌಸರ್ ಅನ್ನು ಆವರಿಸುತ್ತವೆ, ಬೇರೆ ಏನನ್ನೂ ಅಲ್ಲ। ಒರಟು ವಿಧಾನ ಎಂದರೆ ಮಾರಾಟಗಾರರ ಕ್ಲೈಂಟ್ ಅನ್ನು ವರ್ಚುವಲ್ ಯಂತ್ರದಲ್ಲಿ ಚಲಾಯಿಸುವುದು, ಇದರಿಂದ ಅತಿಥಿ ಮಾರ್ಗ ಬದಲಾವಣೆಯ ಮಾಲೀಕನಾಗುತ್ತಾನೆ ಮತ್ತು ಹೋಸ್ಟ್ ತನ್ನ ದಾರಿಯನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಎರಡು ನೆಟ್ವರ್ಕ್ ಸ್ಟಾಕ್ಗಳ ನಿರ್ವಹಣೆಯ ಬೆಲೆಯಲ್ಲಿ।
ಬಿಗಿಯುವ ಆಯ್ಕೆ ಇಲ್ಲದ ಪರಿಕರಗಳಿಗೆ SOCKS ಜಿಗಿತ
ಹೆಚ್ಚಿನ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ಇಂಟರ್ಫೇಸ್ ಬಗ್ಗೆ ಏನೂ ತಿಳಿಯದಿದ್ದರೂ HTTP ಅಥವಾ SOCKS ಪ್ರಾಕ್ಸಿಗೆ ತಿರುಗಿಸಬಹುದು। SSH ಕ್ಲೈಂಟ್ ಸರ್ವರ್ ಕಡೆ ಯಾವುದೇ ಬದಲಾವಣೆಯಿಲ್ಲದೆ ಒಂದನ್ನು ಒದಗಿಸುತ್ತದೆ:
ssh -N -D 127.0.0.1:9999 [email protected]ಆ ಪೋರ್ಟ್ ಬಳಸಲು ಸಂರಚಿಸಿದ ಎಲ್ಲವೂ ಬ್ಯಾಸ್ಟಿಯನ್ನಲ್ಲಿ ಹೊರಹೋಗುತ್ತದೆ, ಡೆಸ್ಕ್ಟಾಪ್ನ ಉಳಿದ ಭಾಗ ತನ್ನ ಸಾಮಾನ್ಯ ಸಂಪರ್ಕವನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ। ಸುರಂಗದ ವಿಳಾಸಕ್ಕೆ ಬದ್ಧವಾದ ಸ್ಥಳೀಯ 3proxy ನಿದರ್ಶನ SSH ಇಲ್ಲದೆ ಒಂದು ಪೋರ್ಟ್ಗೆ ಅದೇ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಮತ್ತು stunnel TLS ನಲ್ಲಿ ಸುತ್ತಿದ ಒಂದೇ ಪೋರ್ಟ್ ಆವರಿಸುತ್ತದೆ। ಮಿತಿಗಳು ಪ್ರಾಯೋಗಿಕ: ಪ್ರಾಕ್ಸಿ ಅದನ್ನು ಬಳಸುವುದು ತಿಳಿದಿರುವ ಪ್ರೋಟೋಕಾಲ್ಗಳನ್ನಷ್ಟೇ ಒಯ್ಯುತ್ತದೆ, UDP ಗೆ SOCKS5 UDP ಸಂಘಟನೆ ಬೇಕು, ಅದನ್ನು ಹಲವು ಕ್ಲೈಂಟ್ಗಳ «SOCKS5» ಸಂಯೋಜನೆ ಸಕ್ರಿಯಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು DNS ಅನ್ನು ಪ್ರಾಕ್ಸಿ ಪರಿಹರಿಸಬೇಕು (curl ನಲ್ಲಿ socks5h), ಇಲ್ಲದಿದ್ದರೆ ಹೆಸರು ಸ್ಥಳೀಯ ಪರಿಹಾರಕಕ್ಕೆ ಸೋರುತ್ತದೆ।
ಬೇರೆ ಯಂತ್ರಕ್ಕೆ ಬೇಕಿಲ್ಲದಿದ್ದರೆ ಶ್ರೋತೃವನ್ನು ಲೂಪ್ಬ್ಯಾಕ್ನಲ್ಲಿ ಇಡಿ।
ಸ್ಥಿತಿ ಸಂದೇಶದಿಂದಲ್ಲ, ಸೆಳೆತದಿಂದ ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸಿ
ಅಪ್ಲಿಕೇಶನ್ ಸ್ಥಿತಿ ಕಿಟಕಿಗಳು ಸಂಯೋಜನೆಯನ್ನು ವಿವರಿಸುತ್ತವೆ, ಪ್ಯಾಕೆಟ್ ಅನ್ನಲ್ಲ। ಎರಡೂ ಇಂಟರ್ಫೇಸ್ಗಳಲ್ಲಿ ಸೆಳೆದು ಹೋಲಿಸಿ:
tcpdump -i any -n port 443
ss -tnp | grep 443ಸಂಪರ್ಕ ಭೌತಿಕ ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಕಾಣಿಸಿ, ಸುರಂಗದಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗುವ ನಮೂದು ಇಲ್ಲದಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ಏನೇ ವರದಿ ಮಾಡಿದರೂ ಆಯ್ಕೆಗಾರ ಜಾರಿಯಲ್ಲಿಲ್ಲ। IPv6 ಮತ್ತು ಪರಿಹಾರಕವನ್ನು ಪ್ರತ್ಯೇಕವಾಗಿ ಪರಿಶೀಲಿಸಿ, ಮತ್ತು ಸಹಾಯಕ ಪ್ರಕ್ರಿಯೆ ಅಥವಾ ಪಾರಂಪರಿಕ ವ್ಯವಸ್ಥೆ ಪ್ರಾಕ್ಸಿಯಂತಹ ಎರಡನೇ ಮಾರ್ಗ ಇದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ।
ನಂತರ ಅಗತ್ಯಕ್ಕೆ ಹೊಂದುವ ಗಡಿಯನ್ನು ಆರಿಸಿ: ಒಂದು ಸೈಟ್ಗೆ ಪ್ರಾಕ್ಸಿ ಸಾಕು, ಒಂದು ಖಾತೆಗೆ UID ನಿಯಮ ಸಾಕು, ಸಂಪರ್ಕ ಮುಚ್ಚಿದ ಸ್ಥಿತಿಯಲ್ಲಿ ವಿಫಲವಾಗಬೇಕಾದಾಗ ಫೈರ್ವಾಲ್ ಪ್ರೊಫೈಲ್ ಸಾಕು, ಮತ್ತು ನೇಮ್ಸ್ಪೇಸ್ ಮಾತ್ರ ಸುರಂಗವನ್ನು ಅದರ ಹೊರಗಿನ ಎಲ್ಲದರಿಂದ ಮರೆಮಾಡುವ ಏಕೈಕ ಆಯ್ಕೆ।