VPN ŝaltita kaj localhost ĉesas funkcii: nomo, prokurilo aŭ bindado?

Via evolua servilo respondis antaŭ minuto, kaj nun, kiam la tunelo staras, la peto tempolimas kun gastigantnomo, kiun vi neniam tajpis. Du mekanismoj klarigas preskaŭ ĉiun kazon, kaj de ekstere ili aspektas identaj. Serĉa sufikso ŝanĝas mallongan nomon en firmaan, dum prokurilo sendas buklan trafikon al gastiganto, kiu ne povas atingi ĝin. Apartigi la du kostas unu peton kaj ŝparas la fajroŝirmilan regulon, kiun vi ĵus pretis skribi.

Kiam localhost solviĝas en la firmaan zonon

Kontrolu, al kio la nomo solviĝas dum la tunelo staras, poste rulu la saman peton kun ĝi malŝaltita kaj komparu la du respondojn. La signo estas adreso en la firmaa gamo tie, kie vi atendis 127.0.0.1. Rikordo kiel localhost.mycompany.corp venkas la buklan rikordon tuj kiam la kliento aldonas tiun sufikson al la serĉlisto, kaj la peto vojaĝas al privata gastiganto, kie nenio aŭskultas sur tiu pordo. Legu la serĉliston anstataŭ diveni, ĉar kliento povas aldoni pli ol unu domajnon kaj la ordo decidas, kiu kandidato estas provata unue:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Anstataŭigu la gastigantnomon per la laŭvorta adreso en la aplikaĵo, la datumbaza kliento aŭ la URL de la kajero, poste ripetu la peton. Se la fiasko malaperas, vi havis nomigan problemon kaj la tunelo estis nur la ellasilo. Se ĝi restas, la aŭskultanto aŭ la itinero estas la sekva suspektato kaj la nomo estis nur falsa spuro.

Prokurilaj agordoj, kiuj kaptas buklon

Sistema prokurilo aplikata kiam la tunelo supreniras akceptos peton al 127.0.0.1 kaj plusendos ĝin al fora prokurilo, kiu tute ne scias, kion vi celis. Malplena preterlista listo ŝanĝas lokan peton en foran, kaj la erarmesaĝo malofte tion diras. Aldonu la buklajn adresojn al la preterlista listo por la tuta sesio anstataŭ por unu komando, poste konfirmu, ke la ilo respektas ĝin antaŭ ol konkludi ion pri la reto.

Aplikaĵaj kadroj legas siajn proprajn mediovariablojn kaj foje sian propran agordan dosieron, do preteriro, kiu funkcias por unu ilo, pruvas nenion por la sekva. Retumiloj aldonas detalon: retumiloj bazitaj sur Chromium preteriras la prokurilon por buklo implicite, kaj preterira ĵetono povas forigi tiun konduton. Kontrolu la efektivan prokurilan decidon anstataŭ supozi, ke la agordo de la operaciumo estas la tuta rakonto. Du komandoj solvas tion por io ajn lanĉita el ŝelo:

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

La bindada adreso decidas, kiu povas konektiĝi

Servilo startigita sur 127.0.0.1 akceptas konektojn nur de tiu maŝino, kio kutime estas la ĝusta defaŭlto por evoluigo. Servilo sur 0.0.0.0 respondas sur ĉiu interfaco, inkluzive de la VPN-adaptilo, kio estas pli da elmeto ol la plej multaj intencas. Kiam la laŭvorta bukla adreso fiaskas, kontrolu la bindadon antaŭ ĉio alia.

Rigardu la aŭskultantan soketon kaj notu la adreson, al kiu ĝi estas ligita, ne nur la pordon. Se alia aparato aŭ ujo devas atingi la servon tra la tunelo, ligiĝu al la specifa interfaco, kiun ĝi uzos, kaj intence permesu tiun pordon. Se nur via propra maŝino bezonas ĝin, konservu la mallarĝan bindadon kaj riparu la klienton anstataŭ vastigi la servilon. Pordplusendo aŭ tunela tavolo povas ponti la du, sed ĉiu aldonas komponanton, kiu poste bezonos sian propran sencimigon.

Kie sencimiga ilo atendas la LAN

Sencimigaj iloj portas supozojn, kiujn tunelo kviete rompas. Telefona sencimiga ponto perdas sian aparaton kiam la VPN kaptas la subreton de la aparato, do rekonekto tra la LAN-adreso aŭ kablo evitas la konflikton. Retumila aŭtomatiga centro tempolimas kiam la centro atingeblas nur tra la prokurilo aŭ kiam loka fajroŝirmilo faligas ĝian kontrolan pordon. Fora sencimigilo povas postuli altigon kaj buklan adreson tie, kie la kliento reverkis la itineron.

Identigu la kontrolan pordon kaj la datuman pordon aparte, ĉar ofte unu postvivas dum la alia ne. Poste decidu, ĉu la riparo apartenas al la agordo de la ilo, al itinero por tiu subreto aŭ al regulo de dividita tunelo. Redakti hosts-dosieron sur ĉiu evoluiga maŝino skaliĝas plej malbone kaj estas forgesata unue. Preferu la agordon, kiu vivas kun la profilo kaj povas esti reviziata de tiu, kiu posedas la tunelon.

Haltu ĉe la unua stadio, kiu fiaskas

Laboru tra tri stadioj: solvu la nomon, malfermu soketon al la laŭvorta adreso, poste lasu la ilon fari sian propran konekton. Ĉiu stadio forigas unu tavolon, do la unua fiasko nomas la tavolon riparindan kaj ĉio poste restas netestita. Skribu la rezulton antaŭ ol ŝanĝi ion, ĉar riparo aplikita antaŭ la mezurado ne distingiĝas de bonŝanco. Se la unua provo fiaskas kaj ripeto funkcias, la tunelo verŝajne ne estis preta kiam la ilo startis.

Anstataŭigu la fiksan paŭzon per limigita preteckontrolo, kiu atendas la itineron, kaj konservu la fiaskantan stadion en la protokolo, por ke la sekva persono vidu, kie ĝi haltis. Ilo, kiu mem resaniĝas, ne estas riparita, ĝi estas bonŝanca, kaj la bonŝanco elĉerpiĝas sur la maŝino de iu alia. Ŝanĝu la tunelon laste, kaj nur por la stadio, kiu efektive fiaskis. Tiu ordo ankaŭ estas la plej mallonga vojo reen al funkcianta konstruo, ĉar ĝi malhelpas vin rekonstrui komponanton, kiu neniam partoprenis.