VPN ndezur dhe localhost nuk punon: emri, proxy apo bind?

Serveri juaj i zhvillimit u përgjigj një minutë më parë, dhe tani që tuneli është ngritur kërkesa skadon me një emër hosti që nuk e keni shtypur kurrë. Pothuajse çdo rast shpjegohet nga dy mekanizma, dhe nga jashtë duken njësoj. Prapashtesa e kërkimit e kthen një emër të shkurtër në një emër korporativ, ndërsa proxy dërgon trafikun loopback drejt një hosti që nuk mund ta arrijë. Ndarja e të dyjave kushton një pyetës dhe kursen rregullin e firewall-it që ishit gati të shkruanit.

Kur localhost rezolvohet në zonën korporative

Kontrolloni në çfarë rezolvohet emri ndërsa tuneli është ngritur, pastaj ekzekutoni të njëjtin pyetës me tunelin poshtë dhe krahasoni dy përgjigjet. Treguesi është një adresë në intervalin korporativ atje ku prisnit 127.0.0.1. Një regjistrim si localhost.mycompany.corp fiton mbi hyrjen loopback sapo klienti shton atë prapashtesë në listën e kërkimit, dhe kërkesa udhëton drejt një hosti privat ku asgjë nuk dëgjon në atë portë. Lexoni listën e kërkimit në vend që ta hamendësoni, sepse një klient mund të shtojë më shumë se një domen dhe radha vendos cili kandidat provohet i pari:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Zëvendësoni emrin e hostit me adresën e fjalëpërfjalshme në aplikacion, klientin e bazës së të dhënave ose URL-në e fletores, pastaj përsëritni kërkesën. Nëse dështimi zhduket, kishit një problem emërtimi dhe tuneli ishte vetëm shkas. Nëse vazhdon, dëgjuesi ose rruga është i dyshuari tjetër dhe emri ishte vetëm një gjurmë e rreme.

Cilësime proxy që kapin loopback

Një proxy sistemi i aplikuar kur tuneli ngrihet do të pranojë një kërkesë drejt 127.0.0.1 dhe do ta përcjellë te një proxy i largët që nuk e ka idenë çfarë kishit menduar. Një listë e zbrazët përjashtimesh e kthen një kërkesë lokale në të largët, dhe mesazhi i gabimit rrallë e thotë këtë. Shtoni adresat loopback në listën e përjashtimeve për të gjithë sesionin dhe jo për një komandë të vetme, pastaj konfirmoni që mjeti e respekton atë përpara se të nxirrni ndonjë përfundim për rrjetin.

Kuadrot e aplikacioneve lexojnë variablat e tyre të mjedisit dhe ndonjëherë skedarin e tyre të konfigurimit, kështu që një përjashtim që funksionon për një mjet nuk provon asgjë për tjetrin. Shfletuesit shtojnë një nuancë: shfletuesit e bazuar në Chromium anashkalojnë në mënyrë implicite proxy-n për loopback, dhe një shenjë përjashtimi mund ta heqë atë sjellje. Kontrolloni vendimin aktual të proxy-t në vend që të supozoni se cilësimi i sistemit operativ është e gjithë historia. Dy komanda e zgjidhin këtë për çdo gjë që niset nga një shell:

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

Adresa e bind-it vendos kush mund të lidhet

Një server i nisur në 127.0.0.1 pranon lidhje vetëm nga ajo makinë, që zakonisht është parazgjedhja e saktë për zhvillim. Një server në 0.0.0.0 përgjigjet në çdo ndërfaqe, përfshirë përshtatësin VPN, që është më shumë ekspozim sesa synojnë shumica e njerëzve. Kur adresa e fjalëpërfjalshme loopback dështon, kontrolloni bind-in përpara çdo gjëje tjetër.

Shikoni socket-in që dëgjon dhe shënoni adresën me të cilën është i lidhur, jo vetëm portën. Nëse një pajisje tjetër ose një kontejner duhet ta arrijë shërbimin përmes tunelit, lidheni me ndërfaqen specifike që do të përdorë dhe lejoni atë portë me qëllim. Nëse vetëm makina juaj ka nevojë për të, mbani bind-in e ngushtë dhe rregulloni klientin në vend që të zgjeroni serverin. Një përcjellje porte ose një shtresë tunelesh mund t'i bashkojë të dyja, por secila shton një komponent që më vonë do të ketë nevojë për korrigjimin e vet.

Ku një mjet korrigjimi pret LAN-in

Mjetet e korrigjimit mbajnë supozime që një tunel i thyen në heshtje. Ura e korrigjimit të telefonit e humb pajisjen kur VPN-ja kap nënrrjetin e pajisjes, kështu që rilidhja përmes adresës LAN ose një kablli shmang konfliktin. Qendra e automatizimit të shfletuesit skadon kur qendra është e arritshme vetëm përmes proxy-t, ose kur një firewall lokal e hedh portën e kontrollit. Një korrigjues i largët mund të kërkojë ngritje dhe një adresë loopback atje ku klienti rishkroi rrugën.

Identifikoni portën e kontrollit dhe portën e të dhënave veçmas, sepse shpesh njëra mbijeton ndërsa tjetra jo. Pastaj vendosni nëse rregullimi i përket konfigurimit të mjetit, një rruge për atë nënrrjet apo një rregulli të tunelit të ndarë. Redaktimi i një skedari hosts në çdo makinë zhvilluesi shkallëzohet më keq dhe harrohet i pari. Preferoni cilësimin që jeton me profilin dhe që mund të rishikohet nga kushdo që zotëron tunelin.

Ndaloni në fazën e parë që dështon

Zbrisni nëpër tre faza: rezolvoni emrin, hapni një socket drejt adresës së fjalëpërfjalshme, pastaj lërini mjetin të bëjë lidhjen e vet. Çdo fazë eliminon një shtresë, kështu që dështimi i parë emërton shtresën që duhet rregulluar dhe gjithçka pas tij mbetet e paprovuar. Shkruani rezultatin përpara se të ndryshoni gjë, sepse një rregullim i aplikuar përpara matjes nuk dallohet nga fati. Nëse përpjekja e parë dështon dhe një përsëritje funksionon, tuneli me gjasë nuk ishte gati kur u nis mjeti.

Zëvendësoni pritjen fikse me një kontroll të kufizuar gatishmërie që pret rrugën, dhe mbani fazën që dështon në regjistër që personi tjetër të shohë ku u ndal. Një mjet që shërohet vetë nuk është rregulluar, ai ka fat, dhe fati mbaron në makinën e dikujt tjetër. Ndryshoni tunelin i fundit, dhe vetëm për fazën që dështoi vërtet. Ai rend është edhe rruga më e shkurtër përsëri drejt një ndërtimi që punon, sepse ju ndalon të rindërtoni një komponent që nuk ishte kurrë i përfshirë.