Apple VPN ಸಂರಚನೆಯಲ್ಲಿ Proxy ಕ್ಷೇತ್ರವನ್ನು ಭರ್ತಿ ಮಾಡುವುದು ಟನೆಲ್ ಅನ್ನು ವೆಬ್ ಪೋರ್ಟ್ ಮೂಲಕ ಮರುನಿರ್ದೇಶಿಸುತ್ತದೆ ಎನಿಸುತ್ತದೆ. ಹಾಗೆ ಮಾಡುವುದಿಲ್ಲ. ಕ್ಷೇತ್ರವು ಹೊಂದಿಕೊಳ್ಳುವ ಅಪ್ಲಿಕೇಶನ್ ಅಲ್ಲಿಗೆ ಕಳುಹಿಸಲು ಆಯ್ಕೆ ಮಾಡುವ ಸಂಚಾರಕ್ಕಾಗಿ ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ಮಧ್ಯವರ್ತಿಯನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಆದರೆ VPN ಕ್ಲೈಂಟ್ನ ಸ್ವಂತ ಸಂಪರ್ಕವನ್ನು ಅದರ ಗೇಟ್ವೇಗೆ ನೀವು ಸಂರಚಿಸಿದ ಪ್ರೋಟೋಕಾಲ್, ಲಿಸನರ್ ಮತ್ತು ಸಾರಿಗೆ ನಿರ್ಧರಿಸುತ್ತವೆ, ಮತ್ತು ಇವು ಪ್ರತ್ಯೇಕ ನಿರ್ಧಾರಗಳು.

ಎರಡು ಸಂಪರ್ಕಗಳು, ಎರಡು ಮಾಲೀಕರು

ಇಂತಹ ಯಾವುದೇ ಸಂರಚನೆಯಲ್ಲಿ ಕ್ಲೈಂಟ್ನಿಂದ ಗೇಟ್ವೇಗೆ ಸಂಪರ್ಕ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನಿಂದ ಗಮ್ಯಸ್ಥಾನಕ್ಕೆ ಸಂಪರ್ಕ ಇರುತ್ತದೆ. Proxy ವಿಭಾಗವು ಎರಡನೆಯದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತದೆ, ಅದು ಮೊದಲನೆಯದರ ಅದೇ ಪ್ರೊಫೈಲ್ನಲ್ಲಿದ್ದರೂ.

ConnectionWhat decides its behaviour
VPN client to VPN gatewayThe supported protocol, the listening port, the transport and the network policy in between
Application to a selected proxyThe application's own proxy support, the configured proxy policy, and the route to that next hop

Apple ನ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ಗಳ ಉಲ್ಲೇಖ HTTP, HTTPS, SOCKS ಮತ್ತು ಸ್ವಯಂಚಾಲಿತ ಪ್ರಾಕ್ಸಿ ಸಂರಚನೆಯನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಇದು ಅಪ್ಲಿಕೇಶನ್ಗಳ ಪ್ರಾಕ್ಸಿ ಆಯ್ಕೆಗಳ ವಿವರಣೆ. ಆ ನಮೂದುಗಳಲ್ಲಿ ಯಾವುದೂ IPsec ಅಥವಾ WireGuard ಪ್ಯಾಕೆಟ್ ಗೇಟ್ವೇಗೆ ಹೇಗೆ ತಲುಪುತ್ತದೆ ಎಂದು ಹೇಳುವುದಿಲ್ಲ.

ವಿಷಯವನ್ನು ಇತ್ಯರ್ಥ ಮಾಡುವ ತ್ವರಿತ ಪರಿಶೀಲನೆ ಇಲ್ಲಿದೆ. VPN ಕ್ಲೈಂಟ್ ತನ್ನ ಲಾಗ್ನಲ್ಲಿ ವರದಿ ಮಾಡುವ ಪೋರ್ಟ್ ಮತ್ತು ಪ್ರೋಟೋಕಾಲ್ ಅನ್ನು ಹೇಳಿ. ಆ ಸಾಲು ಇನ್ನೂ UDP 500 ಅಥವಾ UDP 51820 ಎಂದು ಹೇಳಿದರೆ, ಪ್ರಾಕ್ಸಿ ಕ್ಷೇತ್ರವು ಅದರಲ್ಲಿ ಏನನ್ನೂ ಬದಲಿಸಿಲ್ಲ.

