Jaettu DNS ja VPN: verkkotunnussäännöt eivät ole IP-reittejä
Jaettu DNS valitsee ratkaisijan nimen perusteella, ja vastaus tarvitsee silti reitin. Testaa verkkotunnussääntö ja polku erikseen, alustalla jota todella käytät.
Kannettavasi ratkaisee intranet.corpin tunnelin kautta, kun taas gitlab.com menee edelleen palveluntarjoajan ratkaisijalle, ja se on järjestely, joka toimii suunnitellusti. Kaksi erillistä päätöstä tuotti sen: nimen täsmäytyssääntö valitsi ratkaisijan ja reitti toi vastauksen takaisin. Riko kumpi tahansa, niin selain näyttää virheen, joka näyttää ulkoapäin samalta. Useimmat jaetun DNS:n raportit kuvaavat toista virhettä ja lainaavat samalla todisteita ensimmäisestä.
Kaksi puoliskoa elävät eri paikoissa, ja yleensä eri ihmiset muokkaavat niitä. Toinen on VPN-profiiliin liitetty DNS-käytäntö, toinen on reitti, jonka tunneli asentaa tai jättää asentamatta. Vianetsintä pysähtyy, kun kukaan ei selvitä, kumpi puolisko todella liikkui.
Kaksi päätöstä yhden pyynnön sisällä
Nimipuolisko on käytäntöobjekti, ei reitti. Windowsissa se on nimenratkaisukäytäntö VPN-profiilissa; Applen alustoilla joukko täsmäytysverkkotunnuksia DNS-asetusobjektissa; Linuxissa reititysverkkotunnus, jaetun ratkaisijan rivi tai nimipalvelun vaihtimen järjestys. Reittipuolisko on tavallista reititystä, jonka tunneli tai käsi asentaa, eikä sillä ole aavistustakaan, mikä isäntänimi on. Profiili, joka sallii päätteen, päättää vain kuka vastaa; se ei koskaan tee vastauksesta tavoitettavaa.
Nopea oiretesti erottaa ne: korvaa nimi osoitteella. Jos osoite toimii, reitti on kunnossa ja sääntö väärä. Jos myös osoite epäonnistuu, sääntö voi olla oikea ja reitti puuttua.
Miten kukin alusta ilmaisee saman nimisäännön
Tarkoitus on sama eivätkä kenttien nimet ole. Esimerkki, joka kopioidaan asiakkaasta toiseen, jäsennetään siististi eikä koskaan täsmää. Kolme muotoa näyttävät tältä:
| Platform | Where the rule lives | What usually breaks |
|---|---|---|
| Windows | name-resolution policy on the VPN profile | precedence against the interface suffix list |
| Apple platforms | match domains on the DNS settings object | domains attached to the wrong extension |
| Linux | routing domain, split resolver, nsswitch order | the suffix written the wrong way round |
Täsmäytys- tai reititysverkkotunnus on päätetesti, joten intranet.corp kattaa git.intranet.corpin eikä kata corp.intranetiä, ja sen kääntäminen väärinpäin on koko asetelman yleisin virhe. Windows kantaa kuvauksen profiiliin liitettynä nimenratkaisukäytäntönä, jolla on oma tärkeysjärjestyksensä mitä tahansa liitännällä jo ollutta pääteluetteloa vastaan. Applen alustat liittävät täsmäytysverkkotunnukset verkkolaajennuksen DNS-asetusobjektiin, ja järjestelmä soveltaa niitä jokaista rajattuun ratkaisijaan. Mikään näistä muodoista ei ole reitti, eikä mikään voi tehdä tavoittamattomasta osoitteesta tavoitettavaa. Viite Windowsin nimenratkaisukäytäntö luettelee kyseisen alustan kenttien nimet ja tärkeyssäännöt, eivätkä ne ole ne, joita Applen tai systemdin asiakirjat käyttävät.
Oikea vastaus tarvitsee silti reitin
Ratkaisijan vastaus on vain osoite, ja sovelluksen on silti päästävä siihen. Jaetun tunnelin suunnittelu työntää usein 10.20.0.0/16:n ja pidättää oletusreitin, joten sisäinen nimi ratkeaa ja yhteys jää sitten roikkumaan. Vastakkainen tapaus on yhtä yleinen: reitti on olemassa, julkinen ratkaisija vastaa yksityiseen nimeen NXDOMAINilla ja vika kirjataan reititysongelmaksi. Reitin testaaminen ensin jättää sinut tuijottamaan reittejä nimeä varten, jota ei koskaan ollut tarkoitus ratkaista.
On myös kolmas portti, jota kumpikaan puolisko ei kata. Yhdyskäytävän ACL, palomuurisääntö tai asiakaspuolen käytäntö voi pudottaa yhteyden sen jälkeen, kun molemmat päätökset olivat oikein. Kun nimi ratkeaa, reitti on olemassa ja yhteys silti aikakatkeaa, lopeta DNS:n testaaminen.
Nimien ja reittien testaaminen kiinteässä järjestyksessä
Valitse järjestys ja pidä siitä kiinni, muuten jahtaat vaihetta, joka epäonnistui viimeksi. Ratkaise dokumentoitu täydellinen sisäinen nimi, vahvista, että vastaus on osoite, jonka reititystaulu pystyy kantamaan, ja toista sitten julkisella nimellä todistaaksesi, ettei tunneli kaapannut kaikkea. systemd-isännässä kysely ja ratkaisijan reititysverkkotunnus ovat yhden komennon päässä toisistaan:
resolvectl query intranet.corp
resolvectl domain
ip route get 10.20.5.10Windows-asiakas kysyy samat kaksi kysymystä eri cmdlet-komennoilla. Toinen ilmoittaa liitännän, jota järjestelmä todella käyttäisi:
Resolve-DnsName intranet.corp -Type A
Find-NetRoute -RemoteIPAddress 10.20.5.10Jos haku palauttaa osoitteen ja reittitarkistus nimeää fyysisen liitännän, nimisääntö toimi eikä reitti. Jos lyhyt nimi epäonnistuu täydellisen nimen ratketessa, pääteluettelo on väärä eikä ratkaisija.
Missä vertailu yleensä menee pieleen
Ensimmäinen virhe on kysyä asiaankuulumattomalta julkiselta ratkaisijalta yksityistä nimeä ja lukea kieltäytyminen todisteeksi VPN:stä. Toinen on olettaa, että toimiva julkinen haku todistaa tunnelin ratkaisijareitin. Kolmas on kohdella jaettua tunnelointia ja jaettua DNS:ää yhtenä suunnittelupäätöksenä, vaikka käyttöönotto voi olla oikein toisessa ja rikki toisessa. Jokainen virhe tuottaa varmoja johtopäätöksiä testistä, joka ei koskaan harjoittanut syytettyä osaa.
Selain, jolla on oma suojattu DNS, voi myös ohittaa järjestelmän säännön, minkä vuoksi se, että yksi selain epäonnistuu toisen onnistuessa, ei ole ristiriita. Vertaa ratkaisijaa, joka vastasi, älä selainta, joka valitti.
Kun molemmat puoliskot ovat näkyvissä, jäljellä oleva kysymys on käytäntökysymys eikä tekninen: mitkä nimiavaruudet kuuluvat organisaatiolle, kuka omistaa kunkin vastauksen ja mitkä niistä pitäisi ylipäätään päästää koneesta. Kirjoita se profiilin viereen, koska seuraava sääntöön koskeva tarvitsee sitä.