Wi-Fi는 연결됨이라는데 아무것도 로드되지 않는다: 오래된 Mac 리졸버

리터럴 주소로 ping을 보내면 응답이 온다. 사이트를 이름으로 열면 아무 일도 일어나지 않는데, 네트워크 아이콘은 연결이 멀쩡하다고 주장한다. 방금 VPN에 접속한 Mac에서 이런 조합은 거의 항상 조회가 더 이상 닿을 수 없는 서버를 향하고 있다는 뜻이지, 네트워크가 죽었다는 뜻이 아니다. 주소는 이전 어느 시점에 Wi-Fi 서비스에 고정되었고 그 뒤로 아무것도 그것들을 지우지 않았다. 배제 방식으로 진단한 다음 고정된 항목을 삭제하라.

수리는 플러시가 아니라 삭제이며, 대부분이 먼저 시도하는 명령이 전혀 다른 일을 하기 때문에 그 차이는 중요하다.

연결됨은 링크에 대한 진술이다

macOS는 네트워크 서비스마다 리졸버 구성을 유지한다. DHCP에서 온 값이 한 출처이고, 직접 입력한 값이 또 다른 출처이며, 프로필이 밀어넣거나 클라이언트가 쓴 값이 세 번째다. 고정된 값은 네트워크가 제공하는 것보다 우선하며, 스택 어디에서도 그것을 다시 검증하지 않는다. 그래서 사라진 서버는 사람이 제거하거나 서비스를 처음부터 다시 만들기 전까지 목록에 남는다.

그래서 핸드셰이크를 마친 터널은 이미 잘못 향한 조회를 바꾸지 않는다. VPN은 리졸버를 추가했을 뿐, 실패하던 리졸버를 점검하지는 않았다.

이름과 패킷을 분리하라

먼저 리터럴 주소로 호스트에 도달하라. 그것이 로드되면 패킷은 정상이고 리졸버가 원인이다. 로드되지 않으면 거기서 멈추고, DNS를 바꾸면 이미 혼란스러운 그림에 변수만 하나 더해질 뿐이므로 라우팅 문제로 다뤄라.

이름은 실패하는데 대응하는 주소는 성공하는 것이 지문이며, 범위도 보아야 한다. 모든 것이 실패하면 망가진 전역 항목을 가리키고, 터널 안의 호스트만 실패하면 다른 주인과 더 좁은 수리를 가리킨다.

고정된 서버를 삭제하라

네트워크 설정에서 Wi-Fi 서비스의 세부사항을 열고 DNS 탭으로 전환하라. 각 서버 행을 제거하고 변경을 확인한 다음, 검색 도메인에서 직접 추가한 적 없는 값이 있는지 살펴라. 목록을 비워 두고 서비스를 다시 연결한 뒤, DHCP가 준 주소가 저절로 다시 나타나는지 확인하라. 빈 목록은 고정된 값이 문제였음을 증명하는 일시적 상태다.

오래된 릴리스는 같은 패널을 한 단계 더 깊은 곳, 고급 버튼 뒤에 숨기지만 동작과 결과는 같다.

패널이 아니라 상태를 읽어라

scutil --dns | head -40 은 macOS가 실제로 사용하는 리졸버를 범위별로 묶어 출력하고, 알려진 내부 이름에 nslookup을 한 번 돌리면 응답이 아예 오는지 보여준다. 두 출력을 비교하라. 패널은 깨끗한데 낡은 서버가 여전히 목록에 있다면 그 설정을 소유한 다른 작성자가 있다는 뜻이고, 그것은 다른 버그이며 다른 수리가 필요하다.

둘 다 깨끗해 보이는데 이름이 계속 실패하면 결함은 다른 곳으로 옮겨간 것이며 더 이상 DNS 구성을 디버깅하는 것이 아니다.

누가 항목을 다시 넣는가

삭제 후 다시 돌아오는 서버에는 출처가 있으니 기기 관리에서 구성 프로필을 확인하라. 프로필은 DNS를 실을 수 있고 자체 일정에 따라 재평가된다. 클라이언트 환경설정에서 연결 시 DNS를 설정하는 옵션을 확인하고, 이 기계에서 아직 그 자리에 값할지 판단하라. VPN이 정말 사설 리졸버를 필요로 한다면 미래의 모든 네트워크가 물려받는 전역 목록에 쓰지 말고 그것이 소유한 도메인으로 범위를 좁혀라.

의도한 리졸버와 그것이 답해야 할 도메인을 기록하라. 다음 클라이언트 업데이트 후 공개 이름 하나와 사설 이름 하나를 확인하는 것이 설정을 다시 훑는 것보다 빠르고, 기계가 아직 손에 있을 때 회귀를 잡아낸다.

나머지는 모두 의도적으로 보이지만 측정 가능한 무엇도 바꾸지 않고 다음 사람에게 같은 고장 난 조회를 남기는 유지보수 연극일 뿐이다.