[IPMI] BMC가 어느 물리 포트에 물렸는지 패킷으로 찾기 — ping이 전부 거짓말일 때

서버의 BMC(IPMI)를 관리 네트워크에 편입시키는 작업은 보통 단순하다 — BMC에 IP를 주고, 케이블을 꽂으면 끝. 그런데 이번에는 아니었다. BMC 설정은 어느 모로 봐도 완벽한데 ping이 전부 죽었고, 케이블을 어느 포트에 꽂아도 마찬가지였다. 범인을 찾고 보니 문제는 BMC가 아니라 테스트하는 나 자신의 노트북과 스위치에 있었다. 이 글은 그 삽질의 기록이다: VPN 클라이언트가 진단 트래픽을 몰래 가로채고, macOS의 route 명령이 블랙홀을 만들고, 스위치의 유령 VLAN이 살아있는 포트를 죽은 것처럼 보이게 만든, 3중 함정의 이야기.

상황

GPU 서버 한 대의 BMC를 관리망에 편입시키려 했다. OS에서 in-band로 확인한 BMC 설정은 완벽했다:

$ sudo ipmitool lan print 1
IP Address Source       : Static Address
IP Address              : 192.0.2.44
Subnet Mask             : 255.255.255.0
MAC Address             : aa:bb:cc:3b:85:75
BMC ARP Control         : ARP Responses Enabled, Gratuitous ARP Disabled
Default Gateway IP      : 192.0.2.1
Default Gateway MAC     : 00:00:00:00:00:00

눈에 띄는 것 하나: Default Gateway MAC이 전부 0이다. BMC가 게이트웨이의 ARP를 한 번도 배운 적이 없다 — 즉 이 BMC는 네트워크를 만난 적이 없다. IP만 설정됐지 물리 링크가 없는 상태다.

문제는 이 서버의 랜 포트가 다섯 개라는 것이었다. 전용 관리 포트(MLAN) 하나, 온보드 10G 두 개, 추가 카드 1G 두 개. BMC가 어느 포트에 물려 있는지부터 알아야 케이블을 꽂을 수 있다. 그래서 노트북을 들고 서버 앞으로 갔다.

함정 1 — VPN이 진단 트래픽을 가로챈다

노트북을 MLAN 포트에 직결하고, 같은 대역의 수동 IP를 준 뒤 ping을 쐈다. 전멸. 그런데 출력을 자세히 보니 이상한 게 있었다:

$ ping 192.0.2.44
Request timeout for icmp_seq 0
92 bytes from 192.0.2.1: Destination Host Unreachable
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src            Dst
 4  5  00 5400 79b3   0 0000  3e  01 dc8f 100.64.0.5      192.0.2.44

Src가 100.64.0.5 — Tailscale의 CGNAT 대역 주소다. 케이블로 나가야 할 ping이 VPN 터널로 새고 있었다. 원격 관리를 위해 Tailscale이 관리망 대역을 서브넷 라우트로 광고하고 있었는데, 노트북 입장에서는 "그 대역은 VPN 너머에 있다"는 라우트가 이더넷의 connected 라우트와 경합했고, VPN이 이긴 것이다.

직결 테스트가 애초에 무효였다는 뜻이다. 여기서 얻은 규칙: 직결 테스트 전에 route get <대상 IP>로 송신 인터페이스부터 확인하라. 인터페이스가 utun(VPN)으로 나오면 그 테스트는 아무것도 증명하지 못한다.

함정 2 — macOS route -interface는 블랙홀을 만든다

VPN 라우트를 이기려고 호스트 라우트를 박았다:

$ sudo route -n add -host 192.0.2.44 -interface en7
$ route get 192.0.2.44
  interface: en7        # 좋아, 이더넷으로 나간다!

그런데 여전히 전멸. ARP 테이블을 보고 나서야 이해했다:

$ arp -an | grep 192.0.2.44
? (192.0.2.44) at f8:aa:bb:03:1b:69 on en7 permanent [ethernet]

f8:aa:bb:03:1b:69는 노트북 자신의 MAC이다. macOS에서 route add -host X -interface enX 문법은 게이트웨이를 그 인터페이스의 링크 주소 — 즉 자기 자신의 MAC — 로 잡는다. 결과: 대상 IP로 가는 모든 패킷이 자기 자신에게 배달되는 영구(permanent) ARP 엔트리가 생긴다. 완벽한 블랙홀이고, ping이 케이블 근처에도 못 가본 것이다.

교훈: 직결 상황에서는 호스트 라우트가 애초에 필요 없다. 인터페이스에 같은 대역 IP가 있으면 connected 라우트가 알아서 처리한다. 경합하는 VPN 라우트가 문제라면 라우트를 추가할 게 아니라 VPN 쪽 서브넷 라우트 수용을 끄는 것(Tailscale이라면 "Use subnet routes" 해제)이 정답이다.

