Servidor OpenVPN amb nopool: declareu un interval de pool explícit

Els auxiliars del servidor configuren una subxarxa i després l’omplen amb un pool dinàmic de la seva pròpia elecció. Aquest valor per defecte és convenient fins que algunes adreces han de quedar fora de l’assignació, tant si es reserven per a assignacions fixes com si es guarden per a un segment futur. Suprimir el pool automàtic i declarar l’interval vosaltres mateixos requereix dues línies i una decisió deliberada sobre quines adreces no són per a assignació. La resta és disciplina operativa: inventari, aplicació, verificació i reversió.

Això és un canvi en un servei en funcionament, així que tracteu-lo com una tasca operativa: primer inventari, aplicació pel cicle de vida habitual, verificació amb un client nou i una reversió a punt.

Partiu de la subxarxa que ja teniu

Llegiu la configuració actual del servidor i les adreces que els clients tenen realment. El canvi del pool només té sentit respecte d’aquesta base, i la base no sempre és el que suggereix el fitxer, perquè un producte gestionat o un generador de configuració pot ser el propietari del fitxer que llegiu.

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

Confirmeu la topologia vigent. Amb la topologia de subxarxa cada client pren una adreça del pool; els dissenys net30 més antics assignen un bloc petit per client i l’aritmètica és completament diferent. Si el servidor encara és a net30, aquesta pàgina és la guia de migració equivocada i els números del pool no significaran el que espereu. Comproveu aquesta línia abans de copiar aritmètica d’adreces de qualsevol altre lloc.

Anoteu l’adreça del mateix servidor, cada assignació fixa del directori de configuració de clients i qualsevol adreça de què depengui una ruta o una regla d’accés. Aquestes són les adreces que han de quedar fora de l’interval dinàmic. Anotar-les primer és el que converteix l’interval en una decisió i no en una conjectura. També dona a la reversió alguna cosa concreta a restaurar.

Afegiu nopool i declareu l’interval

La paraula clau auxiliar accepta nopool, que conserva la configuració de la subxarxa i suprimeix el pool dinàmic automàtic, tal com descriu el manual d’OpenVPN 2.6. La línia explícita ifconfig-pool proporciona després l’interval inclusiu que voleu, i la seva màscara de xarxa coincideix amb la subxarxa. Totes dues línies pertanyen al mateix bloc de servidor, perquè un pool sense la seva subxarxa no té sentit. L’ordre entre elles només importa per a la llegibilitat, ja que l’auxiliar desplega la parella quan s’inicia el servei.

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

Tots dos límits són inclusius, de manera que l’exemple ofereix setanta-una adreces. Manteniu l’adreça del servidor i cada assignació fixa fora d’aquest interval; una assignació fixa que caigui dins de l’interval dinàmic produeix una col·lisió que depèn de l’ordre de connexió, que és el pitjor tipus de depurar. Deixeu un marge entre el conjunt reservat i l’interval si és probable que les assignacions fixes creixin.

La mida de l’interval i la concurrència són límits separats. Cent adreces no volen dir cent clients simultanis si max-clients diu el contrari, i un pool més gran que el límit de concurrència és normal, no malbaratament. L’important és que els dos límits es triïn deliberadament i no s’heretin d’un valor per defecte.

Manteniu les assignacions fixes fora de l’interval dinàmic

Un ifconfig-push específic d’un client és un mecanisme diferent de l’assignació del pool i ha d’usar paràmetres adequats a la topologia activa. En mode de subxarxa és una sola adreça i màscara de xarxa; arrossegar una parella net30 perquè va aparèixer en un exemple antic és un error freqüent.

L’historial d’assignacions és un indici, no una autoritat. Un fitxer persist recorda quin client tenia quina adreça, de manera que els clients que es reconnecten solen rebre la mateixa, i no reserva adreces, no les allibera ni substitueix una assignació fixa. Si un dispositiu concret ha de tenir sempre una adreça concreta, feu servir una assignació fixa en lloc de confiar en el fitxer persist.

Després reviseu els camins que depenen de les adreces. Una ruta enviada als clients, una regla de tallafoc que admet una subxarxa o una comprovació de monitoratge que espera un amfitrió concret poden pressuposar l’interval antic. Canviar el pool sense llegir-los trasllada la fallada a un lloc que sembla no relacionat.

Apliqueu pel cicle de vida i després verifiqueu

Apliqueu el canvi tal com el servei rep normalment la configuració, tant si és un fitxer directe més un reinici com una capa de gestió que regenera el fitxer. Una edició manual en un fitxer generat sobreviu fins a la generació següent, i no més. Anoteu quin mecanisme és el propietari del fitxer, perquè el proper operador haurà de saber on fer el mateix canvi. Després reinicieu un cop i llegiu el registre abans de convidar un client.

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

Connecteu un client que no s’havia connectat abans i confirmeu que l’adreça cau dins de l’interval declarat i fora del conjunt reservat. Després confirmeu el camí de tornada: el client ha d’arribar al que la política permet i res més. Una adreça que encaixa amb el pla però no té cap ruta funcional no és un canvi reeixit.

Torneu a connectar un client que tenia una adreça de l’interval antic. Ha de rebre una adreça de l’interval nou, i qualsevol estat a nivell de sessió lligat a l’adreça antiga hauria d’haver desaparegut. Si conserva l’adreça antiga, alguna altra cosa l’assigna i el pool no és el propietari que us penseu.

Revertir un canvi d’interval

Guardeu les tres línies anteriors al registre de canvis, no només el fitxer anterior. Restaurar-les i reiniciar torna l’assignació al comportament antic, i els clients que es reconnectin després rebran adreces d’allà.

Dues advertències pertanyen al registre. Els clients ja connectats quan feu la reversió conserven les adreces actuals fins que es reconnectin, així que una reversió no és instantània a tota la flota. I si l’interval antic se solapava amb una assignació fixa, restaurar-lo restaura també la col·lisió; aquest solapament és el motiu del canvi i necessita una solució diferent d’una reversió.

Un canvi de pool està acabat quan un client nou rep una adreça dins de l’interval, una adreça reservada no es lliura mai i les rutes i regles que consumeixen aquestes adreces continuen comportant-se com cal. Qualsevol cosa menys deixa a la propera persona descobrir quina de les tres no és certa.