Marcar a porta da VPN não dá prioridade às chamadas de voz

Marcar a porta UDP da VPN como alta prioridade é a mudança de QoS de voz mais comum, e não separa uma chamada da transferência de ficheiros que partilha esse túnel. Ambos os fluxos saem pelo mesmo socket cifrado. A marca diz ao próximo salto que tudo importa por igual, o que é o mesmo que não lhe dizer nada. O que protege uma chamada é uma classificação de confiança antes da cifragem mais uma fila que você controla mesmo.

O túnel esconde o fluxo que queria classificar

A cifragem substitui os cabeçalhos internos por um cabeçalho externo por túnel. Depois disso, a voz e o tráfego de cópia de segurança apresentam a mesma origem, destino e porta de transporte, pelo que um classificador baseado na porta do túnel não consegue distingui-los. Seja o que for que promova, promove-o em bloco.

Um valor DSCP definido pela aplicação de origem só sobrevive se algo o copiar para fora. O OpenVPN 2.6 tem passtos, documentado com âmbito IPv4; o IPsec aplica a sua própria política de cópia ou de mapeamento na fronteira do túnel. Sem esse passo, o pacote externo é marcado com qualquer valor padrão que a interface do túnel use, e a fila a jusante nunca fica a saber que há uma chamada lá dentro.

As marcas copiadas merecem a mesma desconfiança que qualquer valor fornecido pelo cliente. Uma estação de trabalho pode reclamar encaminhamento acelerado para uma tarefa de cópia de segurança, por isso a admissão e a remarcação na fronteira de confiança devem estar no projeto antes de a marca ser acreditada.

A prioridade só conta onde a fila se forma

É um uplink saturado que transforma um bom codec numa voz robótica, e a fila que enche costuma estar no dispositivo de acesso ou no buffer do fornecedor. Moldar o caminho de saída à velocidade utilizável, menos a sobrecarga do túnel e da ligação, é o que mantém essa fila em hardware que você administra e não no buffer de outra pessoa.

O enfileiramento justo e a gestão ativa de filas ajudam mesmo sem classe de voz, porque impedem que um fluxo maciço encha o buffer. O CAKE no Linux agrupa moldagem, equidade por fluxo e classes Diffserv opcionais num único qdisc, e o gestor de rede implementado deve possuir essa configuração em vez de uma segunda fila concorrente. Sem moldagem, uma classe que ultrapassa o tráfego maciço continua a esperar atrás de um buffer já cheio.

O tratamento à entrada não é inútil, mas atua depois de o pacote ter atravessado a ligação de receção. Pode influenciar um emissor recetivo e não pode devolver o atraso já gasto a montante, pelo que é uma mitigação e não uma garantia.

O que sobrevive na internet pública

A arquitetura Diffserv descreve o tratamento dentro de domínios administrativos, e é por isso que um fornecedor pode ignorar ou reescrever uma marca numa fronteira. A afirmação contrária, de que todas as redes a removem sempre, é igualmente infundada. A pergunta honesta é o que este caminho concreto está contratado e fiscalizado para fazer. Teste-o com uma sonda marcada em vez de repetir uma regra que leu algures.

Pergunte o que o fornecedor faz com a classe e depois meça. Uma marca preservada mas não escalonada é decoração; um caminho que escalona sem ver a marca é outro problema, e os dois precisam de correções diferentes.

Um plano de medição que isola a etapa

Faça uma chamada normal com um envio concorrente controlado e repita-a numa ligação por cabo. Veja o que a chamada perdeu, o que os contadores de classe registaram e quão perto a interface anda do seu limite real e não da velocidade anunciada do plano.

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

Se o contador da classe de voz ficar em zero, a classificação ou a cópia da marca está quebrada e nenhuma prioridade ajudará. Se o contador de classe se mover localmente enquanto o atraso continua a subir, o estrangulamento está para lá da sua gateway. Nenhum dos dois resultados se corrige aumentando o valor de prioridade.