OpenVPN saadab DNS-i, kuid sinu resolver ei pruugi seda kunagi näha
DNS-i väärtus kliendi logis ei tõesta, et operatsioonisüsteemi resolver seda kasutab. Kontrolli omanikku ja seejärel testi sisemist nime.
Kliendi log näitab saadetud DNS-serverit, tunnel on ühendatud ja sisemine nimi ei lahene ikkagi. Saatmises endas pole midagi katki. Valik jõudis kohale ja operatsioonisüsteemi resolver ei kasutanud seda kunagi, sest enamikus Unixi klientides annab OpenVPN väärtuse edasi ja jätab rakenduse platvormile.
Sümptom: log näitab DNS-i ja nimed ikka ei toimi
OpenVPN dhcp-option kannab DNS-i ja domeeniinfot ning klient logib selle, mille sai. Mõnes implementatsioonis rakendab klient neid seadeid sisemiselt; teistes ekspordib need integreerimisskriptile või võrguteenusele. Logirida kirjeldab ainult loo esimest poolt. Teine pool juhtub kuskil, mida klient ei kontrolli. Just seal elab tavaliselt tõrge.
Seepärast esinevad ühendatud tunnel ja nurjuv sisemine nimi nii sageli koos. Väärtus on olemas, tarbija puudub või on valesti seadistatud, ja resolver kasutab vaikselt edasi avalikku serverit, mida kasutas enne ühendust.
Vastuvõetud ei tähenda rakendatud
Klient võib logida saadetud DNS-i väärtuse, samal ajal kui süsteemi resolver kuulub endiselt teisele teenusele. Brauseril võib olla ka oma krüpteeritud DNS-i poliitika, mis möödub süsteemi resolverist täielikult, tekitades meeldejääva olukorra, kus üks rakendus lahendab sisemisi nimesid ja teine mitte.
Kontrolli implementatsiooni toetatud integreerimist, selle asemel et eeldada, nagu iga Unixi klient kirjutaks sama faili üle. See eeldus on põhjus, miks inimesed muudavad resolveri seadistust, mida miski ei loe.
Leia resolveri omanik platvormi kaupa
Windowsis võib nimelahenduse poliitikatabel suunata teatud sufiksid teatud serveritesse ja VPN-klient võib sinna reegleid paigaldada. Kontrolli poliitikat, mitte ainult adapteri DNS-i loendit. Linuxis võib seadistuse omanik olla NetworkManager või systemd-resolved, ja see, kumb seda omab, määrab, mida uuesti ühendamine säilitab.
Loe tegelikku olekut tööriistaga, mis päringutele tõesti vastab: resolvectl query internal.example.net systemd-resolvedi hostis või platvormi ekvivalent. Seejärel võrdle seda vastust DNS-serveriga, mille kliendi log väidab saatnud olevat.
Väldi mitme teenuse käitamist, mis kirjutavad resolveri seadeid kooskõlastamata üle. Kaks omanikku annavad tulemuse, mis näib katkendlik, ja iga uuesti ühendamine näib seda juhuslikult parandavat või rikkuvat.
Skriptid ja foreign_option
OpenVPN ekspordib saadetud valikud skriptidele muutujate kaudu nimega foreign_option_N, ja skript võib need resolveri käskudeks tõlkida. See korraldus on toetatud integratsioon, mitte automaatne käitumine, ning see tuleb kliendis paigaldada ja esile kutsuda.
Kui toetud skriptile, logi selle käivitamine ja väljumisolek. Skript, mis töötab, kuid nurjub vaikselt, jätab sama sümptomi nagu skripti puudumine, ja seda on raskem märgata, sest seadistus näib täielik. Kontrolli skripti väljundit, mitte skriptifaili. Olemasolev fail ei ole skript, mis töötas.
Testi nime, mitte logi
Päri kliendilt ainult sisemist hostinime pärast ühendamist, seejärel päri avalikku nime ja seejärel kontrolli, milline server vastas. Toimivas seadistuses tulevad kaks vastust eri kohtadest ja mõlemad peaksid kavandiga sobima.
Kui nimi laheneb, kuid teenus nurjub, liigu edasi marsruutimise ja rakenduste juurdepääsu juurde, selle asemel et DNS-i uuesti muuta. OpenVPN-i käsiraamat dokumenteerib dhcp-optioni ja skriptikeskkonna; kasuta seda, et kinnitada, mida sinu klient peaks rakendama, enne kui muudad veel üht resolverifaili.