두 소유자, 하나의 주소: TAP 브리지의 중복 IP

Windows 클라이언트 하나가 10.8.0.2를 유지하며 부팅 순서가 바뀔 때까지 동작한다. 그러면 클라이언트에는 아무 변화가 없는데도 같은 주소가 충돌로 보고된다. 같은 브리지 세그먼트의 두 번째 호스트가 같은 값을 주장하고, 구성을 마지막에 마친 머신이 대개 진다. 둘 다 자기 것이라고 믿고, 진 쪽은 사용하라는 주소를 조용히 쓰지 않게 된다. 이것을 타이밍 문제로 취급하는 것이 바로 재부팅마다 재발하는 이유다.

브리지를 건드리기 전에 충돌 증거를 읽어라

Windows는 주소 충돌을 상대 주장자의 하드웨어 주소와 함께 보고한다. 그 하드웨어 주소가 유용한 사실이다. 한 호스트의 한 인터페이스에 대응하는 반면, 이벤트의 표시 이름은 중복이 어디에 있는지 아무것도 알려주지 않는다. 무엇이든 바꾸기 전에 하드웨어 주소를 적어 두어라.

ARP 기반 중복 탐지는 주소를 사용하기 전에 경쟁 소유자를 조사하고 그 뒤에도 계속 지켜본다. 그래서 네트워크를 구성하는 동안 없었던 호스트가 한 시간 뒤에도 충돌을 일으킬 수 있다. 이 조사는 부팅 때 한 번 하는 점검이 아니다. 나중에 나타난 머신이 하루 종일 조용히 쓰이던 주소를 가져갈 수 있고, 그래서 이 장애는 구성 오류가 아니라 경쟁처럼 읽힌다.

충돌 이벤트만으로는 어느 구성이 다른 주장을 만들었는지 알 수 없고, 실험적으로 주소를 지우면 알려주었을 매핑이 파괴된다. 증거의 목적은 하드웨어 주소를 검사할 수 있는 인터페이스로 바꾸는 것이다. 머신 이름으로 인벤터리를 검색하면 대개 잘못된 호스트로 간다.

세그먼트의 모든 주장을 목록화하라

브리지된 TAP 구성은 이전에 분리되어 있던 Ethernet 세그먼트를 연결하므로, 각자의 네트워크 안에서 고유하던 주소도 프레임이 하나의 링크를 공유하는 순간 충돌할 수 있다. 이 장애 부류가 VPN에는 있고 그것이 대체한 라우팅 네트워크에는 없는 이유다. 의심되는 첫 번째가 아니라 가능한 모든 소유자를 나열하라.

목록을 이 순서로 훑어라. 각 브리지 장치와 그 구성원 포트의 주소, OpenVPN 풀과 클라이언트별 고정 할당, 그리고 브리지 세그먼트를 포괄하는 모든 DHCP 서버다. 그다음 충돌 보고서의 하드웨어 주소를 찾은 인터페이스와 맞춰라.

ip -4 addr show | grep -E 'inet |^[0-9]+: '
bridge link show
ip neigh show dev br0

풀과 DHCP 범위는 사람들이 잊는 두 소유자다. 다른 일을 하기 전에 두 범위를 함께 출력하고 겹침을 찾아라. 수동으로 지정한 브리지 주소와 같은 값을 내주는 풀은 결국 충돌하며, 두 범위를 나란히 출력하기 전까지 그 충돌은 무작위로 보인다.

브리지는 식별자가 필요한 곳에서만 번호를 매겨라

일반적인 호스트 브리지에서 브리지 장치는 호스트의 네트워크 계층 구성을 갖고 Ethernet과 TAP 구성원은 포트 역할을 한다. 각 구성원에 자체 주소를 주거나 주소를 바꾸지 않고 설정 스크립트 하나를 여러 머신에 복사하는 것이 한 세그먼트에 같은 값의 소유자 셋을 만드는 방법이다. 구성원은 프레임을 전달하는 데 자체 식별자가 필요 없다. 필요한 것은 그 세그먼트에서 도달 가능해야 하는 호스트마다 정확히 하나의 식별자뿐이다.

프레임만 스위칭하는 브리지는 그 세그먼트에 주소가 전혀 필요 없다. 번호를 주지 않고 두면 충돌의 한 부류가 통째로 사라진다. 단, 호스트에 검증한 관리 경로가 남아 있어야 한다. 먼저 접근을 확인하고, 둘째 주소를 제거하고, 셋째 도달 가능성을 점검하라.

지우려는 주소가 머신으로 들어가는 유일한 경로라면, 그것을 실험으로 지우는 것은 진단이 아니라 스스로 만든 장애다. 무엇이든 시험하기 전에 대역 밖 경로를 검증하라.

수정이 재부팅을 견디게 하라

살아 있는 인터페이스를 바꾸면 현재 부팅만 고쳐지고 그 밖에는 아무것도 아니다. 부팅 때 주소를 다시 만드는 무엇이든 다음 재부팅에서 충돌을 되살릴 것이고, 당신은 수정이 효과가 없었다고 결론 내릴 텐데 실제로는 애초에 영구적이지 않았던 것이다. 어느 파일을 바꿨는지 기록해 두면 다음 재부팅은 놀라움을 드러내는 대신 결정을 확인해 준다.

그 구성의 소유자를 찾아라. 네트워크 관리자 프로필, 인터페이스별 파일, 컨테이너나 VM 정의, 또는 cloud-init 조각이다. 거기서 바꾸고, 그다음 영향을 받은 호스트 하나를 의도적으로 재부팅해 새 값이 돌아오는지 확인하라. 재부팅만이 영속성을 증명하는 시험이다.

DHCP 범위 안의 브리지 주소를 제외 항목으로 예약하거나 범위 밖으로 옮겨라. 스프레드시트에만 있는 예약은 제외가 아니며, 할당기는 그것을 읽지 않는다.

모든 클라이언트가 온라인인 상태에서 증명하라

연결이 한 번 성공했다고 아무것도 증명되지 않는다. 원래 증상은 순서가 바뀔 때만 나타났기 때문이다. 의도한 모든 클라이언트를 올리고, 부팅 순서를 바꾸고, 재연결 후에 반복하라. 그다음 예전에 경쟁에서 지던 호스트를 재시작해 주소가 살아남는지 확인하라.

직접 확인하려면 주소를 할당하기 전에 중복 소유자가 있는지 조사하고 그 뒤에 이웃 테이블을 지켜보라. 아무것도 조사에 응답하지 않고 전체 재시작 주기 동안 주소가 고유하게 유지된다면, 충돌은 숨겨진 것이 아니라 해결된 것이다. 아래 명령은 브리지 장치에서 두 점검을 모두 수행한다. RFC 5227 이 도구들이 수행하는 조사와 광고 동작을 설명하며, 누군가 탐지를 끄자고 제안할 때 인용해야 할 참고 문헌이다.

arping -D -I br0 10.8.0.2
ip neigh show dev br0 | grep 10.8.0.2

응답이 없는 조사는 깨끗한 세그먼트에서 예상되는 결과다. 응답을 끌어내는 조사는 남은 소유자의 하드웨어 주소를 알려준다. 처음에 Windows 이벤트가 준 것과 같은 증거다. 그 출력을 변경 기록과 함께 보관하라. 주소가 고유하게 유지된다는 유일한 증거이기 때문이다.