ಕ್ಷೇತ್ರವು ಯಾವಾಗ ಸರಿಯಾದ ಸಾಧನ

ಪ್ರಾಕ್ಸಿ ಟನೆಲ್ನ ಮುಂದೆ ನಿಲ್ಲುವ ನಿಜವಾದ ಸಂದರ್ಭವಿದೆ, ಆದರೆ ಅದು ಪ್ರೊಫೈಲ್ ಕ್ಷೇತ್ರವಲ್ಲ, ಕ್ಲೈಂಟ್ನ ವೈಶಿಷ್ಟ್ಯ. OpenVPN ನ ಕೈಪಿಡಿ HTTP CONNECT ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಸಾಗಿಸುವ TCP ಸಂಪರ್ಕಗಳಿಗೆ --http-proxy ಅನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ಅದನ್ನು ಬಳಸಲು ಹೊಂದಿಕೆಯಾಗುವ ಕ್ಲೈಂಟ್ ಆಯ್ಕೆ, ಆ ಮಾರ್ಗದಲ್ಲಿ ತಲುಪಬಹುದಾದ ಗೇಟ್ವೇ ಮತ್ತು ಬಳಕೆಯಲ್ಲಿರುವ ಪೋರ್ಟ್ಗೆ CONNECT ಅನ್ನು ಅನುಮತಿಸುವ ಪ್ರಾಕ್ಸಿ ಬೇಕು.

ನಿಮ್ಮ ಕ್ಲೈಂಟ್ ಆ ಆಯ್ಕೆಯನ್ನು ಒದಗಿಸಿದರೆ ಮತ್ತು ನೆಟ್ವರ್ಕ್ ಪೋರ್ಟ್ಗೆ CONNECT ಅನ್ನು ಅನುಮತಿಸಿದರೆ, ಅದು ಕೆಲಸ ಮಾಡಬಹುದು. ಕ್ಲೈಂಟ್ ಅದನ್ನು ಒದಗಿಸದಿದ್ದರೆ, ಸಿಸ್ಟಂ ಪ್ರಾಕ್ಸಿ ಭರ್ತಿ ಮಾಡುವುದು ಟನೆಲ್ ಮೇಲೆ ಯಾವುದೇ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.

ಯಾವಾಗ ಏನನ್ನೂ ಬದಲಿಸುವುದಿಲ್ಲ

ಪ್ರಾಕ್ಸಿ ಕ್ಷೇತ್ರ ತುಂಬಿರುವ ಕಾರಣ IKEv2 ಅಥವಾ IPsec ಪ್ರೊಫೈಲ್ HTTP ಟನೆಲ್ ಆಗುವುದಿಲ್ಲ. WireGuard ಕೂಡ ಅಲ್ಲ, ಅದರ ಸಂರಚನಾ ಸ್ವರೂಪದಲ್ಲಿ ಪ್ರಾಕ್ಸಿ ಪರಿಕಲ್ಪನೆ ಇಲ್ಲ. ಗೇಟ್ವೇ ಪೋರ್ಟ್ ಬದಲಿಸಿದರೆ ಅದರ ಪ್ರೋಟೋಕಾಲ್ ಕೂಡ ಬದಲಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಸಾಮಾನ್ಯ HTTPS ಗೆ ಉತ್ತರಿಸುವ ಎಂಡ್ಪಾಯಿಂಟ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ VPN ಲಿಸನರ್ ಅಲ್ಲ.

ಅದೇ ಬಲೆ ಹಳೆಯ iPad ಮಾರ್ಗದರ್ಶಿಗಳಿಂದ PPTP ಯುಗದ ಪ್ರೊಫೈಲ್ಗಳನ್ನು ನಕಲಿಸುವವರನ್ನು ಹಿಡಿಯುತ್ತದೆ. ಆಯ್ಕೆಗಳು ಇಂಟರ್ಫೇಸ್ನಲ್ಲಿ ಇನ್ನೂ ಇವೆ; ಅವುಗಳ ಹಿಂದಿನ ಸೇವೆ ಈಗ ಆ ಪ್ರೋಟೋಕಾಲ್ ಮಾತನಾಡುವುದಿಲ್ಲ.

