MTU della VPN su iPhone: scegli il proprietario prima di cambiare un numero

Ogni discussione sulla dimensione dei pacchetti della VPN su iPhone finisce per proporre lo stesso comando Mac contro un'interfaccia chiamata ppp0, di solito con un numero allegato. Non si trasferisce, e non sarebbe il controllo giusto nemmeno sul Mac se non appartenesse a quella determinata connessione. Sul telefono il numero appartiene a chi implementa il tunnel: il sistema operativo per un profilo nativo, un fornitore di tunnel di pacchetti per un'app, o il gateway quando viene negoziato un attributo documentato. Tre domande chiariscono quale di questi casi hai davanti.

Prima domanda: quale client è in esecuzione

Un profilo IKEv2 nativo, il profilo Cisco IPsec integrato e un client Cisco di terze parti sono tre implementazioni diverse con tre diversi insiemi di attributi supportati. Il tipo di profilo in Impostazioni ti dice quale ha avviato davvero il telefono, e l'elenco delle app ti dice se c'è un fornitore sul percorso. Parti da lì, perché il resto della decisione ne deriva. Se nell'elenco delle app non compare alcun fornitore, il tunnel appartiene al sistema operativo.

Non dedurre l'implementazione dal fornitore del gateway. Un headend Cisco può terminare connessioni di client che non condividono altro che il nome del fornitore. Uno screenshot di una build vecchia su una release vecchia ti dice cosa supportava quella coppia, non cosa fa il telefono che hai in mano.

Seconda domanda: a chi appartiene il valore

Apple espone una proprietà MTU agli sviluppatori di tunnel di pacchetti tramite l'oggetto delle impostazioni dell'estensione di rete. È un'API per il fornitore che configura il proprio tunnel, non un interruttore che un utente o un amministratore possa azionare sul client installato di qualcun altro. Un'app di terze parti può scegliere di esporla, ignorarla o codificare un valore in modo fisso.

Per un profilo nativo il sistema operativo sceglie la dimensione dell'interfaccia, e il telefono non espone alcun editor per farlo. Per un gateway Cisco ad accesso remoto esiste un attributo documentato per il profilo di connessione, e se si applichi dipende dal client, dalla release e dal trasporto negoziato. È proprio in quel divario tra documentato e rispettato che un numero copiato va storto.

Terza domanda: il sintomo dipende davvero dalla dimensione

I problemi di dimensione hanno una firma: le richieste piccole riescono, i caricamenti grandi o le risposte grandi si bloccano, e lo stesso servizio funziona su un'altra rete di accesso. Il filtraggio, un limite di payload dell'app e un server bloccato possono produrre una lamentela simile, quindi registra l'operazione che fallisce accanto a una che funziona. Annota entrambe con orari e dimensioni se l'app li riporta. Senza quella coppia, ogni modifica successiva è una congettura.

Esegui lo stesso test in Wi-Fi e in rete mobile. Un guasto che segue la rete punta al percorso; uno che segue il dispositivo punta al client o al profilo, e i due richiedono proprietari diversi. Usa lo stesso servizio e lo stesso account per entrambe le esecuzioni, altrimenti il confronto non ti dice nulla.

Perché la ricetta Mac continua a comparire

Anni di VPN desktop basate su PPP hanno reso la modifica della dimensione dell'interfaccia una soluzione locale legittima, e quelle istruzioni sono state copiate nei thread mobili. Sul telefono non c'è shell, non c'è un nome di interfaccia del genere e non c'è persistenza dopo una riconnessione. Una ricetta che ha risolto un problema desktop nel 2011 ha viaggiato molto più lontano delle condizioni che la rendevano vera. I client mobili non accettano alcun comando shell per questo, qualunque cosa sostenga il thread.

Tratta il valore copiato come un'ipotesi su un percorso, non come un'impostazione. Se una dimensione più piccola fa funzionare un trasferimento e una più grande fallisce in modo affidabile, hai prove sul percorso; devi ancora trovare il componente a cui è permesso agire su di esso. Quella ricerca di solito finisce al profilo del gateway o al fornitore dell'app, e raramente sul telefono.

Il trasporto cambia la risposta

Se la sessione passa su TLS invece che su IPsec, una regolazione della segmentazione TCP sul gateway può aiutare, perché riscrive la dimensione del segmento annunciata per i flussi TCP. Non fa nulla per il traffico UDP, che copre più parte del web moderno di quanto la gente si aspetti. Controlla il trasporto negoziato prima di proporre la modifica, e indica nel ticket quale trasporto ti aspetti che venga influenzato.

La scoperta dell'MTU di percorso esiste perché gli estremi imparino il limite reale invece di indovinarlo. Bloccare il feedback e codificare una dimensione piccola scambia un trasferimento grande funzionante con un costo permanente e nascosto su ogni connessione.

Cosa chiedere al team del gateway

Chiedi tre cose: il nome esatto dell'attributo e la sua portata, se i client distribuiti lo rispettano, e quale trasporto ha negoziato la sessione. Una modifica applicata a una politica di gruppo è verificabile; una modifica globale non lo è, e sposta il rischio su utenti che non hanno mai segnalato un problema. Chiedi anche il riferimento al documento, perché i nomi degli attributi cambiano tra le release.

Poi cambia una cosa e ritesta l'operazione originale che fallisce, non un download di speed test. Conserva il registro prima e dopo con la versione del client e la rete di accesso, così il report successivo può essere confrontato invece di essere riaperto.

Se l'operazione fallisce ancora alla dimensione originale, la dimensione non era la causa. Registra anche questa conclusione, così la persona successiva non riapre la stessa ipotesi.