Wi-Fi siger forbundet, intet indlæses: forældede resolvere på Mac

Ping en bogstavelig adresse, og den svarer. Åbn et websted ved navn, og der sker intet, mens netværksikonet fastholder, at forbindelsen er i orden. På en Mac, der netop har tilsluttet sig en VPN, betyder den kombination næsten altid, at opslagene er rettet mod en server, der ikke længere kan nås, ikke at netværket er nede. Adresserne blev låst til Wi-Fi-tjenesten på et tidligere tidspunkt, og intet har fjernet dem siden. Diagnostiser ved udelukkelse, og slet derefter de fastlåste poster.

Reparationen er en sletning snarere end en udrensning, og forskellen er vigtig, fordi de kommandoer, de fleste prøver først, gør noget helt andet.

Forbundet er en udtalelse om forbindelsen

macOS holder en resolver-konfiguration pr. netværkstjeneste. Værdier fra DHCP er én kilde, indtastede værdier er en anden, og værdier skubbet af en profil eller skrevet af en klient er en tredje. De fastlåste vejer tungere end det, netværket tilbyder, og intet i stakken validerer dem igen. En server, der er forsvundet, bliver derfor på listen, indtil en person fjerner den, eller tjenesten genopbygges fra bunden.

Det er derfor, en tunnel, der fuldfører sit håndtryk, intet ændrer ved et opslag, der allerede var fejlrettet. VPN'en tilføjede en resolver; den reviderede ikke den, der fejlede.

Adskil navne fra pakker

Nå først en vært via en bogstavelig adresse. Når det indlæses, er pakkerne fine, og resolveren har skylden. Når det ikke indlæses, så stop der og behandle problemet som et routingproblem, fordi DNS-ændringer kun tilføjer en variabel til et i forvejen forvirrende billede.

Et navn, der fejler, mens den tilsvarende adresse lykkes, er fingeraftrykket. Bemærk også omfanget: når alt fejler, peger det på en ødelagt global post, mens når kun værter inde i tunnelen fejler, peger det på en anden ejer og en snævrere løsning.

Slet de fastlåste servere

I Netværksindstillinger åbner du Wi-Fi-tjenestens detaljer og skifter til DNS-fanen. Fjern hver serverrække, bekræft ændringen, og gennemgå derefter søgedomænerne for værdier, du aldrig har tilføjet. Lad listen være tom, genopret forbindelsen til tjenesten, og bekræft, at adressen fra DHCP dukker op af sig selv igen. En tom liste er den midlertidige tilstand, der beviser, at de fastlåste værdier var problemet.

Ældre udgaver skjuler samme panel et niveau dybere, bag en Avanceret-knap, med identisk adfærd og samme resultat.

Læs tilstanden i stedet for panelet

scutil --dns | head -40 udskriver de resolvere, macOS faktisk bruger, grupperet efter omfang, og en hurtig nslookup på et kendt internt navn viser, om der overhovedet kommer et svar. Sammenlign de to uddata: et rent panel med en forældet server, der stadig er listet, betyder, at en anden skriver ejer den indstilling. Det er en anden fejl med en anden løsning.

Når begge ser rene ud, og navne stadig fejler, er fejlen flyttet et andet sted hen, og du fejlfinder ikke længere DNS-konfigurationen.

Hvem sætter posterne tilbage

Servere, der vender tilbage efter sletning, har en kilde. Tjek Enhedsstyring for en konfigurationsprofil, fordi profiler kan bære DNS og vurderes igen efter deres egen tidsplan. Tjek klientens indstillinger for en mulighed for at sætte DNS ved forbindelse, og afgør, om den stadig fortjener sin plads på denne maskine. Hvis VPN'en virkelig har brug for en privat resolver, så begræns den til de domæner, den ejer, i stedet for at skrive i den globale liste, som ethvert fremtidigt netværk arver.

Notér den tilsigtede resolver og de domæner, den skal svare på. Efter den næste klientopdatering skal du verificere ét offentligt og ét privat navn, hvilket er hurtigere end at gentage indstillingsrundturen og fanger regressionen, mens maskinen stadig er i dine hænder.

Alt andet er vedligeholdelsesteater: kommandoer, der ser overlagte ud, ændrer intet målbart og efterlader det samme ødelagte opslag til den næste person.