Interne name misluk op die VPN terwyl openbare terreine wel oplos

Een gebruiker rapporteer dat die intranethostnaam nie oor die VPN oplos nie. 'n Tweede verslag, van dieselfde skootrekenaar, sê 'n lekttoets wys steeds navrae wat deur die plaaslike resolver beantwoord word. Hulle klink soos een probleem maar is twee, met verskillende bewyse, en die gewone herstelling vir die eerste maak die tweede erger. Skei hulle voordat jy aan enige instelling raak.

Twee simptome wat nie een fout is nie

Om 'n interne naam nie te kan oplos nie, beteken die vraag het êrens beland waar daar geen antwoord voor is nie. Navrae wat die tonnel verlaat, beteken die vraag het na die verkeerde plek gegaan selfs toe die antwoord beskikbaar was. Dit is teenoorgestelde foute: die een is 'n ontbrekende antwoord, die ander 'n ekstra bestemming.

Die lokval is dat om die kantoorresolver oral by te voeg die eerste regmaak en die tweede waarborg. Om 'n openbare resolver oral by te voeg doen die omgekeerde.

Skryf albei waarnemings met 'n tydstempel neer en werk dan die vier kontroles hieronder in volgorde deur.

Watter adapter se resolver kry die vraag

Op Windows kies die DNS-kliënt bedieners volgens die adapterbindingsorde, en die tonneladapter is nie outomaties eerste nie. Maak die adapter se gevorderde instellings oop en skuif die afstandstoegangverbinding bo die fisiese adapter, en verbind dan weer sodat die verandering op 'n nuwe sessie geld.

Bindingsorde is net die eerste helfte. Die kliënt moet ook weet watter name aan daardie adapter behoort, en dit is 'n agtervoegselvraag eerder as 'n ordervraag.

Plaas die werkende masjien se ipconfig /all langs die skootrekenaar s'n, albei geneem terwyl die tonnel op is. Die werkende masjien sal 'n verbinding-spesifieke DNS-agtervoegsel op sy kantooradapter wys, en die skootrekenaar wys dalk niks op die tonnel. Daardie verskil verduidelik 'n hele klas verslae van die aard die bediener is reg daar en die naam misluk steeds, want sonder 'n agtervoegsel word die kort naam nooit voltooi tot die sone wat die kantoorresolver bedien nie.

'n Kort naam het 'n agtervoegsel nodig voordat dit 'n roete nodig het

Om 'n ongekwalifiseerde hostnaam te tik, vra die resolver om 'n domein te raai. Die raaiskoot kom uit die agtervoegsellys wat aan die verbinding gekoppel is, en as daardie lys leeg is, gaan die navraag uit as 'n enkele etiket wat geen private sone sal pas nie.

Kopieer die werkende masjien se agtervoegsel na die VPN-adapter se IPv4-eienskappe op die DNS-oortjie en verbind dan weer. Op Linux is die ekwivalent die soekdomein op die tonnelskakel, wat systemd-resolved per skakel eerder as globaal blootlê.

Hou die twee instellings apart in jou notas. 'n Agtervoegsel verander wat gevra word; die resolveradres verander wie gevra word. Om die een reg te maak terwyl die ander verkeerd is, lewer 'n resultaat wat willekeurig lyk.

Vra die resolver direk, dan die naam

'n Direkte navraag aan die kantoorresolver skei 'n naamprobleem van 'n padprobleem, want dit omseil die kliënt se resolverkeuse heeltemal.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Die eerste opdrag vra 'n spesifieke bediener vir 'n volledig gekwalifiseerde naam. As dit antwoord, is die resolver en die roete daarheen reg en lê die fout by keuse of agtervoegsel. As dit uittyd, is die adres verkeerd of onbereikbaar en is die probleem routering eerder as DNS. Die tweede opdrag wys wat met die kort naam gebeur, en die derde druk die resolverkonfigurasie per skakel op 'n systemd-gasheer.

Let op wildcard-antwoorde, wat sommige netwerke vir onbekende name terugstuur. 'n Antwoord wat geloofwaardig lyk, is nie bewys dat die bedoelde bediener geantwoord het nie, so vergelyk die teruggegewe adres met die een wat die interne diens werklik gebruik. As die adres aan 'n parkeerblad of 'n proxy behoort, het die resolver geantwoord maar die antwoord was nooit joune nie. Daardie onderskeid spaar 'n uur se jaag op 'n tonnel wat die hele tyd gewerk het.

Op Linux vervang 'n VPN-kliënt wat /etc/resolv.conf herskryf die plaaslike resolvers heeltemal. vpnc stel DNSUpdate no bloot om dit te stop, en systemd-resolved kan slegs die gelyste domeine na die tonnelskakel stuur. Albei benaderings hou openbare name by die plaaslike resolver terwyl interne name na die kantoor gestuur word.

Lekke is 'n reël, nie 'n merkblokkie nie

Naamoplossing is 'n UDP-uitruiling na poort 53, so 'n tonnel wat webverkeer maar nie UDP dra nie, laat die navraag op die fisiese pad. Bewys dit deur op die fisiese netwerkkaart vas te vang terwyl 'n openbare naam opgelos word. 'n Navraag wat op daardie koppelvlak in leesbare vorm sigbaar is, beteken die tonnel dra dit nie.

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

As die navraag op daardie koppelvlak in leesbare vorm verskyn, dra die tonnel dit nie. Die herstelling is 'n reël wat poort 53 slegs na die resolver toelaat wat die VPN gestuur het en ander bestemmings laat val, plus 'n kliëntkonfigurasie wat die gestuurde opsie nie stilweg weggooi nie.

Daardie laaste deel maak meer saak as wat dit lyk. Begin OpenVPN met route-nopull en die gestuurde DNS-opsie verdwyn saam met die roetes, tensy die trekfilter verbreed word om dit te hou. En 'n kliënt wat dhcp-option DNS ignoreer, sal bly gebruik wat hy voorheen gehad het. Enige verandering aan die bedienerkant het 'n nuwe sessie nodig om te geld, want die resolverlys word gelewer wanneer die tonnel opkom en 'n verouderde sessie bly die ou toestand wys.

Teken aan watter fout jy werklik waargeneem het voordat jy die kaartjie sluit. 'n Ontbrekende interne antwoord en 'n navraag wat uit die tonnel ontsnap verg verskillende herstellings, en 'n agtervoegselverandering wat die eerste regmaak, kan die tweede stilweg vererger. Wie die kaartjie volgende optel, sal die etiket vertrou, so maak die etiket akkuraat.