MTU da VPN no iPhone: escolle o propietario antes de cambiar un número
Tres preguntas deciden se a aplicación, o perfil da pasarela ou ninguén no teléfono pode cambiar o tamaño. Responde a elas antes de coller prestado un número dun Mac.
Cada fío sobre o tamaño dos paquetes da VPN no iPhone acaba ofrecendo o mesmo comando de Mac contra unha interface chamada ppp0, normalmente cun número engadido. Non se traslada, e non sería o control correcto nin sequera no Mac a non ser que esa interface pertencese á conexión en cuestión. No teléfono, o número posúeo quen implementa o túnel: o sistema operativo para un perfil nativo, un provedor de túnel de paquetes para unha aplicación, ou a pasarela cando se negocia un atributo documentado. Tres preguntas aclaran con cal deses casos tratas.
Pregunta unha: que cliente está a executarse
Un perfil IKEv2 nativo, o perfil Cisco IPsec integrado e un cliente Cisco de terceiros son tres implementacións distintas con tres conxuntos distintos de atributos compatibles. O tipo de perfil en Axustes diche cal iniciou realmente o teléfono, e a lista de aplicacións diche se hai algún provedor na ruta. Comeza por aí, porque o resto da decisión derívase diso. Se non aparece ningún provedor na lista de aplicacións, o sistema operativo posúe o túnel.
Non deduzas a implementación do fabricante da pasarela. Unha cabeceira Cisco pode rematar conexións de clientes que non comparten nada máis que o nome do fabricante. Unha captura dunha compilación antiga nunha versión antiga diche que soportaba ese par, non que fai o teléfono que tes na man.
Pregunta dúas: quen posúe o valor
Apple expón unha propiedade MTU aos desenvolvedores de túneles de paquetes mediante o obxecto de axustes da extensión de rede. É unha API para o provedor que configura o seu propio túnel, non un interruptor que un usuario ou un administrador poida accionar no cliente instalado doutra persoa. Unha aplicación de terceiros pode optar por expoñela, ignoralo ou fixar un valor de forma ríxida.
Para un perfil nativo, o sistema operativo escolle o tamaño da interface, e o teléfono non expón ningún editor para iso. Para unha pasarela Cisco de acceso remoto existe un atributo documentado para o perfil de conexión, e se se aplica depende do cliente, da versión e do transporte negociado. Ese oco entre o documentado e o respectado é onde falla un número copiado.
| 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 |
Pregunta tres: depende o síntoma do tamaño, sequera
Os problemas de tamaño teñen unha sinatura: as solicitudes pequenas teñen éxito, as cargas grandes ou as respostas grandes colgan, e o mesmo servizo funciona por outra rede de acceso. O filtrado, un límite de carga útil da aplicación e un servidor atascado poden producir unha queixa semellante, así que rexistra a operación que falla xunto a unha que funcione. Anota ambas con horas e tamaños se a aplicación os informa. Sen ese par, cada cambio posterior é unha conxectura.
Executa a mesma proba en Wi-Fi e en datos móbiles. Un fallo que segue a rede apunta á ruta; un que segue o dispositivo apunta ao cliente ou ao perfil, e ambos necesitan propietarios distintos. Usa o mesmo servizo e a mesma conta para as dúas execucións, ou a comparación non che dirá nada.
Por que a receita de Mac non deixa de aparecer
Anos de VPN de escritorio baseadas en PPP converteron un cambio de tamaño de interface nunha solución local lexítima, e esas instrucións copiáronse cara aos fíos de móbil. No teléfono non hai shell, nin ese nome de interface, nin persistencia tras unha reconexión. Unha receita que resolveu un problema de escritorio en 2011 viaxou moito máis lonxe que as condicións que a facían certa. Os clientes móbiles non aceptan ningún comando de shell para isto, diga o que diga o fío.
Trata o valor copiado como unha hipótese sobre unha ruta, non como un axuste. Se un tamaño menor fai que unha transferencia funcione e un maior falla de forma fiable, tes probas sobre a ruta; aínda debes atopar o compoñente ao que se lle permite actuar sobre ela. Esa busca adoita rematar no perfil da pasarela ou no provedor da aplicación, e raramente no teléfono.
O transporte cambia a resposta
Se a sesión vai sobre TLS en lugar de IPsec, un axuste de segmentación TCP na pasarela pode axudar, porque reescribe o tamaño de segmento anunciado para os fluxos TCP. Non fai nada polo tráfico UDP, que abrangue máis parte da web moderna do que a xente espera. Comproba o transporte negociado antes de propoñer o cambio, e indica no tícket a que transporte esperas que afecte.
O descubrimento de MTU de ruta existe para que os extremos aprendan o límite real en lugar de adiviñalo. Bloquear a retroalimentación e fixar un tamaño pequeno cambia unha transferencia grande que funciona por un custo permanente e oculto en cada conexión.
Que preguntar ao equipo da pasarela
Pide tres cousas: o nome exacto do atributo e o seu alcance, se os clientes despregados o respectan, e que transporte negociou a sesión. Un cambio aplicado a unha política de grupo é comprobable; unha edición global non o é, e traslada o risco a usuarios que nunca informaron dun problema. Pide tamén a referencia do documento, porque os nomes dos atributos cambian entre versións.
Despois cambia unha cousa e volve probar a operación orixinal que falla, non unha descarga de proba de velocidade. Garda o rexistro de antes e despois coa versión do cliente e a rede de acceso, para que o seguinte informe se poida comparar en lugar de volver discutirse.
Se a operación segue fallando co tamaño orixinal, o tamaño non era a causa. Rexistra tamén esa conclusión, para que a seguinte persoa non reabra a mesma hipótese.