IL-0354 Fly.io · 2026-09-23networking

Fly.io 일부 머신의 사설 네트워크 6PN 이 끊겼고 다음 날 잠깐 다시 끊겼다

Fly.io 의 6PN 주소는 fdaa:netid:netid:hostid:hostid:machid:machid:2 꼴이다. hostid 부분은 머신을 만들 때 머신이 있던 물리 호스트에서 정해지고, 2025년 5월 무렵 이전에는 머신을 옮길 때도 다시 정해졌다. 2025년에 6PN 주소를 고정한 뒤에도 6PN 라우팅용 맞춤 eBPF 프로그램은 한 번도 옮기지 않은 머신의 경로를 기본적으로 hostid 만 보고 정했다. 2026년에 Fly.io 는 디버깅과 변경이 어려운 맞춤 라우팅 구현을 줄이고 표준 Linux 라우팅 테이블에 기대도록 6PN 을 바꾸고 있었다. 이 작업의 핵심은 host ID 를 6PN 라우팅에서 떼어 내는 일이었다. 그러면 머신의 경로는 주소가 아니라 머신이 지금 있는 위치로 정해진다.

게이트웨이 피어에는 static 과 interactive 두 종류가 있다. fly wireguard create 로 만드는 static 피어는 플랫폼의 라우팅 상태에 고정된 신원이 있다. flyctl 이 fly ssh console 같은 일시적 작업에 쓰는 interactive 피어는 그런 신원이 없어서, 게이트웨이의 host ID 를 보고만 경로를 정할 수 있다. 주소에 게이트웨이 피어와 머신을 가를 다른 표시가 없어서, Fly.io 는 netid 마다 게이트웨이의 /80 접두사 전체를 게이트웨이 호스트로 보내는 규칙을 Linux 라우팅 테이블에 넣었다. 기존 게이트웨이에서는 이 방식에 문제가 없었다.

물리 워커 호스트를 퇴역시키면 그 내부 IP 가 풀리고, 내부 IP 가 host ID 를 정한다. 새 호스트는 새 IP 와 host ID 를 받을 수도 있고 퇴역한 호스트의 값을 다시 받을 수도 있다. 6PN 주소가 고정된 뒤로는 머신이 워커가 아닌 호스트에 다시 배정된 host ID 를 계속 가질 수 있었다. 최근 용량과 연결성을 늘리려고 새 에지를 많이 들이면서 에지들이 퇴역한 워커의 host ID 를 다시 썼다. 에지를 non-static 피어의 게이트웨이로 쓰기 시작하자 에지에 /80 경로가 들어갔고, 이 경로가 머신별 라우팅 코드를 덮어썼다. 그 코드는 로컬에서 아직 접근한 적이 없는 머신에는 경로가 없다는 전제에 기대고 있었다. 그 host ID 를 가진 머신들은 에지가 아니라 워커에 있었기 때문에 6PN 이 끊겼다.

Fly.io 는 약 10분 만에 영향을 받은 모든 호스트의 라우팅 테이블에서 잘못된 /80 경로를 지우고, 6PN 경로를 관리하는 데몬 s6pnforwarderd 의 변경을 롤백했다. 이어 interactive 피어를 /128 로만 넣도록 고쳤지만, 문제는 /80 경로만이 아니라 게이트웨이 로직과 워커 로직 사이의 우선순위였기 때문에 다음 날 잠깐 다시 일어났다. 그 뒤 호스트가 워커인지와 상관없이 그 호스트의 ID 를 가진 머신이 있는지부터 찾도록 고쳐 근본 원인을 일단 막았다.

심각도

–

영향 범위

Private networking (6PN) for the subset of machines whose host IDs had been reused by edges

영향 사용자

–

지역

–

감지까지

–

복구까지

10m