it-swarm-pt.tech

OpenVPN + iptables / NAT

Estou tentando configurar uma VPN OpenVPN, que transportará parte do tráfego (mas não todo) dos clientes para a Internet por meio do servidor OpenVPN.

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

No servidor, executei:

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, executei

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 (digamos, wget google.com), ele simplesmente travará lá. 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 origem aparece como 192.168.1.101 - não deveria haver algo para indicar que veio da VPN?

Edit: 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
5
Mikeage

Duas coisas estavam erradas:

Primeiro, no cliente, eu precisava SNAT da fonte para o IP real.

Em segundo lugar, o filtro de caminho reverso estava bloqueando os pacotes de retorno, pois pensava que estavam falsificados. echo 0 > /proc/sys/net/ipv4/conf/tun0/rp_filter consertou isso

1
Mikeage

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


Vejo que você atualizou e acredito que minha sugestão original estava correta. Observe como sua tabela principal tem a rota de 'link de escopo' para sua rede local e o link de 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 um script para a criação dessas rotas, poderá usar isso. Ele copiará todas as rotas de 'link de escopo' da tabela de rota 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 deixei passar algo bastante óbvio antes.

Sua declaração MASQ parece estar funcionando em eth0. A partir das tabelas de rota 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 apenas usar uma declaração como esta.

iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE
3
Zoredache

Experimente no servidor:

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

Isso, eu acho, vai habilitá-lo temporariamente. Se funcionar, adicione:

net.ipv4.conf.default.forwarding=1 

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

0
Neobyte