OpenVPN potiska DNS, a vaš razreševalnik ga morda nikoli ne bo videl

Dnevnik odjemalca prikazuje poslani strežnik DNS, tunel je povezan, notranje ime pa se še vedno ne razreši. Pri samem pošiljanju ni nič pokvarjeno. Možnost je prispela, a razreševalnik operacijskega sistema je ni nikoli uporabil, ker pri večini odjemalcev Unix OpenVPN vrednost preda in uporabo prepusti platformi.

Simptom: dnevnik prikazuje DNS, imena pa še vedno ne uspejo

OpenVPN dhcp-option prenaša podatke o DNS in domeni, odjemalec pa zabeleži, kaj je prejel. V nekaterih izvedbah odjemalec te nastavitve uporabi znotraj sebe; v drugih jih izvozi za integracijsko skripto ali omrežno storitev. Vrstica v dnevniku opisuje le prvo polovico zgodbe. Druga polovica se zgodi tam, kjer odjemalec nima nadzora. Tam običajno živi napaka.

Zato se povezan tunel in neuspešno notranje ime tako pogosto pojavita skupaj. Vrednost je tu, uporabnik manjka ali je napačno nastavljen, razreševalnik pa tiho še naprej uporablja javni strežnik, ki ga je uporabljal pred povezavo.

Prejeto še ni uporabljeno

Odjemalec lahko zabeleži poslano vrednost DNS, medtem ko sistemski razreševalnik ostaja v lasti druge storitve. Brskalnik ima lahko tudi svojo politiko šifriranega DNS, ki sistemski razreševalnik popolnoma obide, kar ustvari zapomljivo stanje, ko ena aplikacija razrešuje notranja imena, druga pa ne.

Preverite podprto integracijo izvedbe, namesto da bi domnevali, da vsak odjemalec Unix prepiše isto datoteko. Prav ta domneva je razlog, da ljudje urejajo konfiguracijo razreševalnika, ki je nič ne bere.

Poiščite lastnika razreševalnika za vsako platformo

V Windowsu lahko tabela pravil razreševanja imen usmeri določene pripone na določene strežnike, odjemalec VPN pa lahko tam namesti pravila. Preverite pravila, ne le seznama DNS vmesnika. V Linuxu je konfiguracija lahko v lasti NetworkManagerja ali systemd-resolved, in kateri od njiju jo ima, določa, kaj bo ponovna povezava ohranila.

Preberite dejansko stanje z orodjem, ki resnično odgovarja na poizvedbe: resolvectl query internal.example.net na gostitelju s systemd-resolved ali ustreznico platforme. Nato primerjajte ta odgovor s strežnikom DNS, za katerega dnevnik odjemalca trdi, da je bil poslan.

Izogibajte se izvajanju več storitev, ki brez usklajevanja prepisujejo nastavitve razreševalnika. Dva lastnika dajeta rezultat, ki se zdi občasen, vsaka ponovna povezava pa ga očitno naključno popravi ali pokvari.

Skripte in foreign_option

OpenVPN izvaža poslane možnosti v skripte prek spremenljivk z imenom foreign_option_N, skripta pa jih lahko prevede v ukaze razreševalnika. Ta ureditev je podprta integracija, ne samodejno vedenje, in jo je treba namestiti ter priklicati na odjemalcu.

Če se zanašate na skripto, beležite njeno izvajanje in izhodni status. Skripta, ki teče, a tiho ne uspe, pusti enak simptom kot nobena skripta, in to je težje opaziti, ker je konfiguracija videti popolna. Preverite izpis skripte, ne datoteke skripte. Obstajajoča datoteka ni skripta, ki je tekla.

Preizkusite ime, ne dnevnika

Po povezavi pri odjemalcu poizvedite po samo notranjem imenu gostitelja, nato po javnem imenu, nato preverite, kateri strežnik je odgovoril. V delujoči nastavitvi prideta oba odgovora z različnih mest in oba bi se morala ujemati z zasnovo.

Če se ime razreši, storitev pa ne uspe, nadaljujte na usmerjanje in dostop aplikacij, namesto da bi znova spremenili DNS. Priročnik OpenVPN dokumentira dhcp-option in skriptno okolje; uporabite ga, da potrdite, kaj naj bi vaš odjemalec uporabil, preden uredite še eno datoteko razreševalnika.