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