VPN wurket, mar ien app hat gjin ynternet? Besjoch syn proxy

Jo tunnel is oprjochte, de statusside toant in sûne handshake, mar ien applikaasje laded noch hieltyd neat. Dy applikaasje stjoert syn oanfragen wierskynlik noch nei in âldere tuskenpersoan: in systeemproxy, in taheaksel, in konfiguraasjebestân dat troch apparaatbehear ta stjoerd wurdt, of in proxyfariabele dy’t allinnich syn eigen proses lêst. It feroarjen fan VPN-server rekket dy ynstelling net oan, en dat ferklearret it patroan wêrby’t oare apps fan deselde masine ôf wurkje. Wurket fan de mislearjende app nei bûten ta, en lit de tunnel gewurde oant de proxykwestje beslein is.

Hokker laach besit de proxyynstelling

Fjouwer plakken kinne gesach oer de oanfragen fan in app opeaskje, en meastentiids wint de smelste. It bestjoeringssysteem hâldt in globale proxy en in opsjonele automatyske konfiguraasje-URL; in browser kin dy folgje, oerskriuwe of de kontrôle oan in taheaksel jaan; in kommandorigelhelp kin syn eigen omjouwing lêze; en in beheard belied kin nei in feroaring alles hjirboppe wer fêstsette. Beskiede hokker laach ferantwurdlik is foardat jo wat bewurkje, want it fuortheljen fan de ferkearde laach liket op in suksesfolle reparaasje dy’t by de folgjende oanmelding weromkomt.

Ferlykje twa applikaasjes tsjin deselde gewoane webside yn stee fan tsjin in testside dy’t allinnich foar VPN is. As de browser mislearret wylst in download yn de terminal slagget, is it bestjoeringssysteem net it probleem, en it ferskil sit yn it browserprofyl of syn taheaksels. As beide mislearje mar in twadde brûkersaccount op deselde masine slagget, is de ynstelling per brûker. Dy ferliking kostet in minút en nimt it measte rieden fuort.

Lês de wearde dy’t elk helpmiddel eins brûkt

Print de konfiguraasje foardat jo dy feroarje, en kopiearje de krekte proxystring nei in plak dêr’t jo dy weromfine kinne. De shellfariabelen binne de fluchste kontrôle foar kommandorigelhelpmiddels, want in VPN-klant lit se normaal gewurde.

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

Rin allinnich de rigel dy’t by it platform foar jo past, en lês dan de útjefte foar host, poarte en tagongsbewizen. In wearde lykas http://proxy.corp.example:8080 betsjut dat it helpmiddel foar elk fersyk dy host freget, wylst in leech resultaat betsjut dat it direkt giet en de echte fout earne oars sit. Ferbergje it brûkers- en wachtwurdpart foardat jo de útjefte yn in ticket plakke, want dy strings binne folle faker libbene tagongsbewizen as minsken tinke.

Helpmiddels mei in eigen proxymotor hawwe eigen bewiis nedich. Curl neamt it beslút dat it naam doe’t jo de wiidweidigens ferheegje, dat better is as rieden út de omjouwing, en deselde flagge toant oft namme-oplossing lokaal of by de proxy barde.

Wiskje de oerskriuwing en test deselde oanfraach op ’e nij

Feroarje ien laach, werhelje dan presys de oanfraach dy’t mislearre, want in oare URL bewiist neat. Wiskje earst de omjouwingsfariabelen yn de hjoeddeiske shell, want dy bewurking is werom te draaien en kin de tunnel net brekke:

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/'

As de wiidweidige útjefte noch altyd in proxy beweart, wie de omjouwing net it gesach. Gean ien nivo omheech yn stee fan mear oerskriuwingen opinoar te steapeljen.

Kontrolearje op macOS oft in automatysk konfiguraasjebestân de wearde net leveret, skeakelje dan de tsjinstproxy út en befêstigje de feroaring. Tink op Windows deroan dat de WinHTTP-ynstelling en de browserynstelling per brûker ferskillende objekten binne, sadat in skjin kommandorigelhelp bestean kin njonken in browser dy’t noch nei in âlde server wiist. Taheaksels fertsjinje deselde erchtinking: in proxytaheaksel kin oanfragen allinnich foar ien profyl oerskriuwe, en dat is krekt de foarm fan in fout dy’t ien browser rekket en fierder neat.

Kontrolearje dat de reparaasje in werstart oerlibbet

In ynstelling dy’t allinnich yn de terminal wurket dy’t jo bewurke hawwe, is net reparearre. Iepenje de applikaasje op ’e nij fan de buroblêdlansearder, meld jo ôf en wer oan, en sjoch oft de âlde proxy weromkomt.

Twa kontrôles skiede in echte reparaasje fan in tydlike, en beide moatte in direkte ferbining of de bedoelde wearde rapportearje. De rin yn in skjinne omjouwing toant oft in strippe proses noch in systeemynstelling oppakt.

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

As de âlde wearde nei in werstart weromkomt, is de boarne in beheard belied of in profyl dat dy wer tapast, en de eigner fan dat belied moat de útsûndering fuorthelje. Lit sertifikaatferifikaasje hieltyd oan, want in proxy dy’t ferkear ûnderskept sil oars oplost lykje sadree’t jo de kontrôles útskeakelje. Slút ôf troch de fuorthelle wearde en de datum yn jo notysjes te skriuwen, sadat de folgjende persoan in opsetlike proxy fan in fergetten ien skiede kin.