IKEv2 su iPhone: cosa inserire nei campi «Server», «ID remoto» e «ID locale»

Risposta breve: nel campo «Server» di solito si inserisce il nome di dominio o l’IP del vostro server VPN; in «ID remoto» va inserito l’identificatore che deve corrispondere a quello atteso dal server (spesso il nome di dominio indicato nel certificato del server); in «ID locale» si inserisce l’identificatore del client che il server usa per associare le regole (spesso si lascia vuoto o si inserisce nome utente/ID fornito dal provider). I valori precisi vanno sempre richiesti al vostro provider o amministratore: inserire dati a caso è una causa comune di errori nella verifica del certificato o rifiuti di connessione.

Cosa significano i campi IKEv2 su iOS e a cosa servono

In IKEv2 (IPsec) le parti scambiano parametri e confermano le identità. Su iPhone vedete tre campi che spesso generano dubbi:

• Server — indirizzo a cui connettersi (indirizzo del gateway VPN).
• ID remoto (Remote ID) — «come verifico il server»; è una stringa con cui iOS associa il server alla sua identità (di norma corrisponde ai dati presenti nel certificato del server).
• ID locale (Local ID) — «come il server mi riconosce»; identificatore del client che il server può controllare o usare nelle regole.

Questi valori partecipano all’autenticazione. Se non sono concordati con le impostazioni del server e il certificato, iOS può non fidarsi del server o il server può rifiutare il client. Per approfondire la logica degli identificatori e dell’autenticazione vi consigliamo la documentazione Apple su IKEv2/IPsec: Apple: impostazioni di gestione dispositivi IKEv2.

Campo «Server»: dominio o IP e come capire cosa inserire

Cosa si inserisce più spesso

• Nome di dominio completo (FQDN) del tipo vpn.example.com — opzione comune, comoda in caso di cambio IP e per il corretto funzionamento dei certificati.
• Indirizzo IP — a volte usato per test rapidi o quando non c’è un dominio, ma nella verifica del certificato conta sempre l’«ID remoto».

Diagnosi prima di agire

• Chiedete al provider se la connessione prevede un nome di dominio o un IP. Se il provider fornisce dominio e certificato, di solito conviene usare il dominio.
• Se usate un IP, verificate che non cambi (ad esempio, in caso di indirizzo dinamico domestico). Cambi frequenti d’IP possono causare connessioni intermittenti.

Azioni sicure (reversibili)

• Se non siete sicuri, iniziate dal valore indicato nelle istruzioni del provider. In caso di errori, non disattivate la verifica del certificato né passate a opzioni “non verificate”: meglio chiedere l’indirizzo corretto.
• Se il provider ha fornito sia dominio che IP: provate a inserire il dominio in «Server» e usate l’IP solo per test temporanei, poi tornate al dominio.

«ID remoto»: chiave per la verifica del certificato e varianti comuni

«ID remoto» è una delle cause più frequenti di errori, perché iOS lo confronta con ciò che il server «dichiara» in fase di autenticazione. Con il certificato, questo di solito si lega al nome indicato nel certificato del server.

Valori comuni per «ID remoto»

• Nome di dominio VPN (ad esempio vpn.example.com) — variante più diffusa e comprensibile.
• Stringa identificativa (ad esempio ikev2.example.com o gateway-id) — presente quando il provider vuole differenziare «indirizzo di connessione» da «nome nell’identità».
• Indirizzo IP — talvolta accettato, ma può causare problemi se il certificato è emesso per dominio e non per IP.

Diagnosi: come capire cosa viene richiesto

• Controllate le istruzioni del provider IKEv2: a volte «Remote ID» è indicato separatamente rispetto a «Server».
• Se avete un profilo di configurazione (.mobileconfig) o configurazione testuale, lì l’«ID remoto» di solito è specificato chiaramente. Se inserite manualmente, attenetevi a quei valori.
• Se la connessione fallisce con errori di fiducia o certificato, una causa probabile è la non corrispondenza tra «ID remoto» e nome nel certificato.

Azioni sicure (reversibili)

• Se avete usato un IP in «ID remoto», provate a sostituirlo con il nome di dominio fornito dal provider (e in caso tornate indietro).
• Se in «Server» avete un IP e il provider ha fornito un dominio per l’identificazione: lasciate l’IP nel «Server» e inserite il dominio in «ID remoto» così da far corrispondere la verifica del certificato.
• Se il provider ha dato un «Remote ID» separato (una stringa diversa dal dominio), usate quello esattamente, anche se sembra insolito.

«ID locale»: quando lasciarlo vuoto e quando inserirlo esplicitamente

«ID locale» definisce con quale identificatore vi presentate come client. In alcune configurazioni non serve, in altre è fondamentale (per esempio quando il server distingue utenti o profili anche in base a questo ID e non solo a username).

Varianti comuni di «ID locale»

• Vuoto — scelta frequente se al server basta username/password (EAP) o certificato client.
• Nome utente — a volte viene richiesto di inserire in «ID locale» lo stesso login usato per EAP.
• Identificatore specifico (stringa) — se il provider fornisce un «Local ID» specifico, ad esempio client123 o user@realm.

Diagnosi prima di cambiamenti

• Se il server rifiuta la connessione (non errore di certificato) e il provider menziona il Local ID nei parametri, verificate di non aver lasciato vuoto il campo.
• Se avete più profili o utenti e uno funziona mentre un altro no, confrontate se «ID locale» è compilato.

