Os enderezos estables de OpenVPN deben seguir a identidade, non a IP de orixe
Un enderezo estático é unha afirmación sobre unha identidade, non sobre unha IP de orixe. Escolle a chave, mantén as reservas fóra do pool e despois escolle o propietario da asignación.
Os plans de enderezos que din «este portátil recibe 10.90.0.10» son en realidade afirmacións sobre a identidade: que dispositivo autenticado pode ter ese enderezo. A IP pública actual dese dispositivo case non ten que ver, porque NAT e itinerancia cámbiana sen cambiar quen é o usuario. Construír o plan sobre o enderezo de orixe produce regras que se rompen na primeira rede de hotel. Construílo sobre a identidade autenticada produce un plan que sobrevive ás viaxes.
Comeza polo que o servidor pode verificar e despois decide para que serve o enderezo.
Escolle a chave de identidade antes do enderezo
Un certificado de cliente separado por dispositivo dálle ao servidor unha chave estable e verificable para cada membro, que é a base máis limpa para unha asignación estática. Un despregamento con autenticación por usuario pode basearse no nome de usuario, sempre que a selección de configuración siga o mesmo campo. Mesturar os dous modelos produce asignacións que coinciden cun certificado para un cliente e cun nome de usuario para outro, e ninguén pode prever cal gañará. Decide que chave usa o plan antes de escribir unha soa reserva.
Con duplicate-cn, varias sesións simultáneas poden presentar o mesmo nome común, así que un enderezo fixado non pode identificalos individualmente. Iso é unha propiedade do modelo de identidade, non algo que un mellor plan de enderezos poida arranxar.
Reserva enderezos fóra do rango dinámico
Nunha rede con topoloxía de subrede como 10.90.0.0/24, reserva os enderezos baixos para os membros con nome e pon o pool dinámico nun rango disxunto. Unha asignación para un membro fixado ten este aspecto ifconfig-push 10.90.0.10 255.255.255.0 no ficheiro que o servidor selecciona para esa identidade. O segundo argumento significa algo distinto con net30, así que o exemplo non é neutro respecto da topoloxía. Le a topoloxía antes de copialo.
A persistencia do pool rexistra os arrendamentos recentes e tende a devolver o mesmo enderezo, o que é unha comodidade e non unha reserva. Non deixes que o ficheiro de persistencia se converta no rexistro de propiedade, porque cambia co historial de conexións e non coa política.
A precedencia da asignación decide quen gaña
O manual documenta unha orde: unha asignación explícita xerada durante client-connect pode surtir efecto antes que unha entrada de client-config-dir, que á súa vez precede a asignación ordinaria do pool. Ese orde explica a maioría dos informes «o enderezo fixado non se aplicou». Tamén significa que un asignador dinámico que escribe configuración por sesión pode sobrescribir en silencio un ficheiro estático que crías autoritativo.
Escolle unha capa que posúa as asignacións e fai que as demais sexan de só lectura. Dúas capas que ambas afirman decidir producen asignacións que dependen do momento.
Un asignador dinámico necesita o mesmo modelo
Unha integración de client-connect que reparte enderezos por sesión é un asignador pequeno cos problemas habituais dos asignadores. Ten que validar a identidade solicitante, reservar un enderezo de forma atómica, emitir só a saída por conexión admitida e liberar a reserva ao desconectar ou fallar. As solicitudes concurrentes necesitan un bloqueo ou unha restrición de base de datos, non unha secuencia de ler e despois escribir. Sen limpeza, o pool perde enderezos ata un reinicio.
Mantén o estado do asignador onde o seguinte operador poida lelo e rexistra a decisión identidade-a-enderezo, non só o enderezo.
Decide se o enderezo é política ou comodidade
Se unha regra de cortafogos ou unha ruta permite tráfico desde un enderezo de túnel, entón o enderezo participa na política de acceso e unha reasignación herda ese permiso. Coordina o ciclo de vida da identidade, o enderezo e o cortafogos, ou liga a regra a algo que non se poida reasignar. O enderezamento estable fai lexible a configuración; non substitúe a autenticación.
Escribe o plan como un inventario cun propietario por entrada e revísao cando se retire un dispositivo. A reserva non utilizada é a que se reutiliza por accidente.