VPN på og localhost slutter å virke: navn, proxy eller binding?

Utviklingsserveren din svarte for et minutt siden, og nå som tunnelen er oppe, går forespørselen i timeout med et vertsnavn du aldri skrev. To mekanismer forklarer nesten hvert tilfelle, og utenfra ser de identiske ut. Et søketillegg gjør et kort navn om til et bedriftsnavn, mens en proxy sender loopback-trafikk til en vert som ikke kan nå den. Å skille de to koster én spørring og sparer brannmurregelen du var i ferd med å skrive.

Når localhost resolver inn i bedriftssonen

Sjekk hva navnet resolver til mens tunnelen er oppe, kjør deretter samme spørring med tunnelen nede og sammenlign de to svarene. Det avslørende er en adresse i bedriftsområdet der du forventet 127.0.0.1. En post som localhost.mycompany.corp vinner over loopback-oppføringen så snart klienten legger tillegget til søkelisten, og forespørselen reiser til en privat vert der ingenting lytter på den porten. Les søkelisten i stedet for å gjette, fordi en klient kan legge til mer enn ett domene, og rekkefølgen avgjør hvilken kandidat som prøves først:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Erstatt vertsnavnet med den bokstavelige adressen i applikasjonen, databaseklienten eller notatblokkens URL, og gjenta deretter forespørselen. Hvis feilen forsvinner, hadde du et navneproblem, og tunnelen var bare utløseren. Hvis den vedvarer, er lytteren eller ruten den neste mistenkte, og navnet var et falskt spor.

Proxyinnstillinger som fanger loopback

En systemproxy som brukes når tunnelen kommer opp, godtar en forespørsel til 127.0.0.1 og videresender den til en ekstern proxy som ikke aner hva du mente. En tom unntaksliste gjør en lokal forespørsel til en ekstern, og feilmeldingen sier det sjelden. Legg loopback-adressene til unntakslisten for hele økten i stedet for for én kommando, og bekreft deretter at verktøyet respekterer den før du konkluderer noe om nettverket.

Applikasjonsrammeverk leser sine egne miljøvariabler og noen ganger sin egen konfigurasjonsfil, så et unntak som virker for ett verktøy, beviser ingenting for det neste. Nettlesere legger til en vri: Chromium-baserte nettlesere omgår proxyen for loopback implisitt, og et unntakstoken kan fjerne den atferden. Sjekk den faktiske proxyavgjørelsen i stedet for å anta at operativsysteminnstillingen er hele historien. To kommandoer avgjør det for alt som startes fra et skall:

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

Bindingsadressen avgjør hvem som kan koble til

En server som startes på 127.0.0.1, godtar bare tilkoblinger fra den maskinen, noe som vanligvis er riktig standard for utvikling. En server på 0.0.0.0 svarer på hvert grensesnitt, inkludert VPN-adapteren, noe som er mer eksponering enn de fleste har tenkt. Når den bokstavelige loopback-adressen feiler, sjekk bindingen før alt annet.

Se på den lyttende socketen og noter adressen den er bundet til, ikke bare porten. Hvis en annen enhet eller container må nå tjenesten gjennom tunnelen, bind til det spesifikke grensesnittet den vil bruke, og tillat den porten med vilje. Hvis bare din egen maskin trenger den, behold den trange bindingen og rett klienten i stedet for å utvide serveren. En portvideresending eller et tunnellag kan bygge bro mellom de to, men hver av dem legger til en komponent som senere trenger sin egen feilsøking.

Hvor et feilsøkingsverktøy forventer LAN

Feilsøkingsverktøy bærer antakelser som en tunnel stille bryter. En telefonfeilsøkingsbro mister enheten når VPN-en fanger opp enhetens subnett, så å koble til på nytt via LAN-adressen eller en kabel unngår konflikten. Et nettleserautomatiserings-hub går i timeout når huben bare er tilgjengelig via proxyen, eller når en lokal brannmur slipper kontrollporten sin. En ekstern debugger kan kreve forhøyelse og en loopback-adresse der klienten skrev om ruten.

Identifiser kontrollporten og dataporten hver for seg, fordi den ene ofte overlever mens den andre ikke gjør det. Bestem deretter om rettelsen hører til verktøyets konfigurasjon, i en rute for det subnettet eller i en regel for delt tunnel. Å redigere en hosts-fil på hver utviklermaskin skalerer dårligst og glemmes først. Foretrekk innstillingen som lever med profilen og kan gjennomgås av den som eier tunnelen.

Stopp ved det første trinnet som feiler

Arbeid deg gjennom tre trinn: løs opp navnet, åpne en socket til den bokstavelige adressen, og la deretter verktøyet lage sin egen tilkobling. Hvert trinn eliminerer ett lag, så den første feilen navngir laget som skal rettes, og alt etter det forblir utestet. Skriv ned resultatet før du endrer noe, fordi en rettelse brukt før målingen ikke kan skilles fra flaks. Hvis det første forsøket feiler og et nytt virker, var tunnelen sannsynligvis ikke klar da verktøyet startet.

Erstatt den faste søvnen med en avgrenset beredskapskontroll som venter på ruten, og hold trinnet som feiler i loggen slik at neste person ser hvor det stoppet. Et verktøy som kommer seg av seg selv, er ikke rettet, det er heldig, og flaksen tar slutt på noen andres maskin. Endre tunnelen sist, og bare for trinnet som faktisk feilet. Den rekkefølgen er også den korteste veien tilbake til et fungerende bygg, fordi den hindrer deg i å bygge på nytt en komponent som aldri var involvert.