OpenVPN stjoert DNS, mar dyn DNS-oplosser sjocht it miskien nea

It klantlogboek toant de stjoerde DNS-tsjinner, de tunnel is ferbûn, en in ynterne namme wurdt noch altyd net oplost. Der is neat stikken yn it stjoeren sels. De opsje kaam oan en de oplosser fan it bestjoeringssysteem brûkte it nea, want by de measte Unix-klanten leveret OpenVPN de wearde en lit de applikaasje oan it platfoarm oer.

It symptoom: it logboek toant DNS en nammen misse noch altyd

OpenVPN dhcp-option draacht DNS- en domeinynformaasje, en de klant skriuwt op wat er krige. By guon ymplemintaasjes past de klant dy ynstellings yntern ta; by oaren eksportearret er se foar in yntegraasjeskript of in netwurkstsjinst. De rigel yn it logboek beskriuwt allinnich de earste helte fan it ferhaal. De twadde helte bart earne dêr't de klant gjin kontrôle oer hat. Dêr wennet de flater ornaris.

Dêrom komme in ferbûne tunnel en in mislearre ynterne namme sa faak tegearre foar. De wearde is der, de brûker ûntbrekt of is ferkeard konfigurearre, en de oplosser bliuwt stil de publike tsjinner brûken dy't er foar de ferbining brûkte.

Untfongen is net tapast

In klant kin in stjoerde DNS-wearde yn it logboek sette wylst de systeemoplosser noch fan in oare tsjinst is. In browser kin ek syn eigen belied foar fersifere DNS hawwe dat de systeemoplosser hielendal omslút, wat de tinkweardige situaasje jout wêrby't ien applikaasje ynterne nammen oplost en in oare net.

Kontrolearje de stipe yntegraasje fan de ymplemintaasje ynstee fan oan te nimmen dat elke Unix-klant itselde bestân oerskriuwt. Dy oanname is de reden dat minsken in oplosserkonfiguraasje bewurkje dy't neat lêst.

Fyn de eigner fan de oplosser per platfoarm

Op Windows kin de tabel foar namme-oplossingsbelied spesifike efterheaksels nei spesifike tsjinners stjoere, en de VPN-klant kin dêr regels ynstallearje. Kontrolearje it belied, net allinnich de DNS-list fan de adapter. Op Linux kin NetworkManager of systemd-resolved de konfiguraasje hawwe, en hokker fan beiden it hat, bepaalt wat in werferbining bewarret.

Lês de effektive steat mei it ark dat echt antwurdet op fragen: resolvectl query internal.example.net op in systemd-resolved-host, of it ekwivalint fan it platfoarm. Fergelykje dan dat antwurd mei de DNS-tsjinner dy't it klantlogboek seit stjoerd te hawwen.

Foarkom dat ferskate tsjinsten draaie dy't oplosser-ynstellings sûnder koördinaasje oerskriuwe. Twa eigners jouwe in resultaat dat ûnregelmjittich liket, en elke werferbining liket it samar te meitsjen of te brekken.

Skripten en foreign_option

OpenVPN eksportearret stjoerde opsjes nei skripten fia fariabelen mei de namme foreign_option_N, en in skript kin se oersetten yn oplosser-opdrachten. Dy regeling is in stipe yntegraasje, gjin automatysk gedrach, en se moat op de klant ynstallearre en oanroppen wurde.

As jo op in skript fertrouwe, log dan de útfiering en de útgongstatus. In skript dat draait mar stil misse, lit itselde symptoom efter as gjin skript, en it is hurder te merken om't de konfiguraasje kompleet liket. Kontrolearje de útfier fan it skript, net it skriptbestân. In bestân dat bestiet is gjin skript dat draaid hat.

Test de namme, net it logboek

Freegje de klant nei in allinnich-ynterne hostnamme nei it ferbinen, freegje dan nei in publike namme, en kontrolearje dan hokker tsjinner antwurde. Yn in wurkjende opset komme de twa antwurden fan ferskate plakken, en beide moatte by it ûntwerp passe.

As de namme oplost mar de tsjinst misse, gean dan troch nei routing en applikaasjetoegong ynstee fan DNS wer te feroarjen. De OpenVPN-hânlieding beskriuwt dhcp-option en de skriptomjouwing; brûk it om te befêstigjen wat jo klant ferwachte wurdt ta te passen foardat jo noch in oplosserbestân bewurkje.