OpenVPN sendis DNS-servilon, sed Linux ignoras ĝin

La sendita DNS-servilo estas en la protokolo, la tunelo funkcias, kaj internaj nomoj ankoraŭ malsukcesas. Nenio estas rompita en la sendo mem; la agordo alvenis kaj haltis tie. Sendita DNS-opcio estas mesaĝo al la kliento, ne instrukcio al la solvilo de la operaciumo, kaj la transdono inter ili estas kie finiĝas la plej multaj el ĉi tiuj kazoj. Kvin kontroloj, laŭorde, trovas la transdonon, kiu ne okazis.

Kontrolo unu: kiel la konekto komenciĝas

La posedanto de la konekto determinas, kiu povas apliki agordojn de la solvilo. Rekta openvpn-komando el ŝelo posedas nenion krom sia propra procezo, dum systemd-unuo, NetworkManager aŭ vendista kliento ĉiu havas sian propran manieron publikigi DNS. Legu la procezliston kaj la unuan nomon antaŭ ol supozi iun ajn el ili.

Komandlinia procezo ne aŭtomate estas NetworkManager-konekto, kaj NetworkManager-konekto ne aŭtomate estas tio, kio skribis resolv.conf. Tiuj du supozoj klarigas la plej multajn el la perditaj horoj en ĉi tiu esploro. Demandu, kiu komponanto publikigus DNS por la interfaco, kiun vi efektive vidas.

Skribu la posedanton antaŭ ol daŭrigi. Ĉiu posta kontrolo dependas de ĝi.

Kontrolo du: kion la ligilo de la solvilo efektive tenas

Sur systemd-resolved-gastiganto, resolvectl status listigas ĉiun ligilon kun ĝiaj DNS-serviloj kaj domajnoj. Trovu la tunelan ligilon kaj legu ĝiajn enskribojn, kaj ne supozu, ke la interfaco nomiĝas tun0, ĉar la numerado sekvas la ordon de kreado. Se la sendita adreso mankas en la ligilo, la transdono malsukcesis, ne la demando.

Se la adreso ĉeestas, la sekva demando estas, kiujn domajnojn tiu ligilo postulas. Ligilo sen domajna listo respondas nur al nomoj, pri kiuj oni demandas ĝin rekte, kaj tio malofte estas tio, kion split-DNS-ekspansio volas. La adreso sola estas necesa sed ne sufiĉa.

Komparu la ligilan nomon en la eligilo de la solvilo kun la interfaca nomo en la VPN-protokolo antaŭ ol tiri ajnan konkludon. Miskongruo tie kutime signifas, ke la protokola linio venis de alia procezo.

Kontrolo tri: ĉu la nomspaco elektas tiun ligilon

Solvilo povas teni la ĝustan servilon kaj tamen ne esti konsultita. La domajno po ligilo decidas, kiuj demandoj iras al kiu ligilo, kaj sen enkursiga domajno la privata nomspaco refalas al tio, kion diras la apriora ligilo. Tial resolvectl query por la interna nomo povas sukcesi, dum aplikaĵo ankoraŭ malsukcesas. La aplikaĵo eble uzas tute alian solvilan vojon.

Kontrolu la domajnan asignadon, ne nur la servilan adreson. Domajno skribita kiel ~corp.example estas enkursiga domajno, kaj la tildo ŝanĝas kiel la nomo estas kongruigata.

Se la aplikaĵo havas sian propran solvilon, testu per la sama mekanismo, kiun ĝi uzas, anstataŭ per la sistema ilo. Demandilo, kiu preterpasas la sisteman solvilon, sukcesos sendepende de la stato de la ligilo.

Kontrolo kvar: unu posedanto, ne du

Se NetworkManager jam administras la VPN kaj la staton de la solvilo, aldoni senrilatan hokskripton kreas konkurantajn skribantojn. La hoko provizita de la pako por systemd-resolved estas subtenata integriĝo, kaj ĝi atendas specifan vivociklon: script-security 2, up-vojon, up-restart, down-vojon kaj down-pre. Tiuj opcioj igas registradon kaj forigon okazi en la ĝustaj momentoj anstataŭ nur ĉe la unua konekto.

Uzu la instalitan vojon el la pako anstataŭ ilustran kopiitan el gvidilo. Permesoj ankaŭ gravas, ĉar la hoko ruliĝas post kiam privilegioj falas.

Redakti distribuan solvilan skripton por ŝanĝi ĝian eligcelon registras provizoran solvon por unu gastiganto. Ĝi ne estas ĝenerala riparo.

Kontrolo kvin: la sama rezulto post rekonekto

Rekonektu kaj relegu la ligilon. Registrado, kiu aperas unufoje kaj malaperas ĉe la sekva transiro, estas la fiasko, por kiu ekzistas ĉi tiu tuta kontrol-listo. Testu post paŭzo, post deviga rekonekto kaj post restartigo de la solvila servo. Ĉiu transiro provas alian supozon pri la ordo.

Nur kiam ĉiuj kvin kontroloj pasas ĉe rekonekto, vi povas diri, ke la senditaj agordoj estas uzataj. Io ajn pli frue estas momentfoto de bonŝanca momento.