mitmproxy, DevTools, Gradle: tri tavoloj malantaŭ la VPN
Loopback neniam eniras la tunelon. Klasifiku la simptomon al aŭskultanto, fido-stokejo aŭ paketa filtrilo, kaj riparu la tavolon, kiu vere fiaskis.
La VPN konektiĝas, kaj tri malrilataj iloj fiaskas laŭ tri malsamaj manieroj en la sama posttagmezo. mitmproxy ĉesas vidi petojn, Chrome rifuzas la sencimigilon, kaj Gradle ĵetas BindException dum ĝi ligas lokan ingon. La komuna suspekto estas, ke la tunelo blokas localhost. Ĝi ne povas: 127.0.0.1 estas traktata ene de la kerno kaj neniam atingas adaptilon, des malpli enirejon.
Tri tavoloj, tri malsamaj paneoj
Kio ŝanĝiĝis kun la kliento, ne estas la vojo al loopback. Temas pri loka prokurilo, maŝina fido-stokejo kaj paketa filtrilo, kaj ĉiu el ili rompas alian parton de la laborfluo de programisto. Ordigi simptomon en la ĝustan vicon estas la plej granda parto de la diagnozo:
| 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? |
Preskaŭ ĉiu raporto de ĉi tiu speco komenciĝas ĉe la lasta vico kaj iras supren, kio estas malĝusta. La tunelo estas la sola tavolo, kiu pruveble ne povas vidi loopback-trafikon, do ĝi meritas la plej malmultan suspekton. Komencu per tio, kion la procezo ligis, poste demandu, kiujn atestilojn ĝi fidas, kaj nur poste rigardu la politikon sur la maŝino.
Komencu per la aŭskultanto, ne per la tunelo
Kiam prokurilo sur 127.0.0.1:8080 ĉesas ricevi trafikon, okazis unu el tri aferoj: ĝi neniam ekfunkciis, ĝi ligis alian pordon, aŭ la filtrilo forĵetis la loopback-konekton. Listigi la aŭskultantajn ingojn respondas tion per unu komando, kaj ĝi ankaŭ montras, kiu procezo posedas la pordon, kiam du iloj malkonsentas pri tio, kiu estis unua.
Loka adreso en vojserĉo konfirmas la saman aferon el la alia direkto. ip route get kontraŭ loopback-celo raportas la loopback-aparaton, neniam la tunelon, kio estas utila frazo pretigi, kiam iu proponas vojŝanĝon kiel solvon.
La prokurila tavolo: medio ne estas agordo
Multaj korporaciaj klientoj funkciigas HTTP-prokurilon kaj atendas, ke aplikoj uzu ĝin. Agordi HTTPS_PROXY en ŝelo riparas komandliniajn ilojn, kiuj respektas ĝin, kaj faras nenion por ilo, kiu legas sian propran agordan dosieron. Gradle, Selenium kaj gRPC ĉiu konsultas sian propran agordon, kaj prokurilo eksportita en unu terminalo estas nevidebla por demono lanĉita de la IDE.
Konteneraj iloj estas la kutima loko, kie ĉi tio videbliĝas. La loopback de kontenero estas ĝia propra, do 127.0.0.1 ene de la kontenero neniam signifas la prokurilon de la gastiganto; necesas la adreso de la gastiganto aŭ agordo de gastiganta reto. Riparo, kiu funkcias en la ŝelo kaj fiaskas en la konstruo, kutime estas ĉi tiu vico, ne la tunelo.
La fida tavolo: la ilo legas alian stokejon
Interkaptado estas la dua ŝanĝo, kaj ĝi produktas la plej misgvidajn erarojn. La kliento prezentas sian propran atestilon por inspektitaj konektoj, do retumilo, kiu fidas la korporacian radikon, sukcesas, dum ilo kun enpakigita CA-stokejo fiaskas. La requests de Python per certifi estas la klasika kazo: la stokejo de la operaciumo povas esti ĝusta kaj la peto tamen fiaskas, ĉar tiu plenummedio neniam legas ĝin. La erarteksto malofte mencias interkaptadon, kaj tial ĉi tiu vico estas misdiagnozata kiel rompita finpunkto.
Komparu, kion la finpunkto efektive prezentas, kun tio, kion la ilo validigis. openssl s_client montras la ĉenon, kiun la servilo sendis; la propra validiga eligo de la ilo montras, kion ĝi decidis. Kiam ili malkongruas, REQUESTS_CA_BUNDLE aŭ SSL_CERT_FILE estas la levilo por tiu plenummedio, kaj la korporacia radiko apartenas al la stokejo, kiun tiu plenummedio legas, anstataŭ al tutmonda loko, kiun respektas nur kelkaj iloj.
Versia ŝanĝo, kiu riparas SSL-eraron, estas pruvo pri fido- kaj ĉifra politiko, ne pri la VPN. Malaltigo de Python, kiu igas SOAP-klienton funkcii, ŝanĝis la enpakigitan CA-stokejon kaj la defaŭltajn TLS-agordojn; la reta vojo ne moviĝis.
La filtra tavolo: ĝi povas forĵeti ankaŭ loopback
La tria ŝanĝo estas paketa filtrilo, kaj iuj produktoj instalas regulojn, kiuj forĵetas trafikon, kiu ne eniras la tunelon. Lokaj aŭskultantoj povas esti inkluzivitaj. Tio igas funkciantan ingon rifuzita aŭ tempolimita konekto, kaj la rezulta eraro aspektas kiel cimo en la aplikaĵo, ne kiel politiko sur la maŝino.
Pordoposedo estas la alia duono de ĉi tiu tavolo. BindException signifas, ke la ingo ne povis esti malfermita, kio estas malsama fiasko ol rifuzita konekto. Kontrolu, ĉu alia procezo jam tenas la pordon, antaŭ ol kulpigi la filtrilon, poste serĉu regulon, kiu forĵetas lokan trafikon, kaj aldonu la plej mallarĝan permeson, kiun la produkto subtenas. Du iloj konkurantaj pri la sama sencimiga pordo produktas precize la saman mesaĝon kiel politika blokado, kaj nur unu el ili ripariĝas per fajroŝirma ŝanĝo.
La sencimiga pordo de Chrome fiaskas en la sama familio. La retumilo ekfunkcias, la pelilo ne povas atingi la DevTools-finpunkton, kaj la mesaĝo nomas DevTools anstataŭ la reton. Pliaj lanĉaj flagoj kaj superflua peliladministrilo ŝanĝas, kiu procezo posedas la pordon, tial forigi ilin foje ŝajnas ripari la VPN.
Riparu la tavolon, kiu fiaskis
Riparu la tavolon, kiu fiaskis, ne la tunelon. Neatingebla loopback-aŭskultanto bezonas korekton de sia aŭskultanto aŭ pordo. Ne fidinda atestilo bezonas la korporacian radikon instalitan tie, kie tiu specifa plenummedio rigardas, kun la escepto tenata mallarĝa. Filtrilo, kiu forĵetas lokan trafikon, bezonas specifan permesregulon anstataŭ malŝaltita filtrilo, ĉar malŝaltado remalfermas ankaŭ ĉion alian, kion ĝi protektis.
Rekonekti la VPN provas neniun el ĉi tiuj tavoloj. Ĝi nur reekzekutas la ŝanĝon, kiu rompis ilin, tial la samaj tri fiaskoj revenas post ĉiu rekonekto kaj malaperas post ĉiu restartigo, kiu lasas la klienton neaktiva.