Azure VPN Client sur Mac: metu la DNS-servilojn en la profilon

DNS por Azure VPN Client sur macOS troviĝas en la importita profila XML. Redaktu, importu kaj rekonektu, poste aparte testu la solvigan vojon.

Sur macOS, tri malsamaj demandoj ricevas la saman ŝultrolevon. Kiu kliento estas ĉi tio? De kie venas ĝiaj DNS-serviloj? Kaj post kiam la agordo estas en loko, kial mallonga nomo ankoraŭ malsukcesas? Ili havas apartajn respondojn, kaj nur la unua koncernas la profilan dosieron. La ĝusta ordo transformas neklaran DNS-problemon en unu konfirmeblan paŝon samtempe.

Konfirmu kiun klienton vi agordas

Ĉi tio estas la Azure VPN Client de Microsoft, kiu uzas OpenVPN por aliro de punkto al ejo. Ĝia XML ne estas denaska macOS IKEv2-profiprofilo, kaj ankaŭ ne estas agorda dosiero por ĉiu triapartia OpenVPN-kliento.

Se la Mac konektiĝas per la enkonstruita sistema dialogo, vi estas en la malĝusta dokumento.

DNS loĝas interne de la profila XML

Elŝutu la nunan profilon por la celata enirejo kaj aŭtentiga metodo, poste konservu neŝanĝitan kopion antaŭ ol tuŝi ion. Redaktu nur la laboran kopion, kaj ne algluu ĝian aŭtentigan materialon en subtena bileto.

La gvidilo pri laŭvolaj agordoj metas la DNS-rikordojn ene de elemento clientconfig. Minimuma fragmento aspektas tiel, kun adreso, kiun via organizo vere funkciigas.

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

Tiu adreso estas ilustra, ne solvilo provizita de Azure. Integru la rikordojn en la ekzistantan agordon anstataŭ alglui duan elementon clientconfig, ĉar Microsoft deklaras, ke duobligitaj elementoj ne estas subtenataj sur macOS. Generitaj profipoj ankaŭ povas havi nil-lokotenanton tie, kie apartenas la vera agordo, kaj aldoni agordojn apud nil-elemento ne estas riparo.

La importo estas la ŝanĝo

Konservi la dosieron mem ŝanĝas nenion. Malfermu Azure VPN Client, elektu Import, elektu la reviziitan XML, plenigu la postulatajn kampojn kaj konservu la konekton.

Poste rekonektu per tiu importita konekto. Profilo kuŝanta sur la disko dum pli malnova konekto restas aktiva estas la plej ofta kialo, ke ĝusta redakto ŝajnas fari nenion.

La sufiksa limigo decidas vian unuan teston

Kiel dokumentite la 30-an de oktobro 2026, pliaj DNS-sufiksaj valoroj en ĉi tiu agordo ne restas ĝuste sur macOS. Kopii sufikso-ekzemplon el Windows kaj promesi identan konduton estas la maniero, kiel funkcianta solvilo estas raportata kiel difektita. Enigu la sufiksojn, konservu, rekonektu kaj kontrolu, ĉu ili postvivis la rekonekton. Se ne, planu per plene kvalifikitaj nomoj anstataŭ batali kun la kliento.

Unue testu per plene kvalifikita privata gastiga nomo. Se la FQDN solviĝas kaj la mallonga nomo ne, vi lernis ion specifan: la solvilo estas atingebla kaj mankas la etendo de mallongaj nomoj. Tio estas alia difekto ol neatingebla DNS-servilo, kaj ĝi bezonas alian posedanton.

La solvilo ankoraŭ bezonas vojon

Listigi adreson en XML ne kreas DNS-servon. Sur la adreso devas funkcii rajtigita solvilo, kiu povas respondi aŭ plusendi la privatan nomspacon, kaj la Mac devas rajtis atingi ĝin tra la tunelo. Se tiu solvilo staras malantaŭ fajroŝirma regulo, kiu ne konas la tunelan amplekson, la demandoj finiĝas per tempo-limigo sen utila eraro. Tiam la tempolimo aspektas ĝuste kiel malĝusta adreso, kaj homoj denove redaktas la XML dum horo.

Ekzamenu la aktivan solvilan staton de la konektita Mac, poste demandu tiun servilon rekte por izoli ĝian respondon de la solvila elekto de la aplikaĵo. Rekta demando pruvas, ke la servilo funkcias. Ĝi ne pruvas, ke ordinaraj serĉoj elektas ĝin.

Transdonu tri apartajn rezultojn

Tenu ilin aparte en la transdono: la reviziita profilo estis importita, la celata solvilo respondis la petitan nomon, kaj la aplikaĵo atingis la redonitan adreson. Ĉiu havas alian posedanton kaj alian riparon.

Unu linio por rezulto sufiĉas, kaj ĝi malhelpas la sekvan personon redakti profilon, kiu jam estis ĝusta.

Rilataj artikoloj