VPN på och localhost slutar fungera: namn, proxy eller bindning?

Din utvecklingsserver svarade för en minut sedan, och nu när tunneln är uppe löper förfrågan ut i timeout med ett värdnamn du aldrig skrev. Två mekanismer förklarar nästan varje fall, och utifrån ser de identiska ut. Ett söksuffix gör ett kort namn till ett företagsnamn, medan en proxy skickar loopback-trafik till en värd som inte kan nå den. Att skilja de två kostar en fråga och sparar brandväggsregeln du var på väg att skriva.

När localhost resolvar in i företagszonen

Kontrollera vad namnet resolvar till medan tunneln är uppe, kör sedan samma fråga med tunneln nere och jämför de två svaren. Det avslöjande är en adress i företagsintervallet där du förväntade dig 127.0.0.1. En post som localhost.mycompany.corp vinner över loopback-posten så snart klienten lägger till suffixet i söklistan, och förfrågan reser till en privat värd där ingenting lyssnar på den porten. Läs söklistan i stället för att gissa, eftersom en klient kan lägga till mer än en domän och ordningen avgör vilken kandidat som prövas först:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Ersätt värdnamnet med den bokstavliga adressen i applikationen, databasklienten eller anteckningsbokens URL och upprepa sedan förfrågan. Om felet försvinner hade du ett namnningsproblem och tunneln var bara utlösaren. Om det kvarstår är lyssnaren eller rutten nästa misstänkta och namnet var bara ett falskt spår.

Proxyinställningar som fångar loopback

En systemproxy som tillämpas när tunneln går upp accepterar en förfrågan till 127.0.0.1 och vidarebefordrar den till en fjärrproxy som inte har en aning om vad du menade. En tom undantagslista gör en lokal förfrågan till en fjärrförfrågan, och felmeddelandet säger det sällan. Lägg till loopback-adresserna i undantagslistan för hela sessionen och inte för ett enda kommando, och bekräfta sedan att verktyget respekterar den innan du drar någon slutsats om nätverket.

Applikationsramverk läser sina egna miljövariabler och ibland sin egen konfigurationsfil, så ett undantag som fungerar för ett verktyg bevisar ingenting för nästa. Webbläsare lägger till en nyans: Chromium-baserade webbläsare kringgår proxyn för loopback implicit, och en undantagstoken kan ta bort det beteendet. Kontrollera det faktiska proxybeslutet i stället för att anta att operativsystemets inställning är hela historien. Två kommandon avgör det för allt som startas från ett skal:

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

Bindningsadressen avgör vem som kan ansluta

En server som startas på 127.0.0.1 accepterar bara anslutningar från den maskinen, vilket vanligtvis är rätt standard för utveckling. En server på 0.0.0.0 svarar på varje gränssnitt, inklusive VPN-adaptern, vilket är mer exponering än de flesta avser. När den bokstavliga loopback-adressen misslyckas, kontrollera bindningen före allt annat.

Titta på den lyssnande socketen och notera adressen den är bunden till, inte bara porten. Om en annan enhet eller container måste nå tjänsten genom tunneln, bind till det specifika gränssnitt den kommer att använda och tillåt den porten medvetet. Om bara din egen maskin behöver den, behåll den snäva bindningen och rätta klienten i stället för att vidga servern. En portvidarebefordran eller ett tunnellager kan bygga bro mellan de två, men var och en lägger till en komponent som senare behöver sin egen felsökning.

Där ett felsökningsverktyg förväntar sig LAN

Felsökningsverktyg bär antaganden som en tunnel tyst bryter. En telefonfelsökningsbrygga tappar sin enhet när VPN fångar enhetens subnät, så att återansluta via LAN-adressen eller en kabel undviker konflikten. Ett webbläsarautomatiseringsnav löper ut i timeout när navet bara nås via proxyn, eller när en lokal brandvägg tappar dess kontrollport. En fjärrfelsökare kan kräva höjning och en loopback-adress där klienten skrev om rutten.

Identifiera kontrollporten och dataporten separat, eftersom den ena ofta överlever medan den andra inte gör det. Bestäm sedan om rättelsen hör till verktygets konfiguration, i en rutt för det subnätet eller i en regel för delad tunnel. Att redigera en hosts-fil på varje utvecklarmaskin skalar sämst och glöms bort först. Föredra inställningen som lever med profilen och kan granskas av den som äger tunneln.

Stanna vid det första steget som misslyckas

Arbeta dig igenom tre steg: lös namnet, öppna en socket till den bokstavliga adressen och låt sedan verktyget skapa sin egen anslutning. Varje steg eliminerar ett lager, så det första felet namnger lagret som ska rättas och allt efter det förblir otestat. Skriv ner resultatet innan du ändrar något, eftersom en rättelse som används före mätningen inte går att skilja från tur. Om det första försöket misslyckas och ett nytt fungerar var tunneln förmodligen inte redo när verktyget startade.

Ersätt den fasta sömnen med en avgränsad beredskapskontroll som väntar på rutten, och behåll steget som misslyckas i loggen så att nästa person ser var det stannade. Ett verktyg som återhämtar sig självt är inte rättat, det har tur, och turen tar slut på någon annans maskin. Ändra tunneln sist, och bara för steget som faktiskt misslyckades. Den ordningen är också den kortaste vägen tillbaka till en fungerande build, eftersom den hindrar dig från att bygga om en komponent som aldrig var inblandad.