OpenVPN stuur ’n DNS-bediener, maar Linux ignoreer dit

Die gestuurde DNS-bediener staan in die log, die tonnel is op, en interne name misluk steeds. Niks is verkeerd met die stuur self nie; die instelling het aangekom en daar gestop. ’n Gestuurde DNS-opsie is ’n boodskap aan die kliënt, nie ’n opdrag aan die bedryfstelsel se resolver nie, en die oorhandiging tussen hulle is waar die meeste van hierdie gevalle eindig. Vyf kontroles, in volgorde, vind die oorhandiging wat nie gebeur het nie.

Kontrole een: hoe die verbinding begin

Die eienaar van die verbinding bepaal wie resolver-instellings kan toepas. ’n Direkte openvpn-opdrag uit ’n dop besit niks buiten sy eie proses nie, terwyl ’n systemd-eenheid, NetworkManager of ’n verskaffer-kliënt elk sy eie manier het om DNS te publiseer. Lees die proseslys en die eenheidsnaam voordat jy enigeen daarvan aanvaar.

’n Opdragreëlproses is nie outomaties ’n NetworkManager-verbinding nie, en ’n NetworkManager-verbinding is nie outomaties die ding wat resolv.conf geskryf het nie. Daardie twee aannames veroorsaak die meeste van die vermorste ure in hierdie ondersoek. Vra watter komponent DNS vir die koppelvlak wat jy werklik sien, sou publiseer.

Skryf die eienaar neer voordat jy voortgaan. Elke latere kontrole hang daarvan af.

Kontrole twee: wat die resolver-skakel werklik hou

Op ’n systemd-resolved-gasheer lys resolvectl status elke skakel met sy DNS-bediener en domeine. Vind die tonnel-skakel en lees sy inskrywings, en moenie aanneem die koppelvlak heet tun0 nie, want nommering volg die volgorde van skepping. As die gestuurde adres by die skakel ontbreek, het die oorhandiging misluk eerder as die navraag.

As die adres daar is, is die volgende vraag watter domeine daardie skakel opeis. ’n Skakel sonder ’n domeinlys antwoord net name waarvoor dit direk gevra word, wat selde is wat ’n split-DNS-ontplooiing wil hê. Die adres alleen is nodig maar nie voldoende nie.

Vergelyk die skakelnaam in die resolver-uitset met die koppelvlaknaam in die VPN-log voordat jy enige gevolgtrekking maak. ’n Wanverhouding daar beteken gewoonlik dat die logreël van ’n ander proses gekom het.

Kontrole drie: of die naamruimte daardie skakel kies

’n Resolver kan die regte bediener hou en steeds nie geraadpleeg word nie. Die domein per skakel bepaal watter navrae na watter skakel gaan, en sonder ’n roeteringsdomein val die private naamruimte terug op wat die verstek-skakel sê. Dit is waarom resolvectl query vir die interne naam kan slaag terwyl ’n toepassing steeds misluk. Die toepassing gebruik dalk heeltemal ’n ander resolver-pad.

Kontroleer die domeintoewysing, nie net die bedieneradres nie. ’n Domein geskryf as ~corp.example is ’n roeteringsdomein, en die tilde verander hoe die naam gepas word.

As die toepassing sy eie resolver het, toets met dieselfde meganisme wat dit gebruik eerder as met die stelselgereedskap. ’n Navraaggereedskap wat die stelselresolver omseil, sal slaag ongeag die skakeltoestand.

Kontrole vier: een eienaar, nie twee nie

As NetworkManager reeds die VPN en die resolver-toestand bestuur, skep die byvoeging van ’n onverwante haak-skrip mededingende skrywers. Die pakket-voorsiene haak vir systemd-resolved is ’n ondersteunde integrasie, en dit verwag ’n spesifieke lewensiklus: script-security 2, ’n up-pad, up-restart, ’n down-pad en down-pre. Daardie opsies laat registrasie en verwydering op die regte oomblikke gebeur eerder as net by die eerste verbinding.

Gebruik die geïnstalleerde pad uit die pakket eerder as ’n illustratiewe een wat uit ’n gids gekopieer is. Toestemmings maak ook saak, want die haak loop nadat voorregte gedaal het.

Om ’n verspreidingsresolver-skrip te redigeer om sy uitvoerteiken te verander, teken een gasheer se werkwyse op. Dit is nie ’n algemene herstelling nie.

Kontrole vyf: dieselfde resultaat ná ’n herverbinding

Herverbind en lees die skakel weer. ’n Registrasie wat een keer verskyn en by die volgende oorgang verdwyn, is die faling waarvoor hierdie hele kontrolelys bestaan. Toets ná ’n slaap, ná ’n gedwonge herverbinding en ná ’n herstart van die resolver-diens. Elke oorgang oefen ’n ander ordeningsaanname.

Eers wanneer al vyf kontroles by ’n herverbinding slaag, kan jy sê die gestuurde instellings is in gebruik. Enigiets vroeër is ’n momentopname van ’n gelukkige oomblik.