---
status: TWO_DOMAIN_MAIN_HOST_LOSS_CANARY_EXECUTED_BLOCKED_BY_NAT
candidate_version: 1.4.83-peer-sponsored-upnp-diagnostic-default-off-locked
candidate_bytes: 488809
candidate_sha256: 94bb1528978d8be464b201d7ce3cfe3015c62ed76704c5b01df57bc252dfb1b8
production_enabled: false
rollout_policy_written: false
router_mapping_performed: true_and_revoked
external_transfer_started: false
operator_signing_used: false
validator_changed: false
---

# 2개 WAN / 3개 노드 메인 호스트 단절 canary 준비

> 2026-08-05 live 결과: 세 후보와 세 서명은 준비됐지만 public relay는 최대 2개만 동시에 도달했다. 모든 canary policy와 TCP 52001~52003 mapping은 회수됐다. 상세 결과와 다음 outbound overlay 요구사항은 `26-FINITE_UPNP_LIVE_CANARY_RESULT_KO.md`를 따른다. 이 문서의 아래 내용은 실행 전 설계 기록이다.

## 목적

현재 live topology에는 runtime-ready PC가 네 대이고 관측된 network failure domain은 두 개다. 기존 canary는 세 PC가 모두 서로 다른 WAN에 있어야만 실행되므로, 메인 서버 한 대의 단절을 검증할 수 있는 현재 장비도 실행 전에 거부했다.

이번 단계는 보안 등급을 낮추지 않고 검증 목적을 둘로 분리한다.

- `failure-domain-loss`: 세 노드와 세 독립 WAN이 필요하다. 한 WAN 전체 장애까지 견디는 최종 등급이다.
- `main-host-loss`: 세 노드와 최소 두 WAN이 필요하다. 메인 서버 호스트 단절만 검증하며 WAN 장애 내재성 완료로 인정하지 않는다.

2-WAN 프로필은 HTTP를 허용하는 명시적 finite canary에서만 선택할 수 있다. production HTTPS 경로에서 최소 failure-domain 수를 2로 낮추면 verifier가 거부한다.

## 같은 NAT 아래 노드의 포트 충돌 제거

PC Sync 후보 `1.4.81`은 HMAC으로 검증된 runtime policy의 `upnpExternalPortsByNodeKeyId`를 지원한다.

- 키는 policy에 admitted 된 Ed25519 node key ID여야 한다.
- 포트는 동적/사설 범위 `49152..65535`만 허용한다.
- 한 policy 안에서 포트는 중복될 수 없다.
- 최대 여섯 노드만 허용한다.
- public relay 기능이 켜진 승인 lease에서만 유효하다.
- 각 PC는 자기 node key에 연결된 포트만 선택한다.
- 내부 gateway는 계속 TCP 5277이고 외부 포트만 노드별로 다르다.
- policy가 꺼지거나 만료되면 기존 mapping 삭제 절차와 1800초 hard ceiling이 적용된다.

현재 plan은 세 대상에 외부 포트 52001, 52002, 52003을 배정한다. 따라서 한 공유기 아래 두 PC도 서로 다른 origin으로 relay를 열 수 있다. 아직 rollout policy나 공유기 mapping은 쓰지 않았다.

## 읽기 전용 live 판정

2026-08-05 15:28 KST 관측:

- recent PC: 5
- fresh PC: 5
- runtime-ready PC: 4
- runtime-ready failure domains: 2
- `mainHostLossCanaryTopologyReady`: true
- `threeIndependentFailureDomainsReady`: false
- candidate-ready PC: 0 (default-off rollout 미실행)

`--scope=main-host-loss` plan은 세 node identity와 두 failure domain을 확인해 `ok: true`를 반환했다. `--scope=failure-domain-loss` plan은 같은 topology에서 계속 `THREE_INDEPENDENT_PUBLIC_FAILURE_DOMAINS_REQUIRED`로 거부된다.

## 남은 실환경 단계

1. 명시적 승인 ID로 세 PC에 `1.4.81` 후보와 30분 runtime policy를 전달한다.
2. TCP 52001, 52002, 52003 finite UPnP mapping을 만들고 세 public relay의 node identity를 다시 확인한다.
3. 세 RPC 표, 세 manifest 표, 세 directory source, 세 capsule 실행, 세 service shell을 확인한다.
4. 성공과 실패 양쪽에서 policy를 false로 바꾸고 mapping 삭제와 lease 만료를 확인한다.
5. 별도 outage 승인 창에서 메인 서버 경로를 차단하고 Android/Web 실제 단절 전환을 검증한다.

이 canary 성공은 메인 호스트 장애 생존 증거이지, 동일 WAN 안의 여러 PC를 독립 failure domain으로 세는 증거가 아니다. 최종 3-WAN 등급에는 여전히 제3 WAN PC가 필요하다.

증거: `evidence/two-domain-main-host-loss-canary-stage-redacted.json`
