Debug-proxy verloor sig wanneer die korporatiewe VPN verbind
Niks in jou proxy het verander nie. Die tonnelinskrywing dra sy eie instellings, ’n bestuurde PAC kan terugkeer, en sommige kliënte lees nooit die stelselproxy nie.
Die opnamprogram werk die hele oggend, die tonnel skakel in, en dit raak stil. Ontkoppel en dit begin weer. Die instink is dat die VPN die proxy gebreek het, maar niks in die proxy-konfigurasie het werklik verander nie. Wat verander het, is watter konfigurasie die toepassings nou lees: ’n tonnelinskrywing kan sy eie proxy-instellings dra, ’n bestuurde profiel kan outomatiese konfigurasie weer aanskakel, en sommige looptye lees net ’n deel van wat die bedryfstelsel bied. Lees die waarde per verbinding voordat jy die globale een aanraak.
Windows hou ’n proxy per verbinding
Internet-opsies het twee lae wat in die dialoog identies lyk. Die LAN-instellings geld vir die gewone plaaslike verbinding, terwyl ’n inbel- of VPN-inskrywing sy eie kopie onder HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections hou, as ’n binêre waarde gestoor. Om die bekende globale registerwaardes te skryf, werk daardie kopie nie op nie.
Dit is presies hoe ’n program korrek werk voor die verbinding en verkeerd daarna, sonder enige sigbare verandering in sy instellings. Die dialoog waarna jy gestaar het, was die LAN-paneel. Dit was korrek, en dit was irrelevant. Die inskrywing wat Windows werklik gebruik het, was die een wat vir die tonnel geskep is.
Die ondersteunde manier om een inskrywing te verander, is die WinINET-verbindingsopsie-API: vul ’n INTERNET_PER_CONN_OPTION_LIST met die verbindingsnaam, die vlae, die proxyserver en ’n omseillys, pas dit toe en verfris dan. Vir ’n vinnige kontrole, maak die tonnelinskrywing se eie instellingsdialoog oop en vergelyk sy proxypaneel met die LAN-paneel; die verskil is gewoonlik duidelik sodra jy weet waarna om te kyk.
’n Bestuurde PAC kan homself weer aanskakel
Op macOS is die outomatiese proxy-konfigurasieskrip en proxy-outo-ontdekking eienskappe van ’n netwerkdiens, nie van die masjien nie. ’n Konfigurasieprofiel kan dit vereis, so hulle verskyn weer nadat jy dit afgemerk het, en elke versoek word dan na die proxy gestuur wat die skrip kies.
Ondersoek en, as jy gemagtig is, skakel daardie twee skakelaars af vir die diens wat die verkeer dra:
networksetup -setautoproxystate "Wi-Fi" off
networksetup -setproxyautodiscovery "Wi-Fi" off
scutil --proxy
Gebruik die werklike diensnaam eerder as ’n raaiskoot. ’n Skootrekenaar met beide Wi-Fi en ’n USB-Ethernet-adapter het twee daarvan, en net een dra jou verkeer. scutil --proxy druk die waardes vir die huidige primêre diens. Vergelyk daardie uitvoer met wat jy geredigeer het voordat jy tot die gevolgtrekking kom dat die profiel gewen het.
Rig die program op die werklike upstream
As die skrip die korporatiewe proxy bevat, lees dit en voer dieselfde adres as ’n eksterne proxy in die opnamprogram in. Die program stuur dan aan na die werklike upstream, wat die korporatiewe proxy verwag, en dit bly in die versoekpad in plaas daarvan om die beleid te beveg.
Dit is die skuif wat jou aan die ontfout hou eerder as om te herkonfigureer.
Stoot die proxy in die tonnel in
’n Kliënt wat op OpenVPN gebaseer is, kan proxy-opsies aanvaar wat geld sodra die tonnel op is, wat gerieflik is wanneer die kliënt die roetes besit:
dhcp-option HTTPPROXY 127.0.0.1:8888
dhcp-option HTTPSPROXY 127.0.0.1:8888
Net kliënte wat die opsie eerbiedig, sal dit gebruik, en dit hardkodeer jou luisterpoort in ’n profiel. Behandel dit as ’n laboratoriumgerief eerder as ’n ontplooiingstandaard, want die volgende profielstoot sal dit verwyder.
Sommige kliënte lees nooit die stelselproxy nie
Firefox hou sy eie proxy-instellings, daarom hou dit soms aan opneem wanneer ’n blaaier met stelselproxy dit nie doen nie. ’n Ouer .NET-kliënt wat nie outomatiese konfigurasie verstaan nie, verbind direk waar dit ook al loop, so ’n bladsy wat deur die tonnelinskrywing laai, kan steeds binne die toepassing misluk.
Netwerkprogramme het ook hul eie oorsake. ’n FTP-sessie wat oor ’n tonnel of ’n selfoon-tether hang, is dikwels ’n aktief-teenoor-passief-modusprobleem wat deur die kliënt beding word, en geen proxy-instelling sal dit verander nie.
Lees die konfigurasie, nie die skakelaar nie
Werk in hierdie volgorde: die tonnelinskrywing se eie proxywaarde, die PAC- en outo-ontdekkingstoestand per diens, dan die toepassing se eie proxyhantering. Stop by die eerste een wat verskil van wat jy aangeneem het.
Elke geval hier is ’n probleem van konfigurasie-voorrang. Nie een is die tonnel wat jou program breek nie.