Wi-Fi mówi połączono, nic się nie ładuje: przestarzałe resolvery na Macu

Wyślij ping na dosłowny adres, a odpowie. Otwórz stronę po nazwie i nic się nie dzieje, choć ikona sieci upiera się, że połączenie jest w porządku. Na Macu, który właśnie dołączył do VPN, ta kombinacja prawie zawsze oznacza, że zapytania trafiają do serwera, który nie jest już osiągalny, a nie że sieć padła. Adresy zostały kiedyś przypięte do usługi Wi-Fi i nic ich od tego czasu nie usunęło. Diagnozuj przez wykluczenie, potem usuń przypięte wpisy.

Naprawa to usunięcie, a nie wyczyszczenie, i ta różnica ma znaczenie, bo polecenia, których większość próbuje najpierw, robią coś zupełnie innego.

Połączono to stwierdzenie o łączu

macOS trzyma konfigurację resolvera dla każdej usługi sieciowej. Wartości z DHCP to jedno źródło, wpisane ręcznie drugie, a wartości wciśnięte przez profil lub zapisane przez klienta trzecie. Przypięte mają pierwszeństwo przed tym, co oferuje sieć, i nic w stosie nie weryfikuje ich ponownie. Dlatego serwer, który zniknął, pozostaje na liście, dopóki człowiek go nie usunie albo usługa nie zostanie zbudowana od zera.

Właśnie dlatego tunel, który kończy uścisk dłoni, niczego nie zmienia w zapytaniu, które już było źle skierowane. VPN dodał resolver; nie sprawdził tego, który zawodził.

Oddziel nazwy od pakietów

Najpierw dotrzyj do hosta przez dosłowny adres. Gdy się ładuje, pakiety są w porządku i winny jest resolver. Gdy się nie ładuje, zatrzymaj się tam i potraktuj problem jako problem routingu, bo zmiany DNS tylko dodadzą jedną zmienną do już zagmatwanego obrazu.

Nazwa, która zawodzi, podczas gdy odpowiadający jej adres działa, to odcisk palca. Zwróć uwagę także na zasięg: gdy zawodzi wszystko, wskazuje to na zepsuty wpis globalny, a gdy zawodzą tylko hosty wewnątrz tunelu, na innego właściciela i węższą naprawę.

Usuń przypięte serwery

W Ustawieniach sieci otwórz szczegóły usługi Wi-Fi i przejdź do karty DNS. Usuń każdy wiersz serwera, potwierdź zmianę, a potem przejrzyj domeny wyszukiwania pod kątem wartości, których nigdy nie dodałeś. Zostaw listę pustą, połącz usługę ponownie i potwierdź, że adres dostarczony przez DHCP pojawia się sam. Pusta lista to tymczasowy stan, który dowodzi, że problemem były przypięte wartości.

Starsze wersje ukrywają ten sam panel o poziom głębiej, za przyciskiem Zaawansowane, z identycznym zachowaniem i tym samym wynikiem.

Czytaj stan, nie panel

scutil --dns | head -40 wypisuje resolvery, których macOS faktycznie używa, pogrupowane według zasięgu, a szybki nslookup znanej wewnętrznej nazwy pokazuje, czy odpowiedź w ogóle przychodzi. Porównaj oba wyjścia: czysty panel z wciąż wymienionym przestarzałym serwerem oznacza, że to ustawienie należy do innego zapisującego. To inny błąd z inną naprawą.

Gdy oba wyglądają czysto, a nazwy nadal zawodzą, usterka przeniosła się gdzie indziej i nie debugujesz już konfiguracji DNS.

Kto przywraca wpisy

Serwery, które wracają po usunięciu, mają swoje źródło. Sprawdź Zarządzanie urządzeniami pod kątem profilu konfiguracji, bo profile mogą nieść DNS i są ponownie oceniane według własnego harmonogramu. Sprawdź preferencje klienta pod kątem opcji ustawiania DNS przy połączeniu i zdecyduj, czy nadal zasługuje na swoje miejsce na tej maszynie. Jeśli VPN naprawdę potrzebuje prywatnego resolvera, ogranicz go do domen, które posiada, zamiast wpisywać do globalnej listy, którą dziedziczy każda przyszła sieć.

Zapisz zamierzony resolver i domeny, na które powinien odpowiadać. Po następnej aktualizacji klienta sprawdź jedną nazwę publiczną i jedną prywatną, co jest szybsze niż powtarzanie wędrówki po ustawieniach i łapie regresję, dopóki maszyna jest jeszcze w twoich rękach.

Wszystko inne to teatr utrzymania: polecenia, które wyglądają na celowe, nie zmieniają niczego mierzalnego i zostawiają to samo zepsute zapytanie następnej osobie.