VPN ühendatud, aga nimed ei tööta: kus DNS tegelikult katkeb

Tunnel on püsti, ikoon roheline ja iga brauserivahekaart teatab nime lahendamise tõrkest. Selle pildi tekitavad kolm erinevat mehhanismi: resolver võib olla kättesaamatu, klient võib küsida resolverit, mida te ei oodanud, või võivad ainult privaatsed nimed ebaõnnestuda. Eraldage need enne, kui muudate midagi tunneli protokollis, sest igaüht parandatakse erinevas kohas. Alljärgnev järjekord algab tähelepanekutega, mis need kolm eraldavad.

Mida päring tegelikult vajab

Päring vajab kolme asja: resolveri aadressi, marsruudi selle aadressini ja küsimusele vastavat vastust. Igaüks neist võib eraldi ebaõnnestuda ja nähtav sümptom on sama lehekülg, mis ei laadi. Seetõttu ei ütle vealehekülg teile peaaegu midagi enne, kui teate, milline kolmest katki on.

Klient õpib oma resolveri VPN-profiilist, tunneli DHCP-st või oma konfiguratsioonist ning see, milline allikas võidab, sõltub platvormist. Windowsis loetleb ipconfig /all DNS-serverid iga adapteri kohta, nii et näete, kas saadetud väärtus kohale jõudis. Saadetud väärtus, mis ei jõudnud kunagi operatsioonisüsteemi, on vaikne ja tavaline tõrge. Lugege konfigureeritud väärtust enne profiili puutumist.

Linux ja macOS vastavad samale küsimusele erinevate käskudega ning vastus väärib sama lugemist: resolvectl status ja scutil --dns mõlemad loetlevad serverid liidese kaupa. Võrrelge seda loendit aadressiga, mille profiil väidab end saatvat. Siinne lahknevus selgitab kõike edasist, seega lahendage see enne nimede testimist.

Testige üht avalikku ja üht privaatset nime

Küsige tavalisest avalikust hostinimest ja dokumenteeritud privaatsest hostinimest samast masinast ning kirjutage üles, milline server kummale vastas. Kui mõlemad ebaõnnestuvad, on resolver või selle marsruut katki. Kui ainult privaatne nimi ebaõnnestub, vastas resolver ja küsimuseks saab tsoon või marsruutimine. Käivitage mõlemad päringud ühe minuti jooksul, et marsruudi muutus ei saaks erinevust selgitada.

Hoidke sisemised nimed avalikest ekraanipiltidest ja avalikest resolveritest eemal. Aegumine ja mitteeksisteeriva domeeni vastus on erinevad tähelepanekud: esimene ütleb, et midagi ei tulnud tagasi, teine, et volitus vastas, et nime ei ole olemas. Kui käsitleda neid ühe veana, satute valele kihile, ja sertifikaadi hoiatus on jälle kolmas asi, mitte DNS-i tõrge.

nslookup prindib nii küsitud serveri kui ka saadud vastuse ning see on täpselt see paar, mida vajate. Käivitage see kaks korda samas kestas ja kirjutage vastav aadress iga vastuse kõrvale.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Kinnitage, et klient pääseb selle serverini tegelikult

Profiili saadetud privaatne resolver on kasulik ainult siis, kui klient pääseb selleni tunneli püsti ajal. Õigena näiv aadress ilma marsruudita tekitab aegumise ja tunneli ühendatud olek ei ütle selle marsruudi kohta midagi. Kontroll on marsruudi otsing, mis on suunatud resolverile endale, mitte VPN-i lõpp-punktile.

Iga platvorm vastab sellele ühe reaga ja väljundis nimetatud liides on kogu vastus. Kui see osutab füüsilisele adapterile, samal ajal kui resolver asub tunneli taga, ei saada profiil eesliidet, mis selle kataks.

ip route get 10.20.30.53                      # Linux
route -n get 10.20.30.53                     # macOS
Find-NetRoute -RemoteIPAddress 10.20.30.53   # Windows PowerShell

Jagatud tunneli profiilis võib resolver asuda saadetud marsruutidest väljaspool, mis on profiili, mitte serveri probleem. Võrrelge resolveri aadressi saadetud eesliidetega ja kinnitage, et üks neist katab selle. Sama lahknevus selgitab, miks DNS töötab ühes võrgus ja ebaõnnestub teises identse profiiliga.

Pidage meeles, et brauserid võivad süsteemi resolverist mööda minna

Turvalise DNS-iga brauser saab saata päringud HTTPS-i kaudu enda valitud teenusepakkujale ja ignoreerida operatsioonisüsteemi resolverit täielikult. Siis näib süsteem korras olevat, samal ajal kui brauser ebaõnnestub, või vastupidi. See on brauseri, mitte tunneli poliitikaküsimus.

Kontrollige brauseri turvalise DNS-i seadet ja kõiki seda juhtivaid haldatud poliitikaid, seejärel proovige teist rakendust või brauserit muutmata tunneliga. Kui ebaõnnestub ainult üks rakendus, kuulub parandus sellesse rakendusse. Privaatne aken ei ole puhas võrdlus, sest see võib ühes brauseris laiendused vaikimisi keelata ja teises mitte, ning see ei möödu kunagi haldatud poliitikast. Kasutage selle asemel teist brauseriprofiili või muud rakendust.

Tühjendage vahemälu ja testige uuesti tegelikku ülesannet

Pärast seade parandamist tühjendage kohalik resolveri vahemälu, et vana vastus ei jääks parandusest kauem kestma. Lühike taastumine, millele järgneb uus tõrge, tähendab, et põhjus on endiselt olemas, mitte et tühjendamine ebaõnnestus. Valige rida, mis vastab masinale, millel olete, sest kolm vahemälu on eraldiseisvad.

ipconfig /flushdns                 # Windows
resolvectl flush-caches            # Linux
sudo killall -HUP mDNSResponder    # macOS

Seejärel korrake algset ülesannet sünteetilise päringu asemel, sest ülesanne on see, mis kasutajat huvitab. Ühenduge ka korra uuesti, et kordustest kataks oleku, milles kasutaja tegelikult on. Microsofti nslookup-i viide on lehekülg, mida tasub päringuargumentide jaoks hoida.

Kui nimed ebaõnnestuvad alles pärast lahtiühendamist, ei taastanud klient eelmist konfiguratsiooni, mis on elutsükli viga, millest tuleb teatada, mitte DNS-server, mida tuleb välja vahetada. Töötav päring ei ole ka lekketest, sest väljundriik ei ütle, milline resolver vastas.