OpenVPN sende ein DNS-tenar, men Linux overser han
Den sende DNS-tenaren står i loggen, tunnelen er oppe, og interne namn feilar framleis. Kontroller lenkja til resolvaren og vel éin eigar av sambandet.
Den sende DNS-tenaren står i loggen, tunnelen er oppe, og interne namn feilar framleis. Ingenting er øydelagt i sjølve sendinga; innstillinga kom fram og stoppa der. Eit sendt DNS-val er ei melding til klienten, ikkje ei instruks til resolvaren i operativsystemet, og overleveringa mellom dei er der dei fleste av desse sakene endar. Fem kontrollar, i rekkjefølgje, finn overleveringa som ikkje skjedde.
Kontroll éin: korleis sambandet startar
Eigaren av sambandet avgjer kven som kan bruke resolvarinnstillingar. Ein direkte openvpn-kommando frå eit skal eig ingenting utover sin eigen prosess, medan ei systemd-eining, NetworkManager eller ein leverandørklient kvar har sin eigen måte å publisere DNS på. Les prosesslista og namnet på eininga før du går ut frå noko av det.
Ein kommandolinjeprosess er ikkje automatisk eit NetworkManager-samband, og eit NetworkManager-samband er ikkje automatisk det som skreiv resolv.conf. Dei to føresetnadene forklarer det meste av dei bortkasta timane i denne undersøkinga. Spør kva komponent som ville publisert DNS for grensesnittet du faktisk ser.
Skriv ned eigaren før du held fram. Kvar seinare kontroll er avhengig av han.
Kontroll to: kva lenkja til resolvaren faktisk inneheld
På ein systemd-resolved-vert viser resolvectl status kvar lenkje med DNS-tenarane og domena sine. Finn tunnellenkja og les oppføringane, og ikkje gå ut frå at grensesnittet heiter tun0, fordi nummereringa følgjer rekkjefølgja dei vart oppretta i. Viss den sende adressa manglar på lenkja, mislukkast overleveringa og ikkje spørjinga.
Viss adressa finst, er neste spørsmål kva domene den lenkja gjer krav på. Ei lenkje utan domeneliste svarar berre på namn ho blir spurd direkte om, og det er sjeldan det ein split-DNS-utrulling vil ha. Adressa åleine er naudsynt, men ikkje nok.
Samanlikn lenkjenamnet i utdata frå resolvaren med grensesnittnamnet i VPN-loggen før du dreg noka konklusjon. Uoverensstemming der tyder vanlegvis at logglina kom frå ein annan prosess.
Kontroll tre: om namnerommet vel den lenkja
Ein resolvar kan ha den rette tenaren og likevel ikkje bli spurd. Domenet per lenkje avgjer kva spørjingar som går til kva lenkje, og utan eit rutingsdomene fell det private namnerommet tilbake på det standardlenkja seier. Derfor kan resolvectl query for det interne namnet lukkast medan ein applikasjon framleis feilar. Applikasjonen brukar kanskje ein heilt annan resolvarveg.
Kontroller domenetildelinga, ikkje berre tenaradressa. Eit domene skrive som ~corp.example er eit rutingsdomene, og tilde-teiknet endrar korleis namnet blir jamført.
Viss applikasjonen har sin eigen resolvar, test med den same mekanismen som han brukar, i staden for med systemverktøyet. Eit spørjeverktøy som går utanom systemresolvaren, vil lukkast same kva tilstand lenkja er i.
Kontroll fire: éin eigar, ikkje to
Viss NetworkManager alt styrer VPN-en og tilstanden til resolvaren, skaper eit urelatert krok-skript konkurrerande skrivarar. Kroken pakken tilbyr for systemd-resolved, er ein støtta integrasjon, og han ventar ein bestemd livssyklus: script-security 2, ein up-sti, up-restart, ein down-sti og down-pre. Desse vala gjer at registrering og fjerning skjer på dei rette tidspunkta i staden for berre ved det første sambandet.
Bruk den installerte stien frå pakken i staden for ein illustrativ ein kopiert frå ein rettleiar. Løyve tel òg, fordi kroken køyrer etter at privilegia er senka.
Å redigere eit distribusjons-resolvarskript for å endre utdatamålet registrerer omvegen til éin vert. Det er ikkje ei generell reparasjon.
Kontroll fem: same resultat etter ei attilkopling
Kopla til på nytt og les lenkja igjen. Ei registrering som viser seg éin gong og forsvinn ved neste overgang, er feilen heile denne sjekklista finst for å fange. Test etter ein suspendering, etter ei tvinga attilkopling og etter omstart av resolvartenesta. Kvar overgang prøver ein annan føresetnad om rekkjefølgja.
Berre når alle fem kontrollane går gjennom ved ei attilkopling, kan du seie at dei sende innstillingane er i bruk. Alt tidlegare er eit augeblinksbilete av eit heldig augeblikk.