Kehityspalvelimesi vastasi minuutti sitten, ja nyt kun tunneli on päällä pyyntö aikakatkaistaan isäntänimellä, jota et koskaan kirjoittanut. Kaksi mekanismia selittää lähes kaikki tapaukset, ja ulkopuolelta ne näyttävät samoilta. Hakuliite muuttaa lyhyen nimen yrityksen nimeksi, kun taas välityspalvelin lähettää loopback-liikenteen isännälle, joka ei voi tavoittaa sitä. Näiden erottaminen maksaa yhden kyselyn ja säästää palomuurisäännön, jota olit juuri kirjoittamassa.

Kun localhost ratkeaa yrityksen vyöhykkeelle

Tarkista, mihin nimi ratkeaa, kun tunneli on päällä, aja sitten sama kysely tunneli alas ja vertaa kahta vastausta. Paljastava tekijä on osoite yrityksen alueella siellä, missä odotit 127.0.0.1. Tietue kuten localhost.mycompany.corp voittaa loopback-tietueen heti, kun asiakasohjelma lisää liitteen hakuluetteloon, ja pyyntö matkaa yksityiselle isännälle, jossa mikään ei kuuntele sillä portilla. Lue hakuluettelo sen sijaan että arvaisit, koska asiakasohjelma voi lisätä useamman kuin yhden toimialueen ja järjestys ratkaisee, mitä ehdokasta kokeillaan ensin:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Korvaa isäntänimi kirjaimellisella osoitteella sovelluksessa, tietokanta-asiakkaassa tai muistikirjan URL-osoitteessa ja toista sitten pyyntö. Jos vika katoaa, sinulla oli nimeämisongelma ja tunneli oli vain laukaisin. Jos se jatkuu, kuuntelija tai reitti on seuraava epäilty ja nimi oli vain harhautus.

Välityspalvelinasetukset, jotka kaappaavat loopbackin

Järjestelmän välityspalvelin, joka otetaan käyttöön tunnelin noustessa, hyväksyy pyynnön osoitteeseen 127.0.0.1 ja välittää sen etävälityspalvelimelle, jolla ei ole aavistustakaan, mitä tarkoitit. Tyhjä ohituslista muuttaa paikallisen pyynnön etäpyynnöksi, ja virheilmoitus kertoo sen harvoin. Lisää loopback-osoitteet ohituslistaan koko istunnolle eikä yhdelle komennolle, ja vahvista sitten, että työkalu noudattaa sitä, ennen kuin päättelet verkosta mitään.

Sovelluskehykset lukevat omia ympäristömuuttujiaan ja joskus omaa asetustiedostoaan, joten yhdelle työkalulle toimiva ohitus ei todista mitään seuraavasta. Selaimet lisäävät vivahteen: Chromiumiin perustuvat selaimet ohittavat välityspalvelimen loopbackin osalta implisiittisesti, ja ohitustunniste voi poistaa tämän käyttäytymisen. Tarkista tosiasiallinen välityspalvelinpäätös sen sijaan että olettaisit käyttöjärjestelmän asetuksen olevan koko tarina. Kaksi komentoa ratkaisee sen kaikelle, mikä käynnistetään komentotulkista:

curl --noproxy '*' http://127.0.0.1:8080/health
NO_PROXY=localhost,127.0.0.1,::1 your-tool

Sidontaosoite päättää, kuka voi yhdistää

Palvelin, joka käynnistetään osoitteessa 127.0.0.1, hyväksyy yhteyksiä vain siltä koneelta, mikä on yleensä oikea oletus kehitykseen. Osoitteen 0.0.0.0 palvelin vastaa kaikilla liitännöillä, VPN-sovitin mukaan lukien, mikä on enemmän altistusta kuin useimmat tarkoittavat. Kun kirjaimellinen loopback-osoite epäonnistuu, tarkista sidonta ennen kaikkea muuta.

Katso kuuntelevaa pistoketta ja merkitse osoite, johon se on sidottu, älä vain porttia. Jos toisen laitteen tai kontin on päästävä palveluun tunnelin kautta, sido se tiettyyn liitäntään, jota se käyttää, ja salli se portti tarkoituksella. Jos vain oma koneesi tarvitsee sitä, pidä kapea sidonta ja korjaa asiakasohjelma palvelimen avartamisen sijaan. Portin edelleenohjaus tai tunnelikerros voi yhdistää nämä kaksi, mutta kumpikin lisää komponentin, joka tarvitsee myöhemmin oman vianetsintänsä.

Missä vianetsintätyökalu odottaa lähiverkkoa

Vianetsintätyökalut kantavat oletuksia, jotka tunneli rikkoo hiljaa. Puhelimen vianetsintäsilta menettää laitteensa, kun VPN kaappaa laitteen aliverkon, joten uudelleenyhdistäminen LAN-osoitteen tai kaapelin kautta välttää ristiriidan. Selaimen automaatiokeskus aikakatkaistaan, kun keskus on tavoitettavissa vain välityspalvelimen kautta tai kun paikallinen palomuuri pudottaa sen ohjausportin. Etädebuggeri voi vaatia oikeuksien korotuksen ja loopback-osoitteen siellä, missä asiakasohjelma kirjoitti reitin uudelleen.

Tunnista ohjausportti ja dataportti erikseen, koska usein toinen säilyy hengissä ja toinen ei. Päätä sitten, kuuluuko korjaus työkalun asetuksiin, reittiin kyseiselle aliverkolle vai sääntöön jaetusta tunnelista. hosts-tiedoston muokkaaminen jokaisella kehittäjän koneella skaalautuu huonoiten ja unohtuu ensimmäisenä. Suosi asetusta, joka elää profiilin kanssa ja jonka tunnelin omistaja voi käydä läpi.

Pysähdy ensimmäisessä vaiheessa, joka epäonnistuu

Käy läpi kolme vaihetta: ratkaise nimi, avaa pistoke kirjaimelliseen osoitteeseen ja anna sitten työkalun tehdä oma yhteytensä. Jokainen vaihe poistaa yhden kerroksen, joten ensimmäinen vika nimeää korjattavan kerroksen ja kaikki sen jälkeen jää testaamatta. Kirjoita tulos muistiin ennen kuin muutat mitään, koska ennen mittausta tehtyä korjausta ei voi erottaa onnesta. Jos ensimmäinen yritys epäonnistuu ja toisto toimii, tunneli ei todennäköisesti ollut valmis, kun työkalu käynnistyi.

Korvaa kiinteä odotus rajatulla valmiustarkistuksella, joka odottaa reittiä, ja pidä epäonnistuva vaihe lokissa, jotta seuraava näkee, mihin se pysähtyi. Työkalu, joka toipuu itsestään, ei ole korjattu, se on onnekas, ja onni loppuu jonkun toisen koneella. Muuta tunnelia viimeisenä ja vain vaiheelle, joka todella epäonnistui. Tämä järjestys on myös lyhin tie takaisin toimivaan buildiin, koska se estää sinua rakentamasta uudelleen komponenttia, joka ei ollut koskaan mukana.

Aiheeseen liittyvät artikkelit