HTTP ಪ್ರಾಕ್ಸಿ ಮೂಲಕ OpenVPN: ಮೊದಲು CONNECT ಉತ್ತರವನ್ನು ಓದಿ
CONNECT ಪ್ರಾಕ್ಸಿ ಬೈಟ್ಗಳನ್ನು ರವಾನಿಸುತ್ತದೆ, ಹಾಗಾಗಿ ಎರಡೂ ತುದಿಗಳಿಗೆ TCP ಬೇಕು. ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ದೂಷಿಸುವ ಮೊದಲು 407, 403 ಮತ್ತು 503 ಓದಿ, ಮತ್ತು ಸರ್ವರ್ ಪರಿಶೀಲನೆಯನ್ನು ಆನ್ ಆಗಿಡಿ.
VPN ಕ್ಲೈಂಟ್ ಅನ್ನು ಸಾಂಸ್ಥಿಕ HTTP ಪ್ರಾಕ್ಸಿಗೆ ತಿರುಗಿಸಿ, ಮತ್ತು ಮೊದಲ ಉಪಯುಕ್ತ ಸತ್ಯವೆಂದರೆ ಪ್ರಾಕ್ಸಿ VPN ನ ಪ್ರೋಟೋಕಾಲ್ ಆಡುವುದಿಲ್ಲ. ಅದು ನೀವು ಹೇಳಿದ ವಿಳಾಸಕ್ಕೆ ಸಾಮಾನ್ಯ TCP ಸಂಪರ್ಕವನ್ನು ತೆರೆದು ನಂತರ ಪಕ್ಕಕ್ಕೆ ಸರಿಯುತ್ತದೆ, ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಮತ್ತು ಸರ್ವರ್ ಆ ಸ್ಟ್ರೀಮ್ ಮೂಲಕ ತಮ್ಮದೇ ವಿನಿಮಯವನ್ನು ನಡೆಸುತ್ತವೆ. ಕ್ಲೈಂಟ್ಗೆ ಬೇಕಾದ ಎಲ್ಲವೂ, ಸಾರಿಗೆ ಪ್ರಕಾರದಿಂದ ಸರ್ವರ್ನ ಶ್ರೋತೃವಿನವರೆಗೆ, ಆ ವ್ಯವಸ್ಥೆಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು. ಎರಡು ಹೊಂದಾಣಿಕೆಗಳ ಕೊರತೆ ಹೆಚ್ಚಿನ ವೈಫಲ್ಯಗಳನ್ನು ವಿವರಿಸುತ್ತವೆ: CONNECT ಪ್ರಾಕ್ಸಿಗೆ ಗುರಿಯಾದ UDP ಪ್ರೊಫೈಲ್, ಮತ್ತು VPN ದೋಷ ಎಂದು ತಪ್ಪಾಗಿ ತಿಳಿದ ಪ್ರಾಕ್ಸಿ ಉತ್ತರ.
ಪ್ರಾಕ್ಸಿ ಏನು ಸಾಗಿಸುತ್ತದೆ ಮತ್ತು ಏನು ಸಾಗಿಸುವುದಿಲ್ಲ
ಪ್ರಾಕ್ಸಿ ಕೇವಲ ಒಂದು ಸಾರಿಗೆ ಹಂತ. ಅದು ನಿಮ್ಮ ಬ್ರೌಸರ್ ಪ್ರಾಕ್ಸಿ ಆಗುವುದಿಲ್ಲ, ಸುರಂಗದ ಮೂಲಕ ನೀವು ಭೇಟಿ ನೀಡುವ ಸೈಟ್ಗಳನ್ನು ಕ್ಯಾಶ್ ಮಾಡುವುದಿಲ್ಲ, ಮತ್ತು ಯಾರಾದರೂ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಪರಿಶೀಲನೆ ಹೊಂದಿಸದಿದ್ದರೆ ಒಳಗಿನ ಸಂಚಾರವನ್ನು ನೋಡುವುದಿಲ್ಲ. ಅದು ತೆರೆಯುವ ಸುರಂಗ ವಿನ್ಯಾಸದಿಂದಲೇ ಅದಕ್ಕೆ ಅಪಾರದರ್ಶಕವಾಗಿದೆ.
ಇದರ ಅರ್ಥ ಪ್ರಾಕ್ಸಿ ಹೊಂದಿಕೆಯಾದ ಶ್ರೋತೃ ಇಲ್ಲದ ಸರ್ವರ್ ಅನ್ನು ಸರಿಪಡಿಸಲಾಗದು. ಗಮ್ಯಸ್ಥಾನವನ್ನು ತಲುಪುವ ಅನುಮತಿ ಮತ್ತು ಆ ಗಮ್ಯಸ್ಥಾನದಲ್ಲಿ ಕೇಳುವ ಸೇವೆ ಎರಡು ಬೇರೆ ಸತ್ಯಗಳು, ಮತ್ತು ಮೊದಲನೆಯದು ಮಾತ್ರ ಪ್ರಾಕ್ಸಿ ನಿರ್ವಾಹಕರದು.
ವಾಹಕ ಎರಡೂ ತುದಿಗಳಲ್ಲಿ TCP ಆಗಿರಬೇಕು
ಸಾಂಪ್ರದಾಯಿಕ CONNECT ಪ್ರಾಕ್ಸಿ ಕೇವಲ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ರವಾನಿಸುತ್ತದೆ , ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಸ್ಟ್ರೀಮ್ ಸಾರಿಗೆಯನ್ನು ಬಳಸಬೇಕು. ಆ ಸಂದರ್ಭದ ಕ್ಲೈಂಟ್ ತುಣುಕು ಹೀಗೆ ಕಾಣುತ್ತದೆ:
proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128ಸರ್ವರ್ ಬದಿಗೆ remote ಸಾಲಿನಲ್ಲಿ ಹೇಳಿದ ಪೋರ್ಟ್ನಲ್ಲಿ ನಿಜವಾದ TCP ಶ್ರೋತೃ ಬೇಕು. ಪ್ರೊಫೈಲ್ನಲ್ಲಿ proto udp ಅನ್ನು proto tcp-client ಗೆ ಬದಲಿಸುವುದು ಸ್ಟ್ರೀಮ್ ನಿರೀಕ್ಷಿಸುವ ಕ್ಲೈಂಟ್ ಮಾಡುತ್ತದೆ; ಅದು ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಸ್ಟ್ರೀಮ್ ಮಾಡುವುದಿಲ್ಲ. ಅದೇ ಸರ್ವರ್ ಆ ಪೋರ್ಟ್ನಲ್ಲಿ UDP ಮೂಲಕವೂ ಉತ್ತರಿಸಿದರೆ, ಅದು ಬೇರೆ ಶ್ರೋತೃ, ಅದೇ ಶ್ರೋತೃದ ಎರಡನೇ ಮೋಡ್ ಅಲ್ಲ.
ಪ್ರತ್ಯೇಕ TCP ಉದಾಹರಣೆ ಇರುವಲ್ಲಿ, ಅದರ ಸುರಂಗ ಸಾಧನ, ವಿಳಾಸ ಪೂಲ್ ಮತ್ತು ರೂಟಿಂಗ್ ಸ್ವಂತ ಸಂಪನ್ಮೂಲಗಳು. ಕೆಲಸ ಮಾಡುವ ಸಂರಚನೆಯನ್ನು ನಕಲಿಸಿ ಸಾರಿಗೆ ಪದವನ್ನು ಬದಲಿಸಿದರೆ ಆ ಸಂಪನ್ಮೂಲಗಳು ಮೂಲ ಉದಾಹರಣೆಯನ್ನೇ ತೋರಿಸುತ್ತವೆ, ಇದು ದೃಢೀಕರಣ ಮಾಡಿ ನಂತರ ಏನನ್ನೂ ರೂಟ್ ಮಾಡದ ಸಂಪರ್ಕವನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ.
VPN ಫಲಿತಾಂಶಕ್ಕಿಂತ ಮೊದಲು ಪ್ರಾಕ್ಸಿ ಉತ್ತರವನ್ನು ಓದಿ
ಕ್ಲೈಂಟ್ನ ಮೊದಲ ವಿನಿಮಯ ಗಮ್ಯಸ್ಥಾನದ ಹೋಸ್ಟ್ ಮತ್ತು ಪೋರ್ಟ್ ಹೆಸರಿಸುವ ವಿನಂತಿ ಸಾಲು. ಆ ಸಾಲಿನ ಉತ್ತರ ಬೈಟ್ ಸ್ಟ್ರೀಮ್ ಇದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ, ಮತ್ತು ಯಾವುದೇ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ರುಜುವಾತು ಪರಿಶೀಲನೆಗೆ ಮೊದಲೇ ಬರುತ್ತದೆ:
CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194| Proxy reply | What it means | Where to look next |
|---|---|---|
407 Proxy Authentication Required | The proxy wants its own credentials | The client's proxy auth options, not the VPN account |
403 Forbidden | The destination or method is not permitted | The proxy's access policy for that host and port |
503 Service Unavailable | The proxy could not complete the upstream connection | The proxy's own logs and the server's listener |
CONNECT ಗೆ 200 ವರ್ಗದ ಉತ್ತರ ಎಂದರೆ ಸ್ಟ್ರೀಮ್ ಇದೆ. ಗೇಟ್ವೇ ಪ್ರಮಾಣಪತ್ರ ವಿಶ್ವಾಸಾರ್ಹವೇ, ಹಂಚಿದ ಕೀಲಿ ಹೊಂದುತ್ತದೆಯೇ, ಅಥವಾ ಬಳಕೆದಾರ ಖಾತೆ ಮಾನ್ಯವೇ ಎಂಬುದನ್ನು ಅದು ಹೇಳುವುದಿಲ್ಲ. ಆ ಪರಿಶೀಲನೆಗಳು ನಂತರ, ಸ್ಟ್ರೀಮ್ ಒಳಗೆ ನಡೆಯುತ್ತವೆ, ಮತ್ತು ಅವು HTTP ಸ್ಥಿತಿ ಸಾಲಿನ ಬದಲು ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಸಂದೇಶಗಳಿಂದ ವಿಫಲವಾಗುತ್ತವೆ. ಕ್ಲೈಂಟ್ ಲಾಗ್ನಲ್ಲಿ ಮೊದಲ OpenVPN ಘಟನೆಯನ್ನು ಪ್ರಾಕ್ಸಿ ಹ್ಯಾಂಡ್ಶೇಕ್ ನಂತರ ನೋಡಿ, ಕಿಟಕಿ ಮುಚ್ಚುವ ಮೊದಲಿನ ಕೊನೆಯ ಸಾಲನ್ನು ಅಲ್ಲ.
ಪ್ರಾಕ್ಸಿ ರುಜುವಾತುಗಳು ಮತ್ತು VPN ರುಜುವಾತುಗಳು ಹೆಚ್ಚಾಗಿ ಬೇರೆ ಬೇರೆ ತಂಡಗಳಲ್ಲಿರುವ ಬೇರೆ ಬೇರೆ ಗುರುತುಗಳು. 407 VPN ಖಾತೆಯ ಕೆಟ್ಟ ಪಾಸ್ವರ್ಡ್ ಅಲ್ಲ, ಮತ್ತು ತಿರಸ್ಕರಿಸಿದ ಪ್ರಮಾಣಪತ್ರ ಪ್ರಾಕ್ಸಿ ಅನುಮತಿ ಸಮಸ್ಯೆ ಅಲ್ಲ.
CONNECT ಏನನ್ನು ಬಹಿರಂಗಪಡಿಸುವುದಿಲ್ಲ
ಸ್ಪಷ್ಟ CONNECT ಸುರಂಗ ಪ್ರತಿಬಂಧವಲ್ಲ. ಪ್ರಾಕ್ಸಿ ಬೈಟ್ಗಳನ್ನು ಮುಂದೆ ಕಳುಹಿಸುತ್ತದೆ ಮತ್ತು VPN ನ TLS ಸೆಷನ್ ಅನ್ನು ಕೊನೆಗೊಳಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರದ ಕ್ಲೈಂಟ್ ಪರಿಶೀಲನೆ ಅರ್ಥಪೂರ್ಣವಾಗಿ ಉಳಿಯುತ್ತದೆ ಮತ್ತು ಆನ್ ಆಗಿರಬೇಕು. ಪ್ರಾಕ್ಸಿ ದಾಟಲು ಪರಿಶೀಲನೆ ನಿಲ್ಲಿಸುವುದು ನಿಮ್ಮ ಸಮಸ್ಯೆಗಿಂತ ಬೇರೆ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ.
ಸಂಸ್ಥೆ ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ TLS ಕೊನೆಗೊಳಿಸಿ ಪರಿಶೀಲಿಸುವ ಪ್ರತ್ಯೇಕ ವ್ಯವಸ್ಥೆಗಳೂ ಇವೆ. ಅವು ತಮ್ಮದೇ ವಿಶ್ವಾಸ ಸಂರಚನೆ ಮತ್ತು ತಮ್ಮದೇ ನೀತಿ ನಿರ್ಣಯ ಬೇಕಾಗುತ್ತವೆ, ಮತ್ತು ಸಾಮಾನ್ಯ http-proxy ಸಾಲು ಕೇಳುವುದು ಅವು ಅಲ್ಲ.
TCP ಒಳಗಿನ TCP ಯ ವೆಚ್ಚ
ಸುರಂಗವನ್ನು TCP ಮೇಲೆ ಸಾಗಿಸುವುದು ಹೊರ ಸ್ಟ್ರೀಮ್ ಅನ್ನು ಕ್ರಮಬದ್ಧವಾಗಿ ಮತ್ತು ಮರುಕಳುಹಿಸುವಿಕೆಯೊಂದಿಗೆ ಇಡುತ್ತದೆ, ಮತ್ತು ಒಳಗಿನ ಸಂಚಾರವೂ ಸಾಮಾನ್ಯವಾಗಿ TCP. ಎರಡು ಚೇತರಿಕೆ ಕ್ರಮಗಳು ಸಂಯೋಜಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಒಂದು ಕಳೆದುಹೋದ ವಿಭಾಗವು ಆ ಹೊರ ಸ್ಟ್ರೀಮ್ ಹಂಚಿಕೊಳ್ಳುವ ಎಲ್ಲವನ್ನೂ ಮರುಕಳುಹಿಸುವವರೆಗೆ ನಿಲ್ಲಿಸಬಹುದು. ಇದು ಹೊಂದಾಣಿಕೆಗಾಗಿ ನಿಜವಾದ ವಿನಿಮಯ, ಉಚಿತ ಅಪ್ಗ್ರೇಡ್ ಅಲ್ಲ.
ಜಾಲಬಂಧ ಪರ್ಯಾಯ ಬಿಡದಿದ್ದಾಗ ಪ್ರಾಕ್ಸಿ ಮಾರ್ಗ ಬಳಸಿ, ಮತ್ತು ನೀತಿ ಅನುಮತಿಸುವಲ್ಲಿ ನೇರ UDP ಮಾರ್ಗವನ್ನು ಆದ್ಯತೆ ಮಾಡಿ. ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ಬದಲಾವಣೆಯ ನಂತರ ಅದೇ ಪ್ರಾಕ್ಸಿ, ಗಮ್ಯಸ್ಥಾನ ಮತ್ತು ಪ್ರೊಫೈಲ್ ಮುಂದಿನ ಹಂತ ತಲುಪುತ್ತವೆ ಎಂದು ಖಚಿತಪಡಿಸಿ; ಆ ವಿಳಾಸದಲ್ಲಿ ಪುಟ ಲೋಡ್ ಮಾಡುವ ಬ್ರೌಸರ್ ಬೇರೆ ಪ್ರೋಟೋಕಾಲ್ ಬಳಸುತ್ತದೆ ಮತ್ತು ಸುರಂಗದ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ.