Barne-izenek VPN-an huts egiten dute, kanpoko guneak irekitzen diren bitartean

Erabiltzaile batek salatzen du intraneteko ostalari-izena ez dela VPN bidez ebazten. Bigarren txosten batek, ordenagailu beretik, dio ihes-proba batek oraindik erakusten dituela ebazle lokalak erantzundako kontsultak. Arazo bakarra dirudite eta bi dira, froga ezberdinekin, eta lehenengoaren konponketa ohikoak bigarrena okertzen du. Banandu itzazu edozein ezarpen ukitu aurretik.

Bi sintoma, hutsegite bakarra ez direnak

Barne-izen bat ebatzi ezin izateak esan nahi du galdera erantzunik ez duen tokira joan zela. Kontsultek tunela uzten dutenean esan nahi du galdera toki okerrean amaitu zela erantzuna eskuragarri zegoenean ere. Kontrako hutsegiteak dira: bat falta den erantzuna da, bestea gehiegizko helmuga.

Tranpa da bulegoko ebazlea leku guztietan gehitzeak lehenengoa konpontzen duela eta bigarrena bermatzen duela. Ebazle publikoa leku guztietan gehitzeak kontrakoa egiten du.

Idatzi bi behaketak denbora-markarekin eta gero joan beheko lau egiaztapenak ordenan.

Zein egokigailuren ebazlek jasotzen duen galdera

Windows-en DNS bezeroak zerbitzariak aukeratzen ditu egokigailuen lotura-ordena arabera, eta tunelaren egokigailua ez da automatikoki lehena. Ireki egokigailuaren ezarpen aurreratuak eta mugitu urruneko sarbideko konexioa egokigailu fisikoaren gainera, gero berriz konektatu aldaketak saio berri batean balio dezan.

Lotura-ordena lehen erdia baino ez da. Bezeroak jakin behar du zein izen dagozkion egokigailu horri, eta hori atzizkiaren kontua da, ez ordenarena.

Jarri funtzionatzen duen makinaren ipconfig /all irteera eramangailuarenaren ondoan, biak tunela altxatuta hartuta. Funtzionatzen duen makina bulegoko egokigailuan konexioaren berariazko DNS atzizkia erakutsiko du, eta eramangailuak agian bat ere ez tunelan. Alde horrek azaltzen du zerbitzaria hor bertan dago eta izenak huts egiten jarraitzen du motako txostenen klase oso bat, atzizkirik gabe izen laburra ez baita inoiz osatzen bulegoko ebazleak zerbitzatzen duen eremura arte.

Izen laburrak atzizki bat behar du bide bat baino lehen

Kalifikatu gabeko ostalari-izena idazteak ebazleari domeinu bat asmatzeko eskatzen dio. Asmakizuna konexioari lotutako atzizki-zerrendatik dator, eta zerrenda hori hutsik badago kontsulta etiketa bakar gisa irteten da, inongo eremu pribatuk bat egingo ez duena.

Kopiatu funtzionatzen duen makinaren atzizkia VPN egokigailuaren IPv4 propietateetara DNS fitxan, eta berriz konektatu. Linux-en baliokidea tunel-estekaren bilaketa-domeinua da, systemd-resolved-ek esteka bakoitzeko erakusten duena, ez orokorrean.

Eduki bi ezarpenak bereizita zure oharretan. Atzizkiak aldatzen du zer galdetzen den; ebazlearen helbideak aldatzen du nori galdetzen zaion. Bata konpontzeak bestea oker dagoela emaitza ausazkoa dirudiena ematen du.

Galdetu ebazleari zuzenean, gero izenari

Bulegoko ebazleari zuzendutako kontsulta zuzena izenaren arazoa bidearen arazotik bereizten du, bezeroaren ebazle-hautaketa erabat saihesten duelako.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Lehenengo komandoak zerbitzari jakin bati galdetzen dio erabat kalifikatutako izen bat. Erantzuten badu, ebazlea eta hara doan bidea ondo daude eta hutsegitea hautaketan edo atzizkian dago. Denbora agortzen bada, helbidea okerra edo iristezina da eta arazoa bideratzean dago, ez DNSean. Bigarren komandoak izen laburrarekin zer gertatzen den erakusten du, eta hirugarrenak esteka bakoitzeko ebazle-konfigurazioa inprimatzen du systemd duen ostalari batean.

Begiratu eremu-komodin erantzunei, sare batzuek izen ezezagunetarako itzultzen dituztenak. Erantzun sinesgarri batek ez du frogatzen nahi zen zerbitzaria erantzun zuenik, beraz konparatu itzulitako helbidea barne-zerbitzuak benetan erabiltzen duenarekin. Helbidea aparkaleku-orri batena edo proxy batena bada, ebazleak erantzun zuen baina erantzuna ez zen inoiz zurea. Bereizketa horrek ordu bat aurrezten du denbora osoan funtzionatzen ari zen tunel baten atzetik.

Linux-en, /etc/resolv.conf berridazten duen VPN bezeroak tokiko ebazleak erabat ordezkatzen ditu. vpnc-k DNSUpdate no erakusten du hori eragozteko, eta systemd-resolved-ek zerrendatutako domeinuak soilik bidera ditzake tunel-estekara. Bi ikuspegi horiek izen publikoak tokiko ebazlean mantentzen dituzte eta barne-izenak bulegora bidaltzen dituzte.

Ihesak araua dira, ez kontrol-laukia

Izen-ebazpena 53 porturako UDP trukea da, beraz web trafikoa baina UDP eramaten ez duen tunelak kontsulta bide fisikoan uzten du. Frogatu hori txartel fisikoan harrapatuz izen publiko bat ebazten ari den bitartean. Interfaze horretan irakurgarri ikusten den kontsulta batek esan nahi du tunelak ez duela eramaten.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

Kontsulta interfaze horretan irakurgarri agertzen bada, tunelak ez du eramaten. Konponbidea 53 portua VPNak bultzatutako ebazleari soilik uzten dion eta beste helmugak baztertzen dituen araua da, gehi bultzatutako aukera isilpean baztertzen ez duen bezero-konfigurazioa.

Azken zati horrek uste baino gehiago balio du. Abiarazi OpenVPN route-nopull ezarpenarekin eta bultzatutako DNS aukera desagertzen da bideekin batera, tiraketa-iragazkia zabaltzen ez bada hura mantentzeko. Eta dhcp-option DNS alde batera uzten duen bezeroak aurretik zuena erabiltzen jarraituko du. Zerbitzariaren aldeko edozein aldaketak saio berria behar du indarrean jartzeko, ebazleen zerrenda tunela altxatzean ematen delako eta saio zaharrak egoera zaharra erakusten jarraitzen duelako.

Idatzi zein hutsegite ikusi duzun benetan tiketa itxi aurretik. Falta den barne-erantzunak eta tunelatik ihes egiten duen kontsultak konponketa ezberdinak eskatzen dituzte, eta lehenengoa konpontzen duen atzizki-aldaketak bigarrena isilpean okertu dezake. Tiketa geroago hartzen duenak etiketari egingo dio kasu, beraz egin etiketa zehatza.