Encaminhar uma conta Linux pelo OpenVPN com uma regra UID

O encaminhamento por conta encaixa quando cada socket IPv4 pertencente a um utilizador Linux deve sair por um túnel existente, e não encaixa quando precisa de isolamento ao nível do programa. Seleciona por UID, por isso tudo o que correr com essa conta entra no âmbito, incluindo a tarefa em lote de que se esqueceu. Resolva essa questão antes de tocar numa única ip rule.

O exemplo abaixo assume uma conta de navegador dedicada no UID 1500, um dispositivo de túnel tun-office com o endereço local 10.80.0.11 e uma VPN que permite os destinos em questão. O próprio daemon corre fora desse UID.

Três condições que escolhem o mecanismo

Escolha uma regra UID quando a identidade que faz o trabalho é a conta, quando mover todo o seu tráfego é aceitável e quando um namespace seria mais pesado do que a tarefa merece. Escolha um namespace de rede quando a carga de trabalho precisa das suas próprias interfaces, resolvedor e tabela de encaminhamento. Escolha um proxy ou uma ligação por processo quando exatamente uma aplicação deve mudar enquanto o resto da sessão fica no caminho local. Pôr estas três por escrito evita uma regra que cobre em silêncio mais do que o previsto.

O erro a evitar é assumir que o lançador define o proprietário. Um navegador a quem a sessão de outro utilizador passou um URL não criou sockets sob o UID 1500, e nenhuma regra moverá o tráfego que ele gera.

A tabela, a regra e a guarda

Depois de verificar as regras existentes e escolher números de tabela e de prioridade não usados, a disposição é curta: uma rota predefinida numa tabela dedicada que leva o endereço de origem do túnel, uma regra que envia as consultas da conta para essa tabela e uma regra terminal que bloqueia o recurso. Escrito, isso é uma substituição de rota 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.

A guarda é ip -4 rule add priority 12101 uidrange 1500-1500 unreachable, e conta mais do que o seu comprimento sugere. Sem ela, uma rota em falta na tabela 51820 cai no uplink comum e a conta fuga silenciosamente tráfego que a política devia capturar. Com ela, a mesma falha torna-se um tempo limite, ou seja, bloqueio em vez de recurso.

Mantenha a regra normal de endereço local à frente destas, e decida conscientemente se as exceções de LAN ou de gestão vêm antes da tabela escolhida. Uma rota predefinida encontrada ali não consulta depois main para uma rota LAN mais específica, o que surpreende quem espera que a correspondência do prefixo mais longo se aplique entre tabelas. Escreva a lista de exceções prevista na nota de alteração enquanto o raciocínio ainda está fresco.

O que o encaminhamento por UID deixa de fora: DNS

O daemon resolvedor abre os seus sockets a montante sob o seu próprio UID, por isso selecionar 1500 não move essas consultas para a tabela 51820. A integração de DNS é uma decisão separada: aponte a conta para um resolvedor alcançável pelo túnel, ou aceite que a resolução de nomes segue o caminho do anfitrião e o tráfego não.

Uma consulta por loopback a um stub local não é prova de que a consulta a montante usou a rota do navegador, nem o é um carregamento de página bem-sucedido a partir da cache.

IPv6 precisa da sua própria frase no desenho

As regras acima cobrem apenas IPv4. Se o requisito é um túnel IPv4 sem IPv6 direto desta conta, acrescente uma regra terminal revista como ip -6 rule add priority 12101 uidrange 1500-1500 unreachable, e depois verifique as regras IPv6 anteriores e as exceções de loopback que quer manter.

Bloquear IPv6 direto não é tunelamento de dupla pilha; é uma fronteira. Chamar-lhe tunelamento vai confundir a próxima pessoa que ler a política, e a confusão vai aparecer como um pedido de apoio sobre um site IPv6 avariado.

Verifique com a conta real e depois assuma o ciclo de vida

Compare consultas: ip -4 route get 198.51.100.25 uid 1500 contra o mesmo destino com um UID comum. Depois faça um pedido permitido sob a conta dedicada e verifique o endereço de origem que a extremidade remota vê. Um endereço de origem preferido não é source NAT, e não se sobrepõe a uma aplicação que liga outra coisa. Se ambas as consultas devolverem o mesmo caminho, a regra não está a fazer o que pensa.

Mantenha a tabela, as regras e a vida da rota do túnel sob um único proprietário, teste uma reconexão e uma perda de túnel, e ao retirar a política elimine apenas as suas entradas exatas. Um namespace continua disponível se interfaces separadas e estado separado são o que realmente precisa.