> For the complete documentation index, see [llms.txt](https://docs.radiusaas.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.radiusaas.com/pt/outro/troubleshooting/falhas-de-autenticacao-eap-tls-atraves-de-cgnat-e-ligacoes-celulares.md). # Falhas de autenticação EAP-TLS através de CGNAT e ligações celulares Na segurança de rede, a Unidade Máxima de Transmissão (MTU) é um parâmetro de rede crítico que define o maior tamanho de pacote que pode ser transmitido através de uma ligação de rede sem ser fragmentado. Embora a maioria dos utilizadores não precise de pensar na MTU, ela torna-se um fator importante de resolução de problemas em cenários específicos, particularmente com autenticação RADIUS e EAP-TLS. Um sintoma típico é a autenticação funcionar na ligação principal à Internet, mas falhar através de uma ligação de reserva celular ou via satélite. Este artigo explica como a MTU afeta o RADIUS, especialmente quando estão envolvidos payloads grandes, como certificados EAP-TLS, porque isso pode levar a falhas de autenticação e como evitá-las com RADIUSaaS. *** #### Introdução à MTU e à Fragmentação A MTU é o maior tamanho de pacote que uma rede consegue suportar sem o dividir em partes menores. A MTU padrão para a maioria das redes Ethernet é de 1500 bytes. Quando um pacote é demasiado grande para uma ligação de rede, tem de ser descartado ou dividido em partes menores, um processo chamado fragmentação IP. O host de destino é responsável por voltar a reunir todos os fragmentos no pacote original. Ligações como 4G/5G e conexões via satélite têm frequentemente uma MTU efetiva menor do que uma ligação fixa típica, porque a operadora acrescenta a sua própria sobrecarga de tunelamento. Pacotes que passam inalterados numa ligação fixa podem, por isso, ser fragmentados nestas ligações. *** #### Fragmentação EAP vs. Fragmentação IP: Porque é que esta distinção é importante A distinção entre fragmentação EAP e fragmentação IP é crucial para compreender problemas de autenticação. A fragmentação IP acontece na camada de rede. Um router ou host divide um único datagrama UDP em vários pacotes IP menores. Isto acontece abaixo da aplicação RADIUS, que não tem conhecimento de que o seu pacote foi fragmentado. A fragmentação EAP acontece na camada da aplicação. O próprio protocolo EAP não suporta fragmentação, mas métodos EAP individuais, como o EAP-TLS, implementam a sua própria fragmentação. Quando uma mensagem EAP-TLS grande, como um certificado, é demasiado grande, é dividida em vários fragmentos EAP, e cada fragmento é transportado no seu próprio pacote RADIUS. A diferença fundamental é que a fragmentação IP depende de a rede entregar todos os fragmentos para que o pacote possa ser reconstituído, o que muitas vezes falha. A fragmentação EAP é tratada pelos dois pontos finais EAP, o cliente e o servidor RADIUS, e evita esses problemas ao nível da rede. *** #### Framed-MTU vs. Tamanho da Fragmentação EAP O atributo Framed-MTU é muitas vezes confundido com a fragmentação EAP, em parte porque é usado de duas formas diferentes. Num Access-Accept, Framed-MTU indica ao cliente RADIUS qual a MTU a configurar para a sessão do utilizador após a autenticação. Não tem qualquer efeito no próprio processo de autenticação. Num Access-Request, isso é importante para o EAP. A RFC 3579, secção 2.4, explica que um servidor RADIUS não pode usar a descoberta de MTU para conhecer a MTU da ligação, pelo que o autenticador pode incluir Framed-MTU num Access-Request que contenha EAP para dar essa informação ao servidor. Um servidor que o receba "NÃO DEVE enviar qualquer pacote subsequente nesta conversa EAP" cujos atributos EAP-Message concatenados excedam o tamanho anunciado, tendo em conta o tipo de ligação. Para IEEE 802.11, por exemplo, o servidor pode enviar um pacote EAP até Framed-MTU menos quatro octetos, permitindo os campos de cabeçalho 802.1X. Framed-MTU num Access-Request é, portanto, a forma padrão de um autenticador limitar o tamanho dos pacotes EAP que o servidor envia. Contudo, descreve a ligação entre o autenticador e o cliente, e não o caminho de rede entre o autenticador e o servidor RADIUS. Pode reduzir, como efeito secundário, o tamanho dos pacotes RADIUS nesse caminho, mas não garante proteção contra fragmentação IP em ligações com MTU reduzida. Referência: [RFC 3579, Secção 2.4 – Fragmentação](https://www.rfc-editor.org/rfc/rfc3579#section-2.4) *** #### Porque a Fragmentação EAP Sozinha Não é Suficiente Em teoria, a fragmentação EAP mantém cada pacote RADIUS suficientemente pequeno para atravessar a rede sem ser fragmentado por IP. É por isso que reduzir o tamanho do fragmento EAP é uma recomendação comum para servidores RADIUS alojados pelo próprio utilizador. Na prática, o tamanho do fragmento em cada direção é definido pelos dois pontos finais EAP: o supplicant do lado do cliente e o servidor RADIUS do outro lado. O autenticador atua como intermediário e não re-fragmenta mensagens EAP-TLS. As definições EAP em switches e pontos de acesso, como as oferecidas pela Cisco, Aruba ou Juniper, governam principalmente a ligação entre o autenticador e o cliente. Não controlam diretamente o tamanho dos pacotes que o servidor RADIUS devolve. Algumas plataformas, como a Meraki, não expõem esta definição de todo. A maior mensagem numa troca EAP-TLS viaja normalmente do servidor para o autenticador: o Access-Challenge que transporta a cadeia de certificados do servidor. Isso torna o tamanho do fragmento do lado do servidor o fator decisivo. Com RADIUSaaS, este valor é gerido pelo serviço e não pode ser ajustado por cliente, pelo que afinar a fragmentação EAP apenas nos seus dispositivos não impedirá de forma fiável a fragmentação IP em ligações com MTU reduzida. Diminuir a MTU de toda a interface WAN também não é uma boa resposta. Afeta todo o tráfego nessa ligação e, por si só, não impede que pacotes RADIUS UDP sejam fragmentados. A abordagem mais robusta é alterar a forma como o tráfego RADIUS é transportado, como descrito abaixo. *** #### Porque a Fragmentação Falha com CGNAT A fragmentação IP é uma causa comum de falhas de autenticação, especialmente em redes que usam Carrier-Grade NAT (CGNAT), como a maioria das ligações 4G/5G e Starlink. Muitas firewalls e dispositivos CGNAT não foram concebidos para lidar com pacotes fragmentados. Apenas o primeiro fragmento transporta os números de porta UDP que o NAT usa para acompanhar uma ligação, por isso os fragmentos restantes são muitas vezes descartados, seja deliberadamente por motivos de segurança, seja porque o dispositivo não consegue associá-los a uma sessão. Se até um único fragmento se perder, o datagrama UDP original não pode ser reconstituído. O UDP não tem mecanismo de retransmissão para a parte em falta, por isso todo o pacote se perde e a autenticação acaba por expirar por timeout. Isto afeta ambas as direções, mas em EAP-TLS atinge mais ხშირად a resposta do servidor. O Access-Challenge que transporta a cadeia de certificados do servidor é normalmente o maior pacote na troca. Se os seus fragmentos forem descartados, o autenticador nunca recebe o desafio e a autenticação falha. *** #### Solução: Usar RadSec ou Manter o RADIUS UDP fora de Caminhos CGNAT Com RADIUSaaS, o tamanho do fragmento EAP no lado do servidor é gerido por nós e não pode ser alterado por cliente. A correção mais fiável é, portanto, impedir que os pacotes grandes de autenticação sejam fragmentados por IP em caminhos que não conseguem lidar com fragmentos. A opção preferida é ligar o seu autenticador ao RADIUSaaS usando RadSec em vez de RADIUS clássico sobre UDP. O RadSec transporta RADIUS sobre TLS na porta TCP 2083, pelo que pacotes grandes, como a cadeia de certificados do servidor, são divididos em segmentos TCP dimensionados para o caminho e não em fragmentos IP. Firewalls e dispositivos CGNAT tratam-nos como qualquer outro tráfego TCP, e o problema desaparece. Muitas plataformas atuais suportam RadSec de forma nativa. Se o seu dispositivo se ligar através de uma ligação com MTU reduzida, como uma reserva celular ou via satélite, certifique-se também de que o MSS TCP corresponde à MTU real do caminho. Pode fazê-lo definindo uma MTU mais baixa nessa interface WAN, para que os segmentos TLS grandes não sejam descartados silenciosamente. Se o seu autenticador não suportar RadSec, evite enviar RADIUS UDP diretamente através de ligações CGNAT, como 4G/5G ou Starlink. Uma opção é encaminhar o tráfego RADIUS através de uma VPN site-to-site existente para um local com uma ligação fixa à Internet e enviá-lo daí para o proxy RADIUSaaS. Dentro do túnel VPN, os fragmentos são encapsulados e deixam de ser descartados pelo NAT da operadora. Outra opção é executar um pequeno proxy RadSec no local. Este aceita RADIUS UDP dos seus dispositivos na rede local e reencaminha-o para o RADIUSaaS através de RadSec. *** #### Conclusão Mensagens EAP-TLS grandes, em particular a cadeia de certificados do servidor RADIUS enviada durante o handshake, podem exceder a MTU de alguns caminhos de rede. Quando isso acontece sobre UDP, os pacotes são fragmentados por IP. Firewalls e dispositivos CGNAT descartam frequentemente esses fragmentos, o que provoca timeouts de autenticação que normalmente só aparecem em certas ligações, como uma ligação de reserva celular. Como o tamanho do fragmento do lado do servidor RADIUSaaS não pode ser ajustado por cliente, a correção mais robusta é usar RadSec sempre que possível, o que elimina completamente a fragmentação IP. Onde o RadSec não estiver disponível, mantenha o RADIUS UDP fora dos caminhos CGNAT, fazendo tunelamento ou usando um proxy RadSec local. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.radiusaas.com/pt/outro/troubleshooting/falhas-de-autenticacao-eap-tls-atraves-de-cgnat-e-ligacoes-celulares.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.