VPN은 연결됐다고 하지만 기본 경로는 죽어 있다

클라이언트는 연결됐다고 보고하고, 트레이 아이콘도 정상으로 보이는데 아무것도 로드되지 않는다. Wi-Fi에서 케이블로 옮긴 직후, 또는 배포판 업그레이드가 끝난 직후에 시작됐다. 망가진 것은 프로필이 아니라 이전 기본 연결을 위해 만들어진 상태다. 커널에는 아직 아무도 소유하지 않는 터널 장치를 가리키는 기본 경로가 남아 있거나, 리졸버가 사라진 링크의 서버를 여전히 나열하고 있다. 두 고장 모두 죽은 네트워크처럼 보이고 둘 다 그 자리에서 고칠 수 있다.

낡은 조각들은 알아차리기 전부터 이미 틀려 있었다. 케이블을 뽑은 일은 그것들을 드러냈을 뿐이다.

패킷이 어디로 갈지 커널에 물어보라

경로 목록은 시스템이 아는 모든 것을, 더 이상 적용되지 않는 항목까지 포함해 나열하므로 읽기 어렵다. 경로 조회는 물을 가치가 있는 유일한 질문에 답한다. 지금 이 특정 패킷을 어느 장치가 나르는가. 답이 터널 장치를 지목하면, 뒤에 살아 있는 클라이언트 프로세스가 없어도 커널은 그것을 쓰고, 패킷은 아무도 관리하지 않는 인터페이스로 떨어진다. 답이 Ethernet 어댑터를 지목하는데 클라이언트가 연결됐다고 우긴다면, 터널은 존재하지만 선택을 잃은 것이며, 이는 무선에서 유선으로 옮길 때 흔한 결과다.

조회를 두 번 실행하라. 한 번은 공용 주소에, 한 번은 내부 주소에 대해 하는데, 분할 터널 정책이 하나는 정직하게 보내고 다른 하나는 떨어뜨릴 수 있기 때문이다.

ip route show default
ip route get 1.1.1.1
ip route get 10.20.30.40

리졸버도 죽은 링크를 유지한다

systemd-resolved를 쓰는 호스트에서 DNS 서버는 하나의 전역 목록이 아니라 링크에 속한다. 내려간 VPN 링크는 한동안 자기 서버와 함께 등록된 채 남을 수 있고, 그러면 모든 조회가 결코 응답하지 않을 주소를 기다린다. 그 지연은 죽은 네트워크처럼 느껴지고, 경로는 멀쩡한데도 사람들을 경로 쪽으로 보낸다.

resolvectl status
resolvectl query intranet.example.com

링크별 블록을 읽고 문제의 도메인을 어느 링크가 소유하는지 확인하라. 올라와 있지만 내부 도메인의 소유자가 아닌 터널은 내부 이름을 공용 리졸버로 넘기고, 증상은 라우팅 결함과 구별되지 않는다.

고칠 것은 등록이지 /etc/resolv.conf가 아니다. 현재 Ubuntu와 Fedora 설치에서 그 경로는 리졸버의 런타임 상태를 가리키는 심볼릭 링크이므로, 편집은 무시되거나 다음 네트워크 이벤트에서 덮어써진다.

VPN은 절대 스스로 시작하지 않는다

NetworkManager는 기본 연결 위에 VPN을 올리고, 어느 기본 연결을 따라갈지 그 기본의 connection.secondaries 에서 배운다. 연결 설정 참조서 는 VPN 프로필에 자동 연결이 구현되지 않았다고 분명히 밝힌다. 이것이 이 부류의 고장 뒤에 있는 전부다. 기본을 바꾸면 VPN은 다시 짝지어지거나 손으로 다시 활성화해야 한다.

nmcli device status
nmcli connection show --active
nmcli connection up office-vpn

활성 목록이 VPN 없이 기본을 보여 준다면, 터널은 전혀 활성이 아니고 경로는 낡은 채로 남은 것이 아니라 아예 설치된 적이 없다. 활성화가 원본 연결이 없다고 항의한다면, 짝지어져 있던 기본이 사라진 것이므로 먼저 기본이나 짝짓기를 고치고 VPN 재시도는 그만두어라.

업그레이드는 메시지 없이 설정을 떨어뜨릴 수 있다

배포판을 업그레이드하면 클라이언트와 흔히 그 NetworkManager 플러그인이 바뀌지만, 저장된 프로필은 기록될 때의 속성 이름을 그대로 유지한다. 새 플러그인이 더 이상 알아보지 못하는 것은 조용히 건너뛴다. 프로필은 여전히 활성화되고 장치는 여전히 나타나지만, 예전에 함께 오던 경로는 더 이상 오지 않는다.

손으로 쓴 훅도 움직인다. 옛 순서의 예측 가능한 시점에 경로를 설치하던 스크립트는 이제 인터페이스가 존재하기 전에, 또는 클라이언트가 이미 시간 초과된 뒤에 실행될 수 있다.

살아 있는 프로필을 기억하는 동작이 아니라 실제로 가진 플러그인과 비교하라. 키가 문서에서 사라졌다면 옛 속성을 복원하는 대신 작업을 디스패처 스크립트나 지원되는 대체물로 옮겨라.

세 가지 상태, 세 가지 다른 수리

무엇이든 건드리기 전에 자신이 어느 상태인지 정하라. 재부팅은 증거를 파괴하고, 다음 네트워크 변경에서 고장이 돌아오기 때문이다.

공용 주소 조회 하나, 내부 주소 조회 하나, 이름 질의 하나로 끝내라. 주소는 되는데 이름이 안 된다면 남은 고장은 리졸버의 도메인 범위이며, 경로 테이블은 처음부터 문제가 아니었다.