WireGuard DNS iPhonessa: verkkotunnus on vain hakuliite

Kirjoitat yhden rivin, jossa on resolverin osoite ja yrityksen verkkotunnus, ja odotat, että vain kyseisen verkkotunnuksen nimet käyttävät tunnelin resolveria. Apple-asiakkaassa kaikki nimet menevät nyt sinne, ja myös verkkotunnuksen lyhyet nimet ratkaistaan. Rivi tekee kaksi erillistä asiaa, ja vain toinen niistä koskee sitä, mitä kyselyitä tunneli käsittelee. Toinen on kirjoitusmukavuus, jonka toiveikas lukutapa on ylentänyt käytännöksi.

Mihin DNS-rivi jäsennetään

Asiakas lukee merkinnän listana ja luokittelee jokaisen kohteen muodon perusteella. Kaikki osoitteelta näyttävä muuttuu DNS-palvelimeksi; kaikki verkkotunnukselta näyttävä muuttuu hakuliitteeksi. Molemmat päätyvät tunnelin asetuksiin, mutta eri kenttiin. Havainnollistava rivi tunnelille, joka kantaa yksityistä resolveria ja yhtä sisäistä verkkotunnusta, näyttää tältä.

DNS = 10.24.8.53, lab.internal.example

Osoite tarjoaa resolverin. Verkkotunnus tarjoaa liitteen, jonka avulla asiakas voi kirjoittaa lyhyen nimen ja järjestelmä lisää loput ennen kysymistä. Kumpikaan kohta ei kerro mitään resolverin rajaamisesta tuohon verkkotunnukseen, ja juuri sitä ihmiset odottavat eivätkä saa. Vain yksi kenttä alustassa voi ilmaista tämän rajoituksen, eikä se ole tämä kenttä.

Kaksi Applen kenttää, kaksi eri tehtävää

Apple tuo eron esiin DNS-asetusobjektissaan. Hakuverkkotunnusten luettelo on dokumentoitu luetteloksi, jota käytetään yksiosaisien isäntänimien kvalifiointiin: kirjoita paljas isäntänimi ja järjestelmä voi liittää jokaisen liitteen vuorollaan. Se on täydennyssääntö, ei reitityssääntö. Mikään tuossa luettelossa ei päätä, miltä palvelimelta kysytään.

Vastaavuusverkkotunnusten luettelo on eri ominaisuus. Se päättää, mitkä nimiavaruudet käyttävät tätä DNS-asetusjoukkoa, ja tyhjä merkintä tarkoittaa oletusverkkotunnusta eikä yhtä tiettyä liitettä. pakettitunnelin asetusten generaattori Apple-asiakkaassa seuraa tätä mallia. Se laittaa jäsennetyt hakuliitteet hakuluetteloon ja asettaa vastaavuusluettelon tyhjäksi merkkijonoksi, kun palvelimia on läsnä. Tuloksena on tunnelin resolver, joka vastaa kaikkeen, mitä järjestelmä sille lähettää, sekä liite, joka auttaa lyhyissä nimissä.

Verkkotunnus tuolla rivillä ei siis ole nimiavaruuden valitsin. Toisen lisääminen ei kavenna sitä, mitä kyselyitä tunneli käyttää, eikä sen poistaminen laajenna niitä. Ainoa muuttuva asia on se, kuinka monta lyhyttä nimeä täydennetään.

Miksi jokainen nimi silti saavuttaa tunnelin resolverin

Tyhjällä vastaavuusmerkinnällä tunneli on ehdokasresolver tavallisille nimille, ei vain yrityksen verkkotunnukselle. Täystunneliasetuksessa tällä on yleensä vähän merkitystä, koska kaikki liikenne on joka tapauksessa tunnelissa. Jaetussa tunnelissa sillä on suuri merkitys. Julkiset nimet voivat nyt ratketa resolverilla, jolla on vain yksityinen vyöhyke, ja epäonnistuminen näyttää rikkinäiseltä VPN:ltä, vaikka kyse on resolverista, joka vastaa vain osaan nimiavaruudesta. Tunneli on kunnossa, kyselyt lähtevät ja vastaukset tulevat tyhjinä takaisin.

Saatavilla on kaksi korjausta ja ne ovat eri päätöksiä. Tee tunnelin resolverista täydellinen resolver, joka välittää julkiset nimet hyväksyttyä polkua pitkin, tai lopeta julkisten nimien lähettäminen sinne muuttamalla asiakkaan kokoonpanoa verkkotunnusluettelon sijaan. Ensimmäinen pitää jokaisen kyselyn tunnelissa ja luottaa ylävirtaan. Toinen pitää osan kyselyistä paikallisina ja hyväksyy, että yksityiset nimet voivat lakkautua ratkeamasta, kun tunneli on alhaalla.

Mitä jaettu DNS itse asiassa vaatisi

Nimiavaruuteen rajattu resolverikäytäntö vaatii asiakkaan, joka sallii sinun ilmaista sen: sovita verkkotunnuksia Applen alustoilla tai käytä vastaavaa asetusta tuotteessa, jota käytät. Kokoonpanokenttä, joka hyväksyy vain palvelimia ja liitteitä, ei voi ilmaista sitä, miten tahansa välimerkitettynä. Profiili voi kantaa käytännön, koska se kuvaa hallittua kokoonpanoa eikä yhdistämishetken vihjettä. Se voi nimetä verkkotunnuksen, palvelimet ja sen, mitä pitäisi tapahtua, kun tuo verkkotunnus ei ole tavoitettavissa. Se on ero asetuksen ja sopimuksen välillä.

Hallituissa Apple-laitteissa tämä toimitetaan yleensä kokoonpanoprofiilin kautta, joka kantaa verkkotunnuskohtaiset DNS-asetukset. Se on eri mekanismi kuin WireGuardin kokoonpanotiedosto, ja molemmat voivat olla olemassa yhdessä vain, jos asiakas kunnioittaa profiilia. Tarkista, miksi asiakkaasi itse asiassa kutsuu kenttää, ennen kuin oletat, että kaksi tuotetta käyttäytyvät samoin. Skripti wg-quick Macissa ja iPhonen WireGuard-sovellus lukevat samankaltaisia rivejä ja asentavat ne eri kerrosten kautta.

Lue asennetut asetukset, älä kokoonpanoa

Macissa voit tarkastella, mihin järjestelmä päätyi, mikä on valaisevampaa kuin kirjoittamasi tiedoston uudelleen lukeminen. Resolveriluettelo näyttää, mitkä palvelimet on määritetty mille verkkotunnuksille, ja rajatuista kyselyistä näkee, kumpi voitti. Asiakas, joka sotkee rivin, näyttää sen täällä eikä kirjoittamassasi tiedostossa. iOS:ssä ei ole vastaavaa komentoriviä, joten todiste siellä on tulos: yksityinen nimi, joka ratkeaa tunnelin kautta, ja julkinen nimi, jonka vastaus paljastaa, mikä resolver vastasi.

scutil --dns | grep -A3 resolver
networksetup -getdnsservers Wi-Fi

Nämä kaksi komentoa tulostavat nykyisen resolverikokoonpanon ja aktiivisen palvelun DNS-palvelimet. Jos tunnelin resolver näkyy oletusresolverina ilman verkkotunnusrajoitusta, kokoonpano tekee täsmälleen sen, mitä asiakas pyysi. Korjaa se muuttamalla mekanismia, ei lisäämällä toista liitettä ja toivomalla, että käyttäytyminen muuttuu.