Perché IKEv2 su Android fallisce su una porta UDP non standard

Il gateway risponde a IKEv2 sulla UDP 4443 per un motivo, il profilo ha un campo chiamato Server, digitate il nome host e la porta, e il telefono segnala che non riesce a raggiungere il server o non riesce a risolvere l’indirizzo. Nulla viene bloccato. Il modulo nativo di Android si aspetta un host, e lo stesso vale su Windows. Una porta personalizzata è una capacità del client prima di essere un’impostazione del server, e solo alcuni client vi lasciano esprimerla. Percorrete le tre parti in ordine: cosa può dire il client, su cosa ascolta il server e se entrambe le estremità incapsulano i pacchetti allo stesso modo.

Cosa ha effettivamente inviato il telefono

Una stringa host:port in un campo pensato per un nome viene risolta come un nome. Il resolver non restituisce nulla per vpn.example.net:4443, e l’errore che vedete è un fallimento di risoluzione del nome o di raggiungibilità, non un timeout su una porta. La distinzione conta, perché riprovare con un nome più corto o un’altra rete non riparerà mai una stringa che il modulo non sa analizzare.

Il profilo IKEv2 nativo su Android, come il client VPN integrato di Windows, è fissato alle porte IKE standard. Nessuno dei due espone un campo porta, e nessuna modifica del profilo ne aggiunge uno. Se l’ascolto dell’operatore è davvero sulla 4443, il client integrato è lo strumento sbagliato, non uno configurato male.

Usate un client che espone la porta

Il client strongSwan per Android documenta una porta server configurabile nelle impostazioni avanzate del profilo, per questo compare in quasi ogni ricetta che funziona per questo progetto. Quel supporto appartiene a quel client: un’altra applicazione IKEv2, o un fork del fornitore della stessa applicazione, può non esporre lo stesso campo anche se il demone strongSwan sottostante lo supporta.

Chiedete all’operatore l’insieme completo in una volta: nome del gateway, porta UDP, metodo di autenticazione e l’identità del server che il client deve attendersi. Una porta personalizzata non è un motivo per disattivare il controllo dei certificati o cambiare protocollo. Inserite la porta dove il client installato la aspetta, e se quel client non ha un campo simile, la risposta è un altro client approvato e non una soluzione improvvisata.

Il server ha due porte, ed entrambe devono coincidere

IKE parte sulla UDP 500, e il transito NAT di solito sposta IKE e l’ESP incapsulato sulla UDP 4500. Sono impostazioni separate in strongSwan, quindi un server spostato su un’unica porta personalizzata deve cambiarle entrambe allo stesso valore:

plugins {
  socket-default {
    port = 4443
    port_nat_t = 4443
  }
}

Con una sola porta per entrambi i ruoli, il demone deve distinguere IKE da ESP-in-UDP sullo stesso socket, cosa che fa tramite il marcatore di quattro byte che non è ESP e che precede un messaggio IKE. Per questo un client non può negoziare sulla porta personalizzata e poi continuare in silenzio sulla 4500, e per questo la frase «basta cambiare la porta» nasconde un requisito di incapsulamento.

Un inoltro non è un ascolto

Inoltrare la 4443 a un normale ascolto IKE è il modo di fallire che sembra quasi riuscito. Il primo scambio arriva, il server risponde, e poi la connessione si blocca o rinnova le chiavi nel nulla, perché la risposta esce da un’altra porta e il traffico incapsulato successivo non corrisponde mai allo stato creato dalle due estremità. Una regola che riscrive la porta di destinazione senza spostare l’ascolto produce esattamente questo risultato a metà aperto.

Il percorso deve consentire anche UDP da estremo a estremo. Che il TCP 443 passi attraverso una rete alberghiera o di operatore non dice nulla su IKEv2 su una porta UDP, nemmeno con lo stesso numero. Dove è consentito solo il TCP 443, una porta UDP personalizzata non trasforma IKEv2 in HTTPS, e la risposta giusta può essere un altro percorso di accesso invece di un altro esperimento sulla porta.

Separate le tre fasi durante i test

Catturate sul server mentre il client prova una volta. Una richiesta che non arriva mai è una questione di estremità o di firewall; una richiesta che arriva senza risposta è una questione di ascolto o di criterio; una risposta seguita dal silenzio è la questione dell’incapsulamento o dell’identità.

tcpdump -ni eth0 -vv udp port 4443

Poi leggete il messaggio del client invece del suo indicatore rotante. Un errore di proposta significa che gli algoritmi non concordano, un fallimento di autenticazione significa che identità o certificati non concordano, e ritrasmissioni ripetute senza risposta significano che nulla risponde su quella porta. Provate una fase alla volta e cambiate un solo campo tra un tentativo e l’altro; la documentazione strongSwan sul transito NAT descrive il marcatore e il comportamento della porta che la cattura vi sta mostrando.