VPN piztuta eta localhost ez dabil: izena, proxya edo bind-a?

Zure garapen-zerbitzariak duela minutu bat erantzun zuen, eta orain tunela altxatuta dagoela eskaerak denbora-muga gainditzen du inoiz idatzi ez duzun ostalari-izen batekin. Bi mekanismok azaltzen dute ia kasu guztiak, eta kanpotik berdinak dirudite. Bilaketa-atzerizki batek izen laburra enpresako bihurtzen du, eta proxyak loopback trafikoa iritsi ezin duen ostalari batera bidaltzen du. Biak bereizteak kontsulta bat kostatzen du eta idaztear zoazen suebaki-araua aurrezten du.

Localhost zona korporatibora ebazten denean

Egiaztatu izenak zertara ebazten duen tunela altxatuta dagoen bitartean, gero exekutatu kontsulta bera tunela jaitsita eta alderatu bi erantzunak. Aurkikuntza enpresako barrutiko helbide bat da, 127.0.0.1 espero zenuen tokian. localhost.mycompany.corp bezalako erregistro batek loopback sarrera gainditzen du bezeroak atzerizki hori bilaketa-zerrendari gehitzen dion unetik, eta eskaera ataka horretan ezer entzuten ez duen ostalari pribatu batera joaten da. Irakurri bilaketa-zerrenda asmatu beharrean, bezeroak domeinu bat baino gehiago gehi ditzakeelako eta ordenak erabakitzen duelako zein hautagai probatzen den lehenengo:

getent hosts localhost
resolvectl domain
ss -ltnp | grep 8080

Ordezkatu ostalari-izena helbide literalarekin aplikazioan, datu-baseko bezeroan edo koadernoko URLan, eta gero errepikatu eskaera. Hutsegitea desagertzen bada, izenen arazoa zenuen eta tunela eragilea baino ez zen. Irauten badu, entzulea edo bidea da hurrengo susmagarria eta izena arrasto faltsua baino ez zen.

Loopback harrapatzen duten proxy ezarpenak

Tunela altxatzean aplikatzen den sistema-proxy batek 127.0.0.1 helbiderako eskaera onartuko du eta zer esan nahi zenuen ez dakin urruneko proxy batera birbidaliko du. Saihesten zerrenda huts batek tokiko eskaera urruneko bihurtzen du, eta errore-mezuak gutxitan esaten du. Gehitu loopback helbideak saihesten zerrendara saio osoan zehar eta ez komando bakarrerako, eta gero egiaztatu tresnak hori errespetatzen duela sareari buruz ezer ondorioztatu aurretik.

Aplikazio-markoek beren ingurune-aldagaiak eta batzuetan beren konfigurazio-fitxategia irakurtzen dituzte, beraz tresna batentzat funtzionatzen duen saihestenak ez du ezer frogatzen hurrengorako. Nabigatzaileek ñabardura bat gehitzen dute: Chromiumen oinarritutako nabigatzaileek proxya saihesten dute loopbackerako inplizituki, eta saihesten token batek jokaera hori ken dezake. Egiaztatu proxyaren benetako erabakia, sistema eragilearen ezarpena istorio osoa dela suposatu beharrean. Bi komandok argitzen dute hau shell batetik abiatutako edozerrentzat:

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

Bind helbideak erabakitzen du nor konekta daitekeen

127.0.0.1 helbidean abiatzen den zerbitzari batek makina horretatik soilik onartzen ditu konexioak, eta hori da normalean garapenerako lehenetsitako balio zuzena. 0.0.0.0 helbideko zerbitzari batek interfaze guztietan erantzuten du, VPN egokitzailea barne, eta hori jende gehienak nahi duen baino esposizio handiagoa da. Helbide literalak huts egiten duenean, egiaztatu bind-a beste ezer baino lehen.

Begiratu entzuten ari den socket-a eta idatzi lotuta dagoen helbidea, ez ataka bakarrik. Beste gailu batek edo edukiontzi batek zerbitzura tunelaren bidez iritsi behar badu, lotu erabiliko duen interfaze zehatzera eta baimendu ataka hori nahita. Zure makinak soilik behar badu, mantendu bind estua eta konpondu bezeroa zerbitzaria zabaldu beharrean. Ataka-birbideratze batek edo tunel-geruza batek biak zubitu ditzake, baina bakoitzak geroago bere arazketa beharko duen osagai bat gehitzen du.

Non arazketa-tresna batek LANa espero duen

Arazketa-tresnek tunel batek isilka hausten dituen suposizioak daramatzate. Telefono-arazketako zubi batek gailua galtzen du VPNak gailuaren azpisarea harrapatzen duenean, beraz LAN helbidearen edo kable baten bidez berriz konektatzeak gatazka saihesten du. Nabigatzaile-automatizazioko hub batek denbora-muga gainditzen du hub-a proxyaren bidez soilik irisgarria denean, edo tokiko suebaki batek bere kontrol-ataka uzten duenean. Urruneko araztzaile batek igotzea eta loopback helbidea eskatzen ahal ditu bezeroak bidea berridatzi zuen tokian.

Zehaztu kontrol-ataka eta datu-ataka bereizita, askotan bat bizirik irauten duelako eta besteak ez. Gero erabaki konponketa tresnaren konfigurazioan, azpisare horretarako bide batean edo tunel zatituaren arau batean dagokion. Garatzaile-makina bakoitzean hosts fitxategia editatzeak okerren eskalatzen du eta lehenengo ahazten da. Nahiago izan profilarekin bizi den eta tunelaren jabea den edonork berrikus dezakeen ezarpena.

Gelditu huts egiten duen lehen etapan

Jaitsi hiru etapatan: ebatzi izena, ireki socket bat helbide literalerantz, eta gero utzi tresnari bere konexioa egiten. Etapa bakoitzak geruza bat ezabatzen du, beraz lehen hutsegiteak konpondu beharreko geruza izendatzen du eta ondorengo guztia probatu gabe geratzen da. Idatzi emaitza ezer aldatu aurretik, neurketa baino lehen aplikatutako konponketa ezin delako zortetik bereizi. Lehen saiakerak huts egiten badu eta errepikapenak funtzionatzen badu, tunela ziurrenik ez zegoen prest tresna abiatu zenean.

Ordezkatu itxaronaldi finkoa bidea itxaroten duen prestasun-egiaztapen mugatu batekin, eta gorde huts egiten duen etapa erregistroan hurrengo pertsonak non gelditu zen ikus dezan. Bere kabuz sendatzen den tresna ez dago konponduta, zortea du, eta zortea beste norbaiten makinean agortzen da. Aldatu tunela azkenik, eta benetan huts egin zuen etaparentzat bakarrik. Ordena hori ere bide laburrena da funtzionatzen duen build batera itzultzeko, inoiz parte hartu ez zuen osagai bat berreraikitzetik gelditzen zaituelako.