OpenVPN sendte en DNS-server, men Linux ignorerer den

Den sendte DNS-serveren står i loggen, tunnelen er oppe, og interne navn feiler fortsatt. Ingenting er ødelagt i selve sendingen; innstillingen kom frem og stoppet der. Et sendt DNS-alternativ er en melding til klienten, ikke en instruks til operativsystemets resolver, og overleveringen mellom dem er der de fleste av disse sakene ender. Fem kontroller, i rekkefølge, finner overleveringen som ikke skjedde.

Kontroll én: hvordan forbindelsen starter

Eieren av forbindelsen avgjør hvem som kan bruke resolverinnstillinger. En direkte openvpn-kommando fra et skall eier ingenting utover sin egen prosess, mens en systemd-enhet, NetworkManager eller en leverandørklient hver har sin egen måte å publisere DNS på. Les prosesslisten og enhetsnavnet før du antar noe av det.

En kommandolinjeprosess er ikke automatisk en NetworkManager-forbindelse, og en NetworkManager-forbindelse er ikke automatisk det som skrev resolv.conf. De to antakelsene forklarer det meste av de bortkastede timene i denne undersøkelsen. Spør hvilken komponent som ville publisert DNS for grensesnittet du faktisk ser.

Skriv ned eieren før du fortsetter. Hver senere kontroll avhenger av den.

Kontroll to: hva resolverens lenke faktisk inneholder

På en systemd-resolved-vert viser resolvectl status hver lenke med DNS-serverne og domenene sine. Finn tunnel-lenken og les oppføringene, og ikke anta at grensesnittet heter tun0, fordi nummereringen følger rekkefølgen de ble opprettet i. Hvis den sendte adressen mangler på lenken, mislyktes overleveringen og ikke spørringen.

Hvis adressen finnes, er neste spørsmål hvilke domener den lenken gjør krav på. En lenke uten domeneliste svarer bare på navn den blir spurt direkte om, og det er sjelden det en split-DNS-utrulling vil ha. Adressen alene er nødvendig, men ikke tilstrekkelig.

Sammenlign lenkenavnet i resolverens utdata med grensesnittnavnet i VPN-loggen før du trekker noen konklusjon. Uoverensstemmelse der betyr vanligvis at logglinjen kom fra en annen prosess.

Kontroll tre: om navnerommet velger den lenken

En resolver kan ha den riktige serveren og likevel ikke bli spurt. Domenet per lenke avgjør hvilke spørringer som går til hvilken lenke, og uten et rutingsdomene faller det private navnerommet tilbake på det standardlenken sier. Derfor kan resolvectl query for det interne navnet lykkes mens en applikasjon fortsatt feiler. Applikasjonen bruker kanskje en helt annen resolvervei.

Kontroller domenetildelingen, ikke bare serveradressen. Et domene skrevet som ~corp.example er et rutingsdomene, og tilden endrer hvordan navnet matches.

Hvis applikasjonen har sin egen resolver, test med den samme mekanismen som den bruker, i stedet for med systemverktøyet. Et spørringsverktøy som omgår systemresolveren, vil lykkes uansett lenkens tilstand.

Kontroll fire: én eier, ikke to

Hvis NetworkManager allerede styrer VPN-en og resolverens tilstand, skaper tillegg av et urelatert krok-skript konkurrerende skrivere. Kroken pakken tilbyr for systemd-resolved, er en støttet integrasjon, og den forventer en bestemt livssyklus: script-security 2, en up-sti, up-restart, en down-sti og down-pre. Disse alternativene gjør at registrering og fjerning skjer på de riktige tidspunktene i stedet for bare ved den første forbindelsen.

Bruk den installerte stien fra pakken i stedet for en illustrativ en kopiert fra en veiledning. Tillatelser betyr også noe, fordi kroken kjører etter at privilegiene er senket.

Å redigere et distribusjons-resolverskript for å endre utdatamålet registrerer én verts omvei. Det er ikke en generell reparasjon.

Kontroll fem: samme resultat etter en gjenoppkobling

Koble til på nytt og les lenken igjen. En registrering som vises én gang og forsvinner ved neste overgang, er feilen hele denne sjekklisten finnes for å fange. Test etter en suspendering, etter en tvungen gjenoppkobling og etter en omstart av resolver-tjenesten. Hver overgang prøver en annen antakelse om rekkefølgen.

Bare når alle fem kontrollene består ved en gjenoppkobling, kan du si at de sendte innstillingene er i bruk. Alt tidligere er et øyeblikksbilde av et heldig øyeblikk.