MTU da VPN no iPhone: escolha o dono antes de mudar um número
Três perguntas decidem se o aplicativo, o perfil do gateway ou ninguém no telefone pode mudar o tamanho. Responda antes de pegar um número emprestado de um Mac.
Toda discussão sobre o tamanho dos pacotes da VPN no iPhone acaba oferecendo o mesmo comando de Mac contra uma interface chamada ppp0, normalmente com um número anexado. Ele não se transfere, e não seria o controle correto nem no Mac, a menos que essa interface pertencesse à conexão em questão. No telefone, o número pertence a quem implementa o túnel: o sistema operacional em um perfil nativo, um provedor de túnel de pacotes em um aplicativo, ou o gateway quando um atributo documentado é negociado. Três perguntas esclarecem com qual desses casos você está lidando.
Pergunta um: qual cliente está em execução
Um perfil IKEv2 nativo, o perfil Cisco IPsec embutido e um cliente Cisco de terceiros são três implementações diferentes com três conjuntos diferentes de atributos suportados. O tipo de perfil em Ajustes diz qual o telefone realmente iniciou, e a lista de aplicativos diz se há algum provedor no caminho. Comece por aí, porque o resto da decisão decorre disso. Se nenhum provedor aparecer na lista de aplicativos, o sistema operacional é o dono do túnel.
Não deduza a implementação do fornecedor do gateway. Um headend Cisco pode encerrar conexões de clientes que não compartilham nada além do nome do fornecedor. Uma captura de tela de uma compilação antiga em uma versão antiga diz o que aquele par suportava, não o que o telefone na sua mão faz.
Pergunta dois: quem é dono do valor
A Apple expõe uma propriedade MTU aos desenvolvedores de túneis de pacotes por meio do objeto de ajustes da extensão de rede. É uma API para o provedor que configura o próprio túnel, não um interruptor que um usuário ou administrador possa acionar no cliente instalado de outra pessoa. Um aplicativo de terceiros pode optar por expô-la, ignorá-la ou fixar um valor de forma rígida.
Em um perfil nativo, o sistema operacional escolhe o tamanho da interface, e o telefone não expõe nenhum editor para isso. Para um gateway Cisco de acesso remoto existe um atributo documentado para o perfil de conexão, e se ele se aplica depende do cliente, da versão e do transporte negociado. É nessa lacuna entre o documentado e o respeitado que um número copiado dá errado.
| Owner | Who can change it | Reachable from the phone |
|---|---|---|
| Packet-tunnel provider | The app vendor through its API | Only if the app exposes a setting |
| Native IKEv2 or Cisco IPsec profile | The operating system | No user control |
| Gateway group policy attribute | The gateway administrator | If the client honours it |
Pergunta três: o sintoma depende do tamanho
Problemas de tamanho têm uma assinatura: solicitações pequenas funcionam, uploads grandes ou respostas grandes travam, e o mesmo serviço funciona em outra rede de acesso. A filtragem, um limite de payload do aplicativo e um servidor travado podem produzir uma queixa semelhante, então registre a operação que falha ao lado de uma que funciona. Anote as duas com horários e tamanhos se o aplicativo os informar. Sem esse par, cada mudança posterior é um palpite.
Execute o mesmo teste em Wi-Fi e em rede móvel. Uma falha que acompanha a rede aponta para o caminho; uma que acompanha o dispositivo aponta para o cliente ou o perfil, e as duas precisam de donos diferentes. Use o mesmo serviço e a mesma conta nas duas execuções, ou a comparação não diz nada.
Por que a receita do Mac continua aparecendo
Anos de VPNs de desktop baseadas em PPP tornaram a mudança do tamanho da interface uma solução local legítima, e essas instruções foram copiadas para as discussões de celular. No telefone não há shell, não há esse nome de interface e não há persistência após uma reconexão. Uma receita que resolveu um problema de desktop em 2011 viajou muito mais longe do que as condições que a tornavam verdadeira. Clientes móveis não aceitam nenhum comando de shell para isso, diga o que disser a discussão.
Trate o valor copiado como uma hipótese sobre um caminho, não como um ajuste. Se um tamanho menor faz uma transferência funcionar e um maior falha de forma confiável, você tem evidências sobre o caminho; ainda precisa encontrar o componente que tem permissão para agir sobre ele. Essa busca geralmente termina no perfil do gateway ou no fornecedor do aplicativo, e raramente no telefone.
O transporte muda a resposta
Se a sessão roda sobre TLS em vez de IPsec, um ajuste de segmentação TCP no gateway pode ajudar, porque reescreve o tamanho de segmento anunciado para os fluxos TCP. Não faz nada pelo tráfego UDP, que cobre mais da web moderna do que as pessoas esperam. Verifique o transporte negociado antes de propor a mudança, e diga no ticket qual transporte você espera que seja afetado.
A descoberta de MTU de caminho existe para que as pontas aprendam o limite real em vez de adivinhar. Bloquear o feedback e fixar um tamanho pequeno troca uma transferência grande que funciona por um custo permanente e oculto em cada conexão.
O que perguntar à equipe do gateway
Peça três coisas: o nome exato do atributo e seu escopo, se os clientes implantados o respeitam, e qual transporte a sessão negociou. Uma mudança aplicada a uma política de grupo é testável; uma edição global não é, e ela transfere risco para usuários que nunca relataram um problema. Peça também a referência do documento, porque os nomes dos atributos mudam entre versões.
Depois mude uma coisa e teste de novo a operação original que falha, não um download de teste de velocidade. Guarde o registro de antes e depois com a versão do cliente e a rede de acesso, para que o próximo relatório possa ser comparado em vez de reaberto.
Se a operação ainda falha no tamanho original, o tamanho não era a causa. Registre também essa conclusão, para que a próxima pessoa não reabra a mesma hipótese.