OpenVPN pushte een DNS-server, maar Linux negeert hem

De gepushte DNS-server staat in het log, de tunnel is op en interne namen falen nog steeds. Aan het pushen zelf mankeert niets; de instelling kwam aan en stopte daar. Een gepushte DNS-optie is een bericht aan de client, geen instructie aan de resolver van het besturingssysteem, en de overdracht daartussen is waar de meeste van deze gevallen eindigen. Vijf controles, in volgorde, vinden de overdracht die niet plaatsvond.

Controle één: hoe de verbinding begint

De eigenaar van de verbinding bepaalt wie resolverinstellingen kan toepassen. Een direct openvpn-commando uit een shell bezit niets buiten zijn eigen proces, terwijl een systemd-unit, NetworkManager of een leveranciersclient elk hun eigen manier hebben om DNS te publiceren. Lees de proceslijst en de unitnaam voordat u een van die aannames doet.

Een commandoregelproces is niet automatisch een NetworkManager-verbinding, en een NetworkManager-verbinding is niet automatisch het ding dat resolv.conf schreef. Die twee aannames verklaren het grootste deel van de verspilde uren in dit onderzoek. Vraag welke component DNS zou publiceren voor de interface die u werkelijk ziet.

Schrijf de eigenaar op voordat u verdergaat. Elke latere controle hangt ervan af.

Controle twee: wat de resolver-koppeling werkelijk bevat

Op een systemd-resolved-host vermeldt resolvectl status elke koppeling met de DNS-servers en domeinen. Zoek de tunnelkoppeling en lees de vermeldingen, en ga er niet van uit dat de interface tun0 heet, want de nummering volgt de volgorde van aanmaken. Als het gepushte adres op de koppeling ontbreekt, mislukte de overdracht en niet de query.

Als het adres aanwezig is, is de volgende vraag welke domeinen die koppeling opeist. Een koppeling zonder domeinlijst beantwoordt alleen namen waarnaar rechtstreeks wordt gevraagd, en dat is zelden wat een split-DNS-implementatie wil. Het adres alleen is nodig maar niet voldoende.

Vergelijk de koppelingsnaam in de resolver-uitvoer met de interfacenaam in het VPN-log voordat u een conclusie trekt. Een afwijking daar betekent meestal dat de logregel van een ander proces kwam.

Controle drie: of de naamruimte die koppeling kiest

Een resolver kan de juiste server hebben en toch niet worden geraadpleegd. Het domein per koppeling bepaalt welke queries naar welke koppeling gaan, en zonder routeringsdomein valt de private naamruimte terug op wat de standaardkoppeling zegt. Daarom kan resolvectl query voor de interne naam slagen terwijl een applicatie nog steeds faalt. De applicatie gebruikt mogelijk een heel ander resolverpad.

Controleer de domeintoewijzing, niet alleen het serveradres. Een domein geschreven als ~corp.example is een routeringsdomein, en de tilde verandert hoe de naam wordt gematcht.

Als de applicatie een eigen resolver heeft, test dan met hetzelfde mechanisme dat zij gebruikt in plaats van met het systeemgereedschap. Een querytool die de systeemresolver omzeilt, slaagt ongeacht de staat van de koppeling.

Controle vier: één eigenaar, niet twee

Als NetworkManager al de VPN en de resolverstatus beheert, maakt het toevoegen van een ongerelateerd hook-script concurrerende schrijvers. De hook die het pakket voor systemd-resolved levert, is een ondersteunde integratie, en verwacht een bepaalde levenscyclus: script-security 2, een up-pad, up-restart, een down-pad en down-pre. Die opties zorgen dat registratie en verwijdering op de juiste momenten gebeuren en niet alleen bij de eerste verbinding.

Gebruik het geïnstalleerde pad uit het pakket in plaats van een illustratief pad uit een handleiding. Rechten zijn ook belangrijk, want de hook draait nadat privileges zijn verlaagd.

Het bewerken van een distributie-resolverscript om het uitvoerdoel te wijzigen, legt de omweg van één host vast. Het is geen algemene reparatie.

Controle vijf: hetzelfde resultaat na opnieuw verbinden

Verbind opnieuw en lees de koppeling opnieuw. Een registratie die één keer verschijnt en bij de volgende overgang verdwijnt, is de fout waarvoor deze hele checklist bestaat. Test na een slaapstand, na een geforceerde herverbinding en na een herstart van de resolverservice. Elke overgang beproeft een andere aanname over de volgorde.

Alleen wanneer alle vijf controles bij een herverbinding slagen, kunt u zeggen dat de gepushte instellingen in gebruik zijn. Alles daarvoor is een momentopname van een gelukkig moment.