OpenVPN sendte en DNS-server, men Linux ignorerer den

Den sendte DNS-server står i loggen, tunnelen er oppe, og interne navne fejler stadig. Intet er i stykker i selve afsendelsen; indstillingen nåede frem og stoppede der. En sendt DNS-indstilling er en besked til klienten, ikke en instruks til operativsystemets resolver, og overdragelsen mellem dem er hvor de fleste af disse sager ender. Fem kontroller, i rækkefølge, finder den overdragelse, der ikke skete.

Kontrol et: hvordan forbindelsen starter

Ejeren af forbindelsen afgør, hvem der kan anvende resolverindstillinger. En direkte openvpn-kommando fra en shell ejer intet ud over sin egen proces, mens en systemd-unit, NetworkManager eller en leverandørklient hver har sin egen måde at offentliggøre DNS på. Læs proceslisten og unit-navnet, før du antager noget af det.

En kommandolinjeproces er ikke automatisk en NetworkManager-forbindelse, og en NetworkManager-forbindelse er ikke automatisk det, der skrev resolv.conf. De to antagelser forklarer de fleste af de spildte timer i denne undersøgelse. Spørg, hvilken komponent der ville offentliggøre DNS for det interface, du faktisk ser.

Skriv ejeren ned, før du fortsætter. Hver senere kontrol afhænger af det.

Kontrol to: hvad resolver-linket faktisk indeholder

På en systemd-resolved-vært viser resolvectl status hvert link med dets DNS-servere og domæner. Find tunnel-linket og læs dets poster, og antag ikke, at interfacet hedder tun0, fordi nummereringen følger oprettelsesrækkefølgen. Hvis den sendte adresse mangler på linket, mislykkedes overdragelsen snarere end forespørgslen.

Hvis adressen er der, er det næste spørgsmål, hvilke domæner det link gør krav på. Et link uden domæneliste svarer kun på navne, der spørges direkte til, og det er sjældent, hvad en split-DNS-udrulning vil have. Adressen alene er nødvendig, men ikke tilstrækkelig.

Sammenlign linknavnet i resolverens output med interfacenavnet i VPN-loggen, før du drager nogen konklusion. Uoverensstemmelse der betyder normalt, at loglinjen kom fra en anden proces.

Kontrol tre: om navnerummet vælger det link

En resolver kan have den rigtige server og alligevel ikke blive spurgt. Domænet pr. link afgør, hvilke forespørgsler der går til hvilket link, og uden et routingdomæne falder det private navnerum tilbage til det, standardlinket siger. Derfor kan resolvectl query for det interne navn lykkes, mens en applikation stadig fejler. Applikationen bruger måske en helt anden resolvervej.

Kontrollér domænetildelingen, ikke kun serveradressen. Et domæne skrevet som ~corp.example er et routingdomæne, og tilden ændrer, hvordan navnet matches.

Hvis applikationen har sin egen resolver, så test med den samme mekanisme, som den bruger, i stedet for med systemværktøjet. Et forespørgselsværktøj, der omgår systemresolveren, vil lykkes uanset linkets tilstand.

Kontrol fire: én ejer, ikke to

Hvis NetworkManager allerede styrer VPN og resolverens tilstand, skaber tilføjelsen af et urelateret hook-script konkurrerende skrivere. Det hook, pakken stiller til rådighed til systemd-resolved, er en understøttet integration, og det forventer en bestemt livscyklus: script-security 2, en up-sti, up-restart, en down-sti og down-pre. De indstillinger får registrering og fjernelse til at ske på de rigtige tidspunkter i stedet for kun ved den første forbindelse.

Brug den installerede sti fra pakken i stedet for en illustrativ, der er kopieret fra en guide. Rettigheder betyder også noget, fordi hooket kører, efter at privilegierne er sænket.

At redigere en distributions resolver-script for at ændre dets outputmål registrerer én værts workaround. Det er ikke en generel reparation.

Kontrol fem: det samme resultat efter en genopkobling

Genopkobl og læs linket igen. En registrering, der vises én gang og forsvinder ved næste overgang, er den fejl, som hele denne tjekliste findes for at fange. Test efter en suspendering, efter en tvungen genopkobling og efter en genstart af resolver-tjenesten. Hver overgang afprøver en anden antagelse om rækkefølgen.

Kun når alle fem kontroller består ved en genopkobling, kan du sige, at de sendte indstillinger er i brug. Alt tidligere er et øjebliksbillede af et heldigt øjeblik.