mitmproxy, DevTools, Gradle: három réteg a VPN mögött

A VPN csatlakozik, és három független eszköz három különböző módon hibázik ugyanazon a délutánon. A mitmproxy nem lát több kérést, a Chrome elutasítja a hibakeresőt, és a Gradle dob egy BindException hibát helyi socket kötése közben. A közös gyanú az, hogy az alagút blokkolja a localhostot. Nem tudja: 127.0.0.1 a kernelben kezelődik, és soha nem ér el egy adaptert, nemhogy egy átjárót.

Három réteg, három különböző hiba

Ami a klienssel megváltozott, az nem a loopback felé vezető útvonal. Hanem egy helyi proxy, a gép bizalmi tárolója és egy csomagszűrő, és mindegyik a fejlesztői munkafolyamat más részét töri el. A tünet megfelelő sorba sorolása a diagnózis nagy része:

Gyakorlatilag minden ilyen jelentés az utolsó sorból indul és felfelé halad, ami fordított. Az alagút az egyetlen réteg, amely bizonyíthatóan nem lát loopback forgalmat, ezért érdemli a legkevesebb gyanút. Kezdje azzal, amit a folyamat kötött, aztán kérdezze meg, mely tanúsítványokban bízik, és csak utána nézze a gépen lévő házirendet.

A figyelővel kezdje, ne az alagúttal

Amikor egy proxy a 127.0.0.1:8080 címen abbahagyja a forgalom fogadását, három dolog egyike történt: soha nem indult el, másik portot kötött, vagy a szűrő eldobta a loopback kapcsolatot. A figyelő socketek listázása egyetlen paranccsal megválaszolja ezt, és azt is megmutatja, melyik folyamat birtokolja a portot, amikor két eszköz vitatkozik azon, ki volt előbb.

Egy helyi cím az útvonalkeresésben ugyanezt igazolja a másik irányból. ip route get loopback cél felé a loopback eszközt jelenti, soha nem az alagutat, ami hasznos mondat, ha valaki útvonal-módosítást javasol megoldásként.

A proxy réteg: a környezet nem konfiguráció

Sok vállalati kliens futtat HTTP proxyt, és elvárja, hogy az alkalmazások használják. A beállítás HTTPS_PROXY egy shellben kijavítja a parancssori eszközöket, amelyek tisztelik, és semmit sem tesz egy olyan eszközért, amely a saját beállításfájlját olvassa. A Gradle, a Selenium és a gRPC mind a saját konfigurációját nézi, és az egyik terminálban exportált proxy láthatatlan az IDE által indított daemon számára.

A konténereszközök a szokásos hely, ahol ez láthatóvá válik. Egy konténer loopbackje a sajátja, ezért 127.0.0.1 a konténeren belül soha nem a gazdagép proxyját jelenti; a gazdagép címe vagy egy gazdagép-hálózati beállítás szükséges. A javítás, amely a shellben működik és a buildben elbukik, általában ez a sor, nem az alagút.

A bizalmi réteg: az eszköz más tárolót olvas

Az elfogás a második változás, és ez okozza a legfélrevezetőbb hibákat. A kliens a saját tanúsítványát mutatja be az ellenőrzött kapcsolatokhoz, ezért a vállalati gyökérben bízó böngésző sikerül, míg a beépített CA tárolóval rendelkező eszköz elbukik. A Python requests a certifin keresztül a klasszikus eset: az operációs rendszer tárolója helyes lehet, és a kérés mégis elbukik, mert az a futtatókörnyezet soha nem olvassa. A hibaüzenet ritkán említi az elfogást, ezért ezt a sort tévesen törött végpontként diagnosztizálják.

Hasonlítsa össze, mit mutat be valóban a végpont azzal, amit az eszköz érvényesített. openssl s_client megmutatja a szerver által küldött láncot; az eszköz saját érvényesítési kimenete megmutatja, mit döntött. Amikor nem egyeznek, REQUESTS_CA_BUNDLE vagy SSL_CERT_FILE a kar az adott futtatókörnyezethez, és a vállalati gyökér abba a tárolóba tartozik, amelyet az a futtatókörnyezet olvas, nem egy globális helyre, amelyet csak néhány eszköz tisztel.

Az SSL hibát javító verzióváltozás a bizalmi és rejtjelezési házirend bizonyítéka, nem a VPN-é. A SOAP klienst működésre bíró Python-visszalépés megváltoztatta a beépített CA tárolót és az alapértelmezett TLS-beállításokat; a hálózati útvonal nem mozdult.

A szűrő réteg: a loopbacket is eldobhatja

A harmadik változás egy csomagszűrő, és egyes termékek olyan szabályokat telepítenek, amelyek eldobják az alagútba nem belépő forgalmat. A helyi figyelők is benne lehetnek. Ez egy működő socketet elutasított vagy időtúllépéses kapcsolattá tesz, és az így keletkező hiba alkalmazáshibának tűnik, nem a gépen lévő házirendnek.

A port birtoklása ennek a rétegnek a másik fele. BindException azt jelenti, hogy a socketet nem lehetett megnyitni, ami más hiba, mint egy elutasított kapcsolat. Ellenőrizze, hogy egy másik folyamat már tartja-e a portot, mielőtt a szűrőt hibáztatja, aztán keressen egy szabályt, amely eldobja a helyi forgalmat, és adja hozzá a termék által támogatott legszűkebb engedélyt. Két eszköz, amely ugyanazért a hibakereső portért verseng, pontosan ugyanazt az üzenetet adja, mint egy házirend-blokk, és csak az egyikük javul tűzfalváltozástól.

A Chrome hibakereső portja ugyanabban a családban hibázik. A böngésző elindul, az illesztőprogram nem éri el a DevTools végpontot, és az üzenet a DevToolst nevezi meg, nem a hálózatot. A további indítási jelzők és egy felesleges illesztőprogram-kezelő megváltoztatják, melyik folyamat birtokolja a portot, ezért az eltávolításuk néha úgy tűnik, mintha megjavítaná a VPN-t.

Javítsa meg a hibás réteget

Javítsa meg a hibás réteget, ne az alagutat. Egy elérhetetlen loopback figyelőnek a figyelőjét vagy a portját kell kijavítani. Egy nem megbízható tanúsítványnak a vállalati gyökérre van szüksége ott telepítve, ahová az adott futtatókörnyezet néz, a kivételt szűken tartva. Egy helyi forgalmat eldobó szűrőnek konkrét engedélyezési szabályra van szüksége, nem kikapcsolt szűrőre, mert a kikapcsolás minden mást is újra megnyit, amit védett.

A VPN újracsatlakoztatása egyiket sem teszteli ezek közül a rétegek közül. Csak újra lefuttatja a változást, amely eltörte őket, ezért ugyanaz a három hiba tér vissza minden újracsatlakozás után, és tűnik el minden újraindítás után, amely inaktívan hagyja a klienst.