OpenVPN stuur DNS, maar jou resolver sien dit dalk nooit

Die kliëntlog wys die gestuurde DNS-bediener, die tonnel is verbind, en ’n interne naam los steeds niks op. Niks is fout met die stuur self nie. Die opsie het aangekom, maar die bedryfstelsel se resolver het dit nooit gebruik nie, want op die meeste Unix-kliënte lewer OpenVPN die waarde en laat die toepassing aan die platform oor.

Die simptoom: die log wys DNS en name misluk steeds

OpenVPN dhcp-option dra DNS- en domeininligting, en die kliënt teken aan wat hy ontvang. Op sommige implementasies pas die kliënt daardie instellings intern toe; op ander voer hy dit uit vir ’n integrasieskrip of ’n netwerkdiens om te verbruik. Die logreël beskryf net die eerste helfte van die verhaal. Die tweede helfte gebeur iewers waar die kliënt nie beheer het nie. Dis waar die fout gewoonlik sit.

Dis waarom ’n verbinde tonnel en ’n mislukte interne naam so dikwels saam bestaan. Die waarde is daar, die verbruiker ontbreek of is verkeerd opgestel, en die resolver gebruik stilweg die publieke bediener wat hy voor die verbinding gebruik het.

Ontvang is nie toegepas nie

’n Kliënt kan ’n gestuurde DNS-waarde log terwyl die stelselresolver nog aan ’n ander diens behoort. ’n Blaaier kan ook sy eie geënkripteerde-DNS-beleid hê wat die stelselresolver heeltemal omseil, wat die onthoubare situasie skep waar een toepassing interne name oplos en ’n ander nie.

Kontroleer die implementasie se ondersteunde integrasie eerder as om aan te neem elke Unix-kliënt herskryf dieselfde lêer. Dié aanname is die rede waarom mense ’n resolver-konfigurasie wysig wat niks lees nie.

Vind die resolver-eienaar per platform

Op Windows kan die naamresolusiebeleidstabel spesifieke agtervoegsels na spesifieke bedieners stuur, en die VPN-kliënt kan reëls daar installeer. Kontroleer die beleid, nie net die adapter se DNS-lys nie. Op Linux kan NetworkManager of systemd-resolved die konfigurasie besit, en watter een dit besit, bepaal wat ’n herverbinding sal bewaar.

Lees die effektiewe toestand met die instrument wat werklik navrae beantwoord: resolvectl query internal.example.net op ’n systemd-resolved-gasheer, of die platform se ekwivalent. Vergelyk dan daardie antwoord met die DNS-bediener wat die kliëntlog sê hy gestuur het.

Vermy om verskeie dienste te laat loop wat resolver-instellings sonder koördinasie oorskryf. Twee eienaars lewer ’n resultaat wat wisselvallig lyk, en elke herverbinding lyk of dit dit lukraak regmaak of breek.

Skripte en foreign_option

OpenVPN voer gestuurde opsies na skripte uit deur veranderlikes met die naam foreign_option_N, en ’n skrip kan dit in resolver-opdragte vertaal. Dié reëling is ’n ondersteunde integrasie, nie outomatiese gedrag nie, en dit moet op die kliënt geïnstalleer en aangeroep word.

As jy op ’n skrip staatmaak, teken sy uitvoering en sy uitgangstatus aan. ’n Skrip wat loop maar stilweg misluk, laat dieselfde simptoom as geen skrip nie, en dit is moeiliker om raak te sien omdat die konfigurasie volledig lyk. Kontroleer die skrip se uitset, nie die skriplêer nie. ’n Lêer wat bestaan is nie ’n skrip wat geloop het nie.

Toets die naam, nie die log nie

Vra ’n slegs-interne gasheernaam by die kliënt nadat jy verbind het, vra dan ’n publieke naam, en kyk watter bediener geantwoord het. Die twee antwoorde kom uit verskillende plekke in ’n werkende opset, en albei moet by die ontwerp pas.

As die naam oplos maar die diens misluk, gaan voort na roetering en toepassingstoegang in plaas daarvan om DNS weer te verander. Die OpenVPN-handleiding dokumenteer dhcp-option en die skrip-omgewing; gebruik dit om te bevestig wat jou kliënt verwag word om toe te pas voordat jy nog ’n resolver-lêer wysig.