Cliente OpenVPN sem redirecionamento de gateway fazendo roteamento triangular e spoofing de IP não funcionando no Ubuntu

Question

Eu tenho um cliente OpenVPN rodando em um servidor meu, obtendo um IP público em uma rede remota em um país diferente. A configuração do cliente é a seguinte:

dev tap
remote a.b.30.7
float a.b.30.7
port 5167
ifconfig a.b.28.178 255.255.255.128
route-gateway a.b.28.129
#redirect-gateway def1
secret woot.key
cipher AES-128-CBC
dhcp-option DNS a.b.8.8

O

redirect-gateway é comentado para que meu servidor (executando o openvpn client) não seja "controlado" pela conexão VPN. Eu posso vincular serviços à interface tap0 (ou seja, httpd, etc) e executar um site fora deste IP em outro país. O ISP em que o servidor em que o cliente openVPN está sendo executado está ativado e não possui filtragem de saída, portanto, o tráfego para a VPN pode simplesmente sair do gateway padrão da eth0 com o IP público em outro país. Somente o tráfego de entrada é roteado através da VPN (ou seja, solicitações httpd de entrada), mas o tráfego de saída sai da eth0 falsificado com o IP público da VPN. Sem ANY mucking com rotas ou iptables, isso simplesmente funciona sem problemas ... em um servidor DEBIAN. O benefício óbvio é que eu tenho a velocidade e o roteamento da minha interface eth0 normal, mas com um IP em um país diferente.

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
x.y.150.64   0.0.0.0         255.255.255.224 U     0      0        0 eth0
a.b.28.128    0.0.0.0         255.255.255.128 U     0      0        0 tap0
0.0.0.0         x.y.150.65   0.0.0.0         UG    0      0        0 eth0

x.y sendo a rede do servidor real e a.b sendo a rede openvpn remota.

O problema? A mesma coisa EXATA NÃO FUNCIONA no Ubuntu e eu não consigo entender o porquê. Eu fiz isso em inúmeros servidores Debian sem problemas e absolutamente sem rotas customizadas ou qualquer tipo de regra do iptables. Nenhum servidor executa um firewall. Eu acredito que esta é uma questão muito básica, ou o Ubuntu tem algum tipo de coisa estranha acontecendo. É importante notar que a VPN funciona nos servidores Ubuntu se eu descomentar o redirecionamento-gateway (como deveria), exceto que isso não é o que eu quero. Eu ainda preciso acessar o servidor de sua interface principal, eth0.

Rastreio do servidor Debian (WORKING):

# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 40 byte packets
 1  blah (a.b.29.1)  39.161 ms  39.140 ms  39.332 ms
 2  asdf (a.b.30.1)  40.870 ms  40.879 ms  40.850 ms
 3  sth-sbb2-ank35-1-ge26-100.dcs.net (217.78.35.5)  40.816 ms  40.818 ms  40.783 ms
 4  google-gw.dcs.net (217.78.35.14)  40.780 ms  40.601 ms  40.565 ms
 etc. fine here.

Rastreio do servidor Ubuntu (NÃO TRABALHA):

# traceroute -i tap0 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *
 borked.

8.8.8.8 sendo googles DNS público.

O IP da VPN não é acessível do mundo exterior. Curiosamente, se eu fosse:

ssh -b [debian.server.openvpn.client.IP] user@[ubuntu.server.openvpn.client.IP]

