કોર્પોરેટ VPN કનેક્ટ થાય ત્યારે ડિબગ પ્રોક્સી આંધળું થઈ જાય છે

કૅપ્ચર ટૂલ આખી સવાર કામ કરે છે, ટનલ જોડાય છે, અને પછી તે શાંત થઈ જાય છે. ડિસ્કનેક્ટ કરો અને તે ફરી શરૂ થાય છે. પહેલો વિચાર એ આવે છે કે VPN એ પ્રોક્સી તોડી નાખી, પણ પ્રોક્સી કન્ફિગરેશનમાં ખરેખર કંઈ બદલાયું નથી. જે બદલાયું છે તે એ છે કે એપ્લિકેશનો હવે કયું કન્ફિગરેશન વાંચે છે: ટનલ એન્ટ્રી પોતાની પ્રોક્સી સેટિંગ્સ ધરાવી શકે છે, મેનેજ્ડ પ્રોફાઇલ ઑટોમેટિક કન્ફિગરેશન ફરી ચાલુ કરી શકે છે, અને કેટલાક રનટાઇમ ઑપરેટિંગ સિસ્ટમ જે આપે છે તેનો ફક્ત એક ભાગ વાંચે છે. ગ્લોબલ મૂલ્યને સ્પર્શ કરતાં પહેલાં પ્રતિ-કનેક્શન મૂલ્ય વાંચો.

Windows દરેક કનેક્શન માટે અલગ પ્રોક્સી રાખે છે

ઇન્ટરનેટ વિકલ્પોમાં બે સ્તર છે જે સંવાદમાં એકસમાન દેખાય છે. લોકલ નેટવર્ક સેટિંગ્સ સામાન્ય લોકલ કનેક્શનને લાગુ પડે છે, જ્યારે ડાયલ-અપ કે VPN એન્ટ્રી HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections હેઠળ પોતાની નકલ બાઇનરી મૂલ્ય તરીકે રાખે છે. જાણીતા ગ્લોબલ રજિસ્ટ્રી મૂલ્યો લખવાથી એ નકલ અપડેટ થતી નથી.

ટૂલ કનેક્ટ થતાં પહેલાં સાચી અને પછી ખોટી રીતે વર્તે છે તે બરાબર આ રીતે, અને તેની સેટિંગ્સમાં ક્યાંય દૃશ્યમાન ફેરફાર થતો નથી. તમે જે સંવાદ સામે તાકી રહ્યા હતા તે લોકલ નેટવર્ક પેનલ હતું. તે સાચું હતું, અને તે અપ્રસ્તુત હતું. Windows ખરેખર જે એન્ટ્રી વાપરતું હતું તે ટનલ માટે બનાવેલી એન્ટ્રી હતી.

એક એન્ટ્રી બદલવાની સમર્થિત રીત WinINET કનેક્શન ઑપ્શન API છે: કનેક્શનનું નામ, ફ્લેગ, પ્રોક્સી સર્વર અને બાયપાસ યાદી સાથે INTERNET_PER_CONN_OPTION_LIST ભરો, લાગુ કરો, પછી તાજું કરો. ઝડપી તપાસ માટે ટનલ એન્ટ્રીનું પોતાનું સેટિંગ્સ સંવાદ ખોલો અને તેની પ્રોક્સી પેનલની લોકલ નેટવર્ક પેનલ સાથે સરખામણી કરો; ક્યાં જોવું તે ખબર પડે એટલે તફાવત સામાન્ય રીતે સ્પષ્ટ હોય છે.

મેનેજ્ડ PAC પોતે ફરી ચાલુ થઈ શકે છે

macOS પર ઑટોમેટિક પ્રોક્સી કન્ફિગરેશન સ્ક્રિપ્ટ અને પ્રોક્સી ઑટો-ડિસ્કવરી નેટવર્ક સેવાના ગુણધર્મો છે, મશીનના નહીં. કન્ફિગરેશન પ્રોફાઇલ તેમને ફરજિયાત કરી શકે છે, તેથી ટિક કાઢ્યા પછી પણ તે ફરી દેખાય છે, અને પછી દરેક વિનંતી સ્ક્રિપ્ટ જે પ્રોક્સી પસંદ કરે તેને મોકલાય છે.

તપાસો અને, અધિકૃત હોવ તો, ટ્રાફિક વહન કરતી સેવા માટે એ બે સ્વિચ બંધ કરો:

networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy

અનુમાનને બદલે સેવાનું ખરું નામ વાપરો. Wi-Fi અને USB ઇથરનેટ એડેપ્ટર બંને ધરાવતા લેપટોપમાં એવી બે હોય છે, અને તમારો ટ્રાફિક ફક્ત એક જ વહન કરે છે. scutil --proxy વર્તમાન પ્રાથમિક સેવાનાં મૂલ્યો છાપે છે. પ્રોફાઇલ જીત્યું છે એવા નિષ્કર્ષ પર આવતાં પહેલાં એ આઉટપુટને તમે સંપાદિત કરેલા મૂલ્ય સાથે સરખાવો.

ટૂલને ખરા અપસ્ટ્રીમ તરફ દોરો

જો સ્ક્રિપ્ટમાં કોર્પોરેટ પ્રોક્સી હોય, તો તેને વાંચો અને એ જ સરનામું કૅપ્ચર ટૂલની અંદર બાહ્ય પ્રોક્સી તરીકે દાખલ કરો. પછી ટૂલ ખરા અપસ્ટ્રીમ તરફ ફોરવર્ડ કરે છે, જે કોર્પોરેટ પ્રોક્સી અપેક્ષા રાખે છે, અને નીતિ સાથે લડવાને બદલે વિનંતીના માર્ગમાં જ રહે છે.

આ જ એ પગલું છે જે તમને ફરી ગોઠવવાને બદલે ડિબગિંગમાં રાખે છે.

પ્રોક્સીને ટનલની અંદર ધકેલો

OpenVPN-આધારિત ક્લાયન્ટ ટનલ ઊભી થયા પછી લાગુ પડતા પ્રોક્સી વિકલ્પો સ્વીકારી શકે છે, જે ત્યારે અનુકૂળ છે જ્યારે રૂટ ક્લાયન્ટ પાસે હોય:

dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888

ફક્ત જે ક્લાયન્ટ આ વિકલ્પનું સન્માન કરે છે તે જ તેનો ઉપયોગ કરશે, અને તે તમારો સાંભળવાનો પોર્ટ પ્રોફાઇલમાં કાયમી રીતે લખી નાખે છે. તેને લેબ સુવિધા ગણો, ડિપ્લોયમેન્ટ ધોરણ નહીં, કારણ કે આગલું પ્રોફાઇલ પુશ તેને દૂર કરી દેશે.

કેટલાક ક્લાયન્ટ સિસ્ટમ પ્રોક્સી ક્યારેય વાંચતા નથી

Firefox પોતાની પ્રોક્સી સેટિંગ્સ રાખે છે, તેથી ક્યારેક સિસ્ટમ પ્રોક્સી વાપરતું બ્રાઉઝર ન કરે ત્યારે પણ તે કૅપ્ચર ચાલુ રાખે છે. ઑટોમેટિક કન્ફિગરેશન ન સમજતો જૂનો .NET ક્લાયન્ટ જ્યાં પણ ચાલે ત્યાં સીધો જોડાય છે, તેથી ટનલ એન્ટ્રી દ્વારા લોડ થતું પૃષ્ઠ એપ્લિકેશનની અંદર હજી પણ નિષ્ફળ થઈ શકે છે.

નેટવર્ક ટૂલ્સનાં પણ પોતાનાં કારણો હોય છે. ટનલ કે ફોન ટેથરિંગ પર અટકી પડતું FTP સત્ર ઘણી વાર ક્લાયન્ટ દ્વારા વાટાઘાટ થતી સક્રિય વિરુદ્ધ નિષ્ક્રિય મોડની સમસ્યા હોય છે, અને કોઈ પ્રોક્સી સેટિંગ તેને બદલશે નહીં.

કન્ફિગરેશન વાંચો, ટૉગલ નહીં

આ ક્રમમાં કામ કરો: ટનલ એન્ટ્રીનું પોતાનું પ્રોક્સી મૂલ્ય, પ્રતિ-સેવા PAC અને ઑટો-ડિસ્કવરી સ્થિતિ, પછી એપ્લિકેશનની પોતાની પ્રોક્સી હેન્ડલિંગ. તમારી ધારણાથી અલગ પડતા પહેલા તેના પર અટકો.

અહીંનો દરેક કિસ્સો કન્ફિગરેશન અગ્રતાની સમસ્યા છે. એક પણ ટનલ તમારું ટૂલ તોડતું નથી.