ಯಾವ ಪದರವನ್ನು ಸರಿಪಡಿಸಬೇಕು ಎಂದು ನಿರ್ಧರಿಸುವುದು

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

ಮೊದಲ ಸಂದರ್ಭಕ್ಕೆ, ಯಾವ ಅನುಮೋದಿತ ಪರ್ಯಾಯ ಸಾರಿಗೆ ಅಥವಾ ನೆಟ್ವರ್ಕ್ ಬೆಂಬಲಿಸುತ್ತದೆ ಎಂದು ನಿರ್ವಾಹಕರನ್ನು ಕೇಳಿ. TCP 443 ಮೇಲಿನ OpenVPN ಇರುವುದು ಕೆಲವು ನೆಟ್ವರ್ಕ್ಗಳು ಅದನ್ನಷ್ಟೇ ಅನುಮತಿಸುವುದರಿಂದ, ಮತ್ತು ಅದು ಇನ್ನೂ ಸರ್ವರ್ ಅದನ್ನು ಆಲಿಸುವುದನ್ನು ಅಗತ್ಯವಾಗಿಸುತ್ತದೆ.

ನಿರ್ಬಂಧಿಸಲಾದ UDP ಪೋರ್ಟ್ ಅನ್ನು ತಾತ್ಕಾಲಿಕ ಉಪಾಯದ ಅನುಮತಿ ಎಂದು ಪರಿಗಣಿಸಬೇಡಿ. ಹ್ಯಾಂಡ್ಶೇಕ್ ಹೊಂದಿಸಲು ಗೇಟ್ವೇಯ ಪ್ರಮಾಣಪತ್ರ ಅಥವಾ ಗುರುತಿನ ಪರಿಶೀಲನೆಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವ ಬದಲು ಅವುಗಳನ್ನು ಅಕ್ಷತವಾಗಿ ಇರಿಸಿ.

ಎರಡೂ ಪದರಗಳನ್ನು ಒಂದೊಂದಾಗಿ ಪರಿಶೀಲಿಸಿ

ಮೊದಲು ಟನೆಲ್ ದೃಢೀಕರಿಸಿ: ಕ್ಲೈಂಟ್ನ ಸ್ಥಿತಿ ಪುಟದಲ್ಲಿ ಸ್ಥಾಪಿತ ಸೆಷನ್ ಮತ್ತು ಶೂನ್ಯವಲ್ಲದ ಬೈಟ್ ಎಣಿಕೆಯನ್ನು ನೋಡಿ. ನಂತರ ಪ್ರಾಕ್ಸಿ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನೇರವಾಗಿ ಓದಿ, ಪರಿಣಾಮಕಾರಿ ಸಂರಚನೆಗೆ scutil --proxy ಅಥವಾ ಸಂಗ್ರಹಿತ ಮೌಲ್ಯಕ್ಕೆ networksetup -getwebproxy Wi-Fi ಬಳಸಿ. ನಂತರ ಸಿಸ್ಟಂ ಪ್ರಾಕ್ಸಿಯನ್ನು ಗೌರವಿಸುವ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುವ ಇನ್ನೊಂದನ್ನು ಪರೀಕ್ಷಿಸಿ, ಏಕೆಂದರೆ ಅನೇಕ ಸ್ಥಳೀಯ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಅದನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತವೆ.

ಮೂರು ಫಲಿತಾಂಶಗಳು, ಮೂರು ವಿಭಿನ್ನ ಸರಿಪಡಿಸುವಿಕೆಗಳು.

ಎರಡೂ ಪದರಗಳು ಯಶಸ್ಸನ್ನು ವರದಿ ಮಾಡಿದರೂ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲವಾಗುತ್ತಿದ್ದರೆ, ಸ್ಪ್ಲಿಟ್ ಟನೆಲಿಂಗ್, DNS ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ನೆಟ್ವರ್ಕ್ ಸೆಟ್ಟಿಂಗ್ಗಳನ್ನು ನೋಡಿ. ಅದು ಮೂರನೇ ಪದರ, ಮತ್ತು ಅದೂ ಪ್ರಾಕ್ಸಿ ಕ್ಷೇತ್ರವಲ್ಲ.

ಸಂಬಂಧಿತ ಲೇಖನಗಳು