Notranja imena ne delujejo prek VPN, javna spletna mesta pa se razrešujejo

En uporabnik poroča, da se ime gostitelja z intraneta ne razreši prek VPN. Drugo poročilo z istega prenosnika pravi, da test uhajanja še vedno kaže poizvedbe, na katere odgovarja lokalni razreševalnik. Zvenita kot ena težava, a sta dve, z različnimi dokazi, in običajno popravilo prve poslabša drugo. Ločite ju, preden se dotaknete katere koli nastavitve.

Dva simptoma, ki nista ena napaka

Neuspešna razrešitev notranjega imena pomeni, da je vprašanje odšlo nekam, kjer zanj nimajo odgovora. Poizvedbe, ki zapuščajo tunel, pomenijo, da je vprašanje odšlo na napačno mesto, tudi ko je bil odgovor na voljo. To sta nasprotni napaki: ena je manjkajoč odgovor, druga je odvečni cilj.

Past je v tem, da dodajanje pisarniškega razreševalnika povsod popravi prvo in zagotovi drugo. Dodajanje javnega razreševalnika povsod naredi obratno.

Obe opažanji zapišite s časovnim žigom, nato po vrsti opravite štiri preverjanja spodaj.

Kateri razreševalnik vmesnika dobi vprašanje

V sistemu Windows odjemalec DNS izbira strežnike po vrstnem redu vezave vmesnikov, vmesnik tunela pa ni samodejno prvi. Odprite napredne nastavitve vmesnika in premaknite povezavo za oddaljeni dostop nad fizični vmesnik, nato se znova povežite, da se sprememba uveljavi v novi seji.

Vrstni red vezave je le prva polovica. Odjemalec mora vedeti tudi, katera imena pripadajo temu vmesniku, in to je vprašanje pripone, ne vrstnega reda.

Položite ipconfig /all delujočega računalnika poleg tistega s prenosnika, oba zajeta pri dvignjenem tunelu. Delujoči računalnik bo na pisarniškem vmesniku pokazal pripono DNS, specifično za povezavo, prenosnik pa na tunelu morda ne bo pokazal nobene. Ta razlika pojasnjuje cel razred poročil, da je strežnik prav tam, ime pa vseeno ne deluje, ker se brez pripone kratko ime nikoli ne dopolni v območje, ki ga oskrbuje pisarniški razreševalnik.

Kratko ime potrebuje pripono prej kot pot

Vnos nekvalificiranega imena gostitelja prosi razreševalnik, naj ugane domeno. Uganka pride s seznama pripon, pritrjenega na povezavo, in če je ta seznam prazen, poizvedba odide kot ena sama oznaka, ki se ji nobena zasebna cona ne bo ujemala.

Kopirajte pripono delujočega računalnika v lastnosti IPv4 vmesnika VPN na zavihku DNS in se znova povežite. V Linuxu je enakovredna iskalna domena na povezavi tunela, ki jo systemd-resolved izpostavi za posamezno povezavo, ne globalno.

Obe nastavitvi imejte v zapiskih ločeni. Pripona spremeni, kaj se vpraša; naslov razreševalnika spremeni, koga se vpraša. Popravilo ene ob napačni drugi da rezultat, ki deluje naključno.

Vprašajte razreševalnik neposredno, nato ime

Neposredna poizvedba pri pisarniškem razreševalniku loči težavo imena od težave poti, ker povsem obide izbiro razreševalnika pri odjemalcu.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Prvi ukaz vpraša določen strežnik za polno kvalificirano ime. Če odgovori, sta razreševalnik in pot do njega v redu, napaka pa je v izbiri ali priponi. Če se izteče, je naslov napačen ali nedosegljiv in težava je v usmerjanju, ne v DNS. Drugi ukaz pokaže, kaj se zgodi s kratkim imenom, tretji pa izpiše konfiguracijo razreševalnika po povezavah na gostitelju s systemd.

Pazite na nadomestne odgovore, ki jih nekatera omrežja vračajo za neznana imena. Verjeten odgovor ni dokaz, da je odgovoril želeni strežnik, zato primerjajte vrnjeni naslov s tistim, ki ga notranja storitev dejansko uporablja. Če naslov pripada parkirni strani ali posredniku, je razreševalnik odgovoril, a odgovor ni bil nikoli vaš. Ta razlika prihrani uro lova za tunelom, ki je ves čas deloval.

V Linuxu odjemalec VPN, ki prepiše /etc/resolv.conf, popolnoma nadomesti lokalne razreševalnike. vpnc izpostavi DNSUpdate no, da to ustavi, systemd-resolved pa lahko na povezavo tunela usmeri le navedene domene. Oba pristopa ohranjata javna imena pri lokalnem razreševalniku, notranja pa pošiljata v pisarno.

Uhajanja so pravilo, ne kljukica

Razreševanje imen je izmenjava UDP na vrata 53, zato tunel, ki prenaša spletni promet, ne pa UDP, pusti poizvedbo na fizični poti. Dokažite to z zajemom na fizični mrežni kartici med razreševanjem javnega imena. Poizvedba, vidna na tem vmesniku v berljivi obliki, pomeni, da je tunel ne prenaša.

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

Če se poizvedba pojavi na tem vmesniku v berljivi obliki, je tunel ne prenaša. Popravilo je pravilo, ki dovoli vrata 53 le razreševalniku, ki ga je potisnil VPN, in zavrže druge cilje, ter konfiguracija odjemalca, ki potisnjene možnosti tiho ne zavrže.

Zadnji del je pomembnejši, kot se zdi. Zaženite OpenVPN s route-nopull in potisnjena možnost DNS izgine skupaj s potmi, razen če se filter pull razširi, da jo obdrži. In odjemalec, ki ignorira dhcp-option DNS, bo še naprej uporabljal, kar je imel prej. Vsaka sprememba na strežniški strani potrebuje novo sejo, saj se seznam razreševalnikov dostavi ob dvigu tunela, zastarela seja pa še vedno kaže staro stanje.

Preden zaprete zahtevek, zapišite, katero napako ste dejansko opazili. Manjkajoč notranji odgovor in poizvedba, ki uide iz tunela, zahtevata različna popravila, sprememba pripone, ki popravi prvo, pa lahko tiho poslabša drugo. Kdor bo zahtevek prevzel naslednji, bo zaupal oznaki, zato naj bo oznaka točna.