Estou executando um servidor OpenVPN em um VPS com o Debian 5 e um cliente OpenVPS no Ubuntu 11.04 Desktop. Eu quero todo o tráfego de saída do cliente para ser tunnelled embora o servidor VPN.
Eu sou capaz de iniciar uma conexão do cliente para o servidor e executar ping com êxito entre eles, mas quando tento acessar endereços IP externos do cliente, não obtenho êxito.
Por exemplo, ao pingar o google por IP:
ping -n 74.125.91.106
PING 74.125.91.106 (74.125.91.106) 56(84) bytes of data.
^C
--- 74.125.91.106 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6048ms
No lado do servidor, vejo os pedidos de ping a chegar ao túnel, mas sem respostas de volta:
tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 65535 bytes
21:24:59.384736 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7537, seq 1, length 64
21:25:00.391970 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7537, seq 2, length 64
21:25:01.400394 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7537, seq 3, length 64
21:25:02.408914 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7537, seq 4, length 64
21:25:03.416378 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7537, seq 5, length 64
21:25:04.424289 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7537, seq 6, length 64
21:25:05.431804 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7537, seq 7, length 64
Eu também posso ver isso na interface do venet0 no servidor:
tcpdump -i venet0:0 'icmp[icmptype] == icmp-echo or icmp[icmptype] == icmp-echoreply'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on venet0:0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
21:39:11.397967 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7588, seq 1, length 64
21:39:12.407609 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7588, seq 2, length 64
21:39:13.415194 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7588, seq 3, length 64
21:39:14.423050 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7588, seq 4, length 64
21:39:15.431005 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7588, seq 5, length 64
21:39:16.439687 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7588, seq 6, length 64
21:39:17.446949 IP 10.8.0.6 > qy-in-f106.1e100.net: ICMP echo request, id 7588, seq 7, length 64
Eu também posso pingar o google com sucesso pelo servidor.
Alguma ideia do que pode estar causando isso?
Arquivo de configuração do servidor:
dev tun server 10.8.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt ca ca.crt cert server.crt key server.key dh dh1024.pem push "route 10.8.0.0 255.255.255.0" push "redirect-gateway" comp-lzo keepalive 10 60 ping-timer-rem persist-tun persist-key group daemon daemon
Arquivo de configuração do cliente:
remote <<server IP>> dev tun comp-lzo ca ca.crt cert client1.crt key client1.key route-delay 2 route-method exe redirect-gateway def1 dhcp-option DNS 10.8.0.1 verb 3
Você precisa mapear o tráfego "de entrada" para ser roteado adequadamente para o cliente. Ou seja você precisa definir uma tradução NAT no servidor para o IP (o VPN) do cliente.
O que você vê é que o servidor não sabe como encaminhar as respostas.
Veja as instruções de como fazer isso: link - veja o Configuração do iptables no servidor.
O encaminhamento de Ip está ativado? Fonte nating os clientes vpn?
A fonte nating está traduzindo os endereços (vpn client) para o endereço IP externo. Como o Sunny diz, o servidor de recebimento não saberia rotear de volta para um IP interno, mesmo que seu ISP não o filtre em primeiro lugar.
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE iptables -a FORWARD -i tun0 -j ACCEPT