업링크는 둘인데 터널은 하나: 페일오버, 분산, 아니면 본딩
페일오버, 흐름별 분산, 단일 흐름 집계는 서로 다른 세 가지 약속입니다. 기본 경로가 둘이라도 얻는 것은 첫 번째뿐이고 나머지 둘은 아닙니다.
인터넷 회선 두 개는 VPN의 가용성을 높이고 일부 워크로드에서는 속도도 높일 수 있지만, 둘 중 무엇이 일어나는지는 메커니즘이 결정합니다. 기본 경로가 둘인 라우터는 본딩된 것이 아니며, 수천 개의 내부 연결을 나르는 터널도 여전히 하나의 외부 흐름입니다. 약속을 먼저 이름 붙이는 것이 설계와 값비싼 실망의 차이입니다. 아래 표는 각 방식이 원격 끝에서 무엇을 요구하고 링크 손실이 전송에 무엇을 하는지로 선택지를 나눕니다.
세 가지 약속, 파트너가 필요한 것은 하나뿐
페일오버는 선호 링크가 사라져도 경로를 사용 가능하게 유지합니다. 흐름 해시 분산은 독립적인 흐름을 두 업링크에 퍼뜨립니다. 단일 흐름 집계는 하나의 전송이 두 링크를 동시에 쓰게 합니다. 이것들은 요구 사항이 다른 별개의 제품이며, 마지막 것만 라우터 밖의 무언가의 협력을 필요로 합니다.
| Mechanism | Far-end requirement | Effect on one transfer | What breaks under a link loss |
|---|---|---|---|
| Packet-spraying overlay | A cooperating endpoint that reassembles the stream | Packets can spread across both links | Reordering and buffering on the surviving path; its own recovery logic decides what continues |
| MPTCP subflows | A peer or proxy that accepts subflows | Subflows can share one connection | Surviving subflows continue if the peer keeps them alive |
| Flow-hash balancing | Nothing new; the existing tunnel endpoint is enough | One outer flow still follows one link | Flows hashed onto the dead link move; established sessions break |
| Link failover | Nothing new | One path at a time; the second link sits idle | The session stalls or restarts on the other link |
그 표 어디에도 두 번째 회선을 살 이유는 없습니다. 그 표가 하는 일은 페일오버 설계를 본딩인 것처럼 평가하지 않게 막는 것입니다.
라우터에게 터널이 하나의 흐름처럼 보이는 이유
부하를 분산하는 라우터는 출발지와 목적지 주소를 포트와 함께 해시한 뒤 해시가 가리키는 곳으로 흐름 전체를 보냅니다. VPN 터널은 라우터의 관점에서 그런 하나의 흐름이며, 그 안에서 무엇이 돌든 마찬가지입니다. 내부 연결은 해시 결정에 도달하지 않습니다. 바깥 헤더가 이미 경로를 정했기 때문입니다. 그래서 두 번째 업링크는 많은 사용자의 총 용량을 두 배로 늘릴 수 있지만 한 사용자의 큰 전송에는 아무것도 바꾸지 않습니다.
터널 두 개를 따로 두면 후보가 둘 생기지만, 여전히 트래픽을 배정하고 응답을 요청이 지나간 경로에 유지하는 의도적인 정책이 필요합니다. 그 단계를 건너뛰면 비대칭 라우팅이 흔한 결과입니다. 최소한 흐름, 선호 링크, 예비 링크를 지명하는 정책이 있어야 합니다.
이더넷 본딩은 서로 무관한 사업자를 넘지 못합니다. 원격 끝이 집계 프로토콜에 참여해야 하기 때문입니다. 협력하는 끝점이 없다면 두 ISP에 걸친 본딩은 연구 프로젝트입니다.
멀티패스 TCP가 양쪽 끝에서 요구하는 것
Linux의 Multipath TCP 문서는 하나의 연결에 속한 여러 하위 흐름을 설명합니다. 한쪽 끝의 커널 지원만으로는 아무것도 바뀌지 않습니다. 상대도 그 하위 흐름을 받아들여야 하기 때문입니다. 원격 쪽의 프록시가 또 다른 흔한 구성이며, 자체 용량과 가용성을 가진 구성 요소가 되어 계획에 넣어야 합니다. 같은 논리로 WireGuard에는 쉬운 답이 없습니다. 전송이 UDP이기 때문입니다. MPTCP는 TCP 하위 흐름을 늘리는 것이고, 설계에 다른 요소가 없으면 그 터널을 집계할 수 없습니다.
커널 기능이 켜져 있는지는 그것을 전제로 설계하기 전에 확인하세요. 많은 배포판이 꺼진 채로 내놓습니다. 이 세 명령이 일 분이면 답합니다.
sysctl net.mptcp.enabled
ss -M | head
ip mptcp limits show브로슈어가 아니라 워크로드로 고르세요
워크로드가 독립적인 세션이 많다면 흐름 해시 분산이 원격 끝의 협력 없이 용량을 더할 수 있습니다. 하나의 큰 전송이라면 집계 설계만 도움이 되고, 그 설계에는 협력하는 상대가 필요합니다. 링크가 죽어도 작업이 계속되는 것이 요구 사항이라면 답은 페일오버이고, 한 전송의 처리량은 무관합니다.
요구 사항을 동사가 들어간 한 문장으로 쓰세요. 백업 하나가 두 배 빠르게 끝난다, 또는 끊긴 링크가 세션을 끝내지 않는다. 모호한 목표는 아무도 받아들이거나 거부할 수 없는 설계를 낳습니다. 다음으로 원격 끝이 무엇이어도 되는지 정하세요. 가장 싼 선택지는 그곳에 새로운 것을 요구하지 않는 경우가 많기 때문입니다. 그 제약이 첫 회의 전에 브로슈어 주장의 대부분을 지웁니다.
요구 사항 문서에서 세 약속을 따로 두세요. 셋 다 주장하는 설계는 보통 하나를 내놓고 나머지를 조용히 가정합니다. 다음 절은 실제로 무엇이 제공되는지 시험합니다.
전송 하나와 여럿을 시험하고, 그다음 링크를 뽑으세요
지속적인 전송 하나를 같은 목적지로 가는 여러 병렬 전송과 비교하세요. 그리고 각각의 손실, 지연, 링크별 사용률을 기록합니다. 병렬 세션에서만 이득이 난다면 그것은 흐름 분산을 가리키며, 단일 흐름 집계가 아닙니다. 업링크 하나의 손실은 따로 시험하세요. 두 링크가 모두 동작할 때의 용량은 이미 성립된 세션의 페일오버에 대해 아무것도 말해 주지 않습니다. 각 시험 전후로 경로, 소켓, 재전송 카운터를 기록하세요.
ip route show default
ip route get 10.80.0.5
mtr -n -c 20 -r 10.80.0.5단일 전송이 여전히 업링크 하나를 쓴다면, 그 설계는 흐름 해시가 함축하는 그대로 동작합니다. 병렬 전송이 둘로 퍼진다면 분산은 되고 집계는 되지 않습니다. 설계가 세 약속 중 무엇을 실제로 지키는지 기록하세요. 다음 용량 논의는 공급업체의 주장이 아니라 증거에서 시작합니다.