mitmproxy, DevTools, Gradle: тры ўзроўні за VPN
Loopback ніколі не трапляе ў тунель. Адкажыце сімптом да слухача, сховішча даверу або фільтра пакетаў і адрамантуйце той узровень, што сапраўды зламаўся.
VPN падключаецца, і тры незвязаныя інструменты збаўляюцца трыма рознымі спосабамі у той самы пасляабедзенны час. mitmproxy перастае бачыць запыты, Chrome адмаўляе адладчыку, а Gradle кідае BindException падчас прывязкі лакальнага сокета. Агульнае падазрэнне — тунель блакуе localhost. Ён не можа: 127.0.0.1 апрацоўваецца ўнутры ядра і ніколі не дасягае адаптара, не кажучы ўжо пра шлюз.
Тры ўзроўні, тры розныя паломкі
Што змянілася з кліентам — гэта не маршрут да loopback. Гэта лакальны проксі, машыннае сховішча даверу і фільтр пакетаў, і кожны з іх ламае розную частку працоўнага працэсу распрацоўшчыка. Размеркаванне сімптому па правільным радку — гэта большая частка дыягностыкі:
| Symptom | Layer | First check |
|---|---|---|
| Proxy sees no traffic | Local proxy or listener | ss -lntp, or netstat -ano on Windows |
| TLS error in one tool only | Trust store | Which CA bundle does that runtime read? |
| Local bind or connect refused | Packet filter or port owner | Who holds the port, and what rule drops it? |
Амаль кожная справаздача такога роду пачынаецца з апошняга радка і ідзе ўверх, што наадварот. Тунель — адзіны ўзровень, які даказальна не можа бачыць трафік loopback, таму ён заслугоўвае найменшага падазрэння. Пачніце з таго, што прывязаў працэс, затым спытайце, якім сертыфікатам ён давярае, і толькі потым глядзіце на палітыку на машыне.
Пачніце са слухача, а не з тунеля
Калі проксі на 127.0.0.1:8080 перастае атрымліваць трафік, адбылося адно з трох: ён не запусціўся, ён прывязаў іншы порт або фільтр скінуў злучэнне loopback. Пералік слухаючых сокетаў адказвае на гэта адной камандай, і ён таксама паказвае, які працэс валодае портам, калі два інструменты не згодныя, хто быў першым.
Лакальны адрас у пошуку маршруту пацвярджае тое ж самае з іншага боку. ip route get супраць пункта прызначэння loopback паведамляе пра прыладу loopback, ніколі пра тунель, што з'яўляецца карысным сказам, калі хтосьці прапануе змену маршрутызацыі як рашэнне.
Узровень проксі: асяроддзе — гэта не канфігурацыя
Многія карпаратыўныя кліенты запускаюць HTTP-проксі і чакаюць, што праграмы будуць ім карыстацца. Усталяванне HTTPS_PROXY у абалонцы выпраўляе інструменты каманднага радка, якія яго паважаюць, і нічога не робіць для інструмента, які чытае ўласны файл наладаў. Gradle, Selenium і gRPC кожны звяртаецца да сваёй канфігурацыі, а проксі, экспартаваны ў адным тэрмінале, нябачны для дэмана, запушчанага IDE.
Кантэйнерныя інструменты — звычайнае месца, дзе гэта становіцца бачным. Loopback кантэйнера — яго ўласны, таму 127.0.0.1 унутры кантэйнера ніколі не азначае проксі хасцёра; патрэбны адрас хасцёра або налада сеткі хасцёра. Выпраўленне, якое працуе ў абалонцы і збаўляецца ў зборцы, звычайна гэты радок, а не тунель.
Узровень даверу: інструмент чытае іншае сховішча
Перахоп — другая змена, і ён дае самыя падманныя памылкі. Кліент прадстаўляе ўласны сертыфікат для правераных злучэнняў, таму браўзер, які давярае карпаратыўнаму кораню, дасягае поспеху, а інструмент з убудаваным сховішчам CA збаўляецца. Python requests праз certifi — класічны выпадак: сховішча аперацыйнай сістэмы можа быць правільным, а запыт усё роўна збаўляецца, бо гэтае асяроддзе выканання ніколі яго не чытае. Тэкст памылкі рэдка згадвае перахоп, таму гэты радок памылкова дыягнастуюць як зламаны канчатковы пункт.
Параўнайце, што канчатковы пункт фактычна прадстаўляе, з тым, што праверыў інструмент. openssl s_client паказвае ланцужок, які даслаў сервер; уласны вывад праверкі інструмента паказвае, што ён вырашыў. Калі яны не супадаюць, REQUESTS_CA_BUNDLE або SSL_CERT_FILE — гэта рычаг для таго асяроддзя выканання, і карпаратыўны корань належыць у сховішча, якое чытае гэтае асяроддзе, а не ў глабальнае месца, якое паважаюць толькі некаторыя інструменты.
Змена версіі, якая выпраўляе памылку SSL, — гэта доказ пра палітыку даверу і шыфраў, а не пра VPN. Зніжэнне версіі Python, якое прымусіла кліент SOAP працаваць, змяніла ўбудаванае сховішча CA і стандартныя налады TLS; сеткавы шлях не зрушыўся.
Узровень фільтра: ён таксама можа скідаць loopback
Трэцяя змена — фільтр пакетаў, і некаторыя прадукты ўсталёўваюць правілы, якія скідаюць трафік, што не трапляе ў тунель. Лакальныя слухачы могуць быць уключаныя. Гэта ператварае працоўны сокет у адхіленае або пратэрмінаванае злучэнне, і ўзніклая памылка выглядае як памылка ў праграме, а не як палітыка на машыне.
Валоданне портам — другая палова гэтага ўзроўню. BindException азначае, што сокет не ўдалося адкрыць, і гэта іншая няўдача, чым адмова ў злучэнні. Праверце, ці не займае порт ужо іншы працэс, перш чым вінаваціць фільтр, затым шукайце правіла, якое скідае лакальны трафік, і дадайце самае вузкае дазвол, якое падтрымлівае прадукт. Два інструменты, якія спаборнічаюць за адзін і той жа порт адладкі, даюць дакладна тое ж паведамленне, што і блакіроўка палітыкі, і толькі адзін з іх выпраўляецца змяненнем файрвола.
Порт адладкі Chrome збаўляецца ў той жа сям'і. Браўзер запускаецца, драйвер не можа дасягнуць канчатковага пункта DevTools, і паведамленне называе DevTools, а не сетку. Дадатковыя сцягі запуску і лішні менеджар драйвераў змяняюць, які працэс валодае портам, таму іх выдаленне часам выглядае як выпраўленне VPN.
Адрамантуйце той узровень, што зламаўся
Адрамантуйце той узровень, што зламаўся, а не тунель. Недасягальны слухач loopback патрабуе выпраўлення свайго слухача або порта. Ненадзейны сертыфікат патрабуе ўсталявання карпаратыўнага кораня там, дзе глядзіць менавіта гэтае асяроддзе выканання, з вузкім выключэннем. Фільтр, які скідае лакальны трафік, патрабуе пэўнага правіла дазволу, а не адключанага фільтра, бо адключэнне таксама зноў адкрывае ўсё астатняе, што ён абараняў.
Паўторнае падключэнне VPN не правярае ніводзін з гэтых узроўняў. Яно толькі паўторна запускае змену, якая іх зламала, таму тыя ж тры няўдачы вяртаюцца пасля кожнага перападключэння і знікаюць пасля кожнай перазагрузкі, якая пакідае кліент неактыўным.