발상 전환 — BMC가 스스로 위치를 방송하게 하라

두 함정을 치우고도 확신이 없었다. 포트 다섯 개를 ping으로 순회하는 것은 느리고, 각 시도마다 "이번엔 어떤 함정이 있나"를 의심해야 했다. 그래서 방향을 뒤집었다. 내가 BMC를 찾는 게 아니라, BMC가 자기 위치를 광고하게 만들면 된다.

BMC에는 Gratuitous ARP라는 기능이 있다 — 자기 IP/MAC을 주기적으로 브로드캐스트하는 것. in-band로 켤 수 있다:

$ sudo ipmitool lan set 1 arp generate on   # 1초 간격 방송 시작

이제 노트북은 IP 설정도 ping도 필요 없다. 후보 포트에 꽂고 듣기만 하면 된다:

$ sudo tcpdump -i en7 -n -e arp
aa:bb:cc:3b:85:75 > ff:ff:ff:ff:ff:ff, ARP, length 60:
    Announcement 192.0.2.44 (ff:ff:ff:ff:ff:ff)

BMC가 물린 포트에서만 이 방송이 1초마다 찍힌다. 라우팅 오염, ARP 캐시, VLAN — 전부 무관한 전기 신호 레벨의 판정이다. 다섯 포트를 순회한 결과 전용 MLAN 포트에서만 방송이 잡혔고, "온보드 포트 공유(사이드밴드)일 것"이라던 애초의 추론(BMC MAC의 OUI가 온보드 NIC과 같다는 근거)은 오진으로 확정됐다. 참고로 더 정확한 판별법은 MAC의 끝자리다: 사이드밴드라면 BMC MAC이 온보드 NIC MAC과 연번이고, 독립 시퀀스면 전용 포트일 가능성이 높다. 진단이 끝나면 arp generate off로 원복하는 것을 잊지 말 것.

함정 3 — 링크는 뜨는데 침묵하는 포트: 유령 VLAN

BMC 포트를 확정하고 관리망 스위치에 배선했는데, 이번엔 관리망 쪽에서 안 보였다. 스위치의 다른 포트로 옮겨도 마찬가지. 링크 LED는 정상인데 tcpdump를 하면 완전한 침묵 — 게이트웨이가 보내는 ARP 브로드캐스트조차 안 들렸다.

이때 쓴 검증법: VPN 너머 호스트에서 그 대역의 아무 주소로 ping을 계속 쏘게 하면, 게이트웨이가 ARP 브로드캐스트(who-has ...)를 스위치 전체에 뿌린다. 살아있는 포트라면 이게 반드시 들린다. 안 들리면 그 포트는 같은 브로드캐스트 도메인이 아니다.

스위치 콘솔(구형 Cisco Catalyst, 9600bps 시리얼)에 붙어 show vlan brief를 치니 진상이 나왔다: 전임 관리자가 남긴 VLAN 다섯 개가 포트를 쪼개고 있었다. 실제로 장비가 물린 VLAN은 하나뿐이고 나머지는 연결된 장비가 0대인 유령 설정. 다른 VLAN에 속한 포트는 링크는 뜨지만 트래픽이 격리돼, 수년간 "죽은 포트가 섞여 있는 스위치"로 오해받고 있었다. 하드웨어 불량 포트는 하나도 없었다.

Switch> show vlan brief
40   VLAN0040    active    Gi1/0/1, Gi1/0/2, ... Gi1/0/9   ← 실사용은 이것뿐
50   VLAN0050    active    Gi1/0/11, ...                    ← 유령
60   VLAN0060    active    Gi1/0/17, ...                    ← 유령

show mac address-table | include <MAC>으로 BMC가 학습된 포트 번호까지 확정하고 나면 물리 라벨링도 추측이 아니라 실측이 된다.

마무리

최종적으로는 유령 VLAN을 밀어버리고(중요: 연결된 장비들이 전부 같은 VLAN에 있음을 먼저 확인했다 — 그래서 평탄화는 무중단이었다) 어느 포트든 관리망이 되도록 정리했다. BMC는 지금 잘 보인다.

돌아보면 BMC 자체는 처음부터 정상이었다. 실패한 것은 진단이었다:

1. 테스트 경로를 검증하지 않은 테스트는 테스트가 아니다. route get으로 송신 인터페이스를 확인하기 전까지, 내 ping은 단 한 번도 케이블로 나간 적이 없었다.
2. 능동 스캔보다 수동 청취가 강할 때가 있다. Gratuitous ARP + tcpdump 조합은 상위 계층의 모든 오염과 무관하게 물리 계층의 진실을 보여준다.
3. "죽은 포트"라는 진단을 믿지 마라. 링크가 뜨는데 침묵하는 포트는 대개 고장이 아니라 VLAN 격리다. 콘솔에서 show vlan brief 한 줄이면 수년 묵은 미스터리가 풀린다.