VPN aan en localhost werkt niet meer: naam, proxy of binding?

Uw ontwikkelserver antwoordde een minuut geleden, en nu de tunnel staat loopt het verzoek in een time-out met een hostnaam die u nooit hebt getypt. Twee mechanismen verklaren bijna elk geval, en van buitenaf lijken ze identiek. Een zoeksuffix maakt van een korte naam een bedrijfsnaam, terwijl een proxy loopbackverkeer naar een host stuurt die het niet kan bereiken. De twee scheiden kost één query en spaart de firewallregel die u op het punt stond te schrijven.

Wanneer localhost in de bedrijfszone resolvet

Controleer waarop de naam resolvet terwijl de tunnel staat, voer daarna dezelfde query uit met de tunnel neer en vergelijk de twee antwoorden. De aanwijzing is een adres in het bedrijfsbereik waar u 127.0.0.1 verwachtte. Een record als localhost.mycompany.corp wint van de loopback-regel zodra de client dat suffix aan de zoeklijst toevoegt, en het verzoek reist naar een privéhost waar niets op die poort luistert. Lees de zoeklijst in plaats van te gissen, want een client kan meer dan één domein toevoegen en de volgorde bepaalt welke kandidaat eerst wordt geprobeerd:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Vervang de hostnaam door het letterlijke adres in de applicatie, de databaseclient of de notebook-URL en herhaal daarna het verzoek. Verdwijnt de fout, dan had u een naamprobleem en was de tunnel alleen de trigger. Blijft hij, dan is de listener of de route de volgende verdachte en was de naam een dwaalspoor.

Proxyinstellingen die loopback vangen

Een systeemproxy die wordt toegepast wanneer de tunnel opkomt, accepteert een verzoek naar 127.0.0.1 en stuurt het door naar een externe proxy die geen idee heeft wat u bedoelde. Een lege uitzonderingenlijst maakt van een lokaal verzoek een extern verzoek, en de foutmelding zegt dat zelden. Voeg de loopbackadressen voor de hele sessie aan de uitzonderingenlijst toe en niet voor één commando, en bevestig daarna dat de tool zich eraan houdt voordat u iets over het netwerk concludeert.

Applicatieframeworks lezen hun eigen omgevingsvariabelen en soms hun eigen configuratiebestand, dus een uitzondering die voor de ene tool werkt bewijst niets voor de volgende. Browsers voegen een nuance toe: op Chromium gebaseerde browsers omzeilen de proxy voor loopback impliciet, en een uitzonderingstoken kan dat gedrag weghalen. Controleer de werkelijke proxybeslissing in plaats van aan te nemen dat de instelling van het besturingssysteem het hele verhaal is. Twee commando's beslechten het voor alles wat vanuit een shell wordt gestart:

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

Het bindadres bepaalt wie verbinding kan maken

Een server die op 127.0.0.1 start, accepteert alleen verbindingen van die machine, wat voor ontwikkeling meestal de juiste standaard is. Een server op 0.0.0.0 antwoordt op elke interface, inclusief de VPN-adapter, wat meer blootstelling is dan de meeste mensen bedoelen. Als het letterlijke loopbackadres faalt, controleer dan eerst de binding.

Kijk naar de luisterende socket en noteer het adres waaraan hij is gebonden, niet alleen de poort. Moet een ander apparaat of een container de dienst via de tunnel bereiken, bind dan aan de specifieke interface die hij zal gebruiken en sta die poort bewust toe. Heeft alleen uw eigen machine hem nodig, houd dan de nauwe binding en repareer de client in plaats van de server te verbreden. Een port forward of een tunnellaag kan beide verbinden, maar elk voegt een component toe die later zijn eigen debugging nodig heeft.

Waar een debuggingtool het LAN verwacht

Debuggingtools dragen aannames die een tunnel stilzwijgend breekt. Een telefoon-debugbrug verliest zijn apparaat wanneer de VPN het subnet van het apparaat vangt, dus opnieuw verbinden via het LAN-adres of een kabel voorkomt het conflict. Een browserautomatiseringshub loopt in een time-out wanneer de hub alleen via de proxy bereikbaar is, of wanneer een lokale firewall de controlepoort laat vallen. Een remote debugger kan verhoging en een loopbackadres eisen waar de client de route heeft herschreven.

Identificeer de controlepoort en de datapoort apart, want vaak overleeft de ene terwijl de andere dat niet doet. Beslis dan of de correctie bij de configuratie van de tool hoort, bij een route voor dat subnet of bij een regel voor split-tunneling. Een hosts-bestand op elke ontwikkelmachine bewerken schaalt het slechtst en wordt het eerst vergeten. Geef de voorkeur aan de instelling die met het profiel meeleeft en door wie dan ook die de tunnel bezit kan worden nagekeken.

Stop bij de eerste fase die faalt

Werk drie fasen af: los de naam op, open een socket naar het letterlijke adres en laat de tool daarna zijn eigen verbinding maken. Elke fase elimineert één laag, dus de eerste fout noemt de laag die gerepareerd moet worden en alles daarna blijft ongetest. Schrijf het resultaat op voordat u iets verandert, want een correctie die vóór de meting is toegepast valt niet van geluk te onderscheiden. Als de eerste poging faalt en een nieuwe poging werkt, was de tunnel waarschijnlijk niet gereed toen de tool startte.

Vervang de vaste slaap door een begrensde gereedheidscontrole die op de route wacht, en houd de fase die faalt in het log zodat de volgende persoon ziet waar het stopte. Een tool die zichzelf herstelt is niet gerepareerd, hij heeft geluk, en het geluk raakt op op iemands anders machine. Wijzig de tunnel als laatste, en alleen voor de fase die echt faalde. Die volgorde is ook de kortste weg terug naar een werkende build, want hij houdt u tegen een component opnieuw te bouwen die nooit betrokken was.