OpenVPNek DNS zerbitzari bat bidali zuen, baina Linuxek ez du kontuan hartzen

Bidalitako DNS zerbitzaria erregistroan dago, tunela altxatuta dago eta barne-izenek huts egiten dute oraindik. Bidaltzean bertan ez dago ezer apurtuta; ezarpena iritsi eta han gelditu zen. Bidalitako DNS aukera mezu bat da bezeroarentzat, ez argibide bat sistema eragilearen resolverrarentzat, eta bien arteko transmisioa da kasu hauetako gehienak amaitzen diren tokia. Bost egiaztapenek, hurrenez hurren, gertatu ez zen transmisioa aurkitzen dute.

Lehen egiaztapena: nola hasten den konexioa

Konexioaren jabeak zehazten du norek aplika ditzakeen resolverraren ezarpenak. Shell batetik zuzenean emandako openvpn komandoak ez du ezer bere prozesua baino, eta systemd unitateak, NetworkManagerrek edo hornitzaile baten bezeroak bakoitzak bere modua du DNSa argitaratzeko. Irakurri prozesuen zerrenda eta unitatearen izena horietako edozein suposatu aurretik.

Komando-lerroko prozesua ez da automatikoki NetworkManager konexio bat, eta NetworkManager konexio bat ez da automatikoki resolv.conf idatzi zuena. Bi suposizio horiek azaltzen dituzte ikerketa honetan galdutako ordu gehienak. Galdetu zein osagaik argitaratuko lukeen DNSa benetan ikusten duzun interfazearentzat.

Idatzi jabeari aurrera egin aurretik. Ondorengo egiaztapen bakoitza beraren mende dago.

Bigarren egiaztapena: zer daukan resolverraren estekak benetan

systemd-resolved ostalari batean, resolvectl status bidez esteka bakoitza zerrendatzen da bere DNS zerbitzariekin eta domeinuekin. Aurkitu tunelaren esteka eta irakurri bere sarrerak, eta ez suposatu interfazearen izena tun0 denik, zenbakitzeak sorrera-ordena jarraitzen baitu. Bidalitako helbidea estekan ez badago, transmisioak huts egin du, ez kontsultak.

Helbidea badago, hurrengo galdera da esteka horrek zein domeinu aldarrikatzen dituen. Domeinu-zerrendarik gabeko esteka zuzenean galdetzen zaizkion izenei erantzuten die soilik, eta hori gutxitan da split-DNS inplementazio batek nahi duena. Helbidea bakarrik nahitaezkoa da, baina ez da nahikoa.

Ondorio bat atera aurretik, konparatu estekaren izena resolverraren irteeran VPNaren erregistroko interfazearen izenarekin. Han desadostasuna egoteak esan nahi du normalean erregistro-lerroa beste prozesu batetik etorri zela.

Hirugarren egiaztapena: izen-espazioak esteka hori hautatzen ote duen

Resolver batek zerbitzari egokia eduki dezake eta hala ere ez zaio kontsultarik egiten. Estekako domeinuak erabakitzen du zein kontsulta zein estekara doan, eta bideratze-domeinurik gabe izen-espazio pribatuak lehenespen-estekak dioenera egiten du atzera. Horregatik, resolvectl query erabiliz barne-izenarentzat arrakasta izan dezake aplikazioak oraindik huts egiten duen bitartean. Baliteke aplikazioak resolver bide erabat desberdina erabiltzea.

Egiaztatu domeinu-esleipena, ez soilik zerbitzariaren helbidea. ~corp.example gisa idatzitako domeinua bideratze-domeinu bat da, eta tiletak izena nola parekatzen den aldatzen du.

Aplikazioak bere resolver propioa badu, probatu berak erabiltzen duen mekanismo berarekin, eta ez sistemaren tresnarekin. Sistemaren resolverra saihesten duen kontsulta-tresna bat arrakastatsua izango da estekaren egoera edozein dela ere.

Laugarren egiaztapena: jabe bat, ez bi

NetworkManagerrek jadanik VPNa eta resolverraren egoera kudeatzen baditu, erlaziorik gabeko hook script bat gehitzeak idazle lehiakideak sortzen ditu. Paketeak systemd-resolvedentzat hornitzen duen hooka onartutako integrazioa da, eta bizi-ziklo zehatz bat espero du: script-security 2, up bidea, up-restart, down bidea eta down-pre. Aukera horiek erregistroa eta kentzea une egokietan gertarazten dituzte, eta ez lehen konexioan soilik.

Erabili paketetik instalatutako bidea, gidatik kopiatutako adibide batena beharrean. Baimenek ere garrantzia dute, hooka pribilegioak jaitsi ondoren exekutatzen baita.

Distribuzioaren resolver script bat editatu irteera-helburua aldatzeko ostalari bakarreko konponbidea erregistratzea da. Ez da konponketa orokorra.

Bosgarren egiaztapena: emaitza bera berriro konektatu ondoren

Konektatu berriro eta irakurri esteka berriro. Behin agertu eta hurrengo trantsizioan desagertzen den erregistro bat da zerrenda oso hau existitzeko arrazoia den hutsegitea. Probatu suspenditu ondoren, derrigorrezko berriro konexio baten ondoren eta resolver zerbitzua berrabiarazi ondoren. Trantsizio bakoitzak ordena-suposizio desberdin bat probatzen du.

Berriro konektatzean bost egiaztapenek gainditzen dutenean soilik esan dezakezu bidalitako ezarpenak erabiltzen ari direla. Lehenagoko edozein gauza une zoriontsu baten argazkia da.