Rota IP do servidor A para o servidor B

Question

Eu tento direcionar 137.74.9.193 do servidor A para o servidor B (Ubuntu 16.04).

Se eu tentar fazer o ping 137.74.9.193 do Servidor A, ele funciona como esperado, mas quando tento fazer ping do meu computador pessoal, ele não funciona.

Servidor A:

Public IP (ens3): 213.32.69.16
Public IP: 137.74.9.193
Local Tunnel IP: 10.0.0.1

Servidor B:

Public IP (eth0): 139.59.131.76
Local Tunnel IP: 10.0.0.2

Configuração no servidor A:

nano /etc/network/interfaces

auto lo
iface lo inet loopback

auto ens3
iface ens3 inet dhcp

auto tun1
iface tun1 inet static
    address 10.0.0.1
    netmask 255.255.255.252
    pre-up iptunnel add tun1 mode gre local 213.32.69.16 remote 139.59.131.76 ttl 255
    up ifconfig tun1 multicast
    up ifconfig tun1 arp
    up ifconfig tun1 broadcast
    pointopoint 10.0.0.2
    post-up ip route add 137.74.9.193 via 10.0.0.2 dev tun1
    post-down iptunnel del tun1

Comandos executados:

# enable ip forward
$ echo 1 > /proc/sys/net/ipv4/ip_forward
$ echo 1 > /proc/sys/net/ipv4/conf/ens3/proxy_arp

# Add ip to arp to complete the loop.
$ arp -s 137.74.9.193 fa:16:3e:76:31:ea -i ens3 pub

Tabela de roteamento de IP do Kernel de resultados:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         213.32.64.1     0.0.0.0         UG    0      0        0 ens3
10.0.0.2        *               255.255.255.255 UH    0      0        0 tun1
ip193.ip-137-74 10.0.0.2        255.255.255.255 UGH   0      0        0 tun1
213.32.64.1     *               255.255.255.255 UH    0      0        0 ens3

Configuração no servidor B:

nano /etc/network/interfaces

auto eth0
iface eth0 inet static
        address 139.59.131.76
        netmask 255.255.240.0
        gateway 139.59.128.1
iface eth0:0 inet static
        address 137.74.9.193
        netmask 255.255.255.255
        broadcast 137.74.9.193

auto tun1
iface tun1 inet static
        address 10.0.0.2
        netmask 255.255.255.252
        pre-up iptunnel add tun1 mode gre local 139.59.131.76 remote 213.32.69.16 ttl 255
        up ifconfig tun1 multicast
        up ifconfig tun1 arp
        up ifconfig tun1 broadcast
        pointopoint 10.0.0.1
        post-down iptunnel del tun1

Comandos executados:

# enable ip forward
$ echo 1 > /proc/sys/net/ipv4/ip_forward

# Route to tun1
ip route add 10.0.0.1 dev tun1

Tabela de roteamento de IP do kernel:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         gateway         0.0.0.0         UG    0      0        0 eth0
10.0.0.1        *               255.255.255.255 UH    0      0        0 tun1
10.19.0.0       *               255.255.0.0     U     0      0        0 eth0
139.59.128.0    *               255.255.240.0   U     0      0        0 eth0

Obrigado por qualquer ajuda :)

UPDATE (14.11.2016): Adicionar comandos de rota no servidor B

    

Answer 1

Tanto quanto eu posso dizer das informações da sua pergunta, seu problema é que

arp -s 137.74.9.193 fa:16:3e:76:31:ea -i ens3 pub

não faz o que você acha que faz. Esse comando cria uma nova entrada de tabela ARP em seu servidor, de forma que, se o seu servidor enviar pacotes sobre ens3 a 137.74.9.193 , não fará solicitações ARP porque você já especificou um endereço MAC de destino.

Mas você também precisa garantir que o roteador saiba enviar os pacotes ao seu servidor. O roteador enviará uma solicitação ARP para 137.74.9.193 . Mas como esse endereço IP não está atribuído a nenhuma interface em seu servidor, seu servidor não responderá a essas solicitações ARP.

Para fazer esse trabalho, você precisará habilitar o proxy ARP, o que você pode fazer com este comando:

echo 1 > /proc/sys/net/ipv4/conf/ens3/proxy_arp

Se você usar esse comando em vez do comando arp , acho que funcionará. (Eu sei que isso funciona com o peer IP de uma interface ponto-a-ponto. Eu não testei a mesma configuração com uma entrada de tabela de roteamento enviando o tráfego através de uma interface de túnel, e eu não sei com certeza se isso requer etapas adicionais.)

Se o servidor de hospedagem do ISP filtrar o tráfego com base no endereço IP de origem, talvez você não consiga enviar pacotes usando o 137.74.9.193 como endereço de origem. Se você pingar 137.74.9.193 de fora e capturar pacotes ICMP em eth0 no Servidor B, deverá ver se as respostas de eco ICMP estão sendo enviadas nessa interface.

Se você achar que o Servidor B está enviando respostas de eco ICMP e elas nunca chegam ao seu destino, a explicação mais provável é que o ISP está filtrando com base no endereço IP de origem.

Nesse caso, você tem duas opções. Você pode entrar em contato com o ISP e explicar que você precisa originar pacotes com esse IP de origem, de forma que eles possam atualizar seu filtro. Ou você pode encapsular o tráfego de retorno através do Servidor A.

A maneira mais simples de encapsular o tráfego de retorno através de A é criar uma tabela de roteamento em B que se pareça com isto:

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         UG    0      0        0 tun1
213.32.69.16    gateway         255.255.255.255 UG    0      0        0 eth0
10.0.0.1        *               255.255.255.255 UH    0      0        0 tun1
10.19.0.0       *               255.255.0.0     U     0      0        0 eth0
139.59.128.0    *               255.255.240.0   U     0      0        0 eth0

Isso, no entanto, tornará 139.59.131.76 inacessível do restante da Internet. Se você quiser que B seja acessível através de ambos os endereços IP simultaneamente, você precisa criar duas rotas padrão diferentes e uma política de roteamento para escolher entre elas com base no IP de origem do pacote.