OpenVPN siunčia DNS, bet jūsų rezolveris gali jo taip ir nepamatyti

Kliento žurnale matomas nusiųstas DNS serveris, tunelis prijungtas, o vidinis vardas vis tiek nieko neišsprendžia. Pačiame siuntime niekas nesugedę. Parinktis atkeliavo, bet operacinės sistemos rezolveris jos taip ir nepanaudojo, nes daugumoje Unix klientų OpenVPN perduoda reikšmę ir palieka programą platformai.

Simptomas: žurnalas rodo DNS, o vardai vis tiek nepavyksta

OpenVPN dhcp-option perduoda DNS ir domeno informaciją, o klientas įrašo, ką gavo. Kai kuriose realizacijose klientas tuos nustatymus taiko viduje; kitose eksportuoja juos integracijos scenarijui ar tinklo tarnybai. Žurnalo eilutė aprašo tik pirmąją istorijos pusę. Antroji pusė vyksta ten, ko klientas nekontroliuoja. Ten paprastai ir slypi gedimas.

Štai kodėl prijungtas tunelis ir nepavykstantis vidinis vardas taip dažnai sutampa. Reikšmė yra, vartotojas trūksta arba neteisingai sukonfigūruotas, o rezolveris tyliai toliau naudoja viešą serverį, kurį naudojo prieš prisijungimą.

Gauta nereiškia pritaikyta

Klientas gali įrašyti nusiųstą DNS reikšmę, kol sistemos rezolveris vis dar priklauso kitai tarnybai. Naršyklė taip pat gali turėti savo šifruoto DNS politiką, kuri visiškai apeina sistemos rezolverį, o tai sukuria įsimintiną situaciją, kai viena programa išsprendžia vidinius vardus, o kita ne.

Tikrinkite realizacijos palaikomą integraciją, o ne manykite, kad kiekvienas Unix klientas perrašo tą patį failą. Būtent ši prielaida verčia žmones redaguoti rezolverio konfigūraciją, kurios niekas neskaito.

Raskite rezolverio savininką pagal platformą

Windows sistemoje vardų sprendimo politikos lentelė gali nukreipti tam tikrus sufiksus į tam tikrus serverius, o VPN klientas ten gali įdiegti taisykles. Tikrinkite politiką, ne vien adapterio DNS sąrašą. Linux sistemoje konfigūracija gali priklausyti NetworkManager arba systemd-resolved, ir kuri iš jų jai priklauso, lemia, ką išsaugos pakartotinis prisijungimas.

Skaitykite faktinę būseną įrankiu, kuris tikrai atsako į užklausas: resolvectl query internal.example.net systemd-resolved hoste arba platformos atitikmeniu. Tada palyginkite tą atsakymą su DNS serveriu, kurį kliento žurnalas teigia nusiuntęs.

Venkite paleisti kelias tarnybas, kurios be koordinavimo perrašo rezolverio nustatymus. Du savininkai duoda rezultatą, kuris atrodo periodiškas, ir kiekvienas prisijungimas tarsi atsitiktinai jį pataiso ar sugadina.

Scenarijai ir foreign_option

OpenVPN eksportuoja nusiųstas parinktis scenarijams per kintamuosius, pavadintus foreign_option_N, o scenarijus gali juos paversti rezolverio komandomis. Ši tvarka yra palaikoma integracija, o ne automatinis elgesys, ir ją reikia įdiegti bei iškviesti kliente.

Jei remiatės scenarijumi, registruokite jo vykdymą ir išėjimo būseną. Scenarijus, kuris veikia, bet tyliai nepavyksta, palieka tą patį simptomą kaip jokio scenarijaus, ir jį pastebėti sunkiau, nes konfigūracija atrodo išsami. Tikrinkite scenarijaus išvestį, o ne scenarijaus failą. Egzistuojantis failas nėra įvykdytas scenarijus.

Išbandykite vardą, o ne žurnalą

Prisijungę paklauskite kliento tik vidinio hostname, tada paklauskite viešo vardo, tada patikrinkite, kuris serveris atsakė. Veikiančioje sąrangoje du atsakymai ateina iš skirtingų vietų, ir abu turėtų atitikti projektą.

Jei vardas išsprendžiamas, bet tarnyba nepavyksta, pereikite prie maršrutizavimo ir programų prieigos, o ne vėl keiskite DNS. OpenVPN vadove aprašytas dhcp-option ir scenarijų aplinka; naudokite jį norėdami patvirtinti, ką jūsų klientas turėtų taikyti, prieš redaguodami dar vieną rezolverio failą.