Kiu ligilo respondas: enkursigaj domajnoj por DNS de VPN kun disigita tunelo

Tenu ordinaran retumiĝon sur la loka ligilo dum firmaj nomoj solviĝas per la DNS-servilo, kiun la tunelo provizas. Malŝalti la defaŭltan itineron de la VPN donas al vi la unuan duonon kaj lasas la duan nekonstruitan. Sekvas la mankanta agordo, la interpunkcio, kiu ŝanĝas ĝian signifon, kaj la ununura komando, kiu montras, kiu ligilo fakte respondis. NetworkManager kaj systemd-resolved estas supozataj tra la tuta teksto, ĉar ĝuste tiu paro estas kie la konfuzo kutime komenciĝas.

Paŝo unu: apartigu la itineron disde la solvilo

ipv4.never-default respondas al enkursiga demando kaj malhelpas NetworkManager instali ĉi tiun konekton kiel la vojon por la tuta IPv4-trafiko. DNS-enkursiga domajno respondas al alia demando: kiuj nomserviloj de kiu ligilo ricevas demando por kongrua sufikso. Neniu implicas la alian, kaj profilo povas porti unu dum jaroj sen la alia. Nur-itinero signifas, ke la tunelo portas la firmaajn subretojn kaj ĝia solvilo respondas al firmaaj nomoj, dum ĉio alia restas netuŝita.

Agordu nur la itineran econ kaj internaj nomoj malsukcesas, kutime per tempolimo, kiu sonas kiel rompita tunelo. Agordu nur la domajnon kaj vi silente aldonis serĉan sufikson al ĉiu mallonga nomo sur la maŝino. Ambaŭ eraroj sendas la bileton al la VPN-servilo, kiu malofte estas la parto, kiu malĝustas.

Paŝo du: aldonu nur-enkursigan domajnon al la profilo

Supozu, ke la konekto nomiĝas corp-vpn, la firmaa sufikso estas internal.example, kaj la solvilo de la tunelo jam estas atingebla. Unue legu la nunajn valorojn, ĉar la subaj komandoj ŝanĝas ecojn, kiuj eble jam havas enskribojn.

nmcli connection show corp-vpn | grep -E 'dns-search|never-default'
nmcli connection modify corp-vpn +ipv4.dns-search '~internal.example'
nmcli connection modify corp-vpn ipv4.never-default yes

Anstataŭigu per via propra konekta nomo kaj sufikso, ĉar la supraj valoroj estas ilustraj. La plusa signo gravas pli ol ĝi aspektas: kun ĝi la valoro aldoniĝas al la ekzistanta listo, dum sen ĝi la eco estas anstataŭata kaj nerilataj domajnoj malaperas el profilo, kiu funkciis hieraŭ. La tildo ŝanĝas konduton, ne stilon, kaj la suba paragrafo klarigas, kion ĝi elektas. Konservu la legadon antaŭ la skribado, por ke la anstataŭa formo neniam surprizu vin.

Ĉefa tildo markas nur-enkursigan domajnon, do kongruaj demandoj iras al la serviloj de ĉi tiu ligilo kaj la sufikso ne aldoniĝas al mallongaj nomoj. Forigu la tildon kaj la sama ĉeno ankaŭ fariĝas serĉa sufikso, kio estas malsama rezulto, kiun homoj malofte intencas. Ambaŭ supraj agordoj estas IPv4, do duobla-staka profilo bezonas ipv6.never-default kaj la saman enkursigan domajnon en ipv6.dns-search, alie la IPv6-flanko daŭre uzas la defaŭltan itineron kaj internaj nomoj malsukcesas tie.

Paŝo tri: demandu al resolvectl, kiu ligilo respondis

Rulu resolvectl status kaj legu la DNS-servilojn kaj domajnojn de ĉiu ligilo, poste rulu resolvectl query host.internal.example kontraŭ reala interna nomo, pri kiu vi rajtas demandi. La dua komando estas la sola rekta pruvo, ke la enkursiga domajno plenumas sian taskon, ĉar ĝi nomas la ligilon, kiu respondis. Statusa listo sola pruvas agordon; la demando pruvas solvon.

systemd-resolved elektas la plej bone kongruan enkursigan domajnon, do pli specifa domajno sur alia ligilo ankoraŭ povas gajni la kuradon. Se la demando revenas de ligilo, kiun vi ne atendis, legu la domajnajn listojn antaŭ ol tuŝi la DNS-servilon de la VPN. Radika domajno de ~. kongruas kun ĉio, kaj se ĝi jam ĉeestas, via specifa domajno ankoraŭ gajnas por siaj propraj nomoj, dum la ligilo respondas multe pli ol vi petis. Forigu aŭ mallarĝigu tiun radikan enskribon, kiam la intenco estis nur firmaaj nomoj.

Se la VPN-ligilo tute ne listigas DNS-servilon, la kliento neniam registris unu. Enkursiga domajno sen servilo malantaŭ ĝi malsukcesas alimaniere ol mankanta domajno, do unue riparu la registradon.

Paŝo kvar: kiam la nomo solviĝas sed la servo ne

Ĝusta respondo pruvas nur, ke la solvado funkciis, kaj la aplikaĵo ankoraŭ bezonas itineron al la adreso, kiun ĝi ricevis. Tiu itinero devas postvivi la dividitan defaŭltan itineron, kiun vi ĵus agordis, do kontrolu ĝin antaŭ ol denove kulpigi DNS. Poste kontrolu atingeblon sur la pordo de la servo, ĉar dosiera kunhavo aŭ adresara servo malsukcesas ĉe solvado, enkursigado aŭ aŭtentigado kaj produktas tre similajn mesaĝojn en ĉiu kazo. Tenu tiujn tri tavolojn aparte, kiam vi raportas la rezulton, alie la sekva persono rekontrolas DNS, kiu jam estis ĝusta.

La ŝanĝo de Samba, kiu cirkulas apud ĉi tiu demando, traktas la alirtavolon, ne la DNS-elekton. Apliki ĝin al solva fiasko de nomoj estas kiel malgranda problemo akiras duan.

Paŝo kvin: ne anstataŭigu la solvilon por ripari mankantan domajnon

Konsilo, kiu superskribas la solvilan dosieron aŭ instalas alian solvilan administrilon, solvas alian problemon. Tiuj estas ŝanĝoj de sistema integriĝo kun propraj fiaskaj reĝimoj, kaj neniu el ili aldonas enkursigan domajnon, kiu neniam estis agordita. Determinu, kiu komponanto posedas nomosolvadon sur la maŝino antaŭ ol anstataŭigi ĝin, ĉar sur NetworkManager-labortablo kun systemd-resolved tiu posedo jam estas difinita. Batali kontraŭ ĝi estas kiel funkcianta aranĝo fariĝas io, kion neniu povas reprodukti.

Ordo de laboro: konfirmu, ke la tunelo provizas solvilon, aldonu la nur-enkursigan domajnon, rekonektiĝu per la profilaj regiloj, kontrolu la respondan ligilon, poste testu la servon sur ĝia pordo. Tiu sinsekvo lasas rezulton, kiun vi povas transdoni al la sekva persono sen dua interparolo.