MSS clamping num gateway VPN: o que corrige e o que não corrige

Os pedidos pequenos funcionam, as transferências grandes encravam e alguém sugere MSS clamping. Essa sugestão está certa com frequência suficiente para valer a pena experimentá-la na ordem correta, e errada com frequência suficiente para fazer perder uma tarde se for aplicada às cegas. As três verificações abaixo separam um problema real de tamanho TCP de um problema UDP, de uma descoberta path-MTU quebrada e de um clamp que nunca vê o handshake que deveria reescrever.

Comece pela forma da falha

Uma falha de tamanho tem assinatura: a ligação estabelece-se, a autenticação e as respostas pequenas têm sucesso, e depois uma transferência bloqueia indefinidamente assim que precisa de um segmento de tamanho completo. As páginas que carregam texto mas nunca terminam uma imagem são a mesma falha em menor escala. Se nada se liga de todo, o problema está mais atrás no caminho e o clamping não ajudará. Um clamp não repara um handshake que nunca chegou.

A assinatura existe porque é no handshake que se acorda o tamanho do segmento. Cada lado anuncia um tamanho máximo de segmento como opção TCP, e os emissores respeitam o anúncio do par. Se o caminho não consegue transportar um segmento tão grande, a falha aparece mais tarde, quando o emissor finalmente tenta um.

Mantenha o transporte à vista enquanto lê esse sintoma. O clamping é uma reescrita de uma opção TCP, por isso uma chamada de voz ou vídeo que bloqueia no mesmo túnel não é um problema de MSS e não melhora com isso. Registe o transporte antes de tocar numa opção TCP.

Pese o caminho e compare-o com o túnel

Dois números importam e são frequentemente confundidos. A path-MTU é o maior pacote que o caminho transporta sem fragmentação, e o MSS anunciado para IPv4 é esse valor menos os 40 bytes de cabeçalhos IP e TCP, ou menos 60 para IPv6. O encapsulamento do túnel consome parte do orçamento antes de o pacote interior sequer começar.

ping -M do -s 1400 198.51.100.20
tracepath 198.51.100.20

O ping com o bit do-not-fragment diz-lhe se sobrevive um pacote desse tamanho de carga útil; ajuste o tamanho até falhar e terá encontrado o limite do caminho empiricamente. A saída do tracepath indica o MTU descoberto ao longo da rota, que é mais rápido quando funciona e menos fiável quando um salto intermédio filtra as sondas.

Agora subtraia a sobrecarga do túnel. Um cabeçalho IP exterior, um cabeçalho UDP e um cabeçalho específico do túnel saem todos dos mesmos 1500 bytes, por isso o MTU interior utilizável numa base Ethernet típica é mais baixo do que o link físico sugere. Se o MTU interior calculado for inferior ao que os seus pares anunciam, encontrou um candidato real a clamp e não uma suposição. Se o valor calculado já estiver acima do anúncio dos pares, pare aqui e procure noutro lugar.

Coloque o clamp onde o handshake passa

Um clamp funciona reescrevendo a opção MSS nos pacotes SYN e SYN-ACK quando atravessam o gateway. Se a regra estiver numa interface que nenhuma das duas direções atravessa, a negociação conclui-se sem alterações e o sintoma persiste, por isso a colocação decide o resultado mais do que o valor.

A direção é a outra metade. Fazer clamp numa só direção corrige metade dos fluxos e deixa o resto a falhar de uma forma que parece intermitente, por isso aplique-o às duas direções do tráfego reencaminhado. A forma clássica em Linux para uma interface de túnel é uma regra mangle que corresponde a pacotes SYN:

iptables -t mangle -A FORWARD -o tun0 -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Repare no que --clamp-mss-to-pmtu realmente faz: deriva o valor do MTU da rota, que nem sempre é o orçamento real de carga útil do túnel. Num túnel baseado em rota em que a rota interior e o caminho exterior diferem, um valor explícito calculado na verificação anterior é mais previsível do que um automático.

Verifique com uma nova ligação e mantenha o feedback vivo

Uma ligação estabelecida mantém o MSS negociado, por isso testar na mesma sessão não prova nada. Abra uma ligação nova após a alteração e leia o valor negociado diretamente em vez de o inferir de uma transferência que termina por acaso.

ss -tin dst 198.51.100.20
iptables -t mangle -S | grep TCPMSS

O primeiro comando relata o MSS do socket juntamente com o estado de congestionamento, que é a confirmação mais rápida de que o clamp surtiu efeito. O segundo confirma que a regra que julga ter adicionado é a regra que existe, na tabela onde foi colocada.

Depois proteja o mecanismo que não corrigiu. A descoberta path-MTU depende de as mensagens ICMP fragmentation-needed chegarem ao emissor, por isso uma firewall que as descarta continuará a quebrar transferências grandes mesmo com um clamp correto. Permita essas mensagens para o caminho do túnel, ou aceite que o clamping compensa uma política que escolheu.

Por fim, resista à tentação de tratar o clamp como um botão de afinação. Restringe o tamanho do segmento, o que custa débito em caminhos que nunca precisaram dele. Aplicado depois das três verificações é uma reparação dirigida; aplicado primeiro é uma alteração que esconde a falha original e acrescenta uma segunda variável a cada teste posterior. Essa troca merece ser feita deliberadamente, não por omissão.

Registe a path-MTU medida, a sobrecarga do túnel subtraída, a regra adicionada e o MSS observado depois. Quatro números fazem do próximo incidente uma consulta em vez de uma investigação.