VPN oan en localhost wurket net mear: namme, proxy of bining?

Dyn ûntwikkelingsserver antwurde in minút lyn, en no't de tunnel omheech is rint it fersyk út op in hostnamme dy'tst nea typt hast. Twa meganismen ferklearje hast elk gefal, en fan bûten ôf sjogge se itselde. In sykstafefterheaksel makket fan in koarte namme in bedriuwsnamme, wylst in proxy loopback-ferkear stjoert nei in host dy't it net berikke kin. It skieden fan dy beiden kostet ien query en sparret de firewall-regel dy'tst krekt skriuwe woe.

As localhost yn 'e bedriuwsône oplost

Kontrolearje wêr't de namme nei oplost wylst de tunnel omheech is, rin dan deselde query mei de tunnel del en fergelykje de twa antwurden. De oanwizing is in adres yn it bedriuwsberik dêr'tst 127.0.0.1 ferwachte. In record lykas localhost.mycompany.corp wint fan 'e loopback-ynfier sadree't de klant dat efterheaksel oan 'e syklist taheakket, en it fersyk reizget nei in privee host dêr't neat op dy poarte harket. Lês de syklist ynstee fan te rieden, want in klant kin mear as ien domein taheakje en de folchoarder beslút hokker kandidaat earst besocht wurdt:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Ferfang de hostnamme troch it letterlike adres yn 'e applikaasje, de databankklant of de notebook-URL, en werhelje dan it fersyk. As de flater ferdwynt, hienen jo in nammerjoch-probleem en wie de tunnel allinnich de trigger. As it oanhâldt, is de listener of de rûte de folgjende fertochte en wie de namme in falsk spoar.

Proxy-ynstellingen dy't loopback pakke

In systeemproxy dy't tapast wurdt as de tunnel omheech komt, sil in fersyk nei 127.0.0.1 akseptearje en it trochstjoere nei in fiere proxy dy't gjin idee hat watst bedoelde. In lege útsûnderingslist makket fan in lokaal fersyk in fier fersyk, en de flatermelding seit dat selden. Foegje de loopback-adressen ta oan 'e útsûnderingslist foar de hiele sesje en net foar ien opdracht, en befêstigje dan dat it ark it respektearret foardatst wat oer it netwurk konkludearret.

Applikaasjeframes lêze har eigen omjouwingsfariabelen en soms har eigen konfiguraasjebestân, dus in útsûndering dy't foar ien ark wurket bewiist neat foar it folgjende. Browsers foegje in nuânse ta: browsers op basis fan Chromium geane foar loopback ymplisyt om 'e proxy hinne, en in útsûnderingstoken kin dat gedrach fuorthelje. Kontrolearje de effektive proxy-beslissing ynstee fan oan te nimmen dat de ynstelling fan it bestjoeringssysteem it hiele ferhaal is. Twa opdrachten besljochtsje dit foar alles wat út in shell start wurdt:

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

It biningsadres beslút wa't ferbine kin

In server dy't op 127.0.0.1 start, akseptearret allinnich ferbiningen fan dat masine, wat meastentiids de juste standert is foar ûntwikkeling. In server op 0.0.0.0 antwurdet op elk ynterface, it VPN-adapter ynbegrepen, wat mear bleatstelling is as de measte minsken bedoele. As it letterlike loopback-adres mislearret, kontrolearje dan earst de bining.

Sjoch nei de harkjende socket en notearje it adres dêr't it oan bûn is, net allinnich de poarte. As in oar apparaat of in container de tsjinst troch de tunnel berikke moat, bin dan oan it spesifike ynterface dat it brûke sil en stean dy poarte bewust ta. As allinnich dyn eigen masine it nedich hat, hâld de nauwe bining en reparearje de klant ynstee fan 'e server te ferbreedzjen. In poartetrochstjoering of in tunnellaach kin de beide ferbine, mar elk foeget in komponint ta dy't letter syn eigen debugging nedich hat.

Wêr't in debugging-ark it LAN ferwachtet

Debugging-ark drage oannames dy't in tunnel stil brekt. In telefoan-debuggingbrêge ferliest syn apparaat as it VPN it subnet fan it apparaat pakt, dus opnij ferbine fia it LAN-adres of in kabel foarkomt it konflikt. In browser-automatisearringshub rint út op in timeout as de hub allinnich fia de proxy berikber is, of as in lokale firewall syn kontrôlepoarte lit falle. In fiere debugger kin ferheging en in loopback-adres freegje dêr't de klant de rûte oerskreau.

Identifisearje de kontrôlepoarte en de data-poarte apart, want faak oerlibbet de iene wylst de oare dat net docht. Beslis dan oft de reparaasje yn 'e konfiguraasje fan it ark heart, yn in rûte foar dat subnet, of yn in regel foar split-tunnel. In hosts-bestân bewurkje op elk ûntwikkelersmasine skalet it minst en wurdt it earst fergetten. Ferkies de ynstelling dy't by it profyl wennet en troch wa't de tunnel hat neisjoen wurde kin.

Stop by it earste stadium dat mislearret

Wurkje trije stadia ôf: los de namme op, iepenje in socket nei it letterlike adres, lit dan it ark syn eigen ferbining meitsje. Elk stadium eliminatet ien laach, dus de earste flater neamt de laach dy't reparearre wurde moat en alles dêrnei bliuwt ûntest. Skriuw it resultaat op foardatst wat feroarest, want in reparaasje dy't foar de mjitting tapast is, is net te ûnderskieden fan gelok. As de earste poging mislearret en in werhelling wurket, wie de tunnel wierskynlik net klear doe't it ark starte.

Ferfang de fêste wachttiid troch in beheinde klearheidskontrôle dy't op 'e rûte wachtet, en hâld it mislearjende stadium yn it logboek sadat de folgjende persoan sjocht wêr't it stoppe. In ark dat himsels werstelt is net reparearre, it hat gelok, en it gelok rint op 'e masine fan in oar ôf. Feroarje de tunnel as lêste, en allinnich foar it stadium dat echt mislearre. Dy folchoarder is ek de koartste wei werom nei in wurkjende build, want it hâldt dy tsjin in komponint wer op te bouwen dat nea belutsen wie.