Regra de mangle IPTable para marcar o tráfego da tabela de rotas

1

Estou tentando configurar um roteador VPN usando o Ubuntu Server 16.04.

Estou configurando o roteador para ser seguro, para que nenhum tráfego possa vazar ou, se a VPN falhar, ele falhará.

O roteador tem uma interface sem fio (wlp2s0) que se conecta à minha rede sem fio para conectividade com a Internet e uma interface ethernet (enp1s0) onde eu conecto meu laptop.

O ideal é que o openvpn seja executado na inicialização e use wlp2s0 para criar uma interface tun0 e, em seguida, algumas regras de iptable encaminhariam o tráfego enp1s0 para tun0.

Para atingir meu objetivo de evitar o vazamento de tráfego, fiz um script de inicialização que libera todas as rotas e, em seguida, adiciona uma rota de sub-rede local para wlp2s0 à tabela MAIN. Também adiciona uma rota padrão a wlp2s0 para a tabela 100.

Eu adicionei uma regra de mangle iptables que marca o tráfego openvpn e, em seguida, uma regra fw que faz com que o tráfego marcado use a tabela 100.

Então, basicamente, eu só quero que o tráfego openvpn possa usar a rota padrão sem fio (tabela 100) para que possa criar o túnel. Todo o outro tráfego será local ou através do túnel.

Meu script de inicialização funciona bem, ele cria as rotas adequadas na inicialização. Minhas regras de iptable e regra fw parecem estar corretas também.

A questão é que o tráfego openvpn simplesmente não parece atingir a regra mangle do iptables.

Regra iptable que marca o tráfego openvpn.

iptables -t mangle -A OUTPUT -p tcp --dport 501 -j MARK --set-mark 2

Script de inicialização.

ip route add table 100 default via 192.168.0.1 dev wlp2s0
ip rule add fwmark 0x2 table 100
ip route flush table main
ip route add 192.168.0.0/24 dev wlp2s0

Saída de vários comandos que a maioria de vocês solicitará

administrator@ubuntu-svr:~$ sudo iptables -t mangle -L -v
Chain PREROUTING (policy ACCEPT 6153 packets, 1859K bytes)
 pkts bytes target     prot opt in     out     source               destination                  

Chain INPUT (policy ACCEPT 1961 packets, 297K bytes)
 pkts bytes target     prot opt in     out     source               destination       

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination        

Chain OUTPUT (policy ACCEPT 1348 packets, 128K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 MARK       tcp  --  any    any     anywhere             anywhere             tcp dpt:501 MARK set 0x2                  

Chain POSTROUTING (policy ACCEPT 1348 packets, 128K bytes)
 pkts bytes target     prot opt in     out     source               destination         

administrator@ubuntu-svr:~$ ip rule
0:  from all lookup local 
32765:  from all fwmark 0x2 lookup 100 
32766:  from all lookup main 
32767:  from all lookup default 

administrator@ubuntu-svr:~$ ip route show table main
192.168.0.0/24 dev wlp2s0  scope link 

administrator@ubuntu-svr:~$ ip route show table 100
default via 192.168.0.1 dev wlp2s0 

administrator@ubuntu-svr:~$ ip route get 8.8.8.8 mark 0x2
8.8.8.8 via 192.168.0.1 dev wlp2s0  src 192.168.0.209  mark 2

Assim, da saída acima, você pode ver que as rotas adequadas, a regra de mangle iptable e a regra fw estão todas no lugar.

Quando eu emito o comando "ip route get", você pode ver que a rota correta está selecionada para o tráfego marcado.

No entanto, a regra mangle do iptables NÃO está sendo atingida. Eu emiti "telnet 8.8.8.8 501" e ainda a regra não é atingida! Mesmo que o tráfego seja gerado localmente e acesse o tcp 501, que deve corresponder à regra.

O tráfego openvpn é gerado a partir do próprio roteador. Por, a página man do iptables a cadeia OUTPUT para mangle é para modificar a decisão PREROUTE do tráfego LOCALMENTE gerado.

Eu estou completamente perdido aqui. Li outras mensagens de pessoas com problemas semelhantes, mas não consigo encontrar uma solução.

    
por Matt M 04.06.2017 / 05:28

1 resposta

0

O problema é uma rota padrão ausente na tabela main . Isso não pode ser detectado ao verificar com ip route get ... mark ... porque o caminho inteiro está em curto-circuito com a "solução" entregue diretamente.

Como não há rota padrão, uma pesquisa de rota para 8.8.8.8 falha com "A rede está inacessível" antes que o pacote tenha a chance de alcançar a cadeia de saída mangle de forma alguma:

Adicionar qualquer rota padrão na tabela main (mesmo usando um roteador não existente desde que seja uma sintaxe válida) permitiria o fluxo pretendido:

  • o pacote é gerado,
  • a rota é verificada pela primeira vez na tabela ip rule , considerada existente,
  • percorre a cadeia de SAÍDA mangle, herda a marca,
  • é reencaminhado (reencaminhamento no Fluxo de pacotes no Netfilter e na rede geral ) e, assim, aciona pela segunda vez uma pesquisa na tabela ip rule ,
  • agarra a pesquisa antecipada na tabela 100 e obtém sua rota final " via 192.168.0.1 dev wlp2s0 ".

Então, pegando na LAN um IP que não pertence a nenhum host , digamos 192.168.0.250 e adicionando-o no script, assim:

ip route add table 100 default via 192.168.0.1 dev wlp2s0
ip rule add fwmark 0x2 table 100
ip route flush table main
ip route add 192.168.0.0/24 dev wlp2s0
ip route add default via 192.168.0.250 dev wlp2s0

resolverá o teste feito na pergunta:

  • qualquer conexão não feita com a porta tcp de destino 501 acionará solicitações ARP para 192.168.0.250, que deve expirar 3 segundos depois com a mensagem "Nenhuma rota para hospedar" (em vez de "Rede inacessível")
  • qualquer conexão feita com a porta tcp destino 501 irá (resolver a requisição ARP e) ir via 192.168.0.1
por 12.04.2018 / 19:53