Enderezos de cliente OpenVPN estáticos detrás de OPNsense

Os nomes necesitan enderezos que non se movan, e o ficheiro de pool de OpenVPN só fai que un enderezo sexa pegañento. Perda ese ficheiro, ou reemita un certificado cun nome común distinto, e o cliente que volve aterra noutro lugar do pool mentres o seu rexistro DNS segue apuntando ao enderezo antigo. A resposta duradeira é unha anulación específica do cliente que fixa o enderezo, máis unha rede de túnel máis ampla para que os enderezos fixados queden fóra do rango dinámico. A aritmética que hai detrás desa ampliación é onde vive a maior parte da confusión.

OPNsense garda esas anulacións na configuración específica do cliente do servidor, indexadas polo nome común do certificado, o que fai que o nome común forme parte do plan de enderezos.

Un arrendamento pegañento non é un enderezo estático

O ficheiro de pool escribe asignacións de enderezo a cliente e devólveas cando un cliente coñecido se reconecta. Iso é comodidade, non un contrato: o ficheiro pódese rexenerar, a asignación desaparece cando cambia a identidade do cliente, e dous servidores que comparten un pool non se poñerán de acordo. Unha anulación específica do cliente funciona doutro xeito, porque o enderezo vén da configuración e non do historial. Tamén sobrevive a un reinicio e a unha reinstalación do aparello, sempre que a anulación se garde xunto co resto da configuración.

A alternativa dinámica, conectar a VPN ao DNS cun script de conexión de cliente e actualizacións dinámicas, funciona e require un resolutor que acepte actualizacións máis un script en cada conexión. Nun aparello estás limitado aos paquetes que distribúe o fabricante, e normalmente é aí onde ese plan se detén.

A aritmética /30 que ninguén goza

Coa topoloxía net30 predeterminada, cada cliente recibe o seu propio /30: o primeiro enderezo utilizable vai ao lado do servidor e o segundo ao cliente. Por tanto, as anulacións deben quedar fóra da rede de túnel dinámica do servidor, o que significa ampliar primeiro esa rede. Un servidor en 10.8.0.0/24 pode pasar a 10.8.0.0/23, deixando a metade do rango antigo para clientes dinámicos e a outra metade para anulacións. Engada o /24 orixinal como rede local IPv4 adicional para que o tráfico cara a ambas as metades entre no túnel.

Cada enderezo de anulación debe caer nunha fronteira /30, así que o último octeto é múltiplo de catro. Un /30 en 10.8.1.0 dá ao cliente 10.8.1.2, e ese é o enderezo que leva o rexistro DNS. Escoller 10.8.1.3 no seu lugar produce un cliente que se conecta e non pode pasar tráfico, porque o enderezo pertence a unha subrede que a topoloxía nunca lle asignou.

O plan é máis fácil de manter se as anulacións se asignan desde arriba do rango ampliado cara abaixo, de xeito que o pool dinámico se expanda cara ao espazo libre en lugar de arredor de illas fixas.

Redes locais e a zona que consultan os clientes

O tráfico de cliente a cliente necesita o seu propio permiso. A lista de redes locais IPv4 do servidor debe incluír ambas as metades do rango, dinámica e estática; sen ela, o servidor acepta un paquete dun cliente e non ten ningunha política que o deixe pasar a outro. O síntoma lese como un fallo de DNS, porque o nome se resolve e a conexión segue fallando. Comprobe ao mesmo tempo o axuste de cliente a cliente, xa que unha entrada de rede local por si soa non habilita o reenvío entre pares.

Publique os rexistros na zona que os clientes remotos consultan realmente. Un rexistro nunha zona servida só polo resolutor da LAN é invisible para un cliente cuxo resolutor empurrado apunta a outro sitio, e engadir máis rexistros á zona equivocada nunca o repara. Confirme a opción DNS empurrada e o dominio de busca antes de engadir nada.

Que comprobar nunha conexión nova

Reconecte o cliente e confirme que o enderezo asignado coincide coa súa anulación antes de probar calquera outra cousa. Logo resolva o nome desde un segundo cliente e conecte ao servizo por nome, o que exercita o rexistro DNS, a ruta e a devasa á vez. Confirme a ruta de resposta no lado do servidor, xa que un nome que se resolve mentres o servizo segue inaccesible é un problema de encamiñamento ou de política, non de nomes. Manteña a táboa de anulacións xunto á lista de certificados para que ambas se revisen xuntas.

Un certificado reemitido cun nome común distinto deixa de coincidir coa súa anulación e devolve o cliente ao pool dinámico. Espere iso despois de calquera cambio de identidade.