Servidor OpenVPN con nopool: declare un rango de pool explícito

Os axudantes do servidor configuran unha subrede e despois énchena cun pool dinámico da súa propia elección. Ese valor por defecto é cómodo ata que algunhas direccións deben quedar fóra da asignación, xa estean reservadas para asignacións fixas ou retidas para un segmento futuro. Suprimir o pool automático e declarar o rango un mesmo require dúas liñas e unha decisión deliberada sobre que direccións non son para asignación. O resto é disciplina operativa: inventario, aplicación, verificación e reversión.

Este é un cambio nun servizo en funcionamento, así que tráteo como unha tarefa operativa: primeiro inventario, aplicación polo ciclo de vida habitual, verificación cun cliente novo e unha reversión preparada.

Empece pola subrede que xa ten

Lea a configuración actual do servidor e as direccións que os clientes teñen realmente. O cambio do pool só ten sentido fronte a esa liña base, e a liña base non sempre é o que suxire o ficheiro, porque un produto xestionado ou un xerador de configuración pode ser o propietario do ficheiro que está a ler.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Confirme a topoloxía vixente. Coa topoloxía de subrede cada cliente toma unha dirección do pool; os deseños net30 máis antigos asignan un bloque pequeno por cliente e a aritmética é completamente distinta. Se o servidor segue en net30, esta páxina é a guía de migración equivocada e os números do pool non significarán o que espera. Comprobe esa liña antes de copiar aritmética de direccións de calquera outro sitio.

Anote a dirección do propio servidor, cada asignación fixa no directorio de configuración de clientes e calquera dirección da que dependa unha ruta ou unha regra de acceso. Esas son as direccións que deben quedar fóra do rango dinámico. Anotalas primeiro é o que converte o rango nunha decisión e non nunha conxectura. Tamén lle dá á reversión algo concreto que restaurar.

Engada nopool e declare o rango

A palabra clave auxiliar acepta nopool, que conserva a configuración da subrede e suprime o pool dinámico automático, como describe o manual de OpenVPN 2.6. A liña explícita ifconfig-pool achega despois o rango inclusivo que pretende, e a súa máscara de rede coincide coa subrede. Ambas as liñas pertencen ao mesmo bloque de servidor, porque un pool sen a súa subrede non ten sentido. A orde entre elas só importa para a lexibilidade, xa que o auxiliar despregá a parella cando arrinca o servizo.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

Ambos os límites son inclusivos, así que o exemplo ofrece setenta e unha direccións. Manteña a dirección do servidor e cada asignación fixa fóra dese intervalo; unha asignación fixa que caia dentro do rango dinámico produce unha colisión que depende da orde de conexión, que é o peor tipo de depurar. Deixe unha marxe entre o conxunto reservado e o rango se é probable que as asignacións fixas medren.

O tamaño do rango e a concorrencia son límites separados. Cen direccións non significan cen clientes simultáneos se max-clients di o contrario, e un pool maior que o límite de concorrencia é normal en lugar de derrochador. O importante é que os dous límites se elixan deliberadamente en lugar de herdarse dun valor por defecto.

Manteña as asignacións fixas fóra do rango dinámico

Un ifconfig-push específico dun cliente é un mecanismo distinto da asignación do pool e debe usar parámetros axeitados á topoloxía activa. En modo de subrede é unha soa dirección e máscara de rede; arrastrar un par net30 porque apareceu nun exemplo antigo é un erro frecuente.

O historial de asignacións é unha pista, non unha autoridade. Un ficheiro persist lembra que cliente tiña que dirección, de modo que os clientes que se reconectan tenden a recibir a mesma, e non reserva direccións, non as libera nin substitúe unha asignación fixa. Se un dispositivo concreto debe ter sempre unha dirección concreta, use unha asignación fixa en lugar de confiar no ficheiro persist.

Despois revise as rutas que dependen das direccións. Unha ruta empuxada aos clientes, unha regra de devasa que admite unha subrede ou unha comprobación de monitorización que espera un host concreto poden presupor o rango antigo. Cambiar o pool sen lelas traslada o fallo a un lugar que parece non relacionado.

Aplique polo ciclo de vida e logo verifique

Aplique o cambio tal como o servizo recibe normalmente a configuración, xa sexa un ficheiro directo máis un reinicio ou unha capa de xestión que rexenera o ficheiro. Unha edición manual nun ficheiro xerado sobrevive ata a seguinte xeración e non máis. Anote que mecanismo é o propietario do ficheiro, porque o seguinte operador necesitará saber onde facer o mesmo cambio. Despois reinicie unha vez e lea o rexistro antes de invitar un cliente.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Conecte un cliente que non se conectara antes e confirme que a dirección cae dentro do rango declarado e fóra do conxunto reservado. Despois confirme o camiño de volta: o cliente debe alcanzar o que a política permite e nada máis. Unha dirección que encaixa co plan pero non ten ruta funcional non é un cambio exitoso.

Volve conectar un cliente que tiña unha dirección do rango antigo. Debería recibir unha dirección do rango novo, e calquera estado a nivel de sesión ligado á dirección antiga debería desaparecer. Se conserva a dirección antiga, algo máis a está asignando e o pool non é o propietario que vostede cre.

Reverter un cambio de rango

Garde as tres liñas anteriores no seu rexistro de cambios, non só o ficheiro anterior. Restauralas e reiniciar devolve a asignación ao comportamento antigo, e os clientes que se reconecten despois recibirán direccións del.

Dúas advertencias pertencen ao rexistro. Os clientes xa conectados cando reverte conservan as súas direccións actuais ata que se reconectan, así que unha reversión non é instantánea en toda a frota. E se o rango antigo se solapaba cunha asignación fixa, restauralo restaura tamén a colisión; ese solapamento é a razón do cambio e necesita unha solución distinta dunha reversión.

Un cambio de pool está rematado cando un cliente novo recibe unha dirección dentro do rango, unha dirección reservada nunca se entrega e as rutas e regras que consomen esas direccións seguen comportándose como se pretende. Calquera cousa menos deixa á seguinte persoa descubrir cal das tres non é certa.