OpenVPN 트래픽 셰이핑: 어느 인터페이스가 그것을 보는가?

네 가지 점검을 거쳐라: 무엇을 제한하려는지, 그것을 식별하는 정보를 어느 패킷이 나르는지, 셰이퍼가 어느 인터페이스를 볼 수 있는지, 암호화하는 동안 라우터가 무엇을 견디는지. 라우터에는 OpenVPN 페이지와 대역폭 페이지가 함께 제공되지만, 둘의 공존은 어느 쪽에 대해서도 아무것도 증명하지 않는다. 순서가 중요하므로, 잘못된 패킷에 대해 작성한 규칙은 그 속도가 아무리 정확해도 절대 일치하지 않는다.

목표부터 시작하라: 단일 장치 제한, 용량의 공정한 공유, 또는 한 애플리케이션의 우선순위. 각각 다른 매칭이 필요하다.

규칙보다 먼저 목표를 이름 붙여라

장치별 상한은 그 장치의 주소에 대한 매칭이 필요한데, 그 주소는 터널 안에만 존재한다. 경쟁 흐름 사이의 공정성은 모두가 공유하는 큐가 필요하지, 호스트별 규칙이 아니다. 앱 우선순위는 애플리케이션을 식별하는 무언가가 필요하며, 암호화가 내부 헤더를 시야에서 제거한 뒤에는 셋 중 가장 어렵다. 목표를 먼저 적으면 어떤 사실이 필요한지, 어디서 얻을 수 있는지 알 수 있다.

직접 WAN 트래픽에서 작동하는 상한은 같은 호스트가 터널 안에서도 커버된다는 증거가 아니다. 규칙은 셰이퍼가 보는 헤더에 절대 나타나지 않는 주소와 매칭되고 있을 수 있다.

터널 안인가, 밖인가

라우터가 소유한 VPN 클라이언트를 쓰면 많은 LAN 흐름이 하나의 암호화된 전송 안을 지난다. 캡슐화 전에는 라우터가 여전히 내부 출발지와 목적지를 보므로, 그 단계에 붙인 정책은 장치별로 분류할 수 있다. 캡슐화 후에는 일반 장비가 외부 연결만 보며, VPN 포트에 대한 매칭은 어느 장치가 책임인지에 대해 아무것도 말하지 않는다. 그 하나의 사실이 규칙의 위치를 결정한다.

플랫폼마다 이것을 노출하는 방식이 다르다. 어떤 것은 터널 인터페이스에서 큐잉과 분류를 하는 셰이퍼를 제공하고, 다른 것은 리미터를 VPN과 비VPN 트래픽에 똑같이 동작하는 인터페이스 규칙으로 취급하며, 어떤 것은 서로 다른 능력으로 둘 다 한다. 다른 벤더의 안내서에서 인터페이스 이름을 복사하는 대신, 지원하는 인터페이스에 대한 펌웨어 자체 문서를 읽어라.

주소가 어디서 계속 사용 가능한지, 변환이 어디서 일어나는지, 어느 큐가 실제로 병목을 제어하는지 파악하라.

세 가지 정책, 세 가지 증거

속도 상한은 제한된 장치에서 지속적인 전송이 이루어지는 동안 다른 장치가 동시에 전송하는 것으로 입증된다. 공정한 공유는 하나가 굶주리는 대신 두 흐름이 비슷한 속도에 도달하는 것으로 입증되며, 이는 다른 측정이다. 앱 우선순위는 대량 전송 중에 대화형 작업이 응답성을 유지하는 것과, 분류기가 흐름을 인식했는지 확인하는 것으로 입증된다. 각 정책은 고유한 관찰이 필요하며, 어느 것도 구성 페이지로 입증되지 않는다.

분류는 특별한 의심을 받을 만하다. 외부 암호화 포트에 대한 매칭은 모든 내부 애플리케이션의 정체성을 복원할 수 없으므로, 한 애플리케이션을 우선시하는 것처럼 보이는 규칙이 실제로는 그 터널에서 나오는 모든 것을 우선시할 수 있다. 규칙의 의도가 아니라 카운터를 읽어라.

암호화된 워크로드를 측정하라, 벌거벗은 것을 아니라

셰이핑, 분류, 암호화는 하나의 CPU를 두고 경쟁하며, 하드웨어 가속은 당신이 지켜보는 바로 그 규칙과 카운터를 지나쳐 트래픽을 보낼 수 있다. 단순한 라우팅 테스트의 처리량 수치는 암호화되고 셰이핑된 워크로드 아래의 박스에 대해 거의 말해 주지 않는다. 양방향, 여러 대표 클라이언트, 그리고 대량 전송과 함께 작은 대화형 작업을 시험하라. 부하 상태의 응답성이 유휴 링크의 최고 수치보다 중요하다.

측정에 예외를 포함하라: 터널을 우회해야 하는 트래픽, 둘 다 관여한다면 두 주소 체계, 그리고 터널이 끊겼을 때 무슨 일이 일어나는지. 터널이 건강할 때만 합리적으로 행동하는 정책은 절반의 정책이다.

명세를 세 줄로 써라: 트래픽 매칭, 적용 지점, 측정된 워크로드. OpenVPN과 QoS는 명세가 아니다.