Wi-Fi zegt verbonden, niets laadt: verouderde resolvers op de Mac

Ping een letterlijk adres en het antwoordt. Open een site op naam en er gebeurt niets, terwijl het netwerkpictogram volhoudt dat de verbinding in orde is. Op een Mac die net lid is geworden van een VPN betekent die combinatie bijna altijd dat opzoekingen naar een server wijzen die niet meer bereikbaar is, niet dat het netwerk plat ligt. De adressen zijn ooit vastgezet op de Wi-Fi-dienst en niets heeft ze sindsdien verwijderd. Diagnosticeer door uitsluiting en verwijder daarna de vastgezette vermeldingen.

De reparatie is een verwijdering en geen flush, en het verschil is belangrijk omdat de commando's die de meeste mensen eerst proberen iets heel anders doen.

Verbonden is een uitspraak over de verbinding

macOS houdt per netwerkdienst een resolverconfiguratie bij. Waarden van DHCP zijn één bron, ingetypte waarden een tweede, en waarden die een profiel duwt of een client schrijft een derde. De vastgezette waarden gaan voor op wat het netwerk biedt, en niets in de stack valideert ze opnieuw. Een server die weg is blijft dus in de lijst tot een mens hem verwijdert of de dienst vanaf nul opnieuw wordt opgebouwd.

Daarom verandert een tunnel die zijn handshake afrondt niets aan een opzoeking die al verkeerd was gericht. De VPN voegde een resolver toe; hij controleerde niet degene die faalde.

Scheid namen van pakketten

Bereik eerst een host via het letterlijke adres. Als dat laadt, zijn de pakketten in orde en is de resolver de schuldige. Als het niet laadt, stop daar en behandel het probleem als een routeringsprobleem, want DNS-wijzigingen voegen alleen een variabele toe aan een al verwarrend beeld.

Een naam die faalt terwijl het bijbehorende adres werkt, is de vingerafdruk. Let ook op de reikwijdte: als alles faalt wijst dat op een kapotte globale vermelding, terwijl als alleen hosts binnen de tunnel falen dat op een andere eigenaar en een smallere reparatie wijst.

Verwijder de vastgezette servers

Open in Netwerkinstellingen de details van de Wi-Fi-dienst en ga naar het DNS-tabblad. Verwijder elke serverrij, bevestig de wijziging, en kijk daarna de zoekdomeinen door op waarden die je nooit hebt toegevoegd. Laat de lijst leeg, verbind de dienst opnieuw en bevestig dat het adres dat DHCP levert vanzelf terugkomt. Een lege lijst is de tijdelijke toestand die bewijst dat de vastgezette waarden het probleem waren.

Oudere versies verbergen hetzelfde paneel een niveau dieper, achter een knop Geavanceerd, met identiek gedrag en hetzelfde resultaat.

Lees de toestand, niet het paneel

scutil --dns | head -40 drukt de resolvers af die macOS werkelijk gebruikt, gegroepeerd per reikwijdte, en een snelle nslookup van een bekende interne naam laat zien of er überhaupt een antwoord komt. Vergelijk de twee uitvoer: een schoon paneel met een verouderde server die er nog steeds in staat betekent dat een andere schrijver die instelling bezit. Dat is een andere bug met een andere oplossing.

Als beide schoon lijken en namen nog steeds falen, is de fout ergens anders heen verhuisd en debug je niet langer de DNS-configuratie.

Wie zet de vermeldingen terug

Servers die na verwijdering terugkomen hebben een bron. Controleer Apparaatbeheer op een configuratieprofiel, want profielen kunnen DNS dragen en worden volgens hun eigen schema opnieuw beoordeeld. Controleer de voorkeuren van de client op een optie om DNS bij verbinden in te stellen, en beslis of die nog zijn plek op deze machine verdient. Als de VPN echt een privéresolver nodig heeft, beperk hem dan tot de domeinen die hij bezit in plaats van in de globale lijst te schrijven die elk toekomstig netwerk erft.

Noteer de bedoelde resolver en de domeinen die hij moet beantwoorden. Controleer na de volgende clientupdate één openbare en één privénaam, wat sneller is dan de instellingenronde herhalen en de regressie vangt terwijl de machine nog in je handen is.

Al het andere is onderhoudstheater: commando's die doelbewust lijken, niets meetbaars veranderen en dezelfde kapotte opzoeking voor de volgende persoon achterlaten.