De debug-proxy wordt blind zodra de bedrijfs-VPN verbindt

De opnametool werkt de hele ochtend, de tunnel belt in, en hij wordt stil. Verbreek de verbinding en hij begint weer. De eerste gedachte is dat de VPN de proxy heeft gesloopt, maar aan de proxyconfiguratie is niets veranderd. Wat veranderd is, is welke configuratie de applicaties nu lezen: een tunnelvermelding kan eigen proxyinstellingen dragen, een beheerd profiel kan automatische configuratie weer inschakelen, en sommige runtime-omgevingen lezen maar een deel van wat het besturingssysteem biedt. Lees de waarde per verbinding voordat je de globale aanraakt.

Windows houdt een proxy per verbinding bij

In de internetopties zijn er twee lagen die er in het dialoogvenster hetzelfde uitzien. De instellingen van het lokale netwerk gelden voor de gewone lokale verbinding, terwijl een inbel- of VPN-vermelding zijn eigen kopie onder HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections bewaart, opgeslagen als binaire waarde. De bekende globale registerwaarden schrijven werkt die kopie niet bij.

Precies zo gedraagt een tool zich correct vóór het verbinden en onjuist erna, zonder enige zichtbare verandering in zijn instellingen. Het dialoogvenster waar je naar staarde was het paneel van het lokale netwerk. Het was correct, en het was irrelevant. De vermelding die Windows werkelijk gebruikte was degene die voor de tunnel was aangemaakt.

De ondersteunde manier om één vermelding te wijzigen is de WinINET-API voor verbindingsopties: vul een INTERNET_PER_CONN_OPTION_LIST met de verbindingsnaam, de vlaggen, de proxyserver en een uitsluitingslijst, pas hem toe en vernieuw daarna. Voor een snelle controle open je het instellingenvenster van de tunnelvermelding zelf en vergelijk je het proxypaneel met dat van het lokale netwerk; het verschil is meestal duidelijk zodra je weet waar je moet kijken.

Een beheerd PAC kan zichzelf weer inschakelen

Op macOS zijn het automatische proxyconfiguratiescript en automatische proxy-detectie eigenschappen van een netwerkdienst, niet van de machine. Een configuratieprofiel kan ze vereisen, dus ze komen terug nadat je het vinkje weghaalt, en elk verzoek gaat dan naar de proxy die het script kiest.

Controleer en, als je bevoegd bent, schakel die twee schakelaars uit voor de dienst die het verkeer draagt:

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

Gebruik de echte dienstnaam in plaats van een gok. Een laptop met zowel wifi als een USB-Ethernet-adapter heeft er twee, en slechts één draagt jouw verkeer. scutil --proxy drukt de waarden af voor de huidige primaire dienst. Vergelijk die uitvoer met wat je hebt bewerkt voordat je concludeert dat het profiel heeft gewonnen.

Richt de tool op de echte upstream

Als het script de bedrijfsproxy bevat, lees het dan en voer hetzelfde adres in als externe proxy binnen de opnametool. Dan stuurt de tool door naar de echte upstream, wat de bedrijfsproxy verwacht, en blijft hij in het pad van het verzoek in plaats van tegen het beleid te vechten.

Dat is de zet die je aan het debuggen houdt in plaats van aan het herconfigureren.

Duw de proxy de tunnel in

Een client op basis van OpenVPN kan proxyopties accepteren die gelden zodra de tunnel staat, wat handig is wanneer de client de routes bezit:

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

Alleen clients die de optie respecteren gebruiken hem, en hij schrijft je luisterpoort hard in een profiel. Behandel het als laboratoriumgemak en niet als uitrolstandaard, want de volgende profielpush haalt hem weg.

Sommige clients lezen de systeemproxy nooit

Firefox houdt zijn eigen proxyinstellingen bij, daarom gaat hij soms door met opnemen wanneer een browser met systeemproxy dat niet doet. Een oudere .NET-client die automatische configuratie niet begrijpt, verbindt rechtstreeks waar hij ook draait, dus een pagina die via de tunnelvermelding laadt kan binnen de applicatie alsnog mislukken.

Netwerktools hebben ook hun eigen oorzaken. Een FTP-sessie die via een tunnel of telefoon-tethering blijft hangen is vaak een probleem met actieve versus passieve modus dat de client onderhandelt, en geen proxyinstelling verandert dat.

Lees de configuratie, niet de schakelaar

Werk in deze volgorde: de eigen proxywaarde van de tunnelvermelding, de PAC- en automatische detectiestatus per dienst, en dan de eigen proxyafhandeling van de applicatie. Stop bij de eerste die afwijkt van wat je aannam.

Elk geval hier is een probleem met configuratieprioriteit. Geen ervan is de tunnel die je tool sloopt.