Eu consigo conectar / ping / ver. Isto é feito com dois clientes VPN separados rodando tanto no Debian quanto no Ubuntu, na mesma rede a.b que na tabela de rotas (diferentes IP's na rede remota). O IP do cliente VPN do servidor debian é acessível publicamente, mas no servidor Ubuntu não é! Apenas de dentro de a.b!

O objetivo é falsificar o tráfego da eth0 em vez de enviá-lo de volta pela VPN e desperdiçar a largura de banda da VPN. Além disso, a mesma configuração de VPN funcionará em um servidor debian sem problemas. Eu posso colocar a configuração para a VPN que está na caixa do Ubuntu na caixa Debian e está tudo bem.

Servidor Debian roda Debian 5 de 64 bits com 2.6.32-bpo.5-xen-amd64
O servidor Ubuntu roda o Ubuntu 10.04.1 LTS com o 2.6.32-24-server

Eu pensei que isso pode ser um problema com módulos do kernel e tun.ko, como eu não vi isso com modprobe -l no servidor Ubuntu, mas DID no servidor debian. Consulte o link se estiver interessado. Eu tentei as soluções alternativas sem sucesso. Eu acho que é outra coisa.

Qualquer ajuda é muito apreciada! Eu peço desculpas por falta de termos de rede adequados, quando necessário, eu só tenho conhecimentos de rede intermediária e desde que isso funcionou para mim com facilidade no debian não tiveram que fazer nada de especial.

    

Answer 1

Eu tenho que admitir que eu não (ainda) entendo completamente o que você está tentando alcançar. Mas eu acho que você quer que seu servidor Ubuntu (e Debian) seja acessado por um IP que você obteve através do OpenVPN (tráfego de entrada) mas envie seu próprio tráfego (= servidores Ubuntu) através da interface eth0 local para seu servidor (Ubuntu) ("spoofing"). ") o VPN-IP. Ou ao longo destas linhas. Eu não tenho certeza se esta é uma idéia muito boa (provavelmente depende de por que você faz isso), mas eu suponho que há uma razão para isso e como você diz, funciona com o Debian. Então, não vamos elaborar sobre isso (embora possa ser importante mais tarde).

Além disso, pergunto-me por que a linha

route-gateway a.b.28.129

incluído na sua configuração de VPN não (parece) levar a uma entrada na sua tabela de roteamento.

Também não tenho certeza de qual é a meta / insight dos dois traceroutes que você mostra ... Parece que você está tentando rastrear a rota 8.8.8.8 pelo túnel da VPN. Como este é o tráfego de saída , eu não entendo realmente a relevância dele para o seu problema. E eu diria (olhando para a sua tabela de roteamento) que o tráfego que você gera dessa maneira não é (não deveria ser?) Passando pelo túnel. Eu vejo que parece que este é o caso do Debian embora ... Mas eu não vejo porque este é o caso. Olhando para a tabela de roteamento, prefiro assumir que os pacotes traceroute que você tenta enviar em tap0 são (devem ser?) "Reencaminhados" para eth0 (rota padrão).

Agora, isso me leva ao palpite que eu levaria para o seu problema: encaminhamento de IP . Será que a sua caixa do Debian está habilitada enquanto está desabilitada no Ubuntu? Você pode encontrar mais informações (como descobrir se o encaminhamento de IP está ativado, por exemplo) visitando o link acima (ou use o seu mecanismo de busca favorito ou o manual do Ubuntu).

Sua capacidade de acessar o daemon SSH no Ubuntu sugere que você está muito próximo :). Por isso, pode ser crucial saber o que você quer dizer com

"The debian server VPN client IP is publically accessible, but on the Ubuntu server it's not!"

O que você está tentando fazer (ou seja, a que serviço você está tentando se conectar) quando a máquina Ubuntu "não está acessível"? Acessar seu servidor web? Qual IP este serviço está escutando?

    

Answer 2

O Ubuntu pode ter um padrão diferente para a filtragem de caminho inverso. Verifique os vários rp_filter em /proc/sys/net/ipv4/conf/... .

Se isso não ajudar, o próximo passo seria confirmar se os pacotes estão entrando / saindo com o tcpdump ou o wireshark. Confirme também que você realmente não tem um firewall com iptables -vL .

    

Answer 3

Verifique se o rp_filering está ativo

sysctl -a | grep \.rp_filter

Procure por interfaces com = 1

Edite /etc/sysctl.conf e defina

net.ipv4.conf.default.rp_filter=0
net.ipv4.conf.all.rp_filter=0

Há uma boa página da Web aqui sobre isso link