VPN 포트를 표시한다고 음성 통화가 우선되지는 않습니다

VPN의 UDP 포트를 높은 우선순위로 표시하는 것은 가장 흔한 음성 QoS 변경이며, 같은 터널을 공유하는 파일 전송에서 통화를 분리하지 못합니다. 두 흐름 모두 같은 암호화 소켓으로 나갑니다. 표시는 다음 홉에 모든 것이 똑같이 중요하다고 알려 주는데, 이는 아무것도 알려 주지 않는 것과 같습니다. 통화를 보호하는 것은 암호화 전의 신뢰할 수 있는 분류와 실제로 직접 제어하는 대기열입니다.

터널은 분류하려던 흐름을 숨깁니다

암호화는 내부 헤더를 터널마다 하나의 외부 헤더로 바꿉니다. 그 뒤에는 음성과 백업 트래픽이 같은 출발지, 목적지, 전송 포트를 보여 주므로 터널 포트를 기준으로 하는 분류기는 둘을 구분할 수 없습니다. 무엇을 올리든 한꺼번에 올립니다.

원래 응용 프로그램이 설정한 DSCP 값은 무언가가 이것을 바깥으로 복사할 때만 살아남는데, OpenVPN 2.6에는 passtos가 있으며 IPv4 범위로 문서화되어 있습니다. IPsec은 터널 경계에서 자체 복사 또는 매핑 정책을 적용합니다. 그 단계가 없으면 바깥 패킷은 터널 인터페이스가 쓰는 기본값으로 표시되고, 하위 대기열은 안에 통화가 있다는 것을 결코 알지 못합니다.

복사된 표시는 클라이언트가 제공한 어떤 값과도 똑같이 의심해야 합니다. 워크스테이션은 백업 작업을 위해 빠른 전달을 주장할 수 있으므로, 신뢰 경계에서의 수용과 재표시는 표시를 믿기 전에 설계에 들어가야 합니다.

우선순위는 대기열이 형성되는 곳에서만 의미가 있습니다

포화된 업링크가 좋은 코덱을 로봇 같은 음성으로 만드는 원인이며, 차오르는 대기열은 보통 액세스 장치나 제공자 버퍼에 있습니다. 터널과 링크 오버헤드를 뺀 사용 가능한 속도로 송신 경로를 성형하는 것이 그 대기열을 다른 사람의 버퍼가 아니라 직접 관리하는 하드웨어에 두게 합니다.

공정한 대기열과 능동 대기열 관리가 음성 클래스 없이도 도움이 되는 것은, 하나의 대용량 흐름이 버퍼를 채우는 것을 막기 때문입니다. Linux의 CAKE는 성형, 흐름별 공정성, 선택적 Diffserv 클래스를 하나의 qdisc에 묶으며, 배포된 네트워크 관리자가 두 번째 경쟁 대기열 설정이 아니라 그 구성을 소유해야 합니다. 성형이 없으면 대용량 트래픽보다 위인 클래스도 이미 가득 찬 버퍼 뒤에서 기다립니다.

수신 측 처리가 쓸모없지는 않지만 패킷이 수신 링크를 지난 뒤에 작동합니다. 응답하는 송신자에 영향을 줄 수 있고 상류에서 이미 쓴 지연을 되돌려 줄 수는 없으므로 보장이 아니라 완화입니다.

공용 인터넷에서 살아남는 것

Diffserv 아키텍처는 관리 도메인 내부의 처리를 설명하며, 그래서 제공자가 경계에서 표시를 무시하거나 다시 쓸 수 있습니다. 모든 네트워크가 항상 그것을 제거한다는 반대 주장도 근거가 같지 않습니다. 정직한 질문은 이 특정 경로가 계약상 무엇을 하도록 되어 있고 어떻게 감시되는가입니다. 어디선가 읽은 규칙을 반복하지 말고 표시된 프로브로 시험하십시오.

제공자가 클래스를 어떻게 다루는지 물은 다음 측정하십시오. 보존되지만 스케줄되지 않는 표시는 장식이고, 표시를 보지 않고 스케줄하는 경로는 다른 문제이며 둘에는 다른 수정이 필요합니다.

단계를 분리하는 측정 계획

통제된 경쟁 업로드와 함께 평범한 통화를 한 번 하고, 그다음 유선 링크에서 반복하십시오. 통화가 무엇을 잃었는지, 클래스 카운터가 무엇을 기록했는지, 인터페이스가 요금제의 광고 속도가 아니라 실제 한계에 얼마나 가까이 가는지 보십시오.

tc -s qdisc show dev eth0
tc -s class show dev eth0
mtr -rwzbc 50 voice.example.net

음성 클래스 카운터가 영에 머문다면 분류나 표시 복사가 고장 난 것이며 어떤 우선순위도 도움이 되지 않습니다. 지연이 계속 오르는데 클래스 카운터가 로컬에서 움직이면 병목은 게이트웨이 너머에 있습니다. 두 결과 모두 우선순위 값을 올려 고칠 수 없습니다.