NetworkManager의 gateway-ping-timeout은 실제로 무엇을 기다리는가

네트워크를 쓰기 전에 부팅이 끝나는 노트북 이야기에서 connection.gateway-ping-timeout을 보게 되고, 값을 올려 보고 나면 뭔가가 달라진다. 그 변화가 생각한 이유 때문에 도움이 되었는지는 별개의 질문이다. 답은 그 타이머가 도는 동안 활성화가 실제로 무엇을 하는지, 그리고 이 대기에 두 가지 결말이 있다는 사실에서 시작한다.

명령줄에서 연결 하나를 따라가 보면 그 의미가 구체적으로 드러난다.

활성화 하나를 따라가 보기

전역 기본값이 아니라 저장된 연결부터 보는데, 이것은 연결별 속성이기 때문이다. --show-secrets은 정말 필요할 때만 붙이며, 설정 자체는 비밀이 아니다.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

속성이 영이면(문서화된 기본값) 주소 지정이 끝나는 즉시 활성화가 넘어간다. 값을 양수로 두면 IP 구성 활성화는 게이트웨이에서 응답이 오거나 시간 초과가 만료될 때까지 기다린다.

그런 다음 이벤트 스트림을 지켜보면서 연결을 내렸다 올린다. 보이는 순서가 바로 이 설정이 하는 일이며, 장치 상태, 주소 지정, 대기, 마지막으로 종속 서비스가 보통 순서를 맞추는 활성화 상태로 이어진다.

대기에는 두 가지 결말이 있다

두 결말 모두 중요하지만 대부분은 하나만 기억한다. 게이트웨이의 응답은 대기를 일찍 끝내고, 시간 초과도 무언가가 응답했는지와 상관없이 대기를 끝낸다. 이 속성은 활성화가 끝나기 전에 ping 성공을 요구하지 않는다.

그 한 문장은 호텔이나 컨퍼런스 장소에서 캡티브 포털이 로그인 전까지 ICMP를 거부하는 경우가 많다는 점에 대한 혼란을 상당히 정리해 준다. 연결은 시간 초과가 만료된 뒤에도 활성화되며, 다만 필요했던 때보다 늦게 그렇게 될 뿐이고, 그 연결 뒤에 순서가 잡힌 모든 서비스가 함께 기다린다.

이것은 생존 확인도 아니다. 설명 어디에도 연결이 올라온 뒤 게이트웨이에 ping을 보내기 시작하지 않으며, 나중 ping이 실패했다고 활성 프로필을 끊지도 않는다. 손실 감지가 필요하다면 그것은 프로토콜이나 터널 소유자의 몫이지, 활성화 중에 한 번 실행된 속성의 몫이 아니다.

두 객체, 하나의 설정

유선 기본 프로필과 VPN 프로필은 별개의 구성 객체이며, 한쪽에 속성을 설정해도 다른 쪽에는 영향을 주지 않는다. 기본 연결을 지정한 VPN 프로필은 그 활성화 설정을 전혀 물려받지 않으므로, 바꾼 값이 지켜보던 대상에 아무 효과도 없는 것처럼 보일 수 있다.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

이름이 아니라 UUID를 읽는다. 재설치나 프로필 복원 뒤에는 이름이 중복되며, 보이는 이름이 같은 두 연결 때문에 실제 파일은 그대로인 채 엉뚱한 파일을 편집하게 된다.

설치된 NetworkManager 릴리스도 중요하다. 플러그인 동작과 연결 유형이 이 속성을 자체 활성화 단계에 매핑하는 방식이 다르므로, 어디서 본 글이 그대로 적용된다고 가정하지 말고 배포하는 버전에서 시험한다.

대기가 보증할 수 없는 것

가장 많은 시간을 잡아먹는 부분이 여기 있다. 로컬 라우터의 응답은 활성화 중에 호스트 하나가 ICMP 에코 하나에 답했다는 것만 증명한다. VPN 엔드포인트가 이름을 해석하는지, 클라이언트 신원이 받아들여지는지, 사설 경로가 설치되었는지, 사무실 리졸버가 응답하는지, 관심 있는 애플리케이션이 동작할지는 증명하지 않는다.

그것들은 각각 다른 증거를 가진 별개의 의존성이다. DNS가 실패하는 동안에도 게이트웨이는 응답할 수 있고, 모든 애플리케이션 경로가 동작하는 동안에도 게이트웨이가 정책상 ICMP를 조용히 버릴 수 있다. 따라서 이 속성으로 조건을 거는 것은 어느 계층이 늦었는지에 대한 추측이지 측정이 아니다.

종속 서비스를 기다리고 있다면 그 서비스에 무엇이 필요한지 이름 붙여라. 할당된 주소는 주소 지정이 답한다. 터널은 터널 자체의 상태가 답한다. 사설 이름은 질의가 답한다. 애플리케이션은 애플리케이션이 답하며, 그 답들 중 어느 것도 게이트웨이 이름을 딴 타이머에서 나오지 않는다.

바꿨다면 이유를 적어 두기

승인된 변경 전에 이전 값과 이유를 기록하고, 모든 곳이 아니라 특정 연결에 설정한다. 대기를 길게 하면 그 연결 뒤에 순서가 잡힌 모든 것의 활성화 시점이 밀리므로, 느린 시스템은 멀쩡해 보이고 빠른 시스템은 고장 난 것처럼 보일 수 있다.

역사적인 함정 하나를 꼽자면, 이따금 이런 값이 오래된 편집기가 프로필을 받아들이도록 바뀐다는 점이다. 정말 그런 사연이라면 사건은 하나가 아니라 둘이다. 편집기가 저장했고, 실제 네트워크 정책이 바뀌었다. 편집기나 플러그인을 고치고 타이머를 되돌려 놓아라.

NetworkManager 소스는 이 속성을 게이트웨이 응답이나 시간 초과까지 IP 주소 지정 성공을 지연하는 값으로 정의하며 기본값은 영이고, 연결 설정 정의는 남에게 들은 동작을 믿기 전에 읽어야 할 참고 자료다.