Até agora eu criei com sucesso um link virtual entre o servidor A e o servidor B usando um túnel openvpn não criptografado. Eu estou tentando rotear alguns do tráfego do servidor B através do servidor A. O servidor B tem 5 IPs externos e eu gostaria de adicionar 5 IPs VPN locais que redirecionam o tráfego para 5 IPs no servidor A, o que daria ao servidor B 10 IPs de saída distintos para o mundo. Obviamente, alguns roteiros precisam ser feitos em ambos os servidores, mas eu não vou chegar a lugar algum depois de um dia pesquisando e lendo.
eu fiz
ip route add default via 10.0.0.2 dev tun0 table vpn_table
ip rule add from 10.0.0.1/32 table vpn_table
ip rule add to 10.0.0.2/32 table vpn_table
ip route flush cache
no servidor B, e o mesmo no servidor A, mas com IPs trocados. No entanto, no servidor B quando eu faço wget --bind-address=10.0.0.1 somewebsite não está funcionando, eu acho que porque o servidor A não sabe o que fazer com o pedido.
Alguém poderia me apontar na direção certa?
EDITAR
Alguém sugeriu que o servidor A não precisa de regras de ip, então a situação que tenho agora é:
Acho que ainda estou perdendo algumas informações de roteamento no servidor A. Isso é o que o tcpdump no servidor A gera quando eu faço wget --bind-address=10.0.0.1 http://www.cnn.com no servidor B:
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
07:11:58.787908 IP 10.0.0.1.42802 > 157.166.248.10.80: S 2416144580:2416144580(0) win 14600 <mss 1410,sackOK,timestamp 858359606 0,nop,wscale 7>
07:11:59.786129 IP 10.0.0.1.42802 > 157.166.248.10.80: S 2416144580:2416144580(0) win 14600 <mss 1410,sackOK,timestamp 858359856 0,nop,wscale 7>
07:12:01.788535 IP 10.0.0.2 > 10.0.0.1: ICMP host 157.166.248.10 unreachable, length 68
07:12:01.788545 IP 10.0.0.2 > 10.0.0.1: ICMP host 157.166.248.10 unreachable, length 68
Wget no servidor B diz
Connecting to www.cnn.com (www.cnn.com)|157.166.248.11|:80... failed: No route to host.
EDIT 5/19/2014
Adicionado SNAT no servidor A, agora tcpdump no servidor A está me dando (93.184.216.119 = www.exemplo.com, 1.2.3.4 = IP externo do servidor A que agora é a fonte de pacotes vindos de 10.0.0.1)
09:29:44.114475 IP 10.0.0.1.54691 > 93.184.216.119.80: S 717252699:717252699(0) win 14600 <mss 1410,sackOK,timestamp 903625938 0,nop,wscale 7>
09:29:45.113546 IP 10.0.0.1.54691 > 93.184.216.119.80: S 717252699:717252699(0) win 14600 <mss 1410,sackOK,timestamp 903626188 0,nop,wscale 7>
09:29:47.116587 IP 1.2.3.4 > 10.0.0.1: ICMP host 93.184.216.119 unreachable, length 68
09:29:47.116668 IP 1.2.3.4 > 10.0.0.1: ICMP host 93.184.216.119 unreachable, length 68
09:29:47.119289 IP 10.0.0.1.54691 > 93.184.216.119.80: S 717252699:717252699(0) win 14600 <mss 1410,sackOK,timestamp 903626689 0,nop,wscale 7>
09:29:50.120591 IP 1.2.3.4 > 10.0.0.1: ICMP host 93.184.216.119 unreachable, length 68
Portanto, parece que o SNAT no servidor A está funcionando, mas de alguma forma não consegue se conectar ao site solicitado. Lista de iptables do servidor:
SNAT all -- 10.0.0.1 anywhere to:1.2.3.4
Servidor Uma lista de regras de IP:
0: from all lookup local
32766: from all lookup main
32767: from all lookup default
Parte do servidor A 'route -n':
Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.1 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
O gateway que está sendo 0.0.0.0 tem algo a ver com isso?
Existem vários problemas:
Não faz sentido rotear os pacotes de onde eles vêm. Ou seja o
ip rule add from 10.0.0.1/32 table vpn_table
deve ser deixado de fora no servidor A ( ip rule add to... também não é necessário); servidor A tem roteamento "normal". Você precisa dessa regra no servidor B (para o endereço IP de B).
Você precisa de SNAT no servidor A. Algo como
iptables -t nat -A POSTROUTING -s 10.0.0.1 -j SNAT --to-source 1.2.3.4
Tags networking openvpn