GVC bloccato su Acquiring IP: non è un problema di password

Global VPN Client resta fermo su Acquiring IP, e il riflesso è ridigitare la password o reinstallare il client. Nessuna delle due cose tocca la fase che ha fallito. L’autenticazione si è conclusa prima che il client chiedesse un indirizzo, quindi non sono le credenziali a trattenerti su quella riga. Ciò che ti trattiene lì è uno scambio DHCP non concluso, e può bloccarsi in tre punti diversi.

Autenticazione e assegnazione dell’indirizzo sono fasi separate

GVC prima dimostra chi sei, poi richiede le impostazioni per il suo adattatore virtuale secondo la policy assegnata alla tua connessione. Sono passaggi sequenziali con firme di errore diverse. Credenziali errate di solito falliscono prima, con un messaggio di autenticazione o di negoziazione invece che alla riga dell’indirizzo.

Quest’ordine spiega perché reimpostare la password, creare un nuovo utente locale o reinstallare non cambi nulla qui. Il client è già autorizzato; ora attende un lease che il gateway o il suo partner DHCP deve fornire. Persino una policy che consente l’utente ma non assegna alcun intervallo di indirizzi produce esattamente questa schermata.

Quindi la prima domanda utile non è se le credenziali siano corrette, ma quale policy sia stata assegnata e che cosa dica sull’indirizzamento dell’adattatore virtuale. Leggi la configurazione effettiva di quella connessione invece dello screenshot funzionante di un collega.

Da dove arriva davvero il lease

Due modelli sono comuni. Il firewall può gestire da sé un ambito DHCP per i client VPN, oppure inoltrare la richiesta a un server DHCP esterno sulla rete interna. Il modello determina quali log contano e chi chiamare.

Nel modello interno, verifica che l’ambito esista ancora, appartenga all’interfaccia giusta e abbia lease liberi. Un ambito esaurito produce un client che si autentica perfettamente e non riceve mai un indirizzo, e il log del gateway potrebbe mostrare solo la richiesta. Nel modello a inoltro, la destinazione dell’inoltro, la rotta di ritorno all’intervallo dei client VPN e qualsiasi autorizzazione DHCP interna devono allinearsi.

Annota quale modello usa la tua distribuzione prima di testare qualsiasi cosa. Metà dei consigli contraddittori online presuppone l’altro.

Un tunnel può essere attivo e comunque perdere il lease

Una connessione di controllo stabilita dimostra che la negoziazione ha funzionato, non che i dati incapsulati passino in entrambe le direzioni. Lo scambio DHCP ha bisogno di richiesta e risposta per sopravvivere al percorso dati, ed è lì che vivono impostazioni di crittografia, policy per la zona VPN e problemi di MTU.

Il consiglio sul NAT traversal è l’esempio più chiaro del fatto che il contesto conta. Alcuni percorsi lo richiedono attivo, altri funzionano solo disattivato, e il NAT intermedio insieme alla connessione negoziata decidono quale. Cambiarlo alla cieca mentre cambi anche le impostazioni del client significa che non saprai quale modifica ha prodotto il risultato. Annota il percorso negoziato e le prove prima di modificare l’incapsulamento.

Riavviare il router di casa appartiene alla stessa categoria. A volte elimina il sintomo, ma non identifica perché il lease è fallito, e il problema torna alla connessione successiva.

Percorri il percorso del lease in ordine

Parti dall’adattatore e procedi verso l’esterno, così ogni passo può fallire solo per un motivo:

> Get-NetAdapter | Where-Object Name -like "*GVC*"
> ipconfig /all | findstr /i /c:"GVC" /c:"IPv4" /c:"DHCP"
> Test-NetConnection 10.60.0.1 -Port 443

Un indirizzo come 169.254.x.x significa che l’adattatore esiste e non ha ricevuto alcuna risposta, il che punta all’origine del lease o al percorso dati. Un indirizzo corretto nell’intervallo VPN con voci DNS sbagliate è un altro guasto: il lease ha funzionato e la policy ha fornito impostazioni incomplete. Un adattatore che non compare mai significa che il client non è arrivato a crearlo.

Quando compare un lease, prova la risorsa reale invece di dichiarare vittoria alla riga dell’indirizzo. Se l’accesso ai file o all’intranet fallisce ancora, conserva il lease riuscito come prova e passa alla risoluzione dei nomi o alla policy, perché hai lasciato alle spalle il guasto originale.

La nota di SonicWall sull’adattatore virtuale elenca diversi rami separati, e le sue vecchie schermate non vanno lette come la mappa attuale del menu. Usala per confermare la fase raggiunta, non come lista di controllo da applicare in blocco.