OpenVPN puŝas DNS, sed via solvilo eble neniam vidos ĝin

La klienta protokolo montras la puŝitan DNS-servilon, la tunelo estas konektita, kaj interna nomo ankoraŭ ne solviĝas. Nenio estas rompita en la puŝo mem. La opcio alvenis kaj la solvilo de la operaciumo neniam uzis ĝin, ĉar ĉe plej multaj Unix-klientoj OpenVPN transdonas la valoron kaj lasas la aplikon al la platformo.

La simptomo: la protokolo montras DNS kaj nomoj ankoraŭ fiaskas

OpenVPN dhcp-option portas DNS- kaj domajninformojn, kaj la kliento registras, kion ĝi ricevis. Ĉe iuj realigoj la kliento aplikas tiujn agordojn interne; ĉe aliaj ĝi eksportas ilin por integra skripto aŭ reta servo. La protokola linio priskribas nur la unuan duonon de la rakonto. La dua duono okazas ie, kion la kliento ne regas. Tie kutime loĝas la fiasko.

Tial konektita tunelo kaj fiaska interna nomo tiel ofte kunekzistas. La valoro ĉeestas, la konsumanto mankas aŭ estas misagordita, kaj la solvilo kviete plu uzas la publikan servilon, kiun ĝi uzis antaŭ la konekto.

Ricevita ne estas aplikita

Kliento povas registri puŝitan DNS-valoron dum la sistema solvilo restas posedata de alia servo. Foliumilo ankaŭ povas havi sian propran ĉifritan-DNS-politikon, kiu tute preterpasas la sisteman solvilon, kio kreas la memorindan situacion, en kiu unu aplikaĵo solvas internajn nomojn kaj alia ne.

Kontrolu la subtenatan integriĝon de la realigo anstataŭ supozi, ke ĉiu Unix-kliento reskribas la saman dosieron. Tiu supozo estas la kialo, ke homoj redaktas solvilan agordon, kiun nenio legas.

Trovu la posedanton de la solvilo laŭ platformo

En Windows la nomrega politika tabelo povas direkti specifajn sufiksojn al specifaj serviloj, kaj la VPN-kliento povas instali regulojn tie. Kontrolu la politikon, ne nur la DNS-liston de la adaptilo. En Linux la agordon povas posedi NetworkManager aŭ systemd-resolved, kaj kiu el ili posedas ĝin determinas, kion rekonekto konservos.

Legu la efektivan staton per la ilo, kiu fakte respondas demandojn: resolvectl query internal.example.net ĉe systemd-resolved gastiganto, aŭ la platforma ekvivalento. Poste komparu tiun respondon kun la DNS-servilo, kiun la klienta protokolo asertas esti puŝinta.

Evitu funkciigi plurajn servojn, kiuj superskribas solvilajn agordojn sen kunordigo. Du posedantoj produktas rezulton, kiu ŝajnas intermita, kaj ĉiu rekonekto ŝajne hazarde riparas aŭ rompas ĝin.

Skriptoj kaj foreign_option

OpenVPN eksportas puŝitajn opciojn al skriptoj per variabloj nomataj foreign_option_N, kaj skripto povas traduki ilin en solvilajn komandojn. Tiu aranĝo estas subtenata integriĝo, ne aŭtomata konduto, kaj ĝi devas esti instalita kaj vokita ĉe la kliento.

Se vi dependas de skripto, registru ĝian plenumon kaj eliran staton. Skripto, kiu ruliĝas sed fiaskas silente, lasas la saman simptomon kiel neniu skripto, kaj estas pli malfacile rimarki ĝin, ĉar la agordo ŝajnas kompleta. Kontrolu la eligon de la skripto, ne la skriptan dosieron. Ekzistanta dosiero ne estas skripto, kiu ruliĝis.

Testu la nomon, ne la protokolon

Demandu al la kliento nur-internan gastigantnomon post konekto, poste demandu publikan nomon, poste kontrolu, kiu servilo respondis. En funkcianta aranĝo la du respondoj venas el malsamaj lokoj, kaj ambaŭ devus kongrui kun la dezajno.

Se la nomo solviĝas sed la servo fiaskas, pluiru al enrutigado kaj aplika aliro anstataŭ denove ŝanĝi DNS. La gvidilo pri OpenVPN dokumentas dhcp-option kaj la skriptan medion; uzu ĝin por konfirmi, kion via kliento devus apliki, antaŭ ol redakti alian solvilan dosieron.