IP estática de OpenVPN por cliente: ifconfig-push, non ipp.txt

Editar unha liña en ipp.txt parece reservar un enderezo, e non o é. Ese ficheiro, nomeado por ifconfig-pool-persist, rexistra que enderezo tiña un nome común a última vez para que o grupo poida devolver o mesmo cando conveña. Nada nel liga a seguinte conexión a ese número.

Execute as comprobacións seguintes en orde. Cada unha confirma o mecanismo ou dille que se deteña e repare unha entrada.

Para que serve o ficheiro de persistencia

O ficheiro existe para manter os enderezos estables entre reinicios, o que fai as reconexións máis amables e os rexistros máis fáciles de ler. Lese como historia e escríbese como historia, e a ruta de asignación queda libre para escoller outro enderezo cando a pista non encaixa: outro grupo, unha asignación en conflito ou un cliente que chegou despois de que o grupo se enches. Por iso unha edición manual pode verse perfecta no ficheiro e non cambiar nada na conexión. Tráteo como unha caché de decisións pasadas e non como unha fonte de políticas.

Se necesita un enderezo concreto para un cliente concreto, o mecanismo documentado é ifconfig-push, e pertence á configuración que posúe ese cliente.

Comprobe que se selecciona o cliente correcto

A asignación explícita búscase polo nome común do cliente, así que un ficheiro nomeado para a identidade equivocada simplemente nunca se le. Confirme que considera o servidor que é o nome dese cliente, sobre todo onde username-as-common-name o cambia tras a autenticación. Despois confirme que o nome do ficheiro coincide exactamente con ese valor, incluídas as maiúsculas e minúsculas.

Pense na concorrencia mentres está aquí. Se se permite duplicate-cn, varios dispositivos poden presentar a mesma identidade, e un enderezo fixo non pode ser único para todos eles. Decida se o enderezo fixo paga a pena rexeitar sesións concorrentes para esa identidade, porque eses dous requisitos non se poden satisfacer á vez.

Comprobe que os números coinciden coa topoloxía

O significado dos argumentos depende da topoloxía do túnel, e aquí é onde un exemplo copiado fai máis dano. Na disposición net30 máis antiga cada cliente ocupa un bloque de catro enderezos, así que o push subministra un par de enderezos. Na topoloxía de subrede o cliente recibe un enderezo máis a máscara do grupo, e a forma de par é incorrecta. Lea a topoloxía da configuración en execución antes de escribir a liña.

# /etc/openvpn/ccd/partner-a   (subnet topology)
ifconfig-push 10.44.0.61 255.255.255.0

Comprobe o enderezo contra todo o demais que podería posuílo: outra asignación explícita, o rango do grupo dinámico e calquera ruta estática que presupoña un host fixo. Un enderezo que se solape co grupo funcionará ata que o grupo llo dea a outro, e ese fallo parecerá aleatorio.

Comprobe o resultado nunha conexión nova

Unha sesión existente conserva o enderezo que se lle deu, así que a única proba significativa é unha conexión nova. Desconecte o cliente, volva conectalo e lea o enderezo que realmente recibiu xunto coas rutas que chegaron con el. Se o enderezo segue sendo dinámico, a asignación non se aplicou, e o seguinte paso é a consulta da configuración e non outra edición do ficheiro de historial.

Manteña as probas xuntas: o nome do cliente, o ficheiro que coincidiu, o enderezo asignado e o grupo do que saíu.

Por último, un enderezo de túnel fixo non é unha credencial do dispositivo. Identifica un lugar no plan de enderezos, mentres que a autenticación segue descansando no certificado e na conta. Confundir ambas converte un conflito de enderezos nunha suposición de seguridade que ninguén escribiu.