Azioni sicure (reversibili)

• Se il provider non ha fornito un Local ID, iniziate con il campo vuoto. È più facile tornare indietro e non provoca problemi di incompatibilità.
• Se il provider ha dato un Local ID preciso, inseritelo esattamente (maiuscole e simboli contano). Se non funziona, riportate il campo allo stato iniziale e chiedete al provider il formato corretto.

Tipo di autenticazione IKEv2 su iPhone e perché è legato agli ID

Su iOS per IKEv2 si trovano di solito due metodi di autenticazione:

• Nome utente e password (EAP) — inserite le credenziali, il server verifica la vostra identità. Il server quasi sempre usa un certificato per permettere al client (iPhone) di verificare di connettersi al server «giusto». In questo caso è molto importante compilare correttamente l’«ID remoto».
• Con certificato — anche il client possiede un certificato (di solito fornito dall’amministratore o provider). L’«ID locale» può essere importante per selezionare certificato o politica, ma il comportamento dipende dalla configurazione del server.

Diagnosi: riconoscere il metodo

• Se il provider ha dato solo login/password, molto probabilmente si usa EAP.
• Il file .mobileconfig o il certificato da soli non determinano il metodo: può esserci EAP nel profilo e il certificato usato solo per autenticare il server. Verificate il metodo indicato dal provider.

Azioni sicure (reversibili)

• Non cercate di cambiare tipo di autenticazione a caso se il provider ha fornito parametri per un metodo specifico: spesso significa che il server rifiuterà la connessione.
• Se sospettate un errore di metodo (ad esempio avete un certificato ma tentate di connettervi con login/password), chiedete prima al provider quale metodo è previsto e poi tornate alla configurazione corretta.

Verifica della corrispondenza tra nome certificato e «ID remoto»: checklist

Regola pratica: quando l’iPhone verifica il server tramite certificato, l’«ID remoto» deve corrispondere al nome che il server mostra nel certificato (spesso un nome di dominio). Se non combaciano, la connessione potrebbe non stabilirsi.

Checklist diagnostica (senza rivelare dati sensibili)

Se desiderate una guida passo-passo per aggiungere un profilo IKEv2 su iOS (esattamente «dove cliccare»), vi consigliamo questa istruzione separata: configurazione IKEv2 VPN su iOS. Qui spieghiamo solo il senso dei campi e come verificarne la corrispondenza.

Mini promemoria per gestire i parametri in sicurezza

• Non pubblicate valori di «Server», «ID remoto/locale», login, password, chiavi e contenuti certificati in chat o screenshot. Se dovete mostrare un problema, oscurate i dati sensibili.
• Modificate un parametro alla volta, così saprete cosa ha influito e potrete tornare indietro facilmente.
• Non disattivate la verifica del certificato né accettate «qualunque certificato» per collegamenti rapidi: questo peggiora la protezione da falsificazioni del server.

FAQ: domande frequenti su «Server», «ID remoto» e «ID locale»

Posso fare in modo che «Server» e «ID remoto» siano diversi?

Sì, è uno scenario normale: «Server» è dove vi connettete, «ID remoto» è come verificate l’autenticità del server. Per esempio, potete connettervi via IP ma verificare tramite il nome di dominio nel certificato (se fornito dal provider).

Se ho solo un IP, cosa metto in «ID remoto»?

Dipende per chi è emesso il certificato del server e come è configurata la VPN. Spesso il provider fornisce comunque un dominio o un identificatore separato per «ID remoto». Se non avete queste informazioni, meglio chiederle al provider invece di improvvisare.

Devo compilare «ID locale» se entro con login e password?

Spesso no, si lascia vuoto. Ma alcune configurazioni richiedono un «ID locale» esplicito (per associare le politiche). Se il provider l’ha indicato, usatelo; se no, cominciate con il campo vuoto.

Perché dopo aver cambiato dominio la VPN non si connette più?

Le cause possono essere due: è cambiato l’indirizzo «Server» (DNS o routing) oppure non corrisponde più il nome nel certificato con «ID remoto». La soluzione sicura è tornare ai valori precedenti (rollback), poi chiedere al provider il nuovo dominio/Remote ID e verificare che il certificato sia aggiornato al nuovo nome.

Posso usare lo stesso «ID remoto» per server diversi?

Sì, se l’amministratore ha configurato più gateway con un’unica identità di server approvata e certificati validi per quell’ID remoto. In altri casi gli ID differiscono. Usate quello indicato per il server scelto dal provider.

Quando può essere utile un server personale: se vi serve un gateway VPN stabile con IP dedicato, senza “vicini” e con parametri IKEv2 chiari (inclusi valori corretti di «Server/ID»), è più comodo se il provider fornisce dati personali e gestite un profilo specifico.

Quando invece non risolve il problema: se l’errore è dovuto a valori sbagliati che non avete ricevuto (es. Remote ID o certificato) o a limitazioni di rete o dispositivo, il server personale da solo non sostituisce una corretta configurazione e verifica del certificato: serve comunque usare i dati forniti dal provider e non indebolire i controlli.

Se il vostro scenario è «un utente – un server», vpn.how offre un server VPN personale con IP dedicato; localizzazioni, protocolli, prezzi e restrizioni aggiornate sono disponibili sul sito e nell’area clienti.