Il secondo client VPN ha rotto il primo: trovate la risorsa condivisa
Due stack VPN competono per un servizio, una porta fissa, un driver di filtro o la rotta predefinita. Nominate la risorsa esclusiva prima di disinstallare uno dei due client.
Ieri il client originale funzionava. Oggi il nuovo arrivato rivendica una connessione mentre il profilo più vecchio si ferma a una fase che prima superava senza lamentarsi. Le credenziali raramente c'entrano, e il gateway di solito è innocente. Quello che è cambiato è che due stack VPN ora vogliono la stessa risorsa esclusiva, e la riparazione dipende dal nominarla. Percorrete i livelli invece di reinstallare entrambi.
Percorrete i quattro livelli in ordine
Un prodotto VPN ha bisogno di quattro risorse che possono scontrarsi: un servizio in background che spesso rifiuta di girare due volte, una porta fissa, una scheda virtuale o un filtro kernel che vede il traffico prima della tabella di routing, e il diritto di installare rotte davanti a quella predefinita. Sapere quale ha ceduto trasforma un conflitto vago in un'unica domanda con una risposta verificabile.
Mappate il sintomo su un livello prima di toccare qualsiasi cosa. Un client che non si avvia punta al servizio; uno che si avvia e non negozia mai punta alla porta; uno che si connette mentre l'altro perde tutta la connettività punta al filtro o alla rotta predefinita. Annotate questa mappatura, perché risparmia un'ora di reinstallazione di applicazioni nella speranza.
Iniziate dal servizio che non gira due volte
Su Windows un client aziendale è di solito più di un tunnel, perché installa un servizio, un driver di filtro e talvolta un provider di credenziali accanto al profilo. Annotate quali servizi girano prima della modifica e di nuovo dopo, poi confrontate i due elenchi invece di riavviare finché qualcosa funziona. I servizi possono anche escludersi a vicenda tramite dipendenze, dove avviarne uno ferma l'altro, e lo stesso schema appare su macOS con attività launchd e un demone condiviso. Un client che si avvia ed esce in pochi secondi segnala una proprietà, non una configurazione.
Leggete lo stato del servizio e il suo registro prima di leggere il profilo. Un servizio che si è avviato e fermato nello stesso minuto è lo schema da cercare, e il suo registro eventi nomina la dipendenza che lo ha spostato. Un profilo non può riparare un processo che non gira, e il tempo speso a modificarlo è tempo non speso sul conflitto reale.
Poi chiedete chi possiede la porta
La proprietà della porta è la prova più chiara che otterrete, perché un errore di binding nomina il conflitto direttamente. Due implementazioni IKE non possono rispondere entrambe sullo stesso indirizzo locale e sulla stessa porta UDP, e nessuna quantità di tentativi lo cambia.
Get-NetUDPEndpoint -LocalPort 500,4500 | Select-Object LocalAddress,LocalPort,OwningProcess
netstat -ano | findstr :500
sudo lsof -nP -iUDP:500
ss -lunp | grep -E ':500|:4500'
Qualunque riga corrisponda alla vostra piattaforma, la risposta che volete è un processo e il servizio che lo ha generato. Se l'ascoltatore è il servizio IKE integrato, il secondo client è l'intruso; se è un agente del fornitore, lo è il client integrato. Decidete quale può avviarsi all'accesso e disattivate l'avvio automatico dell'altro invece di ucciderlo a ogni sessione.
Il driver di filtro sta sotto le vostre rotte
Un driver di filtro di rete intercetta il traffico tra la scheda e lo stack di protocolli, quindi può riscrivere o bloccare i pacchetti qualunque cosa dica la tabella di routing. È così che una rotta che sembra corretta viene ignorata, e perché un ping riuscito può convivere con un browser che non carica nulla.
Anche i componenti del fornitore si legano a connessioni specifiche. Un filtro legacy legato a una scheda può impedire a un profilo altrimenti corretto di completare la stretta di mano, e sganciare quel componente dalle proprietà della scheda è più ristretto e più reversibile che rimuovere del tutto il prodotto. Poiché il legame è per connessione, confrontate le schede invece dell'intero stack.
Decidete quale prodotto possiede l'avvio, poi registratelo
La coesistenza è realistica solo quando i due client occupano per progetto livelli diversi, come uno stack IPsec accanto a un proxy che gestisce solo il traffico delle applicazioni. Dove entrambi vogliono la stessa porta, lo stesso livello di filtro o il diritto di pubblicare una rotta predefinita, continueranno ad alternarsi e ogni guasto sembrerà un nuovo difetto.
Scegliete il proprietario deliberatamente. Le forme che sopravvivono a un riavvio includono l'esecuzione del secondo client dentro una macchina virtuale, il suo mantenimento su hardware dedicato, o la standardizzazione su un solo client che parla entrambi i protocolli. Disattivare l'avvio automatico e il servizio del perdente è un cambiamento più piccolo che ricostruire la tabella di routing dopo ogni avvio, e si annulla con una sola modifica delle impostazioni.