iptables regra (s) para enviar tráfego openvpn de clientes através de um túnel sshuttle?

Question

Eu tenho uma caixa do Ubuntu 12.04 com o OpenVPN. A VPN está funcionando como esperado - os clientes podem se conectar, navegar na Web, etc. O IP do servidor OpenVPN é 10.8.0.1 no tun0.

Na mesma caixa, eu posso usar o sshuttle para entrar em outra rede para acessar um servidor da Web no 10.10.0.9. sshuttle faz sua mágica usando os seguintes comandos iptables:

iptables -t nat -N sshuttle-12300
iptables -t nat -F sshuttle-12300
iptables -t nat -I OUTPUT 1 -j sshuttle-12300
iptables -t nat -I PREROUTING 1 -j sshuttle-12300
iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.10.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42
iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp

É possível encaminhar o tráfego de clientes OpenVPN através do túnel sshuttle para o servidor Web remoto? Eu gostaria de poder configurar qualquer tunelamento complicado no servidor e ter relativamente Clientes "burros" (iPad, etc.) podem acessar os servidores remotos via OpenVPN.

Abaixo está um diagrama básico do cenário:

[Editar: saída adicionada da caixa do OpenVPN]

$ sudo iptables -nL -v -t nat
Chain PREROUTING (policy ACCEPT 1498 packets, 252K bytes)
 pkts bytes target     prot opt in     out     source               destination
 1512  253K sshuttle-12300  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain INPUT (policy ACCEPT 322 packets, 58984 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 584 packets, 43241 bytes)
 pkts bytes target     prot opt in     out     source               destination
  587 43421 sshuttle-12300  all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain POSTROUTING (policy ACCEPT 589 packets, 43595 bytes)
 pkts bytes target     prot opt in     out     source               destination
 1175 76298 MASQUERADE  all  --  *      eth0    10.8.0.0/24          0.0.0.0/0

Chain sshuttle-12300 (2 references)
 pkts bytes target     prot opt in     out     source               destination
   17  1076 REDIRECT   tcp  --  *      *       0.0.0.0/0            10.10.0.0/24       TTL match TTL != 42 redir ports 12300
    0     0 RETURN     tcp  --  *      *       0.0.0.0/0            127.0.0.0/8


$ sudo iptables -nL -v -t filter
Chain INPUT (policy ACCEPT 97493 packets, 30M 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
 131K  109M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
 1370 89160 ACCEPT     all  --  *      *       10.8.0.0/24          0.0.0.0/0
    0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            reject-with icmp-port-unreachable

[Edit 2: mais saída do servidor OpenVPN]

$ netstat -r
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
default         192.168.1.1     0.0.0.0         UG        0 0          0 eth0
10.8.0.0        10.8.0.2        255.255.255.0   UG        0 0          0 tun0
10.8.0.2        *               255.255.255.255 UH        0 0          0 tun0
192.168.1.0     *               255.255.255.0   U         0 0          0 eth0

[Editar 3: ainda mais saídas de depuração] O encaminhamento de IP parece estar habilitado corretamente no servidor OpenVPN:

# find /proc/sys/net/ipv4/conf/ -name forwarding -ls -execdir cat {} \; 
18926 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/all/forwarding 
1 
18954 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/default/forwarding 
1 
18978 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/eth0/forwarding 
1 
19003 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/lo/forwarding 
1 
19028 0 -rw-r--r-- 1 root root 0 Mar 5 13:31 /proc/sys/net/ipv4/conf/tun0/forwarding 
1

Tabela de roteamento do cliente:

$ netstat -r 
Routing tables 

Internet: 
Destination Gateway Flags Refs Use Netif Expire 
0/1 10.8.0.5 UGSc 8 48 tun0 
default 192.168.1.1 UGSc 2 1652 en1 
10.8.0.1/32 10.8.0.5 UGSc 1 0 tun0 
10.8.0.5 10.8.0.6 UHr 13 0 tun0 
10.10.0/24 10.8.0.5 UGSc 0 0 tun0 
<snip>

Traceroute do cliente:

$ traceroute 10.10.0.9 
traceroute to 10.10.0.9 (10.10.0.9), 64 hops max, 52 byte packets 
1 10.8.0.1 (10.8.0.1) 5.403 ms 1.173 ms 1.086 ms 
2 192.168.1.1 (192.168.1.1) 4.693 ms 2.110 ms 1.990 ms 
3 l100.my-verizon-garbage (client-ext-ip) 7.453 ms 7.089 ms 6.248 ms 
4 * * * 
5 10.10.0.9 (10.10.0.9) 14.915 ms !N * 6.620 ms !N

    

Answer 1

Algumas perguntas para esclarecer, basicamente, você quer que os clientes openvpn tenham acesso ao que o servidor openvpn faz, principalmente a sub-rede do servidor ssh de destino (10.10.0.1). Correto?

O servidor openvpn tem acesso a tudo o que deveria? Se assim for, eu acredito que é simplesmente uma questão de roteamento, dizendo ao cliente openvpn, que qualquer coisa indo para 10.10.0.1/24 rotas através de 10.8.0.1.

Se eu estiver sentindo falta de algo, por favor me avise.

Se não, você pode apenas dizer ao openvpn para rotear os gateways atrás dele, e empurrar essas rotas para o cliente.

push "route 10.10.0.0 255.255.255.0"

Certifique-se de deixar as caixas 10.10.0.0 saberem o caminho de volta para os clientes. Além disso, não se esqueça de permitir o encaminhamento de ip