Sisemised nimed ei toimi VPN-is, avalikud saidid avanevad

Üks kasutaja teatab, et intraneti hostinimi ei lahene VPN-i kaudu. Teine raport samast sülearvutist ütleb, et lekketest näitab endiselt päringuid, millele vastab kohalik resolver. Need kõlavad nagu üks probleem, aga neid on kaks, erinevate tõenditega, ja esimese tavaline parandus teeb teise hullemaks. Eraldage need enne, kui puudutate ühtki seadet.

Kaks sümptomit, mis ei ole üks viga

Sisemise nime lahendamise ebaõnnestumine tähendab, et küsimus läks kuhugi, kus sellele vastust ei ole. Tunnelist lahkuvad päringud tähendavad, et küsimus läks valesse kohta ka siis, kui vastus oli saadaval. Need on vastandlikud vead: üks on puuduv vastus, teine on üleliigne sihtkoht.

Lõks on selles, et kontori resolveri lisamine kõikjale parandab esimese ja garanteerib teise. Avaliku resolveri lisamine kõikjale teeb vastupidist.

Kirjutage mõlemad tähelepanekud ajatempliga üles ja käige seejärel allpool olevad neli kontrolli järjekorras läbi.

Millise adapteri resolveri küsimus saab

Windowsis valib DNS-klient serverid adapterite sidumisjärjekorra järgi ja tunneladapter ei ole automaatselt esimene. Avage adapteri täpsemad seaded ja liigutage kaugjuurdepääsuühendus füüsilise adapteri kohale, seejärel ühenduge uuesti, et muudatus kehtiks uues seansis.

Sidumisjärjekord on ainult esimene pool. Klient peab ka teadma, millised nimed kuuluvad selle adapteri juurde, ja see on sufiksi, mitte järjekorra küsimus.

Pange töötava masina ipconfig /all väljund sülearvuti väljundi kõrvale, mõlemad võetud tunneliga üleval. Töötav masin näitab oma kontoriadapteril ühenduspõhist DNS-sufiksit ja sülearvuti ei pruugi tunnelil ühtegi näidata. See erinevus seletab tervet raportite klassi stiilis server on ju siinsamas ja nimi ikka ei lahene, sest ilma sufiksita ei täiendu lühinimi kunagi tsooniks, mida kontori resolver teenindab.

Lühinimi vajab sufiksit enne, kui vajab marsruuti

Kvalifitseerimata hostinime tippimine palub resolveril domeeni ära arvata. Oletus tuleb ühenduse külge kinnitatud sufiksiloendist ja kui see loend on tühi, läheb päring välja üksiku sildina, millega ükski privaatne tsoon ei klapi.

Kopeerige töötava masina sufiks VPN-adapteri IPv4-omadustesse DNS-vahelehel ja ühenduge uuesti. Linuxis on vasteks tunnelilingi otsingudomeen, mida systemd-resolved näitab lingi kaupa, mitte globaalselt.

Hoidke kahte seadet märkmetes eraldi. Sufiks muudab seda, mida küsitakse; resolveri aadress muudab seda, kellelt küsitakse. Ühe parandamine, kui teine on vale, annab tulemuse, mis näib juhuslik.

Küsige resolverilt otse, seejärel nimelt

Otsene päring kontori resolverile eraldab nimeprobleemi teeprobleemist, sest see läheb klienti resolverivalikust täielikult mööda.

nslookup intranet.corp.example 10.20.0.53
nslookup intranet
resolvectl status

Esimene käsk küsib kindlalt serverilt täielikult kvalifitseeritud nime. Kui see vastab, on resolver ja tee sinna korras ning viga on valikus või sufiksis. Kui aeg lõpeb, on aadress vale või kättesaamatu ja probleem on marsruutimises, mitte DNS-is. Teine käsk näitab, mis juhtub lühinimega, ja kolmas trükib resolveri seadistuse lingi kaupa systemd-hostis.

Pöörake tähelepanu metamärk-vastustele, mida mõned võrgud tundmatute nimede jaoks tagastavad. Usutav vastus ei tõesta, et vastas soovitud server, seega võrrelge tagastatud aadressi sellega, mida sisemine teenus tegelikult kasutab. Kui aadress kuulub parkimislehele või puhverserverile, vastas resolver, aga vastus ei olnud kunagi teie oma. See vahe säästab tunni aega tagaajamist tunnelil, mis töötas kogu aeg.

Linuxis asendab VPN-klient, mis kirjutab üle /etc/resolv.conf, kohalikud resolverid täielikult. vpnc paljastab DNSUpdate no, et seda takistada, ja systemd-resolved saab tunnelilingile suunata ainult loetletud domeenid. Mõlemad lähenemised hoiavad avalikud nimed kohalikus resolveris ja saadavad sisemised nimed kontorisse.

Lekked on reegel, mitte märkeruut

Nimelahendus on UDP-vahetus pordil 53, seega tunnel, mis kannab veebiliiklust, aga mitte UDP-d, jätab päringu füüsilisele teele. Tõestage seda füüsilisel võrgukaardil püüdes, kui avalikku nime lahendatakse. Päring, mis on sellel liidesel loetaval kujul nähtav, tähendab, et tunnel ei kanna seda.

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

Kui päring ilmub sellel liidesel loetaval kujul, siis tunnel ei kanna seda. Parandus on reegel, mis lubab porti 53 ainult resolverile, mille VPN läbi surus, ja viskab kõrvale muud sihtkohad, pluss kliendi seadistus, mis ei viska läbi surutud valikut vaikselt kõrvale.

See viimane osa loeb rohkem, kui paistab. Käivitage OpenVPN valikuga route-nopull ja läbi surutud DNS-valik kaob koos marsruutidega, kui tõmbe filter ei laiene, et seda alles hoida. Ja klient, mis ignoreerib valikut dhcp-option DNS, jätkab selle kasutamist, mis tal enne oli. Iga muudatus serveri poolel vajab kehtimiseks uut seanssi, sest resolverite loend antakse üle tunnelil tõustes ja vana seanss näitab endiselt vana olekut.

Pange kirja, millist viga te tegelikult nägite, enne kui pileti sulgete. Puuduv sisemine vastus ja tunnelist põgenev päring nõuavad erinevaid parandusi ning sufiksi muudatus, mis parandab esimese, võib teise vaikselt hullemaks teha. Kes pileti järgmisena võtab, usaldab silti, seega tehke silt täpseks.