Roteamento OpenVPN + iptables / NAT

5

Estou tentando configurar uma VPN OpenVPN, que transportará alguns (mas não todos) tráfego dos clientes para a Internet através do servidor OpenVPN.

Meu servidor OpenVPN tem um IP público em eth0 e está usando tap0 para criar uma rede local, 192.168.2.x. Eu tenho um cliente que se conecta a partir do IP local 192.168.1.101 e obtém VPN IP 192.168.2.3.

No servidor, eu corri:

iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

No cliente, o padrão permanece para rotear via 192.168.1.1. Para apontá-lo para 192.168.2.1 para HTTP, eu corri

ip rule add fwmark 0x50 table 200
ip route add table 200 default via 192.168.2.1
iptables -t mangle -A OUTPUT -j MARK -p tcp --dport 80 --set-mark 80

Agora, se eu tentar acessar um site no cliente (por exemplo, wget google.com), ele ficará suspenso. No servidor, posso ver

$ sudo tcpdump -n -i tap0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap0, link-type EN10MB (Ethernet), capture size 96 bytes
05:39:07.928358 IP 192.168.1.101.34941 > 74.125.67.100.80: S 4254520618:4254520618(0) win 5840 <mss 1334,sackOK,timestamp 558838 0,nop,wscale 5>
05:39:10.751921 IP 192.168.1.101.34941 > 74.125.67.100.80: S 4254520618:4254520618(0) win 5840 <mss 1334,sackOK,timestamp 559588 0,nop,wscale 5>

Onde 74.125.67.100 é o IP obtido para google.com.

Por que o MASQUERADE não está funcionando? Mais precisamente, vejo que a fonte aparecendo como 192.168.1.101 - não deveria haver algo para indicar que veio da VPN?

Editar: algumas rotas [do cliente]

$ ip route show table main
192.168.2.0/24 dev tap0  proto kernel  scope link  src 192.168.2.4
192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.101  metric 2
169.254.0.0/16 dev wlan0  scope link  metric 1000
default via 192.168.1.1 dev wlan0  proto static

$ ip route show table 200
default via 192.168.2.1 dev tap0
    
por Mikeage 17.05.2009 / 04:41

3 respostas

1

Duas coisas estavam erradas:

Primeiro, no cliente, eu precisava de SNAT a origem para o IP real.

Em segundo lugar, o filtro de caminho inverso estava bloqueando os pacotes de retorno, pois eles achavam que eram falsificados. echo 0 > /proc/sys/net/ipv4/conf/tun0/rp_filter corrigido que

    
por 25.05.2009 / 10:14
3

Você pode postar a saída de ip main show table route e ip route show table 200 ? Eu suspeito que você está perdendo algumas rotas na sua mesa '200'. Sua tabela de rota '200' deve ter praticamente as mesmas rotas que a tabela 'main', sendo a única diferença a rota padrão.

Eu vejo que você atualizou e acredito que minha sugestão original estava correta. Observe como sua tabela principal tem a rota 'link de escopo' para sua rede local e o link vpn? Essas rotas também devem ser adicionadas à tabela '200'.

Tente executar esses comandos além dos outros comandos que você usa.

ip route add 192.168.2.0/24 dev tap0  proto kernel  scope link  src 192.168.2.4 table 200
ip route add 192.168.1.0/24 dev wlan0  proto kernel  scope link  src 192.168.1.101  metric 2 table 200
ip route flush cache

Se você quiser criar scripts para a criação dessas rotas, você pode usar isso. Ele copiará todas as rotas de 'link de escopo' da tabela de rotas principal para sua outra tabela.

#!/bin/bash
IFACE=wlan0
RT=200
/sbin/ip route list scope link table main proto kernel dev ${IFACE} \
| while read ROUTE ; do
    # and add that route to all the tables mentioned in the rrtables option
    # in the interfaces file
    /sbin/ip route add table ${RT} scope link proto kernel dev ${IFACE} ${ROUTE}
done

Outra atualização. Acabei de notar que perdi algo bastante óbvio antes.

Sua instrução MASQ parece estar funcionando na eth0. Nas tabelas de rotas que você postou, seu dispositivo de saída não é eth0. Em vez disso.

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Você provavelmente deve usar apenas uma declaração como essa.

iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
    
por 17.05.2009 / 05:06
0

Experimente o servidor:

echo 1 > /proc/sys/net/ipv4/ip_forward

Isso, penso eu, irá ativá-lo temporariamente. Se funcionar, adicione:

net.ipv4.conf.default.forwarding=1 

para o seu /etc/sysctl.conf para torná-lo permanente.

    
por 17.05.2009 / 17:21