iptables pacotes sem uid

Question

Estou tentando rotear todo o tráfego de um usuário específico na máquina através da VPN. Eu faço isso criando uma regra iptables com "-m owner --uid-owner" para marcar os pacotes do usuário e então usar uma tabela de roteamento deste pacote. Para garantir que tudo seja redirecionado, também tenho um "-m proprietário! --Uid-owner 0-99999 -j DROP" para descartar todos os pacotes de rede "anônimos" para o caso.

Na maioria dos casos, funciona bem, no entanto, recebo alguns pacotes sem uid, embora claramente originados do usuário; observou isso acontecendo raramente para algumas conexões SSL. Significa que estou fazendo "wget link " e vejo no log que o pacote para o IP do google cai porque é emitido sem uid.

Meu entendimento é que o kernel pode às vezes, por algum motivo, "enfileirar" o pedido e, em seguida, processá-lo de forma assíncrona, sem definir o uid para o pacote. É possível rastrear a fonte real desses pacotes neste caso? Não consigo encaminhar todos os pacotes "anônimos" por meio da VPN, pois presumo que isso também aconteça para outros usuários.

Obrigado.

    

Answer 1

Alguns pacotes genuinamente não pertencem a nenhum usuário, apenas ao kernel:

• pacotes roteados
• pacotes gerados pelo kernel em resposta a eventos externos. Ex: ao receber um echo-request, o kernel responderá com uma resposta echo-icmp.
• provavelmente todos os pacotes do iptables '-j REJECT.
• ...

Agora, sobre os pacotes dos quais você está falando: de testes feitos com pacotes de marcação com e sem proprietário, eles parecem pertencer à% final% deACK no final da negociação de fim de comunicação FIN como o RST quando a conexão é cortada de forma mais abrupta. Meu palpite é que em ambos os casos, o kernel já parou de considerar a conexão pertencia ao usuário porque ele está se desintegrando, embora isso nem sempre aconteça para o ACK (talvez quando misturado com PSH e dados finais?). / p>

UPDATE: a resposta para " Iptables: correspondência de tráfego de saída com conntrack e proprietário. Funciona com quedas estranhas " fornece informações mais detalhadas sobre o assunto.

Se você não quiser perder esses pacotes e ainda quiser usar MARK para a decisão, ainda pode contar com CONNMARK do Netfilter porque o último pacote, mesmo sem proprietário, ainda faz parte da mesma conexão. Por exemplo, testando com essas regras adaptadas dos exemplos no link:

#!/bin/sh

iptables -t mangle -N connmark_test
iptables -t mangle -N connmark_log
iptables -t mangle -A connmark_test -j CONNMARK --restore-mark
iptables -t mangle -A connmark_test -m mark ! --mark 0 -j RETURN
iptables -t mangle -A connmark_test -m mark --mark 0 -m owner --uid-owner 0-99999 -p tcp -j MARK --set-mark 1
iptables -t mangle -A connmark_test -m mark --mark 0 -m owner --uid-owner 0-99999        -j MARK --set-mark 2
iptables -t mangle -A connmark_test -m mark --mark 0                              -p tcp -j MARK --set-mark 3
iptables -t mangle -A connmark_test -m mark --mark 0                                     -j MARK --set-mark 4
iptables -t mangle -A connmark_test -j CONNMARK --save-mark
iptables -t mangle -A connmark_log -m owner --uid-owner 0-99999 -j LOG --log-prefix "with_owner "
iptables -t mangle -A connmark_log -m owner ! --uid-owner 0-99999 -j LOG --log-prefix "  NO_owner "
iptables -t mangle -A POSTROUTING -j connmark_test
iptables -t mangle -A POSTROUTING -m mark ! --mark 0 -j connmark_log

Eu pude ver com curl -s -L https://google.com/ >/dev/null (que faz duas conexões) que o ACK ou RST da conexão final, que geralmente falha na correspondência do proprietário, ainda tem um connmark, pois há MARK=0x1 :

[14668.179780] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=53193 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK PSH URGP=0 MARK=0x1 
[14668.181740] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53194 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK FIN URGP=0 MARK=0x1 
[14668.181914]   NO_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.209.238 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=53195 DF PROTO=TCP SPT=33472 DPT=443 WINDOW=339 RES=0x00 ACK URGP=0 MARK=0x1 
[14668.182667] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=83 TOS=0x00 PREC=0x00 TTL=64 ID=58460 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=520 RES=0x00 ACK PSH URGP=0 MARK=0x1 
[14668.184588] with_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=58461 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=520 RES=0x00 ACK RST URGP=0 MARK=0x1 
[14668.201316]   NO_owner IN= OUT=eth0 SRC=10.0.3.66 DST=216.58.198.67 LEN=40 TOS=0x00 PREC=0x00 TTL=64 ID=20784 DF PROTO=TCP SPT=33210 DPT=443 WINDOW=0 RES=0x00 RST URGP=0 MARK=0x1 

Última observação: não se esqueça de que a atividade de um usuário pode disparar pacotes de outro usuário: por exemplo, solicitações DNS para um servidor DNS local, que emitirá solicitações DNS com pacotes de propriedade do usuário que está executando o servidor DNS.