Debug-proxyen bliver blind, når virksomhedens VPN kobler på

Optagelsesværktøjet virker hele formiddagen, tunnelen kobler på, og det bliver stille. Afbryd, og det starter igen. Den første tanke er, at VPN’en ødelagde proxyen, men der er ikke ændret noget i proxykonfigurationen. Det, der er ændret, er hvilken konfiguration programmerne nu læser: en tunnelpost kan bære sine egne proxyindstillinger, en administreret profil kan genaktivere automatisk konfiguration, og nogle runtime-miljøer læser kun en del af det, styresystemet tilbyder. Læs værdien pr. forbindelse, før du rører den globale.

Windows holder en proxy pr. forbindelse

I Internetindstillinger er der to lag, som ser identiske ud i dialogen. LAN-indstillingerne gælder for den almindelige lokale forbindelse, mens en opkalds- eller VPN-post holder sin egen kopi under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, gemt som en binær værdi. At skrive de velkendte globale registreringsværdier opdaterer ikke den kopi.

Det er præcis sådan et værktøj opfører sig korrekt før forbindelsen og forkert bagefter, uden nogen synlig ændring i dets indstillinger. Den dialog, du stirrede på, var LAN-panelet. Det var korrekt, og det var irrelevant. Den post, Windows faktisk brugte, var den, der blev oprettet til tunnelen.

Den understøttede måde at ændre én post på er WinINET-API’et for forbindelsesvalg: udfyld en INTERNET_PER_CONN_OPTION_LIST med forbindelsesnavnet, flagene, proxyserveren og en undtagelsesliste, anvend den, og opdater derefter. Til et hurtigt tjek kan du åbne tunnelpostens egen indstillingsdialog og sammenligne dens proxypanel med LAN-panelet; forskellen er som regel tydelig, når man ved, hvor man skal kigge.

En administreret PAC kan tænde sig selv igen

På macOS er scriptet til automatisk proxykonfiguration og automatisk proxyregistrering egenskaber ved en netværkstjeneste, ikke ved maskinen. En konfigurationsprofil kan kræve dem, så de dukker op igen, når du fjerner fluebenet, og hver forespørgsel sendes derefter til den proxy, scriptet vælger.

Undersøg, og slå om nødvendigt de to kontakter fra for den tjeneste, der bærer trafikken, hvis du er autoriseret:

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

Brug det rigtige tjenestenavn i stedet for et gæt. En bærbar med både Wi-Fi og en USB-Ethernet-adapter har to af dem, og kun én bærer din trafik. scutil --proxy udskriver værdierne for den aktuelle primære tjeneste. Sammenlign det output med det, du redigerede, før du konkluderer, at profilen vandt.

Ret værktøjet mod det rigtige upstream

Hvis scriptet indeholder virksomhedsproxien, så læs det og indtast samme adresse som ekstern proxy inde i optagelsesværktøjet. Så videresender værktøjet til det rigtige upstream, som virksomhedsproxien forventer, og det bliver i forespørgselsstien i stedet for at kæmpe mod politikken.

Det er det træk, der holder dig i fejlfinding i stedet for omkonfiguration.

Skub proxyen ind i tunnelen

En klient baseret på OpenVPN kan acceptere proxyindstillinger, der gælder, når tunnelen er oppe, hvilket er bekvemt, når klienten ejer ruterne:

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

Kun klienter, der respekterer indstillingen, bruger den, og den hårdkoder din lytteport i en profil. Behandl det som en laboratoriebekvemmelighed og ikke en udrulningsstandard, for den næste profiludsendelse fjerner den.

Nogle klienter læser aldrig systemproxyen

Firefox holder sine egne proxyindstillinger, og derfor fortsætter den nogle gange med at optage, når en browser med systemproxy ikke gør. En ældre .NET-klient, der ikke forstår automatisk konfiguration, forbinder direkte, uanset hvor den kører, så en side, der indlæses via tunnelposten, kan stadig fejle inde i programmet.

Netværksværktøjer har også deres egne årsager. En FTP-session, der hænger over en tunnel eller telefon-tethering, er ofte et problem med aktiv kontra passiv tilstand, som klienten forhandler, og ingen proxyindstilling ændrer det.

Læs konfigurationen, ikke kontakten

Arbejd i denne rækkefølge: tunnelpostens egen proxyværdi, PAC- og auto-registreringstilstanden pr. tjeneste, derefter programmets egen proxyhåndtering. Stop ved den første, der afviger fra det, du antog.

Hvert tilfælde her er et problem med konfigurationsprioritet. Ingen af dem er tunnelen, der ødelægger dit værktøj.