Compressão no OpenVPN: recusar, apenas receber ou LZO completo?
comp-lzo no não é uma recusa estrita. Compare recusar a compressão, aceitá-la num só sentido durante uma migração e mantê-la, e depois verifique o que o offload faz.
Três linhas de um perfil parecem todas desativar a compressão, e apenas uma delas o faz de facto. A diferença importa porque o aviso que quer silenciar é um sintoma, enquanto a política é o que decide se o outro extremo ainda pode comprimir. Comparar as opções num único eixo, ou seja, o que cada uma permite depois da alteração, elimina a maior parte da ambiguidade. Qual querer depende de estar a migrar ou a assentar.
Três políticas que parecem iguais num ficheiro de configuração
Cada opção responde a uma pergunta diferente. allow-compression no recusa as cargas comprimidas de imediato, allow-compression asym descomprime o que chega e nunca comprime o que sai, e a antiga comp-lzo no deixa espaço para um push do outro extremo ativar a compressão. Só a primeira é uma política que um servidor não pode anular.
Escreva as três numa tabela antes de escolher, porque os nomes são suficientemente próximos para enganar um revisor. Duas delas ainda executam código de descompressão nos pacotes recebidos, e é exatamente disso que trata o argumento de segurança. A terceira remove a capacidade em vez de restringir a sua direção. Se o registo da alteração diz que a compressão está desativada, exatamente uma linha satisfaz essa frase.
O aviso que iniciou a investigação não é o objetivo. Silenciá-lo mantendo uma política permissiva dá um registo limpo e uma exposição inalterada.
| Setting | What it permits | When it is the right answer |
|---|---|---|
allow-compression no | No compressed payloads, and no compression framing under offload | Both ends can be changed now |
allow-compression asym | Decompress inbound only | A dated migration while peers catch up |
comp-lzo no | Off locally, still pushable by a peer | Legacy compatibility you can still justify |
O que significa no na antiga opção LZO
Na opção LZO obsoleta, no desativa a compressão do lado local sem proibir o outro extremo de a ativar onde a política o permite. É essa assimetria que faz com que passar um perfil para uma recusa estrita altere o comportamento de formas que um teste de laboratório com um único servidor pode nunca revelar.
A preocupação de segurança é condicional, não absoluta. Quando um atacante pode colocar texto simples escolhido ao lado de um segredo e observar como a compressão altera o tamanho do tráfego cifrado, existe um canal de informação. Passar de LZO para LZ4 altera o algoritmo e o enquadramento, não esse mecanismo.
Assim, o enquadramento honesto diz respeito ao que está disposto a permitir, não a qual algoritmo é recomendado agora. A recusa estrita é a única opção que não depende da cooperação do outro extremo.
Apenas receber é um estado de migração, não um destino
A aceitação assimétrica existe para que um extremo possa deixar de comprimir enquanto o outro ainda o espera. É uma ponte, e as pontes precisam de uma data de fim e de um responsável. Registe quais pares ainda enviam tráfego comprimido, porque a política permite exatamente esse tráfego. Sem essa lista, o estado de migração torna-se a configuração permanente por inércia.
Um cliente não pode obrigar um servidor incompatível a abandonar o enquadramento antigo editando o seu próprio ficheiro. A direção do push decide-se no servidor, por isso a migração termina de facto na configuração do servidor e nos seus ficheiros por cliente.
Os modos stub conservam o enquadramento mas saltam o trabalho de compressão propriamente dito, e não são um equivalente direto da opção mais antiga. Teste-os contra o par mais antigo que ainda tem de suportar antes de optar por um.
Onde o offload do canal de dados altera a resposta
O offload do canal de dados leva o processamento de pacotes para o kernel, e um perfil que ainda depende do enquadramento de compressão pode não encaixar nesse caminho. A falha nem sempre é ruidosa: um cliente liga-se e depois comporta-se de forma diferente do túnel que testou.
Verifique que implementação está ativa antes e depois da alteração, não apenas se a ligação tem sucesso. Quando o caminho com offload recusa o enquadramento de compressão, uma política de recusa estrita e uma implementação com offload concordam, enquanto uma política permissiva e uma implementação com offload não.
Essa combinação merece um teste próprio, porque é exatamente aí que um ficheiro que parece correto, em silêncio, não é o que está a ser usado. Compare o estado negociado com a intenção registada no perfil, porque só um dos dois é visível num registo.
Escolha uma política e depois verifique o resultado negociado
Escolha a recusa estrita quando pode alterar ambos os extremos, a aceitação assimétrica quando ainda não pode, e a compressão completa só quando consegue explicar porque a exposição é aceitável. Depois verifique o que foi negociado em vez do que diz o ficheiro. Um registo mais silencioso só é prova quando corresponde à política que pretendia implementar.
Mantenha a decisão junto ao perfil a que se aplica, com a data e os pares ainda isentos. Seis meses depois, essa nota é a diferença entre uma exceção deliberada e um acidente que ninguém consegue datar. Escreva-a no mesmo repositório do perfil, para que o próximo editor veja o motivo antes da diretiva.