Encaminar una cuenta de Linux por OpenVPN con una regla UID

El enrutamiento por cuenta encaja cuando cada socket IPv4 propiedad de un usuario de Linux debe salir por un túnel existente, y no encaja cuando necesita aislamiento a nivel de programa. Selecciona por UID, así que todo lo que se ejecute con esa cuenta entra en el alcance, incluida la tarea por lotes que olvidó. Resuelva esa cuestión antes de tocar una sola ip rule.

El ejemplo siguiente supone una cuenta de navegador dedicada en el UID 1500, un dispositivo de túnel tun-office con dirección local 10.80.0.11 y una VPN que permite los destinos en cuestión. El propio demonio se ejecuta fuera de ese UID.

Tres condiciones que eligen el mecanismo

Elija una regla UID cuando la identidad que hace el trabajo sea la cuenta, cuando mover todo su tráfico sea aceptable y cuando un namespace fuera más pesado de lo que la tarea merece. Elija un namespace de red cuando la carga de trabajo necesite sus propias interfaces, resolutor y tabla de enrutamiento. Elija un proxy o una vinculación por proceso cuando exactamente una aplicación deba moverse mientras el resto de la sesión se queda en la ruta local. Escribir esas tres cosas evita una regla que cubre en silencio más de lo previsto.

El error que hay que evitar es suponer que un lanzador define al propietario. Un navegador al que la sesión de otro usuario le pasa una URL no ha creado sockets bajo el UID 1500, y ninguna regla moverá el tráfico que genera.

La tabla, la regla y el guardián

Tras comprobar las reglas existentes y elegir números de tabla y prioridad no usados, la disposición es corta: una ruta por defecto en una tabla dedicada que lleva la dirección de origen del túnel, una regla que envía las consultas de la cuenta a esa tabla y una regla terminante que bloquea el respaldo. Escrito, eso es un reemplazo de ruta idempotente, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, seguido de ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

El guardián es ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, y importa más de lo que su longitud sugiere. Sin él, una ruta ausente en la tabla 51820 cae al enlace ascendente ordinario y la cuenta filtra en silencio tráfico que la política debía capturar. Con él, el mismo fallo se convierte en un tiempo de espera, es decir, bloqueo en lugar de respaldo.

Mantenga la regla normal de dirección local por delante de estas, y decida conscientemente si las excepciones de LAN o de gestión van antes de la tabla seleccionada. Una ruta por defecto encontrada allí no consulta después main en busca de una ruta LAN más específica, lo que sorprende a quienes esperan que la coincidencia de prefijo más largo se aplique entre tablas. Escriba la lista de excepciones prevista en la nota de cambio mientras el razonamiento aún está fresco.

Lo que deja fuera el enrutamiento por UID: DNS

El demonio resolutor abre sus sockets ascendentes bajo su propio UID, así que seleccionar 1500 no mueve esas consultas a la tabla 51820. La integración de DNS es una decisión aparte: apunte la cuenta a un resolutor accesible por el túnel, o acepte que la resolución de nombres sigue la ruta del host mientras el tráfico no.

Una consulta por loopback a un stub local no es prueba de que la consulta ascendente usara la ruta del navegador, ni lo es una carga de página correcta desde la caché.

IPv6 necesita su propia frase en el diseño

Las reglas anteriores solo cubren IPv4. Si el requisito es un túnel IPv4 sin IPv6 directo desde esta cuenta, añada una regla terminante revisada como ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, y luego compruebe las reglas IPv6 anteriores más las excepciones de loopback que quiera conservar.

Bloquear IPv6 directo no es tunelización de doble pila; es una frontera. Llamarlo tunelización confundirá a la siguiente persona que lea la política, y la confusión aparecerá como un ticket de soporte sobre un sitio IPv6 roto.

Verifique con la cuenta real y luego asuma el ciclo de vida

Compare consultas: ip -4 route get 198.51.100.25 uid 1500 contra el mismo destino con un UID ordinario. Luego haga una petición permitida bajo la cuenta dedicada y compruebe la dirección de origen que ve el extremo remoto. Una dirección de origen preferida no es source NAT, y no anulará una aplicación que enlaza otra cosa. Si ambas consultas devuelven la misma ruta, la regla no hace lo que usted cree.

Mantenga la tabla, las reglas y la vida de la ruta del túnel bajo un solo propietario, pruebe una reconexión y una pérdida de túnel, y al retirar la política elimine solo sus entradas exactas. Un namespace sigue disponible si interfaces separadas y estado separado son lo que realmente necesita.