Encamiñar unha conta Linux por OpenVPN cunha regra UID

O encamiñamento por conta encaixa cando cada socket IPv4 propiedade dun usuario de Linux debe saír por un túnel existente, e non encaixa cando precisa illamento a nivel de programa. Selecciona por UID, así que todo o que se execute con esa conta entra no alcance, incluída a tarefa por lotes que esqueceu. Resolva esa cuestión antes de tocar unha soa ip rule.

O exemplo seguinte supón unha conta de navegador dedicada no UID 1500, un dispositivo de túnel tun-office con enderezo local 10.80.0.11 e unha VPN que permite os destinos en cuestión. O propio demonio execútase fóra dese UID.

Tres condicións que elixen o mecanismo

Elixa unha regra UID cando a identidade que fai o traballo sexa a conta, cando mover todo o seu tráfico sexa aceptable e cando un namespace fose máis pesado do que a tarefa merece. Elixa un namespace de rede cando a carga de traballo necesite as súas propias interfaces, resolvedor e táboa de encamiñamento. Elixa un proxy ou unha vinculación por proceso cando exactamente unha aplicación deba moverse mentres o resto da sesión queda na ruta local. Escribir esas tres cousas evita unha regra que cobre en silencio máis do previsto.

O erro que hai que evitar é supoñer que un lanzador define o propietario. Un navegador ao que a sesión doutro usuario lle pasa un URL non creou sockets baixo o UID 1500, e ningunha regra moverá o tráfico que xera.

A táboa, a regra e o gardián

Tras comprobar as regras existentes e escoller números de táboa e prioridade non usados, a disposición é curta: unha ruta por defecto nunha táboa dedicada que leva o enderezo de orixe do túnel, unha regra que envía as consultas da conta a esa táboa e unha regra terminante que bloquea o retroceso. Escrito, iso é unha substitución de ruta idempotente, ip -4 route replace default dev tun-office src 10.80.0.11 table 51820, seguida de ip -4 rule add priority 12100 uidrange 1500-1500 lookup 51820.

O gardián é ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, e importa máis do que suxire a súa lonxitude. Sen el, unha ruta ausente na táboa 51820 cae á ligazón ascendente ordinaria e a conta filtra en silencio tráfico que a política debía capturar. Con el, o mesmo fallo convértese nun tempo de espera, é dicir, bloqueo en lugar de retroceso.

Manteña a regra normal de enderezo local por diante destas, e decida conscientemente se as excepcións de LAN ou de xestión van antes da táboa seleccionada. Unha ruta por defecto atopada alí non consulta despois main en busca dunha ruta LAN máis específica, o que sorprende a quen espera que a coincidencia de prefixo máis longo se aplique entre táboas. Escriba a lista de excepcións prevista na nota de cambio mentres o razoamento aínda está fresco.

O que deixa fóra o encamiñamento por UID: DNS

O demonio resolvedor abre os seus sockets ascendentes baixo o seu propio UID, así que seleccionar 1500 non move esas consultas á táboa 51820. A integración de DNS é unha decisión á parte: apunte a conta a un resolvedor accesible polo túnel, ou acepte que a resolución de nomes segue a ruta do host mentres o tráfico non.

Unha consulta por loopback a un stub local non é proba de que a consulta ascendente usase a ruta do navegador, nin o é unha carga de páxina correcta desde a caché.

IPv6 necesita a súa propia frase no deseño

As regras anteriores só cobren IPv4. Se o requisito é un túnel IPv4 sen IPv6 directo desde esta conta, engada unha regra terminante revisada como ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, e logo comprobe as regras IPv6 anteriores máis as excepcións de loopback que queira conservar.

Bloquear IPv6 directo non é tunelización de dobre pila; é unha fronteira. Chamarlle tunelización confundirá á seguinte persoa que lea a política, e a confusión aparecerá como un ticket de asistencia sobre un sitio IPv6 roto.

Verifique coa conta real e logo asuma o ciclo de vida

Compare consultas: ip -4 route get 198.51.100.25 uid 1500 contra o mesmo destino cun UID ordinario. Logo faga unha petición permitida baixo a conta dedicada e comprobe o enderezo de orixe que ve o extremo remoto. Un enderezo de orixe preferido non é source NAT, e non anulará unha aplicación que enlaza outra cousa. Se ambas as consultas devolven a mesma ruta, a regra non fai o que vostede cre.

Manteña a táboa, as regras e a vida da ruta do túnel baixo un único propietario, probe unha reconexión e unha perda de túnel, e ao retirar a política elimine só as súas entradas exactas. Un namespace segue dispoñible se interfaces separadas e estado separado son o que realmente necesita.