mitmproxy, DevTools, Gradle: kolme kerrosta VPN:n takana
Loopback ei päädy koskaan tunneliin. Lajittele oire kuuntelijaan, luottamusvarastoon tai pakettisuodattimeen ja korjaa kerros, joka todella petti.
VPN yhdistyy, ja kolme toisiinsa liittymätöntä työkalua epäonnistuu kolmella eri tavalla samana iltapäivänä. mitmproxy lakkaa näkemästä pyyntöjä, Chrome kieltäytyy debuggerista ja Gradle heittää BindException paikallista socketia sitoessaan. Yhteinen epäilys on, että tunneli estää localhostin. Se ei voi: 127.0.0.1 käsitellään ytimen sisällä eikä saavuta koskaan sovitinta, saati yhdyskäytävää.
Kolme kerrosta, kolme eri vikaa
Asiakasohjelman myötä muuttui muu kuin reitti loopbackiin. Muuttuivat paikallinen välityspalvelin, koneen luottamusvarasto ja pakettisuodatin, ja jokainen rikkoo eri osan kehittäjän työnkulusta. Oireen sijoittaminen oikealle riville on suurin osa diagnoosista:
| 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? |
Lähes jokainen tämänkaltainen raportti alkaa viimeiseltä riviltä ja etenee ylöspäin, mikä on nurinkurista. Tunneli on ainoa kerros, joka todistetusti ei voi nähdä loopback-liikennettä, joten se ansaitsee vähiten epäilyä. Aloita siitä, mihin prosessi sitoi, kysy sitten, mihin sertifikaatteihin se luottaa, ja vasta sitten katso koneen käytäntöä.
Aloita kuuntelijasta, ei tunnelista
Kun välityspalvelin osoitteessa 127.0.0.1:8080 lakkaa vastaanottamasta liikennettä, yksi kolmesta tapahtui: se ei koskaan käynnistynyt, se sitoi toisen portin tai suodatin pudotti loopback-yhteyden. Kuuntelevien socketien listaaminen vastaa siihen yhdellä komennolla, ja se näyttää myös, mikä prosessi omistaa portin, kun kaksi työkalua on eri mieltä siitä, kuka oli ensin.
Paikallinen osoite reittihaussa vahvistaa saman toisesta suunnasta. ip route get loopback-kohdetta vastaan raportoi loopback-laitteen, ei koskaan tunnelia, mikä on hyödyllinen lause pitää valmiina, kun joku ehdottaa reittimuutosta korjaukseksi.
Välityspalvelinkerros: ympäristö ei ole kokoonpano
Monet yritysasiakkaat ajavat HTTP-välityspalvelinta ja odottavat sovellusten käyttävän sitä. Sen asettaminen HTTPS_PROXY kuoressa korjaa komentorivityökalut, jotka sitä noudattavat, eikä tee mitään työkalulle, joka lukee oman asetustiedostonsa. Gradle, Selenium ja gRPC konsultoivat kukin omaa kokoonpanoaan, ja yhdessä päätteessä viety välityspalvelin on näkymätön IDE:n käynnistämälle taustapalvelulle.
Konttityökalut ovat tavallinen paikka, jossa tämä tulee näkyviin. Kontin loopback on sen oma, joten 127.0.0.1 kontin sisällä ei tarkoita koskaan isäntäkoneen välityspalvelinta; tarvitaan isäntäkoneen osoite tai isäntäverkon asetus. Korjaus, joka toimii kuoressa ja epäonnistuu buildissa, on yleensä tämä rivi, ei tunneli.
Luottamuskerros: työkalu lukee toista varastoa
Sieppaus on toinen muutos, ja se tuottaa harhaanjohtavimmat virheet. Asiakasohjelma esittää oman sertifikaattinsa tarkastetuille yhteyksille, joten yrityksen juureen luottava selain onnistuu, kun taas sisäänrakennetun CA-varaston työkalu epäonnistuu. Pythonin requests certifin kautta on klassinen tapaus: käyttöjärjestelmän varasto voi olla oikein ja pyyntö silti epäonnistuu, koska se suoritusympäristö ei koskaan lue sitä. Virheteksti mainitsee sieppauksen harvoin, minkä vuoksi tämä rivi diagnosoidaan väärin rikkinäiseksi päätepisteeksi.
Vertaa, mitä päätepiste todella esittää, siihen, mitä työkalu validoi. openssl s_client näyttää ketjun, jonka palvelin lähetti; työkalun oma validointituloste näyttää, mitä se päätti. Kun ne eivät täsmää, REQUESTS_CA_BUNDLE tai SSL_CERT_FILE on sen suoritusympäristön vipu, ja yrityksen juuri kuuluu varastoon, jota se suoritusympäristö lukee, ei globaaliin paikkaan, jota vain jotkin työkalut noudattavat.
SSL-virheen korjaava versiomuutos on todiste luottamus- ja salauskäytännöstä, ei VPN:stä. Pythonin version laskeminen, joka sai SOAP-asiakkaan toimimaan, muutti sisäänrakennetun CA-varaston ja oletusarvoiset TLS-asetukset; verkkopolku ei liikkunut.
Suodatinkerros: se voi pudottaa myös loopbackin
Kolmas muutos on pakettisuodatin, ja jotkin tuotteet asentavat sääntöjä, jotka pudottavat liikennettä, joka ei tule tunneliin. Paikalliset kuuntelijat voivat kuulua joukkoon. Se muuttaa toimivan socketin hylätyksi tai aikakatkaistuksi yhteydeksi, ja tuloksena oleva virhe näyttää sovelluksen bugilta eikä koneen käytännöltä.
Portin omistus on tämän kerroksen toinen puoli. BindException tarkoittaa, että socketia ei voitu avata, mikä on eri vika kuin hylätty yhteys. Tarkista, pitääkö jokin toinen prosessi porttia jo ennen kuin syytät suodatinta, etsi sitten sääntö, joka pudottaa paikallisen liikenteen, ja lisää kapein sallinta, jota tuote tukee. Kaksi samasta debug-portista kilpailevaa työkalua tuottavat täsmälleen saman viestin kuin käytännön esto, ja vain toinen niistä korjautuu palomuurimuutoksella.
Chromen debug-portti epäonnistuu samassa perheessä. Selain käynnistyy, ajuri ei tavoita DevTools-päätepistettä, ja viesti nimeää DevToolsin eikä verkkoa. Ylimääräiset käynnistysliput ja tarpeeton ajurinhallinta muuttavat sitä, mikä prosessi omistaa portin, minkä vuoksi niiden poistaminen näyttää joskus korjaavan VPN:n.
Korjaa kerros, joka petti
Korjaa kerros, joka petti, ei tunnelia. Tavoittamattoman loopback-kuuntelijan kuuntelija tai portti on korjattava. Epäluotettava sertifikaatti tarvitsee yrityksen juuren asennettuna sinne, minne juuri se suoritusympäristö katsoo, poikkeus kapeana pitäen. Paikallista liikennettä pudottava suodatin tarvitsee tietyn sallintasäännön eikä poiskytkettyä suodatinta, koska poiskytkentä avaa uudelleen myös kaiken muun, mitä se suojasi.
VPN:n uudelleenyhdistäminen ei testaa mitään näistä kerroksista. Se vain ajaa uudelleen muutoksen, joka ne rikkoi, minkä vuoksi samat kolme vikaa palaavat jokaisen uudelleenyhdistämisen jälkeen ja katoavat jokaisen uudelleenkäynnistyksen jälkeen, joka jättää asiakasohjelman passiiviseksi.