A VPN működik, de egy alkalmazásnak nincs internetje? Ellenőrizze a proxyját
Előfordulhat, hogy egy böngésző vagy eszköz a régi proxyt használja tovább, miután az alagút felállt. Hasonlítsa össze a rendszer, az alkalmazás és a környezet beállításait, mielőtt szervert vált.
Az alagútja fel van állva, az állapotoldal egészséges kézfogást mutat, de egy alkalmazás mégsem tölt be semmit. Az az alkalmazás valószínűleg még mindig egy régebbi közvetítőnek küldi a kéréseit: rendszerproxynak, bővítménynek, az eszközkezelés által kikényszerített konfigurációs fájlnak vagy olyan proxyváltozónak, amelyet csak a saját folyamata olvas. A VPN-szerver cseréje nem nyúl ehhez a beállításhoz, és ez magyarázza azt a mintát, amelyben más alkalmazások ugyanarról a gépről működnek. A hibás alkalmazástól kifelé haladjon, és hagyja békén az alagutat, amíg a proxy kérdése eldől.
Melyik réteg birtokolja a proxybeállítást
Négy hely tarthat igényt az alkalmazás kérései feletti hatalomra, és általában a legszűkebb nyer. Az operációs rendszer globális proxyt és opcionális automatikus konfigurációs URL-t tart; a böngésző követheti, felülírhatja, vagy átadhatja az irányítást egy bővítménynek; a parancssori eszköz a saját környezetét olvassa; és egy felügyelt szabályzat a változtatás után újra rögzítheti bármelyiket a fentiek közül. Döntse el, melyik réteg a felelős, mielőtt bármit szerkesztene, mert a rossz réteg törlése sikeres javításnak tűnik, amely a következő bejelentkezéskor visszatér.
Hasonlítson össze két alkalmazást ugyanazon a hétköznapi webhelyen, ne egy csak VPN-hez készült tesztoldalon. Ha a böngésző elbukik, miközben egy terminálos letöltés sikerül, akkor nem az operációs rendszer a probléma, és a különbség a böngészőprofilban vagy annak bővítményeiben van. Ha mindkettő elbukik, de egy második felhasználói fiók ugyanazon a gépen sikerül, akkor a beállítás felhasználónkénti. Ez az összehasonlítás egy percbe kerül, és a legtöbb találgatást kiveszi.
Olvassa ki azt az értéket, amelyet az egyes eszközök valóban használnak
Nyomtassa ki a konfigurációt, mielőtt módosítja, és másolja a pontos proxysztringet olyan helyre, ahonnan vissza tudja állítani. A shellváltozók a leggyorsabb ellenőrzés a parancssori eszközöknél, mert a VPN-kliens általában érintetlenül hagyja őket.
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
Csak azt a sort futtassa, amelyik illik az Ön előtti platformhoz, majd olvassa ki a kimenetből a gazdagépet, a portot és a hitelesítő adatokat. Egy ilyen érték, mint http://proxy.corp.example:8080 azt jelenti, hogy az eszköz minden kérésnél ezt a gazdagépet kérdezi, míg az üres eredmény azt jelenti, hogy közvetlenül megy, és az igazi hiba máshol van. Takarja el a felhasználó és a jelszó részét, mielőtt a kimenetet jegybe illeszti, mert ezek a karakterláncok sokkal gyakrabban élő hitelesítő adatok, mint azt az emberek feltételezik.
A saját proxymotorral rendelkező eszközöknek saját bizonyíték kell. A Curl kiírja a döntést, amelyet hozott, amikor növeli a részletességet, ami jobb, mint a környezetből találgatni, és ugyanaz a kapcsoló mutatja, hogy a névfeloldás helyben vagy a proxynál történt.
Törölje a felülírást, és tesztelje újra ugyanazt a kérést
Változtasson egy rétegen, majd ismételje meg pontosan azt a kérést, amelyik elbukott, mert egy másik URL semmit sem bizonyít. Először törölje a környezeti változókat az aktuális shellben, mert ez a módosítás visszafordítható, és nem törheti el az alagutat:
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/'
Ha a részletes kimenet továbbra is proxyt állít, akkor a környezet nem volt a hatalom. Lépjen egy szinttel feljebb, ahelyett hogy további felülírásokat halmozna.
macOS-en ellenőrizze, hogy egy automatikus konfigurációs fájl nem szolgáltatja-e az értéket, majd kapcsolja ki a szolgáltatás proxyját, és erősítse meg a változtatást. Windowson ne feledje, hogy a WinHTTP-beállítás és a felhasználónkénti böngészőbeállítás külön objektumok, ezért egy tiszta parancssori eszköz együtt létezhet olyan böngészővel, amely még mindig egy régi szerverre mutat. A bővítmények ugyanilyen gyanút érdemelnek: egy proxybővítmény csak egy profil számára írhatja át a kéréseket, és pontosan ez a formája annak a hibának, amely egy böngészőt érint, és semmi mást.
Ellenőrizze, hogy a javítás túléli-e az újraindítást
Az a beállítás, amely csak abban a terminálban működik, amelyet szerkesztett, nincs megjavítva. Nyissa meg újra az alkalmazást az asztali indítóból, jelentkezzen ki és vissza, és figyelje, visszatér-e a régi proxy.
Két ellenőrzés választja el a valódi javítást az ideiglenestől, és mindkettőnek közvetlen kapcsolatot vagy a kívánt értéket kell jelentenie. A tiszta környezetben való futtatás megmutatja, hogy egy megtisztított folyamat még mindig átvesz-e egy rendszerbeállítást.
env -i /usr/bin/curl -sS -o /dev/null -w '%{http_code} %{remote_ip}
' https://example.com
networksetup -getwebproxy "Wi-Fi"
Ha a régi érték újraindítás után visszatér, a forrás egy felügyelt szabályzat vagy profil, amely újra alkalmazza, és a szabályzat tulajdonosának el kell távolítania a kivételt. Hagyja a tanúsítványok ellenőrzését végig bekapcsolva, mert egy forgalmat elfogó proxy különben megoldottnak látszik, amint kikapcsolja az ellenőrzéseket. Végül írja fel az eltávolított értéket és a dátumot a jegyzeteibe, hogy a következő ember meg tudja különböztetni a szándékos proxyt az elfelejtettől.