Un concentrador OpenVPN, tres LAN: pla d’adreces i fitxers iroute

Quatre prefixos disjunts, una ruta al nucli per branca, un iroute per propietari. Un ordre de treball per a un concentrador de tres llocs que falla en silenci quan un nom és incorrecte.

Tres LAN privades poden trobar-se en un sol concentrador sense que cap lloc conegui l’interior dels altres, i tot el disseny descansa en quatre decisions breus de configuració. El que el fa funcionar no és una característica exòtica del protocol, sinó un pla d’adreces que ningú no ha d’endevinar, més rutes per client que diuen al concentrador quina branca posseeix cada prefix. Equivoqueu-vos en qualsevol de les dues coses i el túnel igualment s’aixeca, i això és exactament el que fa confús el fracàs.

Recorreu els passos en ordre. Cadascun depèn del pla del pas anterior, i cap no requereix una autoritat de certificació nova.

Comenceu amb un pla que ningú no hagi d’endevinar

Anoteu quatre prefixos disjunts abans de tocar cap fitxer de configuració: la LAN pròpia del concentrador, la LAN de cada branca i el pool que es lliura als clients itinerants. La disjunció és el que manté simple tota la resta, perquè els rangs solapats converteixen l’encaminament en un trencaclosques de coincidència més llarga que cap configuració per client no arregla. Després confirmeu quina màquina és la porta d’enllaç per defecte de cada LAN, perquè un encaminador de branca que no és la porta d’enllaç de la seva LAN necessita les rutes remotes instal·lades en un altre lloc. Finalment, fixeu els noms autenticats que identifiquen cada branca, perquè aquests noms són les claus amb què es busquen els fitxers per client.

Un pla il·lustratiu manté el pool ben lluny de les tres LAN. El vostre serà diferent, i l’única regla ferma és que no hi hagi dos rangs que se solapin.

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

Digueu al nucli del concentrador on són les branques

El concentrador necessita dues informacions per branca: una ruta al nucli que enviï el prefix al dispositiu de túnel, i una iroute entrada que diu al OpenVPN procés quin client la posseeix. La ruta del nucli per si sola lliura els paquets al túnel i s’hi atura, perquè el dimoni encara ha de decidir quin igual ha de rebre’ls. L’entrada iroute per si sola deixa aquests paquets al nucli sense cap ruta per seguir. Totes dues línies pertanyen a la configuració que el dimoni carrega realment, cosa que val la pena verificar abans de depurar res més.

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

Desactiveu client-a-client quan el nucli ha de ser el punt d’aplicació. Aquesta opció retransmet el trànsit entre iguals dins del dimoni, cosa que és convenient i també significa que les vostres regles de reenviament no veuen mai el flux. Tot el que segueix assumeix que el nucli veu cada paquet entre branques.

Doneu a cada branca les rutes que necessita

Cada branca necessita rutes per a les altres branques i per a la LAN del concentrador, i no necessita cap ruta per a la seva pròpia LAN connectada. Empenyeu els prefixos remots des del concentrador en lloc d’enganxar-los a cada encaminador, de manera que un quart lloc més endavant signifiqui un fitxer nou per client en comptes de quatre edicions. El fitxer per client també porta la línia iroute, que manté la propietat i l’anunci al mateix lloc. Feu que el directori i els seus fitxers siguin llegibles segons el model de privilegis del servidor, o la cerca falla sense cap missatge.

# /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 quart lloc segueix el mateix patró: un nom autenticat diferent, un prefix posseït, una ruta al nucli del concentrador, una iroute entrada i anuncis només als llocs que tenen permís per arribar-hi.

Proveu-ho en tots dos sentits abans de donar-ho per fet

Activeu el reenviament IPv4 als tres encaminadors i després confirmeu que el tallafoc permet els fluxos previstos en tots dos sentits, perquè una prova unidireccional passa amb un camí de tornada trencat més sovint del que ningú espera. Entre llocs no cal cap traducció d’origen, i preservar l’origen original és el que permet a cada branca aplicar la seva pròpia política a una petició.

Proveu des d’un equip de la LAN d’una branca fins a un servei d’una altra, després invertiu el sentit i després proveu des d’una branca fins a la LAN del concentrador. Aquests tres resultats són proves diferents i cap no implica els altres. Si un encaminador de branca no és la porta d’enllaç per defecte de la seva LAN, instal·leu els prefixos remots a la porta d’enllaç real i incloeu-hi també el pool quan els clients del túnel hagin d’iniciar connexions cap a aquesta LAN.

Registreu el pla, els fitxers per client i les regles del tallafoc com un sol document, perquè la propera incorporació de lloc es jutjarà contra ells.

El disseny es manté cohesionat perquè cada capa té una feina: el pla manté els prefixos únics, la ruta del nucli mou els paquets, iroute nomena el propietari i el tallafoc decideix què es permet. Quan alguna cosa es trenca, aquesta llista també és l’ordre amb què cal comprovar-la.

Articles relacionats