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 не проверува ниту еден од овие слоеви. Тоа само повторно ја извршува промената што ги расипа, затоа истите три пропусти се враќаат по секое повторно поврзување и исчезнуваат по секое рестартирање што го остава клиентот неактивен.