Wi-Fi seit ferbûn, neat lâdt: ferâldere resolvers op 'e Mac

Ping in letterlik adres en it antwurdet. Iepenje in side by namme en der bart neat, wylst it netwurkikoan beweart dat de ferbining goed is. Op in Mac dy't krekt by in VPN kommen is, betsjut dy kombinaasje hast altyd dat sykopdrachten rjochte binne op in tsjinner dy't net mear berikber is, net dat it netwurk del is. De adressen binne op in earder stuit oan 'e Wi-Fi-tsjinst fêstset en neat hat se sûnt fuortsmiten. Diagnostisearje troch út te sluten, smyt dan de fêstsette ynfieringen fuort.

De repaasje is in fuortsmyt en net in spieljen, en it ferskil makket út omdat de opdrachten dy't de measte minsken earst besykje hielendal wat oars dogge.

Ferbûn is in útspraak oer de keppeling

macOS hâldt in resolver-konfiguraasje per netwurktsjinst. Wearden fan DHCP binne ien boarne, yntype wearden in oare, en wearden dy't in profyl treout of in klient skriuwt in tredde. De fêstsette oerhearskje wat it netwurk biedt, en neat yn 'e stapel falidearret se opnij. In tsjinner dy't fuort is bliuwt dêrom op 'e list oant in minske him fuorthellet of de tsjinst fan 'e grûn ôf weropboud wurdt.

Dêrom feroaret in tunnel dy't syn hânjoering foltôget neat oan in sykopdracht dy't al ferkeard rjochte wie. De VPN foege in resolver ta; hy kontrolearre net dy't mislearre.

Skied nammen fan pakketten

Berik earst in host fia in letterlik adres. As dat lâdt, binne de pakketten goed en is de resolver skuldich. As it net lâdt, stopje dêr en behannelje it probleem as in routingprobleem, want DNS-feroarings foegje allinnich in fariabele ta oan in al betiizjend byld.

In namme dy't mislearret wylst it byhearrende adres slagget is de fingerôfdruk. Let ek op 'e omfang: as alles mislearret wiist dat op in stikken globale ynfiering, wylst as allinnich hosts binnen de tunnel mislearje dat op in oare eigner en in smeller repaasje wiist.

Smyt de fêstsette tsjinners fuort

Iepenje yn Netwurkyustellingen de details fan 'e Wi-Fi-tsjinst en gean nei it DNS-ljep. Ferwiderje elke tsjinnerrige, befêstigje de feroaring, en sjoch dan de sykdominen troch foar wearden dy't jo nea tafoege hawwe. Lit de list leech, ferbyn de tsjinst opnij en befêstigje dat it adres dat DHCP leveret fan sels wer ferskynt. In lege list is de tydlike steat dy't bewuollet dat de fêstsette wearden it probleem wiene.

Aldere ferzjes ferstopje itselde paniel ien nivo djipper, efter in knop Avansearre, mei identyk gedrach en itselde resultaat.

Lês de steat, net it paniel

scutil --dns | head -40 prints de resolvers dy't macOS wier brûkt, groepearre nei omfang, en in flugge nslookup fan in bekend yntern namme docht bliken oft der hielendal in antwurd komt. Fergelykje de twa útfieringen: in skjin paniel mei in ferâldere tsjinner noch op 'e list betsjut dat in oare skriuwer dy ynstelling hat. Dat is in oare bug mei in oare repaasje.

As beide skjin lykje en nammen noch mislearje, is de fout nei earne oars ferhuze en debugge jo net mear de DNS-konfiguraasje.

Wa set de ynfieringen werom

Tsjinners dy't nei it fuortsmyt terugkomme hawwe in boarne. Kontrolearje Apparaatbehear op in konfiguraasjeprofyl, want profile kinne DNS drage en wurde op har eigen skema opnij beoardiele. Kontrolearje de foarkarren fan 'e klient op in opsje om DNS by ferbinen te setten, en beslút oft dy noch syn plak op dizze masine fertsjinnet. As de VPN wier in privee resolver nedich hat, beheinje him dan ta de domeinen dy't hy hat ynstee fan yn 'e globale list te skriuwen dy't elk takomstich netwurk erft.

Skriuw de bedoelde resolver en de domeinen dêr't er antwurd op jaan moat op. Nei de folgjende klientfernijing, ferifiearje ien iepenbier en ien privee namme, wat flugger is as de ynstellingsrûn werhelje en fangt de regression wylst de masine noch yn jo hannen is.

Al it oare is ûnderhâldsteater: opdrachten dy't opsetlik lykje, neat mjitsber feroarje, en deselde stikken sykopdracht foar de folgjende persoan litte.