Wi-Fi sier tilkoblet, ingenting lastes: utdaterte resolvere på Mac

Ping en bokstavelig adresse, og den svarer. Åpne et nettsted ved navn, og ingenting skjer, mens nettverksikonet insisterer på at forbindelsen er i orden. På en Mac som nettopp har koblet til en VPN, betyr den kombinasjonen nesten alltid at oppslagene er rettet mot en server som ikke lenger er tilgjengelig, ikke at nettverket er nede. Adressene ble festet til Wi-Fi-tjenesten på et tidligere tidspunkt, og ingenting har fjernet dem siden. Diagnostiser ved utelukkelse, og slett deretter de festede oppføringene.

Reparasjonen er en sletting og ikke en tømming, og forskjellen betyr noe fordi kommandoene folk flest prøver først, gjør noe helt annet.

Tilkoblet er en uttalelse om lenken

macOS holder en resolver-konfigurasjon per nettverkstjeneste. Verdier fra DHCP er én kilde, innskrevne verdier en annen, og verdier som skyves av en profil eller skrives av en klient er en tredje. De festede går foran det nettverket tilbyr, og ingenting i stakken validerer dem på nytt. En server som er borte, blir derfor stående på listen til et menneske fjerner den eller tjenesten bygges opp fra bunnen.

Derfor endrer en tunnel som fullfører håndtrykket sitt, ingenting på et oppslag som allerede var feilrettet. VPN-en la til en resolver; den reviderte ikke den som feilet.

Skill navn fra pakker

Nå først en vert via den bokstavelige adressen. Når det lastes, er pakkene i orden og resolveren har skylden. Når det ikke lastes, stopp der og behandle problemet som et ruteproblem, fordi DNS-endringer bare legger til én variabel i et allerede forvirrende bilde.

Et navn som feiler mens den tilhørende adressen lykkes, er fingeravtrykket. Legg merke til omfanget også: når alt feiler, peker det på en ødelagt global oppføring, mens når bare verter inne i tunnelen feiler, peker det på en annen eier og en smalere reparasjon.

Slett de festede serverne

I Nettverksinnstillinger, åpne detaljene for Wi-Fi-tjenesten og bytt til DNS-fanen. Fjern hver serverrad, bekreft endringen, og gå deretter gjennom søkedomenene etter verdier du aldri har lagt til. La listen stå tom, koble til tjenesten på nytt, og bekreft at adressen DHCP leverer, dukker opp av seg selv igjen. En tom liste er den midlertidige tilstanden som beviser at de festede verdiene var problemet.

Eldre utgivelser skjuler samme panel ett nivå dypere, bak en Avansert-knapp, med identisk oppførsel og samme resultat.

Les tilstanden, ikke panelet

scutil --dns | head -40 skriver ut resolverne macOS faktisk bruker, gruppert etter omfang, og en rask nslookup av et kjent internt navn viser om det i det hele tatt kommer et svar. Sammenlign de to utdataene: et rent panel med en utdatert server som fortsatt står på listen, betyr at en annen skribent eier den innstillingen. Det er en annen feil med en annen løsning.

Når begge ser rene ut og navn fortsatt feiler, har feilen flyttet seg et annet sted, og du feilsøker ikke lenger DNS-konfigurasjonen.

Hvem setter oppføringene tilbake

Servere som kommer tilbake etter sletting, har en kilde. Sjekk Enhetsadministrasjon for en konfigurasjonsprofil, fordi profiler kan bære DNS og vurderes på nytt etter sin egen plan. Sjekk klientens innstillinger for et alternativ for å sette DNS ved tilkobling, og avgjør om det fortsatt fortjener plassen på denne maskinen. Hvis VPN-en virkelig trenger en privat resolver, begrens den til domenene den eier, i stedet for å skrive i den globale listen som hvert framtidige nettverk arver.

Noter den tiltenkte resolveren og domenene den skal svare på. Etter neste klientoppdatering, verifiser ett offentlig og ett privat navn, noe som er raskere enn å gjenta innstillingsrunden og fanger regresjonen mens maskinen fortsatt er i hendene dine.

Alt annet er vedlikeholdsteater: kommandoer som ser overlagte ut, endrer ingenting målbart, og etterlater det samme ødelagte oppslaget til neste person.