Ynterne nammen mislearje op de VPN wylst publike siden har wol oplosse

Ien brûker meldt dat de intranet-hostnamme net oplost oer de VPN. In twadde melding, fan deselde laptop, seit dat in lekktest noch altyd sjen lit dat queries troch de lokale resolver beäntwurde wurde. Se klinke as ien probleem en binne twa, mei ferskillend bewiis, en de gebrûklike reparaasje foar de earste makket de twadde slimmer. Skied se foardat jo oan in ynstelling komme.

Twa symptomen dy't gjin ien fout binne

It net oplossen fan in ynterne namme betsjut dat de fraach earne kaam dêr't gjin antwurd foar is. Queries dy't it tunnel ferlitte betsjutte dat de fraach op it ferkearde plak kaam, sels doe't it antwurd beskikber wie. Dat binne tsjinoerstelde flaters: de iene is in ûntbrekkend antwurd, de oare in ekstra bestimming.

De falstrik is dat it oeral tafoegjen fan de kantoarresolver de earste reparearret en de twadde garandearret. It oeral tafoegjen fan in publike resolver docht it omkearde.

Skriuw beide observaasjes op mei in tiidstimpel, en wurkje dan de fjouwer kontrôles hjirûnder yn folchoarder ôf.

Hokker adapterresolver de fraach krijt

Op Windows kiest de DNS-klant servers neffens de biningsoarder fan de adapters, en de tunneladapter is net automatysk earst. Iepenje de avansearre ynstellingen fan de adapter en set de ferbining foar remote tagong boppe de fysike adapter, meitsje dan opnij ferbining sadat de wiziging op in nije sesje jildt.

Biningsoarder is mar de earste helte. De klant moat ek witte hokker nammen by dy adapter hearre, en dat is in suffiksfraach, gjin oarderingsfraach.

Set de ipconfig /all fan de wurkjende masine njonken dy fan de laptop, beide nommen wylst it tunnel omheech is. De wurkjende masine sil in ferbiningseigen DNS-suffiks op syn kantoaradapter sjen litte, en de laptop miskien gjinien op it tunnel. Dat ferskil ferklearret in hiele klasse fan meldingen dat de server der krekt is en de namme dochs mislearret, want sûnder suffiks wurdt de koarte namme nea oanfolle ta de sône dy't de kantoarresolver betsjinnet.

In koarte namme hat in suffiks nedich foardat in rûte

It typen fan in net-kwalifisearre hostnamme freget de resolver om in domein te rieden. De gissing komt út de suffikslist dy't oan de ferbining hinget, en as dy list leech is, giet de fraach út as ien inkeld label dat gjin privee sône matche sil.

Kopiearje it suffiks fan de wurkjende masine nei de IPv4-eigenskippen fan de VPN-adapter, op it tabblêd DNS, en meitsje dan opnij ferbining. Op Linux is it ekwivalint it sykdomein op de tunnellink, dat systemd-resolved per link eksposearret yn stee fan globaal.

Hâld de twa ynstellingen apart yn jo notysjes. In suffiks feroaret wat frege wurdt; it resolveradres feroaret wa't frege wurdt. Ien reparearje wylst de oare ferkeard is, jout in resultaat dat tafallich liket.

Freegje de resolver streekrjocht, en dan de namme

In streekrjochte fraach oan de kantoarresolver skiedt in nammeprobleem fan in paadprobleem, want it giet folslein foarby de resolverkar fan de klant.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

It earste kommando freget in folslein kwalifisearre namme oan in spesifike server. As it antwurdet, binne de resolver en de rûte dêrhinne goed en sit de fout yn de kar of it suffiks. As it tiid útrint, is it adres ferkeard of net berikber en is it probleem rûtering, gjin DNS. It twadde kommando lit sjen wat der mei de koarte namme bart, en it tredde prints de resolverkonfiguraasje per link op in systemd-host.

Let op wildcard-antwurden, dy't guon netwurken foar ûnbekende nammen jouwe. In antwurd dat oannimlik liket is gjin bewiis dat de bedoelde server antwurde, dus ferlykje it werombrochte adres mei dat wat de ynterne tsjinst echt brûkt. As it adres by in parkearside of in proxy heart, antwurde de resolver wol, mar wie it antwurd nea dyn. Dat ûnderskie besparret in oere fan sykjen nei in tunnel dy't al dy tiid wurke.

Op Linux ferfangt in VPN-klant dy't /etc/resolv.conf wer oanskriuwt de lokale resolvers hielendal. vpnc eksposearret DNSUpdate no om dat te stopjen, en systemd-resolved kin allinnich de neamde domeinen nei de tunnellink rûte. Beide oanpakken hâlde publike nammen by de lokale resolver wylst se ynterne nammen nei it kantoar stjoere.

Lekken binne in regel, gjin checkbox

Namme-oplossing is in UDP-útwikseling nei poarte 53, dus in tunnel dy't webferkear mar gjin UDP draacht lit de fraach op it fysike paad. Bewiis it troch op de fysike NIC te finzen wylst in publike namme oplost wurdt. In fraach dy't op dy ynterface lêsber te sjen is, betsjut dat it tunnel dy net draacht.

sudo tcpdump -ni eth0 -c 20 'udp port 53'
resolvectl query example.com

As de fraach lêsber op dy ynterface ferskynt, draacht it tunnel dy net. De reparaasje is in regel dy't poarte 53 allinnich tastiet nei de resolver dy't de VPN trochjoech en oare bestimmingen sakjefallet, plus in klantkonfiguraasje dy't de trochjûne opsje net stilwei fuortgoait.

Dat lêste part is wichtiger as it liket. Start OpenVPN mei route-nopull en de trochjûne DNS-opsje ferdwynt tegearre mei de rûtes, útsein as it pull-filter ferbrede wurdt om it te hâlden. In klant dy't dhcp-option DNS negearret, bliuwt brûken wat er earder hie. Elke wiziging oan de serverkant freget in nije sesje om effekt te hawwen, want de resolverlist wurdt levere as it tunnel omheech komt en in ferâldere sesje bliuwt de âlde steat sjen litten.

Skriuw op hokker flater jo eins sjoen hawwe foardat jo it ticket slute. In ûntbrekkend yntern antwurd en in fraach dy't it tunnel ûntkomt freegje om ferskillende reparaasjes, en in suffikswiziging dy't de earste reparearret kin de twadde stilwei slimmer meitsje. Wa't it ticket dêrnei oppakt, fertrout it label, dus meitsje it label krekt.