Início / server / Perguntas / 993051
Accepted
Lasse Michael Mølgaard
Asked: 2019-11-24 10:35:07 +0800 CST

O gateway OpenVPN não responde no ping IPv6, mas encaminha o pacote

  • 772

Estou tentando depurar minha rede IPv6 e me deparei com um problema que não consigo entender.

Estou usando o OpenVPN como meu servidor VPN e aqui está um pequeno diagrama da configuração:

Rede IPv6 com servidor VPN de hospedagem dupla Todos os pacotes são descartados, quando tento fazer ping do VPN Client ( 2001:470:7875:1::2) para o VPN Server ( 2001:470:7875:1::1), mas aqui está o curioso:

Posso pingar qualquer outro host em IPv6 (como o Google) ou qualquer outro cliente VPN conectado ao mesmo servidor VPN em IPv6.

Também posso pingar meu servidor VPN em sua interface IPv6 nativa ( ens3). É apenas a interface do servidor VPN ( tun0) que não responde quando pingado diretamente.

Por isso estou me perguntando o que está acontecendo?

Como tenho dois links IPv6 para a versão IPv6 da internet, tenho roteamento baseado em política de tarefas. As regras são bem simples.

  • Somente pacotes IPv6 originados do próprio servidor VPN podem ser enviados pelo link IPv6 nativo.
  • Todos os outros pacotes IPv6 devem ser tratados pelo túnel Hurricane Electric IPv6.

Isso me leva à seguinte tabela de roteamento no servidor VPN:

O comando ip -6 rule showtem a seguinte configuração:

0:      from all lookup local
32000:  from 2001:470:7875::/48 lookup openvpn
32766:  from all lookup main

Tabela local:

local ::1 dev lo proto kernel metric 0 pref medium
anycast 2001:470:1f14:2c7:: dev he-ipv6 proto kernel metric 0 pref medium
local 2001:470:1f14:2c7::2 dev he-ipv6 proto kernel metric 0 pref medium
anycast 2001:470:7875:1:: dev tun0 proto kernel metric 0 pref medium
local 2001:470:7875:1::1 dev tun0 proto kernel metric 0 pref medium
anycast 2a01:xxx:xxxx:: dev ens3 proto kernel metric 0 pref medium
local 2a01:xxx:xxxx:xxx::1 dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev ens3 proto kernel metric 0 pref medium
anycast fe80:: dev tun0 proto kernel metric 0 pref medium
anycast fe80:: dev he-ipv6 proto kernel metric 0 pref medium
local fe80::95d2:9e6b dev he-ipv6 proto kernel metric 0 pref medium
local fe80::5054:ff:fe66:f97f dev ens3 proto kernel metric 0 pref medium
local fe80::af96:f1e3:dbf3:96a7 dev tun0 proto kernel metric 0 pref medium
ff00::/8 dev ens3 metric 256 pref medium
ff00::/8 dev tun0 metric 256 pref medium
ff00::/8 dev he-ipv6 metric 256 pref medium

Tabela main:

local ::1 dev lo proto kernel metric 256 pref medium
2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
2xxx:xxx:xxxx::/48 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev tun0 proto kernel metric 256 pref medium
fe80::/64 dev he-ipv6 proto kernel metric 256 pref medium
default via 2a01:xxx:xxxx::1 dev ens3 metric 1024 pref medium

Tabela openvpn:

unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium
default via 2001:470:1f14:2c7::1 dev he-ipv6 metric 1024 pref medium

Tem alguém que possa me dar uma dica? :-)

Uma rápida recapitulação das linhas inacessíveis na tabela de roteamento

2001:470:1f14:2c7::/64 dev he-ipv6 proto kernel metric 256 pref medium
2001:470:7875:1::/64 dev tun0 proto kernel metric 256 pref medium
unreachable 2001:470:7875::/48 dev lo metric 1024 error -113 pref medium

O intervalo de 2001:470:7875::/48é de 2001:470:7875:0:0:0:0:0a 2001:470:7875:ffff:ffff:ffff:ffff:ffff.

