A hibakereső proxy megvakul, amikor a vállalati VPN csatlakozik

A rögzítőeszköz egész délelőtt működik, az alagút csatlakozik, és elhallgat. Bontsa a kapcsolatot, és újraindul. Az első gondolat, hogy a VPN tönkretette a proxyt, pedig a proxy konfigurációjában valójában semmi nem változott. Az változott meg, hogy most melyik konfigurációt olvassák az alkalmazások: az alagútbejegyzés saját proxybeállításokat hordozhat, egy felügyelt profil újra bekapcsolhatja az automatikus konfigurációt, és egyes futtatókörnyezetek csak egy részét olvassák annak, amit az operációs rendszer kínál. Olvassa el a kapcsolatonkénti értéket, mielőtt a globálishoz nyúl.

A Windows kapcsolatonként tart proxyt

Az internetbeállításokban két réteg van, amely a párbeszédablakban azonosnak látszik. A helyi hálózat beállításai a szokásos helyi kapcsolatra érvényesek, míg egy betárcsázós vagy VPN-bejegyzés saját másolatot tart a HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections alatt, bináris értékként tárolva. Az ismert globális beállításjegyzék-értékek írása nem frissíti ezt a másolatot.

Pontosan így viselkedik egy eszköz helyesen a csatlakozás előtt és helytelenül utána, anélkül hogy bármi látható változás történne a beállításaiban. A párbeszédablak, amelyet bámult, a helyi hálózat panelje volt. Helyes volt, és irreleváns volt. A bejegyzés, amelyet a Windows valójában használt, az alagúthoz létrehozott bejegyzés volt.

Egy bejegyzés módosításának támogatott módja a WinINET kapcsolati beállítási API: töltse ki a INTERNET_PER_CONN_OPTION_LIST szerkezetet a kapcsolat nevével, a jelzőkkel, a proxykiszolgálóval és a kihagyási listával, alkalmazza, majd frissítsen. Gyors ellenőrzéshez nyissa meg az alagútbejegyzés saját beállítási párbeszédablakát, és hasonlítsa össze a proxy paneljét a helyi hálózat paneljével; a különbség általában nyilvánvaló, ha tudja, hová kell nézni.

Egy felügyelt PAC újra bekapcsolhatja magát

macOS-en az automatikus proxykonfigurációs szkript és a proxy automatikus felderítése egy hálózati szolgáltatás tulajdonságai, nem a gépé. Egy konfigurációs profil megkövetelheti őket, így a kipipálás után újra megjelennek, és minden kérés aztán ahhoz a proxyhoz megy, amelyet a szkript kiválaszt.

Vizsgálja meg, és ha erre jogosult, kapcsolja ki ezt a két kapcsolót annál a szolgáltatásnál, amely a forgalmat hordozza:

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

A valódi szolgáltatásnevet használja, ne tippeljen. Egy laptop, amelyben Wi-Fi és USB Ethernet adapter is van, kettő ilyet tartalmaz, és csak az egyik hordozza a forgalmát. A scutil --proxy az aktuális elsődleges szolgáltatás értékeit nyomtatja. Hasonlítsa össze ezt a kimenetet azzal, amit szerkesztett, mielőtt arra jutna, hogy a profil győzött.

Irányítsa az eszközt a valódi felsőbb pontra

Ha a szkript tartalmazza a vállalati proxyt, olvassa el, és ugyanazt a címet adja meg külső proxyként a rögzítőeszközön belül. Ekkor az eszköz a valódi felsőbb pontra továbbít, amit a vállalati proxy elvár, és a kérés útvonalán marad ahelyett, hogy a szabályzattal harcolna.

Ez az a lépés, amely hibakeresésben tartja, nem újrakonfigurálásban.

Tolja be a proxyt az alagútba

Egy OpenVPN-alapú kliens elfogadhat olyan proxybeállításokat, amelyek az alagút felállása után érvényesek, ami kényelmes, ha az útvonalak a kliensnél vannak:

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

Csak az ezt tiszteletben tartó kliensek fogják használni, és ez keményen beleírja a figyelő portját egy profilba. Kezelje laboratóriumi kényelemként, nem telepítési szabványként, mert a következő profilküldés eltávolítja.

Egyes kliensek soha nem olvassák a rendszerproxyt

A Firefox saját proxybeállításokat tart, ezért néha tovább rögzít, amikor a rendszerproxyt használó böngésző már nem. Egy régebbi .NET-ügyfél, amely nem érti az automatikus konfigurációt, közvetlenül csatlakozik, bárhol is fut, így egy az alagútbejegyzésen át betöltött oldal az alkalmazáson belül mégis meghiúsulhat.

A hálózati eszközöknek is megvannak a maguk okai. Az alagúton vagy telefonos tetheren át akadó FTP-munkamenet gyakran az aktív és passzív mód közötti, a kliens által egyeztetett probléma, és semmilyen proxybeállítás nem változtat rajta.

A konfigurációt olvassa, ne a kapcsolót

Ebben a sorrendben dolgozzon: az alagútbejegyzés saját proxyértéke, a szolgáltatásonkénti PAC- és automatikus felderítési állapot, majd az alkalmazás saját proxykezelése. Az elsőnél álljon meg, amely eltér attól, amit feltételezett.

Minden eset itt konfigurációs elsőbbségi probléma. Egyik sem az alagút, amely tönkreteszi az eszközét.