Un concentrador OpenVPN, tres LAN: plan de enderezos e ficheiros iroute

Tres LAN privadas poden atoparse nun único concentrador sen que ningún sitio coñeza o interior dos demais, e todo o deseño descansa en catro decisións breves de configuración. O que o fai funcionar non é unha característica exótica do protocolo, senón un plan de enderezos que ninguén ten que adiviñar, máis rutas por cliente que din ao concentrador que sucursal posúe cada prefixo. Equivócate en calquera das dúas e o túnel segue levantándose, que é xusto o que volve confuso o fallo.

Percorre os pasos en orde. Cada un depende do plan do paso anterior, e ningún require unha autoridade de certificación nova.

Comeza cun plan que ninguén teña que adiviñar

Anota catro prefixos disxuntos antes de tocar un ficheiro de configuración: a LAN propia do concentrador, a LAN de cada sucursal e o conxunto que se entrega aos clientes itinerantes. A disxunción é o que mantén simple todo o demais, porque os rangos solapados converten o encamiñamento nun crebacabezas de coincidencia máis longa que ningunha configuración por cliente repara. Despois confirma que máquina é a porta de enlace predeterminada de cada LAN, porque un router de sucursal que non é a porta de enlace da súa LAN necesita as rutas remotas instaladas noutro lugar por completo. Por último, fixa os nomes autenticados que identifican cada sucursal, porque eses nomes son as chaves coas que se buscan os ficheiros por cliente.

Un plan ilustrativo mantén o conxunto ben lonxe das tres LAN. O teu será distinto, e a única regra estrita é que non se solapen dous rangos.

Hub LAN        172.20.0.0/24
Branch A LAN   172.21.0.0/24
Branch B LAN   172.22.0.0/24
VPN pool       10.77.0.0/24

identity branch-a owns 172.21.0.0/24
identity branch-b owns 172.22.0.0/24

Dille ao núcleo do concentrador onde están as sucursais

O concentrador necesita dous datos por sucursal: unha ruta no núcleo que envíe o prefixo ao dispositivo de túnel, e unha iroute entrada que diga ao OpenVPN proceso que cliente a posúe. A ruta do núcleo por si soa entrega os paquetes ao túnel e detense aí, porque o daemon aínda ten que decidir que par debe recibilos. A entrada iroute por si soa deixa eses paquetes no núcleo sen unha ruta que seguir. Ambas as liñas pertencen á configuración que o daemon carga realmente, algo que paga a pena verificar antes de depurar calquera outra cousa.

dev tun
topology subnet
server 10.77.0.0 255.255.255.0
disable-dco

route 172.21.0.0 255.255.255.0
push "route 172.20.0.0 255.255.255.0"
client-config-dir /etc/openvpn/ccd
route 172.22.0.0 255.255.255.0

Desactiva cliente-a-cliente cando se supón que o núcleo é o punto de aplicación. Esa opción retransmite o tráfico entre pares dentro do daemon, o que é cómodo e tamén significa que as túas regras de reenvío nunca ven o fluxo. Todo o que segue asume que o núcleo ve cada paquete entre sucursais.

Dálle a cada sucursal as rutas que necesita

Cada sucursal necesita rutas cara ás outras sucursais e cara á LAN do concentrador, e non necesita unha para a súa propia LAN conectada. Empuxa os prefixos remotos desde o concentrador en lugar de pegalos en cada router, de modo que un cuarto sitio despois signifique un ficheiro novo por cliente en vez de catro edicións. O ficheiro por cliente tamén leva a liña iroute, que mantén a propiedade e o anuncio no mesmo lugar. Fai que o directorio e os seus ficheiros sexan lexibles segundo o modelo de privilexios do servidor, ou a busca falla sen mensaxe.

# /etc/openvpn/ccd/branch-a
iroute 172.21.0.0 255.255.255.0
push "route 172.22.0.0 255.255.255.0"

Un cuarto sitio segue o mesmo patrón: un nome autenticado distinto, un prefixo propio, unha ruta no núcleo do concentrador, unha iroute entrada e anuncios só aos sitios aos que se permite chegar a el.

Proba en ambos os sentidos antes de dalo por rematado

Activa o reenvío IPv4 nos tres routers e logo confirma que a devasa permite os fluxos previstos en ambos os sentidos, porque unha proba unidireccional pasa cun camiño de volta roto máis a miúdo do que ninguén espera. Entre sitios non fai falta tradución de orixe, e preservar a orixe orixinal é o que permite a cada sucursal aplicar a súa propia política a unha petición.

Proba desde un equipo da LAN dunha sucursal ata un servizo doutra, logo inverte o sentido e despois proba desde unha sucursal ata a LAN do concentrador. Eses tres resultados son probas distintas e ningún implica os outros. Se un router de sucursal non é a porta de enlace predeterminada da súa LAN, instala os prefixos remotos na porta de enlace real e inclúe tamén o conxunto cando os clientes do túnel deban iniciar conexións cara a esa LAN.

Rexistra o plan, os ficheiros por cliente e as regras da devasa como un único documento, porque a próxima incorporación de sitio xulgarase contra eles.

O deseño sostense porque cada capa ten unha tarefa: o plan mantén os prefixos únicos, a ruta do núcleo move paquetes, a iroute nomea o propietario e a devasa decide que se permite. Cando algo se rompe, esa lista é tamén a orde na que hai que revisalo.