Eu atribuí a sub -rede 2001:470:7875:1::/64ao túnel VPN.

  • 2001:470:7875:1::/64faz parte da 2001:470:7875::/48sub-rede, o que pode levar a um conflito na tabela de roteamento.
  • 2001:470:1f14:2c7::/64não faz parte da 2001:470:7875::/48sub-rede e, portanto, não entra em conflito com a tabela de roteamento.

Nenhum outro intervalo de IP está em uso, mas estará em uma data posterior indeterminada.

Tendo em mente que as vitórias de prefixo mais longas nos dá o seguinte comportamento:

  • Quaisquer pacotes IP para 2001:470:1f14:2c7::/64sub-rede serão tratados pela interface he-ipv6.
  • Quaisquer pacotes IP para 2001:470:7875:1::/64sub-rede serão tratados pela interface tun0.
  • Todos os outros pacotes de IP para a sub-rede 2001:470:7875::/48 serão respondidos com inacessível.
ipv6

1 respostas

  1. Best Answer

    Então...

    Depois de mais escavações, descobri que minha configuração poderia ser um pouco refinada, embora não esteja totalmente convencido de que cobri todas as minhas bases.

    De qualquer forma ip -6 rule showpoderia ser ajustado um pouco.

    a linha:

    32000:  from 2001:470:7875::/48 lookup openvpn

    Foi gerado pelo seguinte comando:

    ip -6 rule add priority 32000 from 2001:470:7875::/48 table openvpn

    Isso poderia ser simplificado para:

    ip -6 rule add priority 32000 iif tun0 to 2000::/3 table openvpn

    O que isso significa é que basicamente todo o tráfego baseado em IPv6 deve pesquisar a tabela openvpn se e somente se o tráfego se originar do link VPN e o endereço de destino pertencer ao 2003::/3, que é basicamente toda a Internet IPv6 oficial - excluindo endereços locais como fe80::/10 e fc ::/7.

    O resultado final é que o tráfego IPv6 do meu link VPN é sempre encaminhado pelo link Hurricane Electric.

    Coisas para lembrar. Sempre que adiciono uma nova sub-rede do meu pool de endereços disponíveis no 2001:470:7875::/48intervalo, tenho que fazer duas entradas.

    • Um na tabela main, que informa como encaminhar o pacote do servidor VPN para a nova sub-rede.
    • Ativado na tabela openvpn, que informa como os clientes VPN podem acessar a nova sub-rede. Isso geralmente ocorre quando há tráfego site a site de um cliente para outro cliente pelo link VPN.

    De qualquer forma: o ping funciona agora e ainda posso pingar o Google por IPv6.

    O comando ip -6 rule showagora fornece a seguinte saída:

    0:      from all lookup local
32000:  from all to 2000::/3 iif tun0 lookup openvpn
32766:  from all lookup main

    Todo o resto está como está na pergunta inicial.

    Traceroute foi um pouco complicado, mas funciona desde que seja feito com pacotes ICMP Echo.

    A execução do comando traceroute -6 -I google.comno meu cliente VPN deu o seguinte rastreamento:

    traceroute to google.com (2a00:1450:400e:80b::200e), 30 hops max, 80 byte packets
 1  2001:470:7875:1::1 (2001:470:7875:1::1)  16.868 ms  37.912 ms  37.847 ms
 2  tunnel547738.tunnel.tserv11.ams1.ipv6.he.net (2001:470:1f14:2c7::1)  37.777 ms  37.710 ms  37.647 ms
 3  10ge11-20.core1.ams1.he.net (2001:470:0:7d::1)  37.575 ms  37.509 ms  37.443 ms
 4  amsix-router.google.com (2001:7f8:1::a501:5169:1)  37.453 ms  52.425 ms  52.392 ms
 5  2001:4860:0:f8d::1 (2001:4860:0:f8d::1)  52.323 ms  52.259 ms  52.189 ms
 6  2001:4860:0:1::219f (2001:4860:0:1::219f)  36.456 ms  25.560 ms  18.169 ms
 7  ams17s01-in-x0e.1e100.net (2a00:1450:400e:80b::200e)  34.566 ms  34.502 ms  34.435 ms
    • 0

relate perguntas