macOSissa kolmeen eri kysymykseen vastataan samalla olankohautuksella. Mikä asiakasohjelma tämä on? Mistä sen DNS-palvelimet tulevat? Ja kun asetus on paikallaan, miksi lyhyt nimi epäonnistuu silti? Niillä on erilliset vastaukset, ja vain ensimmäinen koskee profiilitiedostoa. Oikea järjestys muuttaa epämääräisen DNS-ongelman yhdeksi todennettavaksi askeleeksi kerrallaan.

Varmista, mitä asiakasohjelmaa määrität

Tämä on Microsoftin Azure VPN Client, joka käyttää OpenVPN-ohjelmaa piste-paikka-yhteyteen. Sen XML ei ole macOSin natiivi IKEv2-profiili eikä myöskään minkään kolmannen osapuolen OpenVPN-asiakasohjelman asetustiedosto.

Jos Mac yhdistää sisäänrakennetun järjestelmävalintaikkunan kautta, olet väärässä asiakirjassa.

DNS asuu profiilin XML:n sisällä

Lataa nykyinen profiili halutulle yhdyskäytävälle ja todennusmenetelmälle ja säilytä sitten muuttumaton kopio ennen kuin kosket mihinkään. Muokkaa vain työkopiota äläkä liitä sen todennusmateriaalia tukipyyntöön.

Valinnaisten asetusten opas sijoittaa DNS-merkinnät clientconfig-elementin sisään. Minimaalinen katkelma näyttää tältä, ja siinä on osoite, jota organisaatiosi todella käyttää.

<clientconfig>
    <dnsservers>
        <dnsserver>10.20.2.4</dnsserver>
    </dnsservers>
</clientconfig>

Tuo osoite on havainnollinen, ei Azuren tarjoama resolver. Yhdistä merkinnät olemassa olevaan kokoonpanoon sen sijaan, että liittäisit toisen clientconfig-elementin, koska Microsoft ilmoittaa, että päällekkäisiä elementtejä ei tueta macOSissa. Luodut profiilit voivat sisältää myös nil-paikkamerkin siinä, mihin varsinainen kokoonpano kuuluu, eikä asetusten lisääminen nil-elementin viereen ole korjaus.

Tuonti on muutos

Tiedoston tallentaminen ei itsessään muuta mitään. Avaa Azure VPN Client, valitse Import, valitse muokattu XML, täytä vaaditut kentät ja tallenna yhteys.

Yhdistä sitten uudelleen tämän tuodun yhteyden kautta. Levyllä oleva profiili, kun vanhempi yhteys pysyy aktiivisena, on yleisin syy siihen, että oikea muokkaus näyttää tekevän ei mitään.

Pääterajoitus ratkaisee ensimmäisen testin

Kuten 30. lokakuuta 2026 on dokumentoitu, ylimääräiset DNS-päättearvot eivät säily tässä kokoonpanossa oikein macOSissa. Windowsin pääte-esimerkin kopioiminen ja saman käyttäytymisen lupaaminen on se tapa, jolla toimiva resolver raportoidaan rikkinäisenä. Syötä päätteet, tallenna, yhdistä uudelleen ja tarkista, selvisivätkö ne uudelleenyhdistämisestä. Jos eivät, suunnittele täysin kelvollisten nimien varaan sen sijaan, että taistelet asiakasohjelman kanssa.

Testaa ensin täysin kelvollisella yksityisellä isäntänimellä. Jos FQDN ratkeaa mutta lyhyt nimi ei, opit jotain konkreettista: resolver on tavoitettavissa ja lyhyiden nimien laajennus puuttuu. Se on eri vika kuin tavoittamaton DNS-palvelin, ja se tarvitsee eri omistajan.

Resolver tarvitsee silti polun

Osoitteen listaaminen XML:ssä ei luo DNS-palvelua. Osoitteella on pyöritettävä valtuutettua resolveria, joka voi vastata yksityiseen nimiavaruuteen tai välittää sen eteenpäin, ja Macilla on oltava lupa tavoittaa se tunnelin kautta. Jos tämä resolver on palomuurisäännön takana, joka ei tunne tunnelin aluetta, kyselyt aikakatkaistaan ilman hyödyllistä virhettä. Silloin aikakatkaisu näyttää täsmälleen väärältä osoitteelta, ja ihmiset muokkaavat XML:ää uudelleen tunnin ajan.

Tarkista yhdistetyn Macin aktiivinen resolver-tila ja kysy sitten kyseiseltä palvelimelta suoraan erottaaksesi sen vastauksen sovelluksen resolver-valinnasta. Suora kysely todistaa, että palvelin toimii. Se ei todista, että tavalliset haut valitsevat sen.

Luovuta kolme erillistä tulosta

Pidä ne erillään luovutuksessa: muokattu profiili tuotiin, aiottu resolver vastasi pyydettyyn nimeen ja sovellus saavutti palautetun osoitteen. Jokaisella on eri omistaja ja eri korjaus.

Yksi rivi tulosta kohden riittää, ja se estää seuraavaa henkilöä muokkaamasta uudelleen profiilia, joka oli jo oikein.

Aiheeseen liittyvät artikkelit