L'adaptador OpenVPN parpelleja a Windows? Comproveu si hi ha una IP duplicada

A Windows, un adaptador OpenVPN que agafa una adreça, la deixa anar i ho repeteix cada pocs segons normalment no és un error de DHCP. Es diu a l'adaptador que faci servir una adreça que ja respon una altra cosa, així que Windows la marca com a no utilitzable i el client torna a començar. El registre del client queda silent perquè el conflicte es resol per sota, dins de la pròpia pila de xarxa del sistema operatiu.

Aquesta distinció importa, perquè cada pas de diagnòstic adreçat a la configuració del túnel es perdrà una adreça duplicada al costat del servidor.

Comenceu pel registre d'esdeveniments de Windows, no pel registre del client

Windows enregistra els conflictes d'adreces al registre del sistema, amb els identificadors d'esdeveniment 4198 i 4199. El primer informa d'un conflicte detectat per a una adreça, el segon informa que una interfície no ha pogut utilitzar l'adreça amb què estava configurada. Cap dels dos no esmenta OpenVPN, i per això mateix és fàcil passar-los per alt.

Extreu els esdeveniments recents i compara'n les marques de temps amb el cicle de renovació de l'adaptador: Get-WinEvent -FilterHashtable @{LogName='System'; Id=4198,4199} -MaxEvents 40 | Format-Table TimeCreated,Id,Message -Wrap. Un conflicte cada quinze segons encaixa amb un client que torna a provar la mateixa adreça contra un propietari que continua responent-hi. Un sol conflicte en el moment de la connexió apunta més aviat a una col·lisió puntual. En qualsevol cas, la pregunta següent és qui més té l'adreça.

Tres disposicions posen dos amfitrions en una adreça

Pregunteu al servidor qui creu que té l'adreça i després pregunteu a la xarxa qui hi respon. grep -H ifconfig-push /etc/openvpn/ccd/* llista cada adreça de túnel fixada i el certificat a què pertany. ip -4 neigh show dev tap0 mostra què ha après el pont a la segona capa. Comparar aquestes dues llistes troba la majoria de duplicats en menys d'un minut.

Tres disposicions expliquen gairebé tots els casos: una entrada de client-config-dir fixa una adreça per a dos certificats, un segment tap pontat dona a una màquina una adreça que un altre amfitrió ja té estàticament, o un fitxer de concessió obsolet retorna una adreça que un client encara connectat creu que posseeix. El tercer cas és el més traïdor, perquè ifconfig-pool-persist reutilitza deliberadament adreces per a clients coneguts.

Feu l'adreça única en lloc de competir per ella

L'ordre d'arrencada només decideix qui guanya avui, així que tracteu com a temporal qualsevol solució basada en la seqüència de reinici. Doneu a cada client la seva pròpia línia ifconfig-push o assigneu adreces estàtiques d'un rang que cap interfície de pont ni de servidor toqui. Reviseu també la llista de clients per si hi ha noms comuns duplicats, perquè duplicate-cn permet que dues sessions comparteixin una identitat i, per tant, una adreça fixada. Si un dispositiu pontat necessita de debò una adreça fixa, moveu-lo a la seva pròpia subxarxa o reserveu-la del conjunt en un lloc que el servidor enregistri.

Suprimiu el fitxer persist només després de saber quines concessions conté, o la propera reconnexió repartirà les mateixes adreces una altra vegada.

Reinicieu en l'ordre correcte i confirmeu un sol propietari per adreça

Apliqueu el canvi primer al servidor i després reconnecteu els clients, perquè cada participant es registri contra el conjunt corregit. Reiniciar primer els clients els deixa amb adreces que el servidor encara creu ocupades. Després del reinici, llegiu el fitxer d'estat i confirmeu que cada nom comú apareix una vegada amb una adreça. Dues entrades per a un nom volen dir que una sessió antiga no es va tancar mai, no que el conjunt estigui trencat.

Si un client encara no pot conservar la seva adreça, comproveu si la porta una interfície de pont al mateix amfitrió. Un pont que ha heretat una adreça d'un dispositiu de proveïdor respondrà l'ARP per a ella fins i tot quan el servidor VPN ja hagi lliurat aquesta adreça a un client.

Observeu un cicle de renovació complet abans de tancar el tiquet

Una lectura neta no demostra res. Observeu l'adaptador almenys deu minuts i forceu una reconnexió al mig: Get-NetIPAddress -InterfaceAlias "OpenVPN*" | Select-Object IPAddress,AddressState. L'adreça hauria de sobreviure a la reconnexió i quedar-se en un estat preferent.

Després torneu a executar la consulta d'esdeveniments del primer pas i confirmeu que no retorna res de nou. Un registre silenciós durant una reconnexió és la prova que el conflicte ha desaparegut, mentre que un registre silenciós després d'una sola connexió només vol dir que la cursa encara no ha passat. Finalment, proveu el recurs pel qual existeix el túnel, perquè un pont que ha perdut la seva adreça pot trencar un camí del proveïdor mentre la VPN mateixa sembla sana.

Anoteu el rang del conjunt, cada adreça fixada i l'amfitrió que la posseeix a les notes del servidor. Així la propera col·lisió es detecta en minuts en lloc de necessitar tota una tarda per retrobar-la.