Nabubulag ang debug proxy kapag kumonekta ang corporate VPN

Gumagana ang capture tool buong umaga, kumokonekta ang tunnel, at tumatahimik ito. Idiskonekta at magsisimula itong muli. Ang unang akala ay sinira ng VPN ang proxy, pero wala talagang nagbago sa configuration ng proxy. Ang nagbago ay kung aling configuration ang binabasa ng mga application ngayon: ang tunnel entry ay maaaring may sariling proxy settings, ang managed profile ay maaaring muling buhayin ang automatic configuration, at ang ilang runtime ay bahagi lamang ang binabasa ng ibinibigay ng operating system. Basahin ang halaga ng bawat koneksyon bago hawakan ang global.

Nag-iimbak ang Windows ng proxy bawat koneksyon

Sa mga pagpipilian sa Internet may dalawang layer na magkamukha sa dialog. Ang mga setting ng local network ay para sa karaniwang lokal na koneksyon, habang ang dial-up o VPN entry ay may sariling kopya sa ilalim ng HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, na naka-imbak bilang binary value. Ang pagsulat ng pamilyar na global registry values ay hindi nag-a-update ng kopyang iyon.

Ganito talaga ang kilos ng isang tool nang tama bago kumonekta at mali pagkatapos, nang walang nakikitang pagbabago sa mga setting nito. Ang dialog na tinitigan mo ay ang panel ng local network. Tama ito, at hindi ito mahalaga. Ang entry na talagang ginamit ng Windows ay ang ginawa para sa tunnel.

Ang sinusuportahang paraan para baguhin ang isang entry ay ang WinINET connection option API: punan ang isang INTERNET_PER_CONN_OPTION_LIST ng pangalan ng koneksyon, mga flag, proxy server, at listahan ng bypass, ilapat ito, at pagkatapos ay i-refresh. Para sa mabilis na pagsusuri, buksan ang dialog ng mga setting ng tunnel entry mismo at ihambing ang panel ng proxy nito sa panel ng local network; kadalasang halata ang pagkakaiba kapag alam mo kung saan titingin.

Maaaring muling buhayin ng managed PAC ang sarili nito

Sa macOS, ang automatic proxy configuration script at automatic proxy discovery ay mga katangian ng isang network service, hindi ng makina. Maaaring kailanganin ng configuration profile ang mga ito, kaya muling lumilitaw ang mga ito pagkatapos mong tanggalin ang check, at ang bawat request ay pupunta sa proxy na pinipili ng script.

Suriin at, kung awtorisado ka, patayin ang dalawang switch na iyon para sa serbisyong nagdadala ng trapiko:

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

Gamitin ang tunay na pangalan ng serbisyo sa halip na hulaan. Ang laptop na may Wi-Fi at USB Ethernet adapter ay may dalawa, at isa lamang ang nagdadala ng iyong trapiko. scutil --proxy ay nagpi-print ng mga halaga para sa kasalukuyang pangunahing serbisyo. Ihambing ang output na iyon sa iyong na-edit bago magpasya na nanalo ang profile.

Itutok ang tool sa tunay na upstream

Kung ang script ay naglalaman ng corporate proxy, basahin ito at ilagay ang parehong address bilang external proxy sa loob ng capture tool. Pagkatapos ay ipapasa ng tool sa tunay na upstream, na siyang inaasahan ng corporate proxy, at nananatili ito sa landas ng request sa halip na lumaban sa patakaran.

Iyon ang galaw na nagpapanatili sa iyo sa pag-debug kaysa sa muling pagkumpigura.

Itulak ang proxy sa loob ng tunnel

Ang client na nakabase sa OpenVPN ay maaaring tumanggap ng mga pagpipilian sa proxy na nalalapat kapag nakaangat na ang tunnel, na maginhawa kapag pag-aari ng client ang mga ruta:

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

Tanging ang mga client na gumagalang sa pagpipilian ang gagamit nito, at ito ay nagha-hardcode ng iyong listening port sa isang profile. Ituring itong kaginhawahan sa laboratory at hindi pamantayan sa deployment, dahil aalisin ito ng susunod na pagpapadala ng profile.

May mga client na hindi kailanman nagbabasa ng system proxy

Ang Firefox ay may sariling proxy settings, kaya kung minsan ay nagpapatuloy itong kumuha kapag ang browser na gumagamit ng system proxy ay hindi na. Ang lumang .NET client na hindi nauunawaan ang automatic configuration ay direktang kumokonekta saanman ito tumakbo, kaya ang pahinang na-load sa pamamagitan ng tunnel entry ay maaari pa ring mabigo sa loob ng application.

May sariling mga dahilan din ang mga network tool. Ang FTP session na nakabitin sa tunnel o tethering ng telepono ay kadalasang problema sa active laban sa passive mode na pinag-uusapan ng client, at walang setting ng proxy ang magbabago nito.

Basahin ang configuration, hindi ang toggle

Magtrabaho sa ganitong pagkakasunod-sunod: ang sariling halaga ng proxy ng tunnel entry, ang estado ng PAC at automatic discovery bawat serbisyo, at pagkatapos ang sariling paghawak ng proxy ng application. Huminto sa unang naiiba sa iyong palagay.

Ang bawat kaso dito ay problema sa precedence ng configuration. Wala sa mga ito ang tunnel na sumisira sa iyong tool.