Dos clients OpenVPN en una sola passarel·la Linux: dividiu la política

Dos dimonis OpenVPN poden informar tots dos d’un túnel correcte mentre la passarel·la envia cada client pel mateix. Res de l’handshake no decideix quin túnel fa servir un client; ho decideix el nucli, paquet a paquet, recorrent les regles de política i després la taula que cada regla anomena. Un cop ho mireu així, la configuració deixa de tractar-se d’opcions d’OpenVPN i es converteix en una matriu d’encaminament amb dos propietaris.

El nucli decideix, no el dimoni

Un paquet reenviat arriba a la interfície LAN i el codi d’encaminament avalua la llista de regles per ordre de prioritat. La primera regla el selector de la qual coincideix anomena una taula, i les rutes d’aquesta taula trien el dispositiu de sortida. Si la taula no té cap ruta coincident, la consulta continua cap a la regla següent, i aquest és el detall que fa que una configuració mig feta falli en silenci en lloc de fer-ho sorollosament.

El procés del túnel no hi té res a dir, en aquest recorregut. Crea una interfície i pot instal·lar rutes, però si el paquet d’un client concret entra en aquesta interfície depèn totalment de la taula a què es va enviar. Per tant, dos túnels amb rutes importades idèntiques competeixen, i l’últim que escriu guanya per a tothom. És per això que una configuració pot semblar equilibrada als fitxers de configuració i, tot i així, enviar tots els clients per un sol dimoni.

Doneu a cada instància el seu propi conjunt de recursos

Comenceu pels noms, perquè els noms reutilitzats són la manera com les dues instàncies acaben compartint estat per accident. Assigneu dispositius de túnel diferents, fitxers de configuració diferents, credencials diferents i unitats de servei diferents. Anoteu el punt final exterior i l’adreça del túnel de cada instància a la mateixa taula que la matriu de política, perquè un canvi posterior tingui un sol lloc on mirar.

dev tun-office
route-nopull
pull-filter ignore "redirect-gateway"

dev tun-lab
route-nopull

route-nopull manté les rutes que imposa un servidor fora de la taula local, que és el que voleu quan les taules de política han de ser explícites. Si un servidor determinat també imposa una opció redirect-gateway, i si la vostra versió de client admet la forma amb filtre, val la pena comprovar-ho al manual en lloc de suposar-ho.

Escriviu la matriu: origen, taula, dispositiu

Per a cada grup de clients, afegiu una regla que triï una taula per adreça d’origen i, després, poseu el camí volgut en aquesta taula:

ip rule add from 10.8.1.0/24 lookup 100 priority 1000
ip rule add from 10.9.1.0/24 lookup 200 priority 1000
ip route add default dev tun-office table 100
ip route add default dev tun-lab table 200

La taula necessita les rutes de destinació que el grup hauria de tenir, més les excepcions locals o de gestió que mantinguin la passarel·la utilitzable. Una taula que només conté una ruta per defecte és una política de túnel complet per a aquest grup, cosa que pot ser exactament el correcte, però hauria de ser una decisió i no una omissió.

El transport del mateix túnel no és en un grup de clients

Els paquets xifrats de cada dimoni s’originen a la mateixa passarel·la, adreçats al parell exterior. Una regla que només coincideix amb un prefix d’origen de client deixa aquests paquets tranquils, i per això les regles limitades a l’origen són més segures que les regles que coincideixen amb tot. Una regla sense selector pot capturar el transport del mateix túnel i tornar-lo a enviar per un túnel, i llavors la connexió falla d’una manera que sembla un problema del proveïdor.

Mantingueu la sessió de gestió local i el camí de la capa inferior explícitament fora de les taules de política. Escriviu aquestes excepcions al costat de la matriu; formen part del disseny, no són una solució alternativa que calgui redescobrir durant un incident.

Triar un camí no el permet

El permís de reenviament és una segona decisió presa més endavant al camí. Una regla de tallafocs que accepta paquets que surten pel segon túnel no fa que el codi d’encaminament el triï, i una taula correcta no atorga permís per reenviar. Totes dues coses han d’existir, i una prova que només demostra una us enganyarà sobre l’altra. Quan un grup funciona i l’altre no, comproveu aquests dos passos per separat en lloc de reescriure les taules.

La traducció d’origen és una tercera decisió, i s’hauria d’acotar al grup d’origen i al dispositiu de túnel que realment el transporta. Afegiu una cadena dedicada per a les dues instàncies en lloc de buidar la cadena postrouting, perquè serveis no relacionats poden tenir-hi entrades i un buidatge les elimina en silenci.

Què passa quan cau un túnel

Decidiu el comportament de fallada per endavant. Quan una taula de túnel perd la seva ruta, la consulta cau a la regla següent i el trànsit del grup continua per l’altre túnel o pel enllaç ascendent ordinari sense cap error. Si això no és acceptable, afegiu una regla de terminació amb un número de prioritat més baix que retorni un resultat inabastable per a aquest origen, perquè la pèrdua sigui visible en lloc de quedar absorbida.

Envieu una petició nova des de cada grup d’origen i anoteu quatre fets: la taula seleccionada, el dispositiu de sortida, l’origen traduït i si la resposta va tornar pel mateix camí. Després atureu un túnel i repetiu. Dos dispositius TUN a la llista d’interfícies proven que tots dos dimonis s’han iniciat; no diuen res sobre quin va fer servir un client concret. La segona execució, amb un túnel menys, és la que mostra si la vostra regla de reserva fa el que volíeu.