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 અને એપની પોતાની નેટવર્ક સેટિંગ્સ જુઓ. તે ત્રીજું સ્તર છે, અને તે પણ પ્રોક્સી ક્ષેત્ર નથી.