iPhone Always On VPN: due tunnel possono condividere un IP virtuale

Su un iPhone supervisionato con un profilo Always On gestito, il telefono mantiene un tunnel per ogni interfaccia IP attiva, così la rete cellulare e il Wi-Fi hanno ciascuno il proprio. Il server elenca quindi due associazioni di sicurezza IKE per un solo dispositivo, spesso condividendo un indirizzo virtuale, e il primo istinto è chiamarlo ciclo di rekey e iniziare a cambiare i timer. Quell’istinto di solito è sbagliato. Seguite i passaggi qui sotto nell’ordine in cui le prove compaiono sul server, e lasciate stare le impostazioni del telefono finché il server non vi dice quale caso avete.

Iniziate dalle due righe che il server ha già

Elencate le associazioni con swanctl --list-sas e leggete quattro campi in entrambe le voci: l’indirizzo remoto, l’identità autenticata, l’IP virtuale assegnato e l’ora di creazione. Due indirizzi esterni diversi con una identità e un IP virtuale è la forma che ha avviato questa domanda, e vale la pena annotarla prima di qualsiasi modifica. Poi controllate le associazioni figlie collegate a ciascuna, perché i selettori di traffico decidono se una ricerca di destinazione potrebbe mai distinguere i due tunnel. Una coppia che appare e scompare in pochi secondi è un animale diverso da una coppia in cui entrambi vivono per ore.

Ordinate l’elenco per ora di creazione prima di trarre una conclusione. L’adiacenza nell’output non significa nulla, e un elenco tabellare invita esattamente a quell’errore.

Decidete quale sovrapposizione state guardando

Il rekey IKEv2 e la riautenticazione make-before-break creano di proposito una breve sovrapposizione, stabilendo la nuova associazione prima di eliminare la vecchia. I timestamp risolvono il caso, perché una vecchia SA che scompare uno o due secondi dopo la comparsa della nuova è rinnovo che fa il suo lavoro. I tunnel indipendenti per interfaccia non hanno mai questo aspetto, dato che ciascuno persiste finché la sua interfaccia è attiva e cancellarne uno non deriva dal crearne un altro.

Il comportamento Always On gestito di Apple è per interfaccia, per questo un dispositivo supervisionato può legittimamente sembrare più occupato di un profilo configurato a mano. L’interruttore di connessione automatica di un’app del fornitore non implica la stessa cosa, e nemmeno una regola on-demand ordinaria. La panoramica di distribuzione di Apple descrive il modello per interfaccia; confrontate le vostre due righe con essa prima di supporre un ciclo. Entrambe le forme attingono anche allo stesso pool lato server, quindi la sovrapposizione è il vostro unico segnale precoce.

Vedete perché un indirizzo virtuale per due tunnel rompe le risposte

Una risposta al telefono è indirizzata all’indirizzo interno, e il kernel sceglie un tunnel in uscita per destinazione e criterio, non per l’interfaccia usata dal telefono. Due associazioni simultanee che tengono lo stesso IP virtuale con criteri coincidenti lasciano la decisione di instradamento senza modo di dire a quale sessione appartiene una risposta. Alcune risposte prendono il tunnel sbagliato, e il telefono mostra una connessione che funziona in un senso o muore quando il Wi-Fi sale. Due output di comando provano lo stato: swanctl --list-sas mostra lo stesso IP virtuale su entrambe le SA, e ip xfrm policy mostra due selettori identici.

È proprio quella coppia di output che incollate nel registro delle modifiche. Nessuno dei due da solo è convincente, perché ciascuno può sembrare plausibile separatamente.

Si tratta di indirizzamento e criteri lato server, non di cattivo comportamento del telefono, e nessuna impostazione del client separa due indirizzi interni identici. Il pool ha assegnato due volte lo stesso valore e l’installatore di criteri l’ha accettato. Leggete il risultato dal lato del server prima di dare la colpa al client.

Cambiate il pool o il modello di concorrenza, non il timer di rekey

Nella configurazione swanctl, l’unicità è un criterio esplicito sulla connessione: unique = replace rimuove una connessione più vecchia quando se ne stabilisce una nuova, e unique = keep rifiuta la nuova arrivata. Entrambi i valori agiscono quando si imposta una connessione, non sulle SA figlie al suo interno.

connections {
  ios-alwayson {
    unique = replace
  }
}

Nessuno dei due valori è neutro per un client per interfaccia. keep ripristina una schermata di stato ordinata rifiutando il secondo tunnel e rompe il progetto gestito, mentre replace abbatte il tunnel più vecchio ed è lo stesso compromesso nella direzione opposta. Se entrambi i tunnel servono davvero, il backend del pool deve rilasciare lease distinti per una identità, e la sua chiave di lease deve distinguere le richieste. Una tabella statica identità-indirizzo restituirà volentieri due volte lo stesso indirizzo e riprodurrà il problema originale con più configurazione. Controllate come il backend genera le chiavi di lease prima di aggiungere una seconda mappatura statica.

Provate le transizioni che distribuite davvero

Uscite dalla portata del Wi-Fi con una sessione attiva, poi rientrate, e verificate che le risposte arrivino in entrambe le direzioni. Fatelo due volte, perché la seconda transizione è dove di solito compare un criterio obsoleto. Provate con un servizio che risponde sulla connessione che avete aperto, e ripetete l’uscita mentre il tunnel porta traffico invece di restare inattivo. Un telefono che può inviare ma non ricevere sembra sano in un log di handshake e rotto in un browser.

Una schermata di stato ridotta a una riga non è prova di un progetto funzionante, solo prova che un tunnel se n’è andato. Entrambe le direzioni devono funzionare prima che una transizione passi. Annotate ciò che avete osservato, insieme ai due output del controllo di sovrapposizione, così il prossimo ingegnere può confrontare invece di ripetere la passeggiata.