Debug-proxyen blir blind når bedrifts-VPN-en kobler til

Opptaksverktøyet virker hele formiddagen, tunnelen kobler til, og det blir stille. Koble fra og det starter igjen. Den første tanken er at VPN-en ødela proxyen, men i proxykonfigurasjonen er det faktisk ikke endret noe. Det som er endret, er hvilken konfigurasjon programmene nå leser: en tunneloppføring kan bære egne proxyinnstillinger, en administrert profil kan slå på automatisk konfigurasjon igjen, og noen kjøretidsmiljøer leser bare en del av det operativsystemet tilbyr. Les verdien per tilkobling før du rører den globale.

Windows holder en proxy per tilkobling

I Internett-alternativer er det to lag som ser like ut i dialogen. Innstillingene for lokalnettet gjelder den vanlige lokale tilkoblingen, mens en oppringings- eller VPN-oppføring holder sin egen kopi under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, lagret som en binær verdi. Å skrive de kjente globale registerverdiene oppdaterer ikke den kopien.

Det er nøyaktig slik et verktøy oppfører seg riktig før tilkobling og galt etterpå, uten noen synlig endring i innstillingene. Dialogen du stirret på, var lokalnettpanelet. Det var riktig, og det var irrelevant. Oppføringen Windows faktisk brukte, var den som ble opprettet for tunnelen.

Den støttede måten å endre én oppføring på er WinINET-API-et for tilkoblingsvalg: fyll ut en INTERNET_PER_CONN_OPTION_LIST med tilkoblingsnavnet, flaggene, proxyserveren og en unntaksliste, bruk den og oppdater deretter. For en rask kontroll kan du åpne innstillingsdialogen til selve tunneloppføringen og sammenligne proxypanelet med lokalnettpanelet; forskjellen er som regel tydelig når man vet hvor man skal se.

En administrert PAC kan slå seg på igjen

På macOS er skriptet for automatisk proxykonfigurasjon og automatisk proxyoppdagelse egenskaper ved en nettverkstjeneste, ikke ved maskinen. En konfigurasjonsprofil kan kreve dem, så de dukker opp igjen etter at du fjerner haket, og hver forespørsel sendes da til den proxyen skriptet velger.

Undersøk, og slå om nødvendig av de to bryterne for tjenesten som bærer trafikken, hvis du er autorisert:

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

Bruk det ekte tjenestenavnet i stedet for en gjetning. En bærbar maskin med både trådløst nett og en USB-Ethernet-adapter har to slike, og bare én bærer trafikken din. scutil --proxy skriver ut verdiene for den gjeldende primærtjenesten. Sammenlign den utskriften med det du redigerte før du konkluderer med at profilen vant.

Rett verktøyet mot den ekte oppstrømsen

Hvis skriptet inneholder bedriftsproxyen, les det og legg inn samme adresse som ekstern proxy inne i opptaksverktøyet. Da videresender verktøyet til den ekte oppstrømsen, som er det bedriftsproxyen forventer, og det blir i forespørselsbanen i stedet for å kjempe mot policyen.

Det er trekket som holder deg i feilsøking i stedet for omkonfigurering.

Skyv proxyen inn i tunnelen

En klient basert på OpenVPN kan godta proxyvalg som gjelder når tunnelen er oppe, noe som er praktisk når klienten eier rutene:

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

Bare klienter som respekterer valget vil bruke det, og det hardkoder lyttingen din port inn i en profil. Behandle det som en laboratoriebekvemmelighet og ikke en distribusjonsstandard, for neste profilutsendelse fjerner det.

Noen klienter leser aldri systemproxyen

Firefox holder egne proxyinnstillinger, og derfor fortsetter den noen ganger å ta opp når en nettleser med systemproxy ikke gjør det. En eldre .NET-klient som ikke forstår automatisk konfigurasjon kobler direkte til uansett hvor den kjører, så en side som lastes gjennom tunneloppføringen kan fortsatt feile inne i programmet.

Nettverksverktøy har også sine egne årsaker. En FTP-økt som henger over en tunnel eller telefon-tethering er ofte et problem med aktiv kontra passiv modus som klienten forhandler om, og ingen proxyinnstilling endrer det.

Les konfigurasjonen, ikke bryteren

Arbeid i denne rekkefølgen: tunneloppføringens egen proxyverdi, PAC- og autooppdagelsesstatus per tjeneste, deretter programmets egen proxyhåndtering. Stopp ved den første som avviker fra det du antok.

Hvert tilfelle her er et problem med konfigurasjonsprioritet. Ingen av dem er tunnelen som ødelegger verktøyet ditt.