Apple VPN சுயவிவரத்தில் Proxy புலம் உண்மையில் என்ன செய்கிறது
ப்ராக்ஸி புலத்தை நிரப்புவது VPN-ஐ HTTP ஆக்காது. இதில் இரண்டு இணைப்புகள் ஈடுபடுகின்றன, புலம் அவற்றில் ஒன்றை மட்டுமே அடைகிறது.
Apple VPN உள்ளமைவில் Proxy புலத்தை நிரப்பும்போது அது சுரங்கப்பாதையை ஒரு வலைத் துறை வழியாகத் திருப்பிவிடும் என்று தோன்றுகிறது. ஆனால் அது செய்யாது. பொருத்தமான செயலி அங்கு அனுப்ப முடிவெடுக்கும் போக்குவரத்துக்கு, புலம் பயன்பாட்டு மட்டத்திலான இடைத்தரகரைத் தேர்ந்தெடுக்கிறது. ஆனால் VPN வாடிக்கையாளரின் சொந்த கேட்வே இணைப்பை நீங்கள் உள்ளமைத்த நெறிமுறை, கேட்பான் மற்றும் போக்குவரத்து தீர்மானிக்கின்றன, அவை தனித்தனி முடிவுகள்.
இரண்டு இணைப்புகள், இரண்டு உரிமையாளர்கள்
இத்தகைய எந்த அமைப்பிலும் வாடிக்கையாளரிலிருந்து கேட்வே வரை ஒரு இணைப்பும், செயலியிலிருந்து இலக்கு வரை மற்றொரு இணைப்பும் இருக்கும். Proxy பிரிவு இரண்டாவதைப் பற்றிப் பேசுகிறது, அது முதலில் உள்ள அதே சுயவிவரத்தில் இருந்தாலும்.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The 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 மற்றும் செயலியின் சொந்த நெட்வொர்க் அமைப்புகளைப் பாருங்கள். அது மூன்றாவது அடுக்கு, அதுவும் ப்ராக்ஸி புலம் அல்ல.