VPN yhdistetty, mutta nimet epäonnistuvat: missä DNS todella katkeaa

Tunneli on pystyssä, kuvake vihreä ja jokainen selaimen välilehti ilmoittaa nimenratkaisun epäonnistumisesta. Kuvan tuottaa kolme eri mekanismia: resolveri voi olla tavoittamaton, asiakas voi kysellä resolverilta, jota et odottanut, tai vain yksityiset nimet voivat epäonnistua. Erota ne ennen kuin muutat mitään tunnelin protokollassa, sillä jokainen korjataan eri paikassa. Alla oleva järjestys alkaa havainnoista, jotka erottavat kolme toisistaan.

Mitä haku todella tarvitsee

Haku tarvitsee kolme asiaa: resolverin osoitteen, reitin siihen osoitteeseen ja kysymykseen sopivan vastauksen. Jokainen voi epäonnistua yksinään, ja näkyvä oire on sama sivu, joka ei lataudu. Siksi virhesivu ei kerro juuri mitään ennen kuin tiedät, mikä kolmesta meni rikki.

Asiakas oppii resolverinsa VPN-profiilista, tunnelin DHCP:stä tai omasta kokoonpanostaan, ja se, mikä lähde voittaa, riippuu alustasta. Windowsissa ipconfig /all luettelee DNS-palvelimet sovitinkohtaisesti, joten näet, saapuiko lähetetty arvo todella perille. Lähetetty arvo, joka ei koskaan saavuttanut käyttöjärjestelmää, on hiljainen ja yleinen vika. Lue määritetty arvo ennen profiilin koskemista.

Linux ja macOS vastaavat samaan kysymykseen eri komennoilla, ja vastaus ansaitsee saman lukemisen: resolvectl status ja scutil --dns molemmat luettelevat palvelimet liittymäkohtaisesti. Vertaa sitä luetteloa osoitteeseen, jonka profiili väittää lähettävänsä. Epäjohdonmukaisuus tässä selittää kaiken alavirtaan, joten selvitä se ennen nimien testaamista.

Testaa yksi julkinen ja yksi yksityinen nimi

Kysy tavallista julkista isäntänimeä ja dokumentoitua yksityistä isäntänimeä samasta koneesta ja kirjaa, mikä palvelin vastasi kumpaankin. Jos molemmat epäonnistuvat, resolveri tai sen reitti on rikki. Jos vain yksityinen nimi epäonnistuu, resolveri vastasi ja kysymys muuttuu vyöhykkeeksi tai reititykseksi. Suorita molemmat kyselyt minuutin sisällä toisistaan, jotta reittimuutos ei voi selittää eroa.

Pidä sisäiset nimet poissa julkisista kuvakaappauksista ja julkisista resolvereista. Aikakatkaisu ja vastaus olemattomasta verkkotunnuksesta ovat eri havaintoja: ensimmäinen sanoo, ettei mitään tullut takaisin, toinen, että auktoriteetti vastasi nimen puuttuvan. Jos käsittelet niitä yhtenä virheenä, päädyt väärälle kerrokselle, ja varoitus varmenteesta on taas kolmas asia, ei DNS-vika.

nslookup tulostaa sekä palvelimen, jolta kysyttiin, että saadun vastauksen, ja se on täsmälleen se pari, jonka tarvitset. Suorita se kahdesti samassa kuoressa ja kirjoita vastaava osoite jokaisen vastauksen viereen.

nslookup example.com
nslookup host.corp.example 10.20.30.53

Varmista, että asiakas todella tavoittaa kyseisen palvelimen

Profiilin lähettämä yksityinen resolveri on hyödyllinen vain, jos asiakas tavoittaa sen tunnelin ollessa pystyssä. Oikealta näyttävä osoite ilman reittiä tuottaa aikakatkaisun, eikä tunnelin yhdistetty tila kerro mitään siitä reitistä. Tarkistus on reittihaku, joka kohdistuu itse resolveriin, ei VPN:n päätepisteeseen.

Jokainen alusta vastaa siihen yhdellä rivillä, ja tulosteessa nimetty liittymä on koko vastaus. Jos se osoittaa fyysiseen sovittimeen samalla kun resolveri on tunnelin takana, profiili ei lähetä etuliitettä, joka kattaisi sen.

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

Jaetun tunnelin profiilissa resolveri voi olla lähetettyjen reittien ulkopuolella, mikä on profiilin eikä palvelimen ongelma. Vertaa resolverin osoitetta lähetettyihin etuliitteisiin ja varmista, että yksi niistä kattaa sen. Sama epäjohdonmukaisuus selittää, miksi DNS toimii yhdessä verkossa ja epäonnistuu toisessa samanlaisella profiililla.

Muista, että selaimet voivat ohittaa järjestelmän resolverin

Selain, jossa suojattu DNS on käytössä, voi lähettää kyselyitä HTTPS:n kautta itse valitsemalleen palveluntarjoajalle ja jättää käyttöjärjestelmän resolverin kokonaan huomiotta. Silloin järjestelmä näyttää oikealta, kun selain epäonnistuu, tai päinvastoin. Se on selaimen, ei tunnelin, käytäntökysymys.

Tarkista selaimen suojatun DNS:n asetus ja kaikki sitä ohjaavat hallitut käytännöt ja kokeile sitten toista sovellusta tai selainta tunnelin pysyessä ennallaan. Jos vain yksi sovellus epäonnistuu, korjaus kuuluu siihen sovellukseen. Yksityinen ikkuna ei ole puhdas vertailu, koska se voi poistaa laajennukset käytöstä oletuksena yhdessä selaimessa ja toisessa ei, eikä se koskaan ohita hallittua käytäntöä. Käytä sen sijaan toista selainprofiilia tai toista sovellusta.

Tyhjennä välimuisti ja testaa todellinen tehtävä uudelleen

Kun olet korjannut asetuksen, tyhjennä paikallinen resolverin välimuisti, jotta vanha vastaus ei jää elämään korjauksen jälkeen. Lyhyt toipuminen ja uusi epäonnistuminen tarkoittaa, että syy on yhä olemassa, ei että tyhjennys epäonnistui. Valitse rivi, joka vastaa konetta, jolla olet, koska kolme välimuistia ovat erillisiä.

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

Toista sitten alkuperäinen tehtävä synteettisen haun sijaan, koska tehtävä on se, mikä käyttäjää kiinnostaa. Yhdistä myös kerran uudelleen, jotta uusintatesti kattaa tilan, jossa käyttäjä todella on. Microsoftin nslookup-viite on sivu, joka kannattaa pitää kyselyn argumentteja varten.

Jos nimet epäonnistuvat vasta irrotuksen jälkeen, asiakas ei palauttanut edellistä kokoonpanoa, mikä on elinkaarivirhe, josta pitää raportoida, ei DNS-palvelin, joka pitää vaihtaa. Toimiva hakukaan ei ole vuototesti, koska lähtömaa ei kerro, mikä resolveri vastasi.