레지스트리 데이터가 바뀌면, 정상 작동하던 네트워크가 왜 사라질 수 있을까?

모바일 연결에서는 서비스가 여전히 작동하는데, 다른 네트워크의 고객은 더 이상 접속하지 못한다고 해 보자. 서버는 정상이다. 케이블도 연결되어 있다. 한 가지 가능한 설명은 기록이 바뀐 뒤 다른 네트워크가 해당 주소로 향하는 라우트를 더 이상 수락하지 않는다는 것이다.

빠진 연결 고리는 기록과 라우터 사이에서 이루어지는 결정이다. 시스템이 데이터베이스의 변경 내용을 이용해 필터를 만들거나 라우트 공지를 평가하면, 그 변경이 연결에 영향을 줄 수 있다. 장애를 이해하려면 이 과정을 따라가야 한다. “레지스트리가 잘못됐다”는 진단의 시작일 뿐이다.

기록 변경이 라우트 수락 여부에 영향을 주더라도 물리적 연결은 온전할 수 있다. 증거와 수신 측 정책을 따라가야 한다.

먼저 어떤 기록이 바뀌었는지 물어야 한다

IP 프리픽스는 주소 블록이다. 자율 시스템 번호인 ASN은 다른 네트워크와 라우트를 교환하는 네트워크를 식별한다. BGP는 이 네트워크들이 자신이 도달할 수 있는 목적지를 알리는 데 사용하는 프로토콜이다.

이러한 교환과 관련해 여러 종류의 기록이 존재한다. 각각 답하는 질문이 다르다.

• 등록 기록: 어떤 조직이 해당 주소 블록에 등록되어 있으며 누구에게 연락해야 하는지를 나타낸다. RIPE 데이터베이스 문서는 같은 데이터베이스에 저장되어 있더라도 자원 등록, 라우팅 정보, 연락처 기록을 구분한다.
• 인터넷 라우팅 레지스트리(IRR) 기록: 운영자가 수락할 라우트 목록을 만드는 데 쓸 수 있는 정보다. 기록은 의도한 라우팅을 설명할 뿐, 그 자체로 라우트를 공지하지는 않는다.
• 자원 공개 키 기반 구조(RPKI) 기록: 서명된 라우트 출발지 인증인 ROA 등이 포함된다. 검증기는 이를 바탕으로 출발지 네트워크와 허용된 프리픽스 길이를 확인할 데이터를 생성한다.

오래된 연락처 이메일이 BGP 라우트를 직접 철회하지는 않는다. 반면 사업자가 생성한 필터에 라우트가 빠지면 그 사업자는 해당 라우트를 수락하지 않을 수 있다. 두 경우를 모두 “유효하지 않은 레지스트리 데이터”라고 부르면 중요한 차이가 가려진다.

기록 하나가 어떻게 라우트 거부로 이어지는가

IRR 데이터를 바탕으로 고객용 필터를 만드는 사업자를 생각해 보자. 다음과 같은 순서로 장애가 발생할 수 있다.

1. 라우트 기록이 삭제되거나 고객의 라우트 집합에서 빠진다.
2. 사업자가 다음번에 필터를 생성할 때 그 라우트를 누락한다.
3. 새 필터가 사업자의 라우터에 적용되고, 라우터는 고객의 공지를 거부한다.
4. 사용할 수 있는 대안이 남아 있지 않으면 그 경로에 의존하던 사람들은 접속할 수 없게 된다.

이 과정이 일어나려면 해당 데이터가 실제로 그 필터의 입력으로 쓰여야 한다. NTT DATA가 공개한 라우팅 레지스트리 정책은 IRR 기반 고객 필터와 자동 업데이트의 구체적인 사례를 보여 준다. RPKI Invalid 라우트를 거부하고 충돌하는 IRR 기록을 제외하는 방식도 설명한다. 이는 확인 가능한 운영 메커니즘이지, 레지스트리가 가진 만능 차단 스위치가 아니다.

RPKI의 ‘Invalid’는 정확히 무엇을 뜻하는가

출발지 검증에서는 공지된 라우트를 검증된 인증 데이터와 비교한다. RFC 6811은 세 가지 결과를 정의한다.

• Valid(유효): 해당 라우트를 포괄하는 인증 중 적어도 하나가 출발지 ASN과 일치하고 공지된 프리픽스 길이를 허용한다.
• Invalid(유효하지 않음): 해당 라우트를 포괄하는 인증 데이터는 있지만, 두 조건을 모두 충족하는 인증은 없다.
• NotFound(찾지 못함): 해당 라우트를 포괄하는 인증 데이터가 없다.

예를 들어 네트워크 A가 공지한 라우트에 부합하는 인증이 사라지고 그 라우트를 포괄하는 네트워크 B의 인증은 남아 있다면, 해당 라우트는 Invalid가 될 수 있다. 포괄하는 인증이 하나도 남아 있지 않다면 결과는 NotFound다. 여기서 ‘Invalid’는 라우팅 검증 결과이지, 소유권이나 기관의 정당성에 대한 판정이 아니다. 출발지 검증은 라우트가 거쳤다고 주장하는 전체 경로를 인증하지도 않는다.

그다음 단계는 운영자가 설정한 정책이다. RFC 8481은 검증 상태를 지정하는 일과 그 상태에 따라 조치하는 일을 구분한다. 정책은 운영자가 설정해야 한다. Invalid 라우트를 거부하도록 설정된 네트워크는 이에 따라 해당 공지를 거부할 수 있다. 레지스트리 수정과 라우트 거부는 이 메커니즘을 통해 연결되지만, 같은 사건은 아니다.

왜 어떤 사람들은 다른 사람들보다 먼저 접속이 끊기는가

모든 네트워크가 같은 시점에 같은 필터, 사업자, 데이터를 사용하는 것은 아니다. RFC 7115는 RPKI 캐시마다 서로 다른 데이터 상태를 보유할 수 있으며, 업데이트가 라우터에 도착하는 간격도 하나의 보장된 값으로 정해져 있지 않다고 설명한다.

도입부의 예에서 한 네트워크는 이미 변경된 데이터에 따라 조치했지만, 다른 네트워크에는 여전히 수락된 경로가 남아 있을 수 있다. 따라서 부분적인 장애가 가능하다. 그렇다고 특정 장애의 원인이 레지스트리라고 입증되는 것은 아니다. 엔지니어는 여전히 영향을 받은 라우트, 사용 중인 데이터, 해당 라우트를 거부한 결정을 확인해야 한다.

다른 것을 더 바꾸기 전에 끊어진 고리를 찾아라

복구에 도움이 되는 질문은 구체적이다. 어느 시스템이 어떤 공지를 더 이상 수락하지 않으며, 그 이유는 무엇인가? 운영자는 사업자와 함께 다음 순서로 확인할 수 있다.

1. 공지를 식별한다. 영향을 받은 프리픽스와 출발지 ASN을 기록하고, 예상한 라우트가 여전히 공지되는지 확인한다.
2. 거부 지점을 찾는다. 사업자에게 설치된 필터와 검증 결과를 해당 라우트와 대조한다. 어떤 데이터 출처와 업데이트가 그 결정을 낳았는지 묻는다.
3. 증거를 보존한다. 관련 기록, 관측 결과, 타임스탬프를 남겨 잘못된 업데이트와 무단 공지를 구별할 수 있게 한다.
4. 수정하고 검증한다. 정확히 어떤 기록이나 설정을 바로잡을지 조율하고, 수정 내용이 이를 사용하는 시스템에 도달했는지 확인한 다음, 접속이 실패했던 네트워크에서 접근을 시험한다.

모든 곳에서 검증을 끄면 잘못된 공지에 대한 보호도 사라진다. 운영상 해야 할 일은 정확한 증거와 의도한 라우팅을 복원하고 결과를 검증하는 것이다. 데이터베이스 수정에 성공했다는 사실만으로 고객이 다시 연결할 수 있다고 입증되지는 않는다.

더 깊은 문제: 유용한 증거가 집중된 권력으로 바뀔 수 있다

바로 이 지점에서 기술적 과정이 루헝의 주장과 만난다. 관리자는 누구의 패킷도 전달하지 않으면서 그 사람의 네트워크 도달 가능성에 영향을 줄 수 있다. 다른 시스템들이 관리자가 통제하는 기록에 의존한다면, 그 결정은 사무실에서 멀리 떨어진 운영자와 고객에게도 비용을 떠넘길 수 있다.

루헝은 노트 65, 작동하는 코드의 우선성에서 조정은 실제로 운영 중인 네트워크의 필요에 의해 제한되어야 한다고 주장한다. 기록을 유지하는 역할이 스스로 영구적인 정치적 위임으로 확대될 수는 없다. 기록에 서명이 있다는 사실은 그 주장에 관한 기술적 질문에 답할 뿐, 영향을 받는 모든 사람을 지배할 권리를 확립하지 않는다.

그의 제안은 더 나은 민원 절차를 넘어선다. 공통 규칙은 고유성, 검증 가능한 통제권, 상호운용성을 보호해야 한다. 참여자는 로컬에서 상태를 검증하고 어떤 호환 가능한 변경을 채택할지 결정한다. 무제한 거부권을 가진 새 위원회를 만들면 이름만 바꾼 채 같은 문제가 되풀이된다.

연속성을 위해서는 다른 네트워크도 사용할 수 있는 이탈 경로가 필요하다

쓸 수 있는 대안은 신뢰할 수 있는 기록, 보안에 관한 진술, 운영 관계를 이어 가야 한다. 다른 네트워크가 그 기록을 검증하고 사용할 수 있어야 한다. 데이터베이스를 복사하는 것만으로 다른 네트워크가 대체자를 받아들이지는 않으며, 독립을 선언한다고 거부된 라우트가 복구되지도 않는다.

노트 72는 목표를 분명히 한다. 정확한 기록, 운영 연속성, 제 기능을 못 하는 조정자로부터 실제로 떠날 수 있는 능력이다. 실무적 과제는 독립적인 네트워크들이 통신할 수 있게 하는 공통의 고유성과 호환성을 잃지 않으면서 그 능력을 구축하는 것이다.

관련 안내인 레지스트리 상태 내보내기 가이드는 이 작업 중 기록을 옮겨 이어 가는 부분을 살펴본다. 이는 검증, 운영자의 채택, 연속성 시험과 함께 전환을 구성하는 한 요소다.

서비스가 아직 작동할 때 준비하라

팀에 중요한 주소 블록 하나를 골라 그 기록부터 이에 의존하는 사업자와 고객까지 추적해 보도록 요청하라. 각 기록은 누가 바꿀 수 있는가? 누가 사용하는가? 현 관리자가 이용 불가능하거나 그 지위에 이견이 생기면 오류를 어떻게 바로잡을 것인가?

조직 사이에서 이 답을 확립하려면 시간이 걸린다. 장애 전에 답을 찾으면 행동할 여유가 생기지만, 중단 중에야 답을 찾아 나서면 고객이 비용을 떠안는다. 시급한 과제는 연속성을 아직 보호할 수 있을 때 실질적인 독립성을 구축하는 것이다.

이어서 읽을 글은 노트 65: 작동하는 코드의 우선성이다. 작동하는 네트워크, 로컬 검증, 자발적 채택에 기반한 조정에 관한 루헝의 전체 논의를 살펴볼 수 있다.