유닛은 빨간색인데 인터페이스는 존재하고 터널은 대체로 동작한다. 이것이 가장 혼란스러운 조합이다. 설정은 순서여서 먼저 인터페이스가 만들어지고 그다음 주소, 경로, 리졸버 설정, 어떤 훅 명령이 뒤따른다. 네 번째 단계에서 실패하면 앞의 세 단계는 그대로 남으므로 인터페이스 이름은 시작되었다는 증거이지 끝났다는 증거가 아니며, 사실 하나만 더 있었어도 혼란은 없었을 것이다.

부분 상태가 정상적인 실패다

그 동작은 손상으로 볼 것이 아니라 예상해야 할 일이다. 인터페이스는 설정에서 가장 값싼 부분이고 남겨 두기 가장 쉬우며, 기계를 반쯤 동작하는 것처럼 보이게 하는 부분도 바로 이것이다.

아직 존재하지 않는 것은 실패한 단계 이후에 온 모든 것이다. 실패가 리졸버 단계에서 일어났다면, 주소와 경로는 있고 DNS는 없다. 경로였다면, 터널에는 주소가 있고 그를 지나는 길이 없다.

결과는 일부 시험에는 답하고 다른 시험에서는 실패하는 기계이며, 그래서 사람들은 서비스가 깜빡인다고 결론짓지만 실제로는 한 번도 성공적으로 시작된 적이 없다. 끝나지 않은 서비스는 깜빡일 수 없다. 같은 이유로 반복해서 실패할 수 있을 뿐이다.

첫 번째 실패 단계를 찾아라

현재 상태만이 아니라 유닛의 저널을 읽고, 실패한 실행의 처음부터 읽어라. 마지막 줄이 종료 코드를 알려 주고, 첫 번째 오류가 무엇을 고쳐야 하는지 알려 준다.

이 명령들은 유닛의 상태, 해당 유닛의 부팅 저널, 터널의 실시간 상태를 출력한다:

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

리졸버 오류, 이미 존재하는 경로, 영이 아닌 코드로 종료된 훅, 설정 구문 분석 실패가 모두 그 창에 나타나며 각각 자기 구성 요소를 지목한다. 인터페이스 상태만으로 추측하는 것은 그 모든 정보를 무시하는 일이다.

복구를 결정하는 세 가지 조건

정리할지, 그 자리에서 복구할지, 유닛을 부팅 경로에서 제거할지 결정하고, 무엇이든 입력하기 전에 결정하라.

인터페이스가 깨졌지만 설정이 올바르면 정리하고 다시 시작하고, 설정이 틀렸다면 고치되 그래도 먼저 정리하라. 부분 상태 위에서 두 번째 관리자를 시작하면 한 인터페이스에 주인이 둘이 되기 때문이다. 실패가 기계에 없는 리졸버 도우미 같은 결여된 시스템 구성 요소라면, 유닛이 불평을 멈출 때까지 편집하는 대신 의존성을 의도적으로 설치하거나 제거하라.

그 세 경우가 신비한 빨간 유닛처럼 보이는 것의 대부분을 덮는다. 구별하는 질문은 같은 실패가 깨끗한 상태의 기계에서도 일어날지이며, 답은 보통 첫 번째 오류 줄에서 나온다.

다시 시도하기 전에 정리하라

기존 상태 위에서의 재시도는 새로운 이유로 실패해 원래 이유를 가릴 수 있다. 인터페이스를 만든 것과 같은 도구로 내리고, 그다음 아무것도 남지 않았는지 확인하라.

무관한 인터페이스를 삭제하지 말고 호스트의 네트워킹 스택을 초기화하지 마라. 둘 다 작은 객체를 고치기 위한 큰 행동이며, 실패한 터널 하나를 다른 연결을 다시 세워야 하는 기계로 바꾼다. 올바른 범위는 인터페이스 하나와 그것을 소유한 유닛이다. 그보다 넓은 것은 일어나기 전에 기록된 이유가 필요하다.

유닛이 아니라 터널을 증명하라

초록색 유닛은 시작 순서가 영으로 끝났다는 뜻이다. 패킷이 반대편에 도달했다는 뜻도 아니고, 리졸버가 의도한 대로 설정되었다는 뜻도 아니다.

터널을 통해 요청을 보내고 그것을 만들어 낸 상태를 읽어라:

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

응답 없는 핸드셰이크도 터널이 형성되었고 반대편이 조용하다는 것을 알려 주므로, 이것은 한 번도 시작되지 않은 유닛과는 다른 문제다. 유닛 상태, 핸드셰이크, 요청 결과를 하나의 기록에 보관하는 것은 그것들이 독립적으로 실패하며 오직 조합만이 시스템을 설명하기 때문이다.

관련 글