Miksi yksityiset DNS-nimet epäonnistuvat VPN-asiakkaissa ja mistä tarkistaa

Avaat kannettavan hotellihuoneessa, käynnistät asiakkaan, kirjoitat sisäisen tiedostopalvelimen nimen etkä saa mitään takaisin. Tunneli ilmoittaa olevansa yhteydessä, ja ping saman aliverkon osoitteeseen vastaa edelleen, joten itse siirto on kunnossa. Vain nimi epäonnistuu, ja tuo aukko rajaa ongelman kahteen paikkaan: mitä ratkaisijaa asiakas kysyi ja voiko saatu vastaus palata tunnelin läpi. Korjaa toinen ja jätä toinen väliin, niin vika vain siirtyy.

Ennen kuin muokkaat yhtään profiilia, varmista, mitä asiakas tekee nimellä. Linuxissa resolvectl query files.corp.example näyttää, mikä linkki ja mikä ratkaisija vastauksen tuottivat. Windowsissa Resolve-DnsName files.corp.example näyttää palvelimen, joka vastasi, ja osoitteen, jonka se palautti.

Lue vastaus ennen kuin muutat mitään

Jos nimi palaa NXDOMAINina muutamassa millisekunnissa, kysely ei koskaan saavuttanut vyöhykettäsi ja jokin julkinen tai hotellin ratkaisija vastasi sen sijaan. Jos se palaa pitkän tauon jälkeen, jokin pudottaa UDP-portin 53 matkalla ja asiakas putosi lopulta varavaihtoehtoon. Jos se vastaa oikealla osoitteella mutta yhteys jatkaa jumittamista, nimihaku on kunnossa ja ongelmasi on reitityksessä tai itse palvelussa.

Tuo kolmijako säästää tunnin arvailua. Se kertoo myös, pitääkö VPN:ään ylipäätään koskea: nimi, joka ratkeaa oikeaksi yksityiseksi osoitteeksi, on jo todistanut ratkaisijan polun, joten jäljellä oleva työ on datapolulla.

Jaa ratkaisija tunnelin sisältä

Asiakkaat jakautuvat kahteen ryhmään. Toiselle palvelin voi antaa ratkaisijan yhteyden muodostuksen aikana; toinen pitää asetuksen paikallisessa tiedostossa, jota mikään yhdyskäytävä ei voi muuttaa etänä.

OpenVPN kuuluu ensimmäiseen ryhmään. Palvelimella push "dhcp-option DNS 10.8.0.53" ja push "dhcp-option DOMAIN corp.example" kulkevat ohjauskanavaa pitkin, mutta vain jos asiakkaan kokoonpanossa pull on yhä käytössä. Käsin muokattu asiakas, jossa on pull-filter ignore "dhcp-option", ei koskaan näe niitä, ja tuo yksi rivi selittää hämmästyttävän monta tapausta, joissa palvelin työntää asetuksen mutta kannettavani on eri mieltä.

WireGuard kuuluu toiseen ryhmään, koska protokollassa ei ole lainkaan vaihtoehtojen neuvottelua. Ratkaisija ja hakutoimialue menevät asiakkaan omaan [Interface]-lohkoon muodossa DNS = 10.8.0.53, corp.example. wg-quick soveltaa sen resolvconfin tai systemd-resolvedin kautta, ja Windowsissa virallinen asiakas asentaa NRPT-säännöt, jotka ovat olemassa vain tunnelin ollessa pystyssä: Get-DnsClientNrptPolicy luettelee ne, mikä tekee siitä nopean tavan nähdä, sovelsiko asiakas tiedostosi koskaan.

IPsec/IKEv2 on siinä välissä. strongSwanin attr-liitännäinen voi palauttaa poolista otetun DNS-palvelimen, ja Windows-asiakas hyväksyy sen yleensä, mutta profiili, joka lukitsee oman nimipalvelimensa, voittaa sen, mitä yhdyskäytävä tarjoaa. Linux-asiakkaalla vastaava manuaalinen vaihe on resolvectl dns wg0 10.8.0.53 ja sen jälkeen resolvectl domain wg0 '~corp.example'; molemmat katoavat rajapinnan mukana, mikä on juuri sitä, mitä tunnelikohtaiselta asetukselta haluat.

Rajaa suffiksi sen sijaan että nielet jokaisen kyselyn

Asiakkaan koko ratkaisijaluettelon osoittaminen sisäiselle palvelimellesi on helppoa ja yleensä väärin. Silloin jokainen julkinen nimi ratkeaa datakeskuksesi ulostulosta, CDN:t palauttavat kaukaisia osoitteita, ja yksi ratkaisijan katkos vie käyttäjän selailun mukanaan.

Lähetä sisäänpäin vain yksityinen suffiksi. systemd-resolvedissa ~-merkillä alkava toimialue on vain reititystä varten, joten ~corp.example tarkoittaa, että kyseisen suffiksin alla olevat kyselyt menevät tuon linkin palvelimille, kun taas kaikki muu käyttää edelleen fyysistä verkkoa. Windows tekee saman nimiavaruuteen rajatuilla NRPT-säännöillä ja macOS lisäratkaisijatiedostolla /etc/resolver/-hakemistossa.

Multicast-nimet ansaitsevat oman vastauksensa. .local-nimet ovat rakenteeltaan link-local (RFC 6762), eikä pisteestä pisteeseen -tun-rajapinta kuljeta tuota multicast-ryhmää, joten julkisen ratkaisijan lisääminen ei julkaise niitä, ja jos niitä kysyy sisäiseltä unicast-ratkaisijalta, vastauksena on NXDOMAIN. Reflektori, kuten avahi reflektoritilassa, voi yhdistää kaksi segmenttiä, mutta se on palvelinpuolen päätös, jota mikään asiakas ei voi pyytää. Jos tulostimen tai NASin on oltava tavoitettavissa nimellä, anna sille sen sijaan A-tietue omalla vyöhykkeelläsi.

Todista, että vastaus voi palata

Oikea vastaus, joka osoittaa saavuttamattomaan osoitteeseen, näyttää täsmälleen ratkaisijaongelmalta, kunnes tarkistat reitin. Kysy ytimeltä, minne vastaus menisi: ip route get 10.20.5.20 nimeää rajapinnan ja hyödyllisemmin lähdeosoitteen, jota se käyttäisi.

Tarkkaile itse ratkaisijan osoitetta. Asiakas, jossa DNS = 10.8.0.53 on AllowedIPs = 10.20.0.0/16:n vieressä, lähettää kyselynsä fyysisen verkkokortin kautta, missä ne kuolevat hiljaa, koska ratkaisija ei ole missään etuliitteessä, jota tunneli vaatii. Tuo epäsuhta on yleisin yksittäinen syy koko tällä alueella, ja se on näkymätön, ellet vertaa DNS-asetusta sallittuihin etuliitteisiin rivi riviltä.

Päällekkäiset alueet aiheuttavat päinvastaisen vian. Vastaus on oikea, reitti on olemassa, ja se osoittaa väärään isäntään, koska kotona 192.168.0.0/24 on tarkempi kuin tunnelin reitti samaan alueeseen. Numeroi toinen puoli uudelleen tai työnnä kapeampi reitti, ja vahvista sitten palvelun isännän palomuuri ja paluupolku; strongSwanin huomautukset edelleenlähetyksestä kattavat tuon polun sysctl-puolen.

Varmenteet ovat erillinen identiteettitarkistus, jonka ihmiset laittavat DNS:n syyksi. Jos selain ilmoittaa nimien epäsuhdasta ratkaisuvirheen sijaan, haku on jo toiminut ja korjattava on varmenteen SAN. Testaa HTTPS:ää nimeä vastaan, älä koskaan paljasta IP:tä vastaan.

Testaa uudelleen asiakkaalta, älä yhdyskäytävältä

Testaa sovelluksessa, josta käyttäjä valittaa, koska komentorivihaku ei todista, että selain kulkee samaa polkua. Chromen suojattu DNS ja Firefoxin network.trr.mode voivat ohittaa järjestelmän ratkaisijan kokonaan, ja kun ne tekevät niin, yksityinen nimi joko epäonnistuu tai vuotaa julkiselle ratkaisijalle. resolvectl query:n vertaaminen käsin ajettuun dig @10.8.0.53 files.corp.example:een kertoo, kumpi näistä tapahtui.

Katkaise sitten yhteys ja yhdistä uudelleen ennen kuin sanot sitä korjatuksi. Rajapinnalle käsin tehdyt asetukset katoavat rajapinnan mukana, ja profiili, joka näytti oikealta vain jäljelle jääneen paikallisen muutoksen ansiosta, pettää seuraavassa käynnistyksessä.

Lyhyt tarkistuslista seuraavalle koneelle: nimi ratkeaa tunnelin ratkaisijan kautta, suffiksi on rajattu eikä globaali, ratkaisijan osoite on sallittujen etuliitteiden sisällä, vastauksen isäntä vastaa palvelun portissa ja varmenne kattaa käyttäjän kirjoittaman nimen.