Felsökningsproxyn blir blind när företagets VPN ansluter

Inspelningsverktyget fungerar hela förmiddagen, tunneln kopplar upp och det blir tyst. Koppla ner och det startar igen. Den första tanken är att VPN:en förstörde proxyn, men i proxykonfigurationen har ingenting ändrats. Det som ändrats är vilken konfiguration programmen nu läser: en tunnelpost kan bära egna proxyinställningar, en hanterad profil kan slå på automatisk konfiguration igen, och vissa körmiljöer läser bara en del av det operativsystemet erbjuder. Läs värdet per anslutning innan du rör det globala.

Windows håller en proxy per anslutning

I internetalternativen finns två lager som ser identiska ut i dialogrutan. Inställningarna för det lokala nätverket gäller den vanliga lokala anslutningen, medan en uppringnings- eller VPN-post håller sin egen kopia under HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections, lagrad som ett binärt värde. Att skriva de välkända globala registervärdena uppdaterar inte den kopian.

Precis så beter sig ett verktyg korrekt före anslutning och felaktigt efter, utan någon synlig ändring i inställningarna. Dialogrutan du stirrade på var panelen för det lokala nätverket. Den var korrekt, och den var irrelevant. Posten som Windows faktiskt använde var den som skapades för tunneln.

Det stödda sättet att ändra en post är WinINET-API:et för anslutningsalternativ: fyll i en INTERNET_PER_CONN_OPTION_LIST med anslutningens namn, flaggorna, proxyservern och en undantagslista, tillämpa den och uppdatera sedan. För en snabb kontroll kan du öppna inställningsdialogrutan för själva tunnelposten och jämföra dess proxypanel med panelen för det lokala nätverket; skillnaden är oftast tydlig när man vet var man ska titta.

En hanterad PAC kan slå på sig själv igen

I macOS är skriptet för automatisk proxykonfiguration och den automatiska proxyidentifieringen egenskaper hos en nätverkstjänst, inte hos maskinen. En konfigurationsprofil kan kräva dem, så de dyker upp igen när du tar bort bocken, och varje begäran går då till den proxy som skriptet väljer.

Undersök och slå, om du har behörighet, av de två reglagen för tjänsten som bär trafiken:

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

Använd tjänstens riktiga namn i stället för en gissning. En bärbar dator med både trådlöst nät och en USB-Ethernet-adapter har två sådana, och bara en bär din trafik. scutil --proxy skriver ut värdena för den aktuella primära tjänsten. Jämför den utskriften med det du redigerade innan du drar slutsatsen att profilen vann.

Rikta verktyget mot den verkliga uppströmslänken

Om skriptet innehåller företagsproxyn, läs det och ange samma adress som extern proxy inuti inspelningsverktyget. Då vidarebefordrar verktyget till den verkliga uppströmslänken, vilket företagsproxyn förväntar sig, och det stannar kvar i begärans väg i stället för att slåss mot policyn.

Det är draget som håller dig kvar i felsökningen i stället för i omkonfigureringen.

Tryck in proxyn i tunneln

En klient baserad på OpenVPN kan acceptera proxyalternativ som gäller när tunneln är uppe, vilket är praktiskt när klienten äger rutterna:

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

Bara klienter som respekterar alternativet använder det, och det hårdkodar din lyssnarport i en profil. Behandla det som en laboratoriebekvämlighet och inte som en distributionsstandard, eftersom nästa profilutskick tar bort det.

Vissa klienter läser aldrig systemproxyn

Firefox håller egna proxyinställningar, vilket är varför det ibland fortsätter spela in när en webbläsare med systemproxy inte gör det. En äldre .NET-klient som inte förstår automatisk konfiguration ansluter direkt var den än körs, så en sida som laddas via tunnelposten kan fortfarande misslyckas inne i programmet.

Nätverksverktyg har också sina egna orsaker. En FTP-session som hänger sig över en tunnel eller telefon-tethering är ofta ett problem med aktiv kontra passivt läge som klienten förhandlar om, och ingen proxyinställning ändrar det.

Läs konfigurationen, inte reglaget

Arbeta i den här ordningen: tunnelpostens eget proxyvärde, PAC- och autodetekteringsstatus per tjänst, sedan programmets egen proxyhantering. Stanna vid den första som avviker från det du antog.

Varje fall här är ett problem med konfigurationsprioritet. Ingen av dem är tunneln som förstör ditt verktyg.