VPN aan en localhost werk nie meer nie: naam, proxy of binding?

Jou ontwikkelingsbediener het 'n minuut gelede geantwoord, en nou dat die tonnel op is, val die versoek uit met 'n gasheernaam wat jy nooit getik het nie. Twee meganismes verklaar byna elke geval, en van buite lyk hulle identies. 'n Soekagtervoegsel verander 'n kort naam in 'n korporatiewe een, terwyl 'n proxy loopback-verkeer na 'n gasheer stuur wat dit nie kan bereik nie. Om die twee te skei kos een navraag en spaar die vuurmuurreël wat jy op die punt was om te skryf.

Wanneer localhost in die korporatiewe sone resolve

Kyk waarna die naam resolve terwyl die tonnel op is, en voer dan dieselfde navraag uit met dit af en vergelyk die twee antwoorde. Die verraaier is 'n adres in die korporatiewe reeks waar jy 127.0.0.1 verwag het. 'n Rekord soos localhost.mycompany.corp wen bo die loopback-inskrywing sodra die kliënt daardie agtervoegsel by die soeklys voeg, en die versoek reis na 'n private gasheer met niks wat op daardie poort luister nie. Lees die soeklys eerder as om te raai, want 'n kliënt kan meer as een domein byvoeg en die volgorde besluit watter kandidaat eerste probeer word:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Vervang die gasheernaam met die letterlike adres in die toepassing, die databasis-kliënt of die notaboek-URL, en herhaal dan die versoek. As die fout verdwyn, het jy 'n naamprobleem gehad en die tonnel was net die sneller. As dit voortduur, is die luisteraar of die roete die volgende verdagte en was die naam 'n misleiding.

Proxy-instellings wat loopback vang

'n Stelselproxy wat toegepas word wanneer die tonnel opkom, sal 'n versoek vir 127.0.0.1 aanvaar en dit na 'n afgeleë proxy stuur wat geen idee het wat jy bedoel het nie. 'n Leë bypass-lys verander 'n plaaslike versoek in 'n afgeleë een, en die foutboodskap sê dit selde. Voeg die loopback-adresse by die bypass-lys vir die hele sessie eerder as vir 'n enkele opdrag, en bevestig dan dat die gereedskap dit respekteer voordat jy enigiets oor die netwerk aflei.

Toepassingsraamwerke lees hul eie omgewingsveranderlikes en soms hul eie konfigurasielêer, so 'n bypass wat vir een stuk gereedskap werk, bewys niks vir die volgende nie. Blaaiers voeg 'n kinkel by: Chromium-gebaseerde blaaiers omseil die proxy vir loopback implisiet, en 'n bypass-teken kan daardie gedrag verwyder. Kontroleer die effektiewe proxy-besluit eerder as om te aanvaar dat die bedryfstelsel-instelling die hele storie is. Twee opdragte besleg dit vir enigiets wat uit 'n dop gestart word:

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

Bindingsadres besluit wie kan verbind

'n Bediener wat op 127.0.0.1 begin is, aanvaar net verbindings van daardie masjien, wat gewoonlik die regte verstek vir ontwikkeling is. 'n Bediener op 0.0.0.0 antwoord op elke koppelvlak, die VPN-adapter ingesluit, wat meer blootstelling is as wat die meeste mense bedoel. Wanneer die letterlike loopback-adres misluk, kyk eerste na die binding.

Kyk na die luisterende sokkel en let op die adres waaraan dit gebind is, nie net die poort nie. As 'n ander toestel of 'n houer die diens deur die tonnel moet bereik, bind aan die spesifieke koppelvlak wat dit sal gebruik en laat daardie poort doelbewus toe. As net jou eie masjien dit nodig het, hou die nou binding en maak die kliënt reg eerder as om die bediener te verbreed. 'n Poortaanstuur of 'n tonnellaag kan die twee oorbrug, maar elkeen voeg 'n komponent by wat later sy eie debugging sal nodig hê.

Waar 'n ontfoutingsgereedskap die LAN verwag

Ontfoutingsgereedskap dra aannames wat 'n tonnel stilweg breek. 'n Foon-ontfoutingsbrug verloor sy toestel wanneer die VPN die toestel se subnet vang, so om weer deur die LAN-adres of 'n kabel te verbind vermy die konflik. 'n Blaaier-outomatiseringshub val uit wanneer die hub net deur die proxy bereikbaar is, of wanneer 'n plaaslike vuurmuur sy beheerpoort laat val. 'n Afgeleë ontfouter kan verhoging en 'n loopback-adres eis waar die kliënt die roete herskryf het.

Identifiseer die beheerpoort en die datapoort afsonderlik, want een oorleef dikwels terwyl die ander nie. Besluit dan of die regstelling in die gereedskap se konfigurasie hoort, in 'n roete vir daardie subnet, of in 'n split-tonnel-reël. Om 'n hosts-lêer op elke ontwikkelaarmasjien te redigeer skaal die slegste en word eerste vergeet. Verkies die instelling wat by die profiel woon en deur wie ook al die tonnel besit, nagegaan kan word.

Stop by die eerste stadium wat misluk

Werk deur drie stadiums: resolve die naam, maak 'n sokkel na die letterlike adres oop, en laat dan die gereedskap sy eie verbinding maak. Elke stadium skakel een laag uit, so die eerste mislukking noem die laag om reg te maak en alles daarna bly ongetoets. Skryf die resultaat neer voordat jy enigiets verander, want 'n regstelling wat voor die meting toegepas is, kan nie van geluk onderskei word nie. As die eerste poging misluk en 'n herpoging werk, was die tonnel waarskynlik nie gereed toe die gereedskap begin het nie.

Vervang die vaste slaap met 'n begrensde gereedheidskontrole wat vir die roete wag, en hou die mislukte stadium in die log sodat die volgende persoon sien waar dit gestop het. 'n Gereedskap wat vanself herstel, is nie reggemaak nie, dit is gelukkig, en die geluk raak op iemand anders se masjien op. Verander die tonnel laaste, en net vir die stadium wat werklik misluk het. Daardie volgorde is ook die kortste pad terug na 'n werkende bou, want dit keer dat jy 'n komponent herbou wat nooit betrokke was nie.