Vidiniai vardai neveikia per VPN, o viešos svetainės atsiveria

Vienas naudotojas praneša, kad intraneto kompiuterio vardas per VPN neišsprendžiamas. Antras pranešimas iš to paties nešiojamojo kompiuterio sako, kad nutekėjimo testas vis dar rodo atsakymus iš vietinio resolverio. Jie skamba kaip viena problema, bet yra dvi su skirtingais įrodymais, o įprastas pirmosios taisymas antrąją padaro blogesnę. Atskirkite jas prieš liesdami bet kurį nustatymą.

Du simptomai, kurie nėra vienas gedimas

Nepavykęs vidinio vardo sprendimas reiškia, kad klausimas nukeliavo ten, kur atsakymo į jį nėra. Užklausos, išeinančios iš tunelio, reiškia, kad klausimas nukeliavo ne ten, net kai atsakymas buvo prieinamas. Tai priešingi gedimai: vienas yra trūkstamas atsakymas, kitas — papildoma paskirties vieta.

Spąstai yra tai, kad biuro resolverio pridėjimas visur ištaiso pirmąjį ir garantuoja antrąjį. Viešo resolverio pridėjimas visur duoda priešingą rezultatą.

Užrašykite abu stebėjimus su laiko žyma, tada iš eilės pereikite keturis patikrinimus žemiau.

Kurio adapterio resolveris gauna klausimą

Windows sistemoje DNS klientas serverius renkasi pagal adapterių susiejimo tvarką, o tunelio adapteris nėra automatiškai pirmas. Atidarykite adapterio išplėstinius nustatymus ir perkelkite nuotolinės prieigos ryšį virš fizinio adapterio, tada prisijunkite iš naujo, kad pakeitimas galiotų naujai sesijai.

Susiejimo tvarka yra tik pirmoji pusė. Klientas taip pat turi žinoti, kurie vardai priklauso tam adapteriui, ir tai yra priesagos, o ne tvarkos klausimas.

Padėkite veikiančio kompiuterio ipconfig /all šalia nešiojamojo, abu paimtus įjungus tunelį. Veikiantis kompiuteris rodys ryšiui būdingą DNS priesagą savo biuro adapteryje, o nešiojamasis gali nerodyti jokios tunelyje. Šis skirtumas paaiškina visą klasę pranešimų „serveris yra čia pat, o vardas vis tiek neveikia“, nes be priesagos trumpas vardas niekada neužbaigiamas iki zonos, kurią aptarnauja biuro resolveris.

Trumpam vardui pirmiausia reikia priesagos, o paskui maršruto

Rašydami nekvalifikuotą kompiuterio vardą prašote resolverio atspėti domeną. Spėjimas gaunamas iš prie jungties prikabintų priesagų sąrašo, o jei sąrašas tuščias, užklausa išeina kaip viena žymė, kurios nesutapatins jokia privati zona.

Nukopijuokite veikiančio kompiuterio priesagą į VPN adapterio IPv4 savybes skirtuke DNS, tada prisijunkite iš naujo. Linux sistemoje atitikmuo yra paieškos domenas tunelio sąsajoje, kurį systemd-resolved rodo kiekvienai sąsajai atskirai, o ne globaliai.

Laikykite abu nustatymus atskirai savo užrašuose. Priesaga keičia, ko klausiama, o resolverio adresas — kam klausiama. Taisant vieną, kai kitas neteisingas, rezultatas atrodo atsitiktinis.

Klauskite resolverio tiesiogiai, tada vardo

Tiesioginė užklausa biuro resolveriui atskiria vardo problemą nuo kelio problemos, nes ji visiškai apeina kliento resolverio pasirinkimą.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Pirmoji komanda konkrečiam serveriui pateikia pilnai kvalifikuotą vardą. Jei ji atsako, resolveris ir kelias iki jo yra geri, o gedimas yra pasirinkime arba priesagoje. Jei baigiasi skirtasis laikas, adresas neteisingas arba nepasiekiamas, ir problema yra maršrutizavimas, o ne DNS. Antroji komanda parodo, kas nutinka su trumpu vardu, o trečioji išspausdina kiekvienos sąsajos resolverio konfigūraciją systemd sistemoje.

Stebėkite pakaitos simbolių atsakymus, kuriuos kai kurie tinklai grąžina nežinomiems vardams. Tikėtinai atrodantis atsakymas neįrodo, kad atsakė numatytas serveris, todėl palyginkite grąžintą adresą su tuo, kurį iš tikrųjų naudoja vidinė tarnyba. Jei adresas priklauso parkavimo puslapiui arba tarpiniam serveriui, resolveris atsakė, bet atsakymas niekada nebuvo jūsų. Šis skirtumas sutaupo valandą, praleistą vejantis tunelį, kuris visą laiką veikė.

Linux sistemoje VPN klientas, perrašantis /etc/resolv.conf, visiškai pakeičia vietinius resolverius. vpnc turi DNSUpdate no, kad to sustabdytų, o systemd-resolved gali nukreipti tik išvardytus domenus į tunelio sąsają. Abu būdai palieka viešus vardus vietiniame resolveryje, o vidinius vardus siunčia į biurą.

Nutekėjimą sprendžia taisyklė, o ne varnelė

Vardų sprendimas yra UDP mainai į 53 uostą, todėl tunelis, kuris praleidžia saityno srautą, bet ne UDP, palieka užklausą fiziniame kelyje. Įrodykite tai fiksuodami fiziniame tinklo adapteryje, kol sprendžiamas viešas vardas. Užklausa, matoma šioje sąsajoje skaitoma forma, reiškia, kad tunelis jos nepraleidžia.

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

Jei užklausa pasirodo šioje sąsajoje skaitoma forma, tunelis jos nepraleidžia. Taisymas yra taisyklė, leidžianti 53 uostą tik VPN perduotam resolveriui ir atmetanti kitas paskirties vietas, kartu su kliento konfigūracija, kuri tyliai neišmeta perduotos parinkties.

Ta paskutinė dalis svarbesnė, nei atrodo. Paleiskite OpenVPN su route-nopull, ir perduota DNS parinktis dingsta kartu su maršrutais, nebent traukimo filtras praplečiamas jai išsaugoti. ir klientas, kuris nepaiso dhcp-option DNS, toliau naudos tai, ką turėjo anksčiau. Bet koks pakeitimas serverio pusėje reikalauja naujos sesijos, kad įsigaliotų, nes resolverių sąrašas pateikiamas tuneliui pakilus, o pasenusi sesija toliau rodo seną būseną.

Užrašykite, kurį gedimą iš tikrųjų pastebėjote, prieš uždarydami užklausą. Trūkstamas vidinis atsakymas ir užklausa, ištrūkusi iš tunelio, reikalauja skirtingų taisymų, o priesagos pakeitimas, ištaisantis pirmąjį, gali tyliai pabloginti antrąjį. Kas perims užklausą toliau, pasitikės žyme, todėl padarykite žymę tikslią.