Wi-Fi seier tilkopla, ingenting lastar: utdaterte resolvarar på Mac

Ping ei bokstaveleg adresse, og ho svarar. Opne ein nettstad ved namn, og ingenting skjer, medan nettverksikonet insisterer på at sambandet er i orden. På ein Mac som nettopp har kopla til ein VPN, tyder den kombinasjonen nesten alltid at oppslaga er retta mot ein tenar som ikkje lenger er tilgjengeleg, ikkje at nettverket er nede. Adressene vart feste til Wi-Fi-tenesta på eit tidlegare tidspunkt, og ingenting har fjerna dei sidan. Diagnostiser ved utelukking, og slett deretter dei feste oppføringane.

Reparasjonen er ei sletting og ikkje ei tømming, og skilnaden har noko å seie fordi kommandoane folk flest prøver først, gjer noko heilt anna.

Tilkopla er ei utsegn om lenkja

macOS held ein resolver-konfigurasjon per nettverksteneste. Verdiar frå DHCP er éi kjelde, innskrivne verdiar ei anna, og verdiar som ein profil skyv eller ein klient skriv er ei tredje. Dei feste går framom det nettverket byr, og ingenting i stakken validerer dei på nytt. Ein tenar som er borte, blir derfor ståande på lista til eit menneske fjernar han eller tenesta blir bygd opp frå botnen.

Derfor endrar ein tunnel som fullfører handtrykket sitt, ingenting på eit oppslag som allereie var feilretta. VPN-en la til ein resolver; han såg ikkje over den som feila.

Skil namn frå pakkar

Nå først ein vert via den bokstavelege adressa. Når det lastar, er pakkane i orden og resolveren har skulda. Når det ikkje lastar, stopp der og handsam problemet som eit ruteproblem, fordi DNS-endringar berre legg til éin variabel i eit allereie forvirrande bilete.

Eit namn som feilar medan den tilhøyrande adressa lukkast, er fingeravtrykket. Legg merke til omfanget òg: når alt feilar, peikar det på ein øydelagd global oppføring, medan når berre vertar inne i tunnelen feilar, peikar det på ein annan eigar og ein smalare reparasjon.

Slett dei feste tenarane

I Nettverksinnstillingar, opne detaljane for Wi-Fi-tenesta og byt til DNS-fana. Fjern kvar tenarrad, stadfest endringa, og gå deretter gjennom søkjedomena etter verdiar du aldri har lagt til. La lista stå tom, kople tenesta til på nytt, og stadfest at adressa DHCP leverer, dukkar opp av seg sjølv igjen. Ei tom liste er den mellombelse tilstanden som beviser at dei feste verdiane var problemet.

Eldre utgåver gøymer same panelet eitt nivå djupare, bak ein Avansert-knapp, med identisk åtferd og same resultat.

Les tilstanden, ikkje panelet

scutil --dns | head -40 skriv ut resolverane macOS faktisk brukar, grupperte etter omfang, og ein rask nslookup av eit kjent internt namn viser om det i det heile kjem eit svar. Samanlikn dei to utdata: eit reint panel med ein utdatert tenar som framleis står på lista, tyder at ein annan skribent eig den innstillinga. Det er ein annan feil med ei anna løysing.

Når begge ser reine ut og namn framleis feilar, har feilen flytta seg ein annan stad, og du feilsøkjer ikkje lenger DNS-konfigurasjonen.

Kven set oppføringane tilbake

Tenarar som kjem tilbake etter sletting, har ei kjelde. Sjekk Einingstyring for ein konfigurasjonsprofil, fordi profilar kan bera DNS og blir vurderte på nytt etter sin eigen plan. Sjekk innstillingane til klienten for eit alternativ for å setje DNS ved tilkopling, og avgjer om det framleis fortener plassen på denne maskinen. Viss VPN-en verkeleg treng ein privat resolver, avgrens han til domena han eig, i staden for å skrive i den globale lista som kvart framtidige nettverk arvar.

Noter den tiltenkte resolveren og domena han skal svare på. Etter neste klientoppdatering, stadfest eitt offentleg og eitt privat namn, noko som er raskare enn å gjenta innstillingsrunden og fangar regresjonen medan maskinen framleis er i hendene dine.

Alt anna er vedlikehaldsteater: kommandoar som ser overlagde ut, endrar ingenting målbart, og lèt det same øydelagde oppslaget vere att til neste person.