VPN slået til og localhost holder op med at virke: navn, proxy eller binding?

Din udviklingsserver svarede for et minut siden, og nu hvor tunnelen er oppe, udløber anmodningen med et værtsnavn, du aldrig har skrevet. To mekanismer forklarer næsten hvert tilfælde, og udefra ser de identiske ud. Et søgesuffiks gør et kort navn til et virksomhedsnavn, mens en proxy sender loopback-trafik til en vært, der ikke kan nå den. At skelne de to koster én forespørgsel og sparer den firewallregel, du var ved at skrive.

Når localhost opløses i virksomhedszonen

Kontroller, hvad navnet opløses til, mens tunnelen er oppe, og kør derefter den samme forespørgsel med den nede og sammenlign de to svar. Det afslørende er en adresse i virksomhedsområdet, hvor du forventede 127.0.0.1. En post som localhost.mycompany.corp vinder over loopback-posten, når klienten føjer det suffiks til søgelisten, og anmodningen rejser til en privat vært uden noget, der lytter på den port. Læs søgelisten i stedet for at gætte, fordi en klient kan tilføje mere end ét domæne, og rækkefølgen afgør, hvilken kandidat der prøves først:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Erstat værtsnavnet med den bogstavelige adresse i applikationen, databaseklienten eller notesbogens URL, og gentag derefter anmodningen. Hvis fejlen forsvinder, havde du et navneproblem, og tunnelen var kun udløseren. Hvis den fortsætter, er lytteren eller ruten den næste mistænkte, og navnet var et falsk spor.

Proxyindstillinger, der fanger loopback

En systemproxy, der anvendes, når tunnelen kommer op, accepterer en anmodning til 127.0.0.1 og videresender den til en fjernproxy, der ikke aner, hvad du mente. En tom undtagelsesliste gør en lokal anmodning til en fjern, og fejlmeddelelsen siger det sjældent. Føj loopback-adresserne til undtagelseslisten for hele sessionen i stedet for for en enkelt kommando, og bekræft derefter, at værktøjet respekterer den, før du konkluderer noget om netværket.

Applikationsrammer læser deres egne miljøvariabler og nogle gange deres egen konfigurationsfil, så en undtagelse, der virker for ét værktøj, beviser intet for det næste. Browsere tilføjer en drejning: Chromium-baserede browsere omgår proxyen for loopback implicit, og et undtagelsestoken kan fjerne den adfærd. Kontroller den effektive proxybeslutning i stedet for at antage, at operativsystemets indstilling er hele historien. To kommandoer afgør det for alt, der startes fra en shell:

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

Bindingsadressen afgør, hvem der kan forbinde

En server startet på 127.0.0.1 accepterer kun forbindelser fra den maskine, hvilket normalt er den rigtige standard for udvikling. En server på 0.0.0.0 svarer på alle grænseflader, inklusive VPN-adapteren, hvilket er mere eksponering, end de fleste har til hensigt. Når den bogstavelige loopback-adresse fejler, skal du kontrollere bindingen før alt andet.

Se på den lyttende socket, og bemærk den adresse, den er bundet til, ikke kun porten. Hvis en anden enhed eller container skal nå tjenesten gennem tunnelen, bind til den specifikke grænseflade, den vil bruge, og tillad den port med vilje. Hvis kun din egen maskine har brug for den, behold den snævre binding og ret klienten i stedet for at udvide serveren. En portforwarding eller et tunnellag kan bygge bro mellem de to, men hver især tilføjer en komponent, der senere skal fejlfindes selv.

Hvor et fejlfindingsværktøj forventer LAN

Fejlfindingsværktøjer bærer antagelser, som en tunnel stille bryder. En telefonfejlfindingsbro mister sin enhed, når VPN'en fanger enhedens undernet, så genopkobling via LAN-adressen eller et kabel undgår konflikten. Et browserautomatiseringshub udløber, når hubben kun er tilgængelig via proxyen, eller når en lokal firewall dropper dens kontrolport. En fjernfejlfinder kan kræve forhøjelse og en loopback-adresse, hvor klienten har omskrevet ruten.

Identificer kontrolporten og dataport separat, da den ene ofte overlever, mens den anden ikke gør. Beslut derefter, om rettelsen hører til værktøjets konfiguration, i en rute til det undernet eller i en regel for delt tunnel. Redigering af en hosts-fil på hver udviklermaskine skalerer dårligst og glemmes først. Foretræk den indstilling, der lever med profilen, og som kan gennemgås af den, der ejer tunnelen.

Stop ved det første trin, der fejler

Arbejd dig ned gennem tre trin: opløs navnet, åbn en socket til den bogstavelige adresse, og lad derefter værktøjet oprette sin egen forbindelse. Hvert trin eliminerer et lag, så den første fejl navngiver det lag, der skal rettes, og alt derefter forbliver utestet. Skriv resultatet ned, før du ændrer noget, fordi en rettelse anvendt før målingen ikke kan skelnes fra held. Hvis det første forsøg fejler og et nyt virker, var tunnelen sandsynligvis ikke klar, da værktøjet startede.

Erstat den faste søvn med et afgrænset parathedstjek, der venter på ruten, og behold det fejlende trin i loggen, så den næste person kan se, hvor det stoppede. Et værktøj, der kommer sig af sig selv, er ikke rettet, det er heldigt, og heldet slipper op på en andens maskine. Ændr tunnelen sidst, og kun for det trin, der faktisk fejlede. Den rækkefølge er også den korteste vej tilbage til et fungerende build, fordi den forhindrer dig i at genopbygge en komponent, der aldrig var involveret.