VPN werkt, maar één app heeft geen internet? Controleer de proxy ervan

Je tunnel staat, de statuspagina toont een gezonde handshake, maar één applicatie laadt nog steeds niets. Die applicatie stuurt zijn verzoeken waarschijnlijk nog naar een oudere tussenlaag: een systeemproxy, een extensie, een configuratiebestand dat door apparaatbeheer wordt geduwd, of een proxyvariabele die alleen zijn eigen proces leest. Een andere VPN-server verandert niets aan die instelling, en dat verklaart het patroon waarbij andere apps vanaf dezelfde machine werken. Werk van de falende app naar buiten toe en laat de tunnel met rust tot de proxyvraag is beslecht.

Welke laag bezit de proxyinstelling

Vier plekken kunnen gezag over de verzoeken van een app claimen, en de smalste wint meestal. Het besturingssysteem heeft een globale proxy en een optionele automatische configuratie-URL; een browser kan die volgen, overschrijven of de controle aan een extensie geven; een opdrachtregelprogramma leest zijn eigen omgeving; en een beheerd beleid kan na een wijziging alles hierboven weer vastzetten. Bepaal welke laag verantwoordelijk is voordat je iets bewerkt, want de verkeerde laag wissen lijkt op een geslaagde reparatie die bij de volgende aanmelding terugkomt.

Vergelijk twee applicaties tegen dezelfde gewone website in plaats van tegen een testpagina die alleen voor VPN is. Als de browser faalt terwijl een download in de terminal slaagt, is het besturingssysteem niet het probleem, en zit het verschil in het browserprofiel of de extensies ervan. Als beide falen maar een tweede gebruikersaccount op dezelfde machine slaagt, is de instelling per gebruiker. Die vergelijking kost een minuut en haalt het meeste giswerk weg.

Lees de waarde die elk hulpmiddel werkelijk gebruikt

Druk de configuratie af voordat je die wijzigt, en kopieer de exacte proxystring naar een plek waar je die kunt herstellen. De shellvariabelen zijn de snelste controle voor opdrachtregelprogramma's, omdat een VPN-client ze normaal ongemoeid laat.

env | grep -i -E 'http_proxy|https_proxy|all_proxy|no_proxy'
scutil --proxy
gsettings get org.gnome.system.proxy mode
netsh winhttp show proxy

Voer alleen de regel uit die bij het platform voor je past, en lees daarna de uitvoer voor host, poort en inloggegevens. Een waarde als http://proxy.corp.example:8080 betekent dat het hulpmiddel die host voor elk verzoek vraagt, terwijl een leeg resultaat betekent dat het rechtstreeks gaat en de echte fout elders zit. Verberg het gebruikers- en wachtwoorddeel voordat je de uitvoer in een ticket plakt, want die strings zijn veel vaker levende inloggegevens dan mensen aannemen.

Hulpmiddelen met hun eigen proxymotor hebben hun eigen bewijs nodig. Curl meldt de beslissing die het nam wanneer je de uitvoerigheid verhoogt, wat beter is dan gissen uit de omgeving, en dezelfde vlag laat zien of naamresolutie lokaal of bij de proxy gebeurde.

Wis de overschrijving en test hetzelfde verzoek opnieuw

Wijzig één laag en herhaal dan precies het verzoek dat faalde, want een andere URL bewijst niets. Wis eerst de omgevingsvariabelen in de huidige shell, omdat die wijziging omkeerbaar is en de tunnel niet kan breken:

unset http_proxy https_proxy all_proxy
curl -v --max-time 10 https://example.com 2>&1 | grep -i -E 'uses proxy|connected to|http/'

Als de uitgebreide uitvoer nog steeds een proxy claimt, was de omgeving niet het gezag. Ga een niveau omhoog in plaats van meer overschrijvingen te stapelen.

Controleer op macOS of een automatisch configuratiebestand de waarde niet levert, schakel dan de serviceproxy uit en bevestig de wijziging. Onthoud op Windows dat de WinHTTP-instelling en de browserinstelling per gebruiker verschillende objecten zijn, zodat een schoon opdrachtregelprogramma kan samengaan met een browser die nog naar een oude server wijst. Extensies verdienen hetzelfde wantrouwen: een proxy-extensie kan verzoeken alleen voor één profiel herschrijven, en dat is precies de vorm van een fout die één browser raakt en niets anders.

Controleer of de reparatie een herstart overleeft

Een instelling die alleen werkt in de terminal die je hebt bewerkt, is niet gerepareerd. Open de applicatie opnieuw via de bureaubladstarter, meld je af en weer aan, en kijk of de oude proxy terugkomt.

Twee controles scheiden een echte reparatie van een tijdelijke, en beide zouden een directe verbinding of de bedoelde waarde moeten melden. De uitvoering in een schone omgeving laat zien of een gestript proces nog een systeeminstelling oppikt.

env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"

Als de oude waarde na een herstart terugkomt, is de bron een beheerd beleid of een profiel dat die opnieuw toepast, en de eigenaar van dat beleid moet de uitzondering verwijderen. Laat certificaatverificatie de hele tijd aan staan, omdat een proxy die verkeer onderschept anders opgelost lijkt zodra je de controles uitzet. Sluit af door de verwijderde waarde en de datum in je notities te schrijven, zodat de volgende persoon een bewuste proxy van een vergeten proxy kan onderscheiden.