OpenVPN se gestuurde DNS word geïgnoreer: watter komponent pas dit toe

Die log wys die opsie wat die bediener gestoot het, die tonnel is op, en interne name faal steeds. 'n Navraag direk na die resolver antwoord, so die bediener is reg, tog bly elke toepassing die plaaslike router vra. Wat by die kliënt aankom, is 'n aanbod, nie 'n verandering aan die resolver nie, en die komponent wat naamoplossing besit, verskil op Linux, Windows en macOS. Sodra jy die opsie van sy eienaar skei, dek vier foute byna elke verslag: geen hook nie, twee mededingende hooks, gesplete DNS wat werk soos ontwerp, of 'n kort naam wat 'n agtervoegsel eerder as 'n bediener nodig het.

In gestuurde opsie is 'n aanbod, nie 'n installasie nie

Op die bediener beskryf twee opdragte die bedoeling, nie die effek nie:

push "dhcp-option DNS 10.8.0.1"
push "dhcp-option DOMAIN corp.example"

Die kliënt ontvang nie 'n gekonfigureerde resolver nie. Dit ontvang omgewingsveranderlikes, foreign_option_1 en verder, een per gestuurde reël, en iets plaasliks moet dit lees en die bedryfstelsel se resolver-toestand herskryf. Op Linux doen niks dit by verstek nie, en daarom kan 'n korrekte bediener en 'n gekoppelde kliënt steeds deur die LAN oplos.

Drie stadiums sit tussen die twee kante: die stoot moet reis, die kliënt moet dit blootstel, en 'n hook moet dit toepas. Lees die middelste stadium in die kliëntlog en die laaste stadium in die resolver-toestand, nooit omgekeerd nie, want 'n logreël bewys net die eerste twee.

Bevestig dat die stoot aangekom het en vind die eienaar

Begin deur die launcher te noem: 'n kaal openvpn opdrag, 'n systemd-instansie, NetworkManager of 'n verskafferkliënt. Dit bepaal waar 'n hook kan woon. Op 'n gasheer met systemd-resolved resolvectl status lys elke skakel met die DNS-bedienerers en soekdomeine wat dit werklik gebruik, en die tonnelskakel heet nie altyd tun0.

As die gestuurde adres in die log verskyn maar op geen skakel nie, ontbreek die integrasie. As dit op die skakel verskyn en navrae gaan steeds elders uit, is die probleem watter navrae daardie skakel kies. NetworkManager met dns=dnsmasq in /etc/NetworkManager/NetworkManager.conf laat 'n plaaslike deurstuurder loop wat gesplete DNS doelbewus implementeer: name binne die VPN-domein gaan na die VPN-resolver, al die res behou sy vorige pad. Daardie gedrag lyk na 'n fout wanneer jy verwag het dat alle verkeer moet skuif; kyk na die per-verbinding-instellings met nmcli connection show "My VPN", waar ipv4.dns en ipv4.dns-search die waardes agter wat die toestel rapporteer hou, voordat jy dit as stukkend bestempel. As elke navraag werklik die VPN-resolver moet bereik, verwyder dns=dnsmasq van NetworkManager.conf en herbegin NetworkManager, wat naamoplossing teruggee aan die verbindingsinstellings; anders behou gesplete DNS en korrigeer eerder die gestuurde domeinlys.

Linux: gee die opsies aan die resolver

Verspreidingspakkette lewer 'n hook hiervoor, en die kliënt moet toegelaat word om dit te laat loop. 'n Tipiese reëling op 'n gasheer sonder systemd-resolved:

script-security 2
up /etc/openvpn/update-resolv-conf
down /etc/openvpn/update-resolv-conf

Met systemd-resolved verander die ouer resolv.conf-skrip dalk niks wat saak maak nie, want die stub-resolver hou toestand per skakel. Die update-systemd-resolved helper dokumenteer 'n hook-vorm wat gebruik maak van up-restart en down-pre, wat saak maak wanneer 'n koppelvlak 'n enkele verbindingspoging oorleef. Wat jy ook al kies, een komponent moet die toestand besit. Om 'n onverwante hook langs NetworkManager te voeg, gee twee skrywers aan dieselfde skakel, en die uitkoms hang dan van ordening af eerder as van jou konfigurasie.

Daar is ook die geval waar NetworkManager die gestuurde opsie heeltemal geïgnoreer het totdat die bedieneradres in die verbinding se IPv4-instellings ingevoer is, waarna die resolver-toestand getoon het dat dit in gebruik is. Dit is die moeite werd om te probeer voordat jy skripte herskryf, want dit verskuif die probleem van 'n shell-hook na die verbindingsprofiel wat die tonnel reeds dra.

Windows en macOS pas verskillende dele toe

Die Windows-kliënt stel wel die VPN-adapter se DNS-bedienerers in, maar Windows kies steeds 'n koppelvlak op metrieke en het steeds 'n agtervoegsel nodig om 'n kort naam uit te brei. Bevestig die adaptertoestand eerder as die profiel:

Get-DnsClientServerAddress -InterfaceAlias "My VPN"
Get-DnsClientNrptPolicy

As die adres ontbreek, stel dit met Set-DnsClientServerAddress -InterfaceAlias "My VPN" -ServerAddresses 10.8.0.1, voeg dan die agtervoegsel by die adapter se IPv4-eienskappe sodat fileserver word fileserver.corp.example. 'n Masjienwye SearchList waarde onder Tcpip\Parameters doen dieselfde. Waar die lang naam oplos en die kale een nie, is die resolver reeds korrek en die soeklys is die fout. Die regstellings, in volgorde: stoot 'n DOMAIN sodat die kliënt die agtervoegsel leer, voeg daardie agtervoegsel by die adapter of verbinding se soeklys, en pen as tydelike maatreël die naam in hosts, of LMHOSTS op Windows; NetBIOS-blaaiery steek nie 'n router oor nie, so die uitsending wat 'n kort naam op die kantoor-LAN vind, bereik nooit 'n tonnelkliënt nie.

block-outside-dns block-outside-dns is 'n Windows-kliëntgedrag, nie 'n draagbare profielreël nie, en om dit na 'n Linux- of macOS-profiel te kopieer, reproduseer dit nie daar nie. As publieke name werk en interne name op Windows faal, vergelyk die adapterorde onder Gevorderde instellings met ipconfig /all. Op macOS behoort die resolverorde per diens aan die stelsel, so gebruik scutil --dns om te sien watter resolver vir watter domein geraadpleeg word, en beskou enige enkele gerapporteerde profielregstelling as kliëntafhanklik eerder as algemeen.

'n Virtuele masjien op dieselfde skootrekenaar erf niks hiervan nie. Gee die gas sy eie resolver-inskrywing vir die interne domein, of laat die hipervisor se NAT sy navrae deur die gasheer stuur, wat net korrek is terwyl die gasheer se tonnel op is.

Geskiedenis is die derde oorsaak. DNS-bedienerers of agtervoegselinstellings van 'n vroeëre profiel kan herverbindings oorleef, so wanneer die adapter korrek lyk en opsoeke steeds faal, vergelyk die lewende adapter met Get-VpnConnection en wis of oorskryf die verouderde inskrywing voordat jy aan die bediener raak.

Bewys waar die navraag heen gegaan het

'n Opname tydens een opsoek besleg die argument: tcpdump -ni eth0 port 53 wys navrae op die fisiese koppelvlak, wat beteken hulle verlaat buite die tonnel en die resolver is nooit omgeskakel nie. dig @10.8.0.1 name.corp.example skei dan die twee oorblywende gevalle. As die direkte navraag antwoord, werk die resolver en gebruik die kliënt dit nie; as dit uittyd, is die resolver onbereikbaar deur die tonnel en geen plaaslike verandering sal help nie.

As die resolver wat steeds gebruik word die een is wat die verskaffer uitgedeel het, versleutel die tonnel die verkeer terwyl die name sigbaar bly vir daardie verskaffer. Dit is 'n lekkasievraag eerder as 'n funksionele een, en dieselfde opname antwoord dit: 'n navraag op die fisiese koppelvlak gaan na iemand buite die tonnel.

Bereikbaarheid sluit die firewall op die VPN-gasheer in, wat UDP en TCP 53 vanaf die poel moet toelaat. 'n Geslote poort lyk presies soos 'n stukkende stoot, en so ook 'n resolver wat net van binne die tonnelnetwerk antwoord. Herhaal die opname nadat jy een keer ontkoppel en weer gekoppel het, want instellings wat by die eerste verbinding verskyn en by die tweede verdwyn, is 'n lewenssiklusfout in die hook, nie 'n ontbrekende opsie nie.

Hou een eienaar en verifieer in volgorde

'n Skrip wat adapter-DNS herskryf op grond van 'n gerade tonneltoestand dupliseer konfigurasie wat die profiel reeds dra, en dit faal stil die eerste keer dat die raaiskoot verkeerd is. Verkies die verbinding se eie DNS-instellings of een gedokumenteerde hook, en teken aan watter een jy gekies het sodat die volgende persoon nie 'n tweede byvoeg nie.

Sluit die lus met vier kontroles: die gestuurde adres teenwoordig op die tonnelskakel, die interne naam wat as 'n volledig gekwalifiseerde naam oplos, dieselfde naam wat sonder die agtervoegsel oplos, en albei nog waar ná een herverbinding. Een opname sê vir jou watter van die vier gefaal het. Die OpenVPN 2.6-handleiding lys die dhcp-option en skripdirektiewe met hul platformnotas.