Discuta este tópico no fórum

Se este conteúdo te ajudou, deixe um presente!

domingo, 22 de maio de 2016

NetVirtua e problemas com IPv6 (perda de rota padrão)

Sim, IPv6 é necessário, é o futuro e já devíamos estar todos usando. Se você se julga com algum conhecimento de redes e não conhece IPv6, já passou da hora de estudar. Mas não é sobre isto este artigo.

Sou um entusiasta do IPv6 faz alguns anos. Sempre sonhei poder conectar da internet em qualquer equipamento da minha rede interna sem todos os "artifícios técnicos" para contornar o NAT (encaminhamento de porta, túnel sobre SSH, etc). Bastaria o firewall não bloquear. Por este motivo, em 2010 eu já utilizava túneis para obter conectividade IPv6. Era lento, deixava minha navegação pior, mas funcionava perfeitamente.

Em 2015, finalmente chegou o tão sonhado IPv6 pelo provedor! Logo reconfigurei meus equipamentos para utilizar a nova pilha IPv6. E então apareceram os problemas. Este é o tema deste artigo.

Administro duas redes ligadas a Net. Testei a configuração em uma... funcionou! Perfeito. Copiei para a segunda... funcionou novamente! Porém, depois de alguns minutos, notei que as máquinas da primeira rede não mais conversavam IPv6 com o mundo. No roteador da rede, ele estava sem rota padrão para o IPv6. Desliguei alguma coisa? E a segunda rede continuava a funcionar. Recarreguei a interface WAN e tudo voltou a funcionar. Mais alguns minutos... novamente sem IPv6 na primeira rede! (e a segunda rede continuava a funcionar...). Como as duas redes usavam o mesmo equipamento, mesma configuração, seria problema do equipamento do provedor? Vamos a investigação.

A NET distribui IPv6 por DHCPv6. O comportamento é similar ao IPv4: você ganha um endereço WAN para falar com a internet. A diferença é que, como não temos mais NAT, não iremos esconder os computadores da rede interna nem usar endereços falsos (192.168.x.x). Nesta mesma requisição do DHCPv6, a NET também informa uma rede com endereços IPv6 reais para suas máquinas internas (LAN), chamado de prefixo delegado. O roteador usa este endereço para que sejam definidos os endereços IPv6 (reais) da LAN. Tudo está funcionando perfeitamente quando, então, a tabela de roteamento IPv6 que era:

root@router:~# ip -6 r
default from 2804:14d:????:1000:204c:36a0:daed:f2d7 via fe80::217:10ff:fe87:5c9c dev eth0.2  proto static  metric 512 
default from 2804:14d:????:8417::/64 via fe80::217:10ff:fe87:5c9c dev eth0.2  proto static  metric 512 
2804:14d:????:1000::/64 dev eth0.2  proto static  metric 256 
2804:14d:????:1010::/64 dev eth0.2  proto static  metric 256 
2804:14d:????:8417::/64 dev br-lan  proto static  metric 1024 

Vira:

root@router:~# ip -6 r
2804:14d:????:1000::/64 dev eth0.2  proto static  metric 256 
2804:14d:????:1010::/64 dev eth0.2  proto static  metric 256 
2804:14d:????:8417::/64 dev br-lan  proto static  metric 1024 

Se você está enfrentando isto e quer apenas "resolver", para usuários do OpenWRT, basta subir novamente a interface wan6 a cada 20 minutos. A cron é excelente para isto:

root@router:~# crontab -l
*/20 * * * * /sbin/ifup wan6

Isto não era suficiente. Eu queria mais: mas porquê? E eu tinha um trunfo: acesso a duas redes com comportamentos diferentes. O primeiro passo é sempre dar uma "cheirada" na rede. O roteador das duas redes são OpenWRT. Desta forma, posso instalar o tcpdump(-mini) e capturar os pacotes durante a negociação do endereço. Podemos fazer isto de forma assíncrona:

root@router:~# tcpdump -i eth0.2 -U -s 0 -w /tmp/dump-ipv6.pcap ip6

E analisar o arquivo dump-ipv6.pcap, ou mesmo já jogar a captura para dentro do wireshark local.

luiz@minhamaquina:~$ ssh root@router tcpdump -i eth0.2 -U -s 0 -w - ip6 | wireshark -k -i -

Observando as duas capturas, já é possível notar que estamos em equipamentos diferentes da NET. Na que para de funcionar, o roteador que responde é o 2804:14d:baa6:1000::1 (vou chamar de baa6). Na segunda, que continua a funcionar, 2804:14d:baa5:1000::1 (vou chamar de baa5).

Na rede que para de funcionar depois de um tempo, a requisição de roteador (router solicitation - RS) que ocorre antes do DHCPv6 é respondida, enquanto na outra, não. Aparentemente o baa6 está configurado para enviar RA (route advertisement) e o baa5 não. Mas responder (ou não) com um RA não deveria ser um problema, desde que ele continue a respondê-lo e enviá-lo periodicamente. De resto, os dois tráfegos são equivalentes, exceto que a rede que funciona (conectada no baa6) tenta novamente após 10s uma nova solicitação de roteador (também sem resposta).

Olhando com carinho, o tempo de vida do RA (router lifetime) é de 1800s (30 min), muito próximo ao tempo até a queda da rota padrão. Interessante. Pode ser por aí o problema. O RA é enviado voluntariamente pelo roteador em um período aleatório mas dentro de um intervalo máximo e mínimo. Pelo que eu entendi da RFC 4861, o cliente não deve enviar um novo RS em situações normais, apenas aguardar o próximo RA que deveria chegar antes de estourar o tempo de vida da rota (router lifetime)Então, onde está meu RA não solicitado? Será que o roteador não está enviando? Ou será que ele está sendo bloqueado? Eu monitorei o tráfego e não achei qualquer outro RA chegando na minha interface WAN.

Bem, vamos simular uma situação onde o baa6 não responderia o RS. Isto pode ser feito bloqueando qualquer RA que chega no roteador pela WAN. 

root@router:~# ip6tables -A INPUT -i eth0.2 -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m comment --comment "bloqueia RA da NET" -j DROP

Ou para usuário do OpenWRT:

config rule
option name 'bloqueia RA da NET'
option src 'wan'
option proto 'icmp'
option family 'ipv6'
list icmp_type 'router-advertisement'
option target 'DROP'

Atualizando: a recarga das regras do firewall ocorria justamente quando o RA estava chegando. Por isto, o RA poderia ser aceito neste tempo. Melhor usar uma regra em um chain que o fw3 não limpa ao recarregar (somente ao reiniciar). Coloque isto em /etc/firewall.user:

if ! ip6tables -L INPUT | grep -q "bloqueia RA da NET"; then
        echo "Primeira vez que esta rodando... adicionando filtro do RA e recarregando WAN"
        ip6tables -t filter -I INPUT -i $(uci get network.wan.ifname) -p icmpv6 -m icmp6 --icmpv6-type 134 -m comment --comment "bloqueia RA da NET" -j DROP
        ifup wan6
fi

Você saberá que funcionou quando o comando abaixo mostrar no primeiro número (número de pacotes casados) um valor diferente de zero (normalmente 4):

root@router:~# ip6tables -L -nv | grep 'bloqueia RA da NET'
    4   544 DROP       icmpv6    eth0.2 *       ::/0                 ::/0                 ipv6-icmptype 134 /* bloqueia RA da NET */

Depois de 30 minutos nossas rotas devem ainda estar vivas. Estamos no caminho certo. Sem RA, a rota padrão vem apenas do DHCPv6 e sem validade de 30 minutos. Falta apenas descobrir o porquê de não receber o RA. Se o equipamento for um Cisco, eu chutaria que ele usou "ipv6 nd ra suppress" quando deveria ter usado "ipv6 nd ra suppress all". Mas vamos a mais alguns testes novamente com o sniffer ligado.

Pelo DHCPv6, recebo o endereço WAN e uma rede para a LAN. Esta rede para LAN vai gerar todos os endereços de equipamentos da minha rede local, inclusive para a interface LAN do roteador. No meu caso, ela é <prefixo recebido>::1/64. Quando eu realizava um teste com o ping6 para endereços na internet, eles respondiam sem problemas. Porém, eu notei que o roteador estava usando o endereço da LAN e não da WAN. E se eu escolher o endereço que o ping deve usar? Ex:

root@router:~# ping -6 -I <endereço IPv6 WAN e não o nome da interface!> ipv6.br
 

Bingo! Na rede que sempre funcionou o IPv6 (ligada ao baa5), consigo usar tanto o endereço LAN como o WAN e ambos funcionam. Na rede que não funciona (ligada ao baa6), não tenho resposta. Agora a dúvida: eu não consigo enviar ou receber? Novamente vamos usar o trunfo de ter administração em duas redes. Ligando o sniffer na rede sem problemas, podemos ver a chegada e a saída de pacotes:

02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:40.378262 IP6 [IP:WAN:baa5] [IP:WAN:baa6] ICMP6, echo reply, seq 0, length 64

Opa! O "echo request" chegou nos dois casos e foram respondidos prontamente. Agora olhando no lado da origem:

02:50:15.246987 IP6 [IP:LAN:baa6] > [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64
02:50:15.247433 IP6 [IP:WAN:baa5] > [IP:LAN:baa6] ICMP6, echo reply, seq 0, length 64
02:50:40.377930 IP6 [IP:WAN:baa6] [IP:WAN:baa5] ICMP6, echo request, seq 0, length 64

Faltou chegar o pacote da resposta. Tentando o ping vindo da outra rede, nada chegou. Tentei também ping vindos de fora das duas redes e o comportamento foi o mesmo. Na rede que sempre funcionou, recebi os pacotes sem problemas. Na outra, nenhum pacote chegou.

Para confirmar esta suspeita, liguei o cabo do NetVirtua diretamente em um computador. Assim, ele assumiria o endereço WAN para uso normal (sem usar o prefixo delegado). O resultado: ganhei o endereço IPv6 mas, fora isto, nada relacionado a IPv6 funcionou pois nunca recebi pacotes vindos da internet do IPv6. Para que serve uma conexão com a internet se só posso enviar pacotes e não receber?

Em suma: a NET está com um roteador que não permite enviar dados para o endereço IPv6 WAN. Por mera coincidência, ele também responde o RS com um RA, o que exigiria o envio de um novo RA antes de estourar a validade da rota (30 min). Como não recebo qualquer pacote, o novo RA nunca chega e perco a rota padrão. Se o RA estivesse desligado, isto dificilmente seria notado pois é raro que os roteadores recebam pacotes (exceto se usar OpenWRT).

Enviei tudo isto para a Net e esta foi a sua grande resposta:
Protocolo de Atendimento:08815.12620.98631
Prezado cliente, 

Informo que nesse momento não há viabilidade técnica para instalação dos produtos IPV6 e infelizmente não há previsão de adequação da rede e liberação da mesma para comercialização dos produtos. 
Agradecemos o seu contato. 

Atenciosamente, 
MARCKSON FERNANDO DE DEUS
Depois dessa como vou argumentar?! Meu endereço IPv6 e o roteamento com a internet deve ter brotado por abiogênese!

Atualizando: entrei em contato novamente para a NET. A nova resposta:

Protocolo de Atendimento: 08816.14500.66951 
Prezado cliente, 
Recebemos o seu e-mail e conforme verificado em sistema informamos que o seu EMTA 2.0 não é compatível com protocolo IPV6. É necessário a troca do equipamento para obter o IPV6, ressaltamos que a visita será cobrada o valor de R$ 90,00, caso tenha interesse será necessário realizar uma nova solicitação através de nossos canais de atendimento, que agendaremos uma visita técnica em sua residência. 
Agradecemos o seu contato. 

Atenciosamente, 
LARISSA RIBEIRO SANTOS

Legal! Querem agora me cobrar por uma falha deles! Ao menos não disseram que não tenho esse tal de IPv6. Agora vamos a argumentação: EMTA 2.0 deve ser DOCSIS 2.0, que realmente não teria suporte ao IPv6. Porém, No local onde funcionava (ligado ao baa5), o modem era realmente diferente (Cisco  DPC2203) do meu (Thomson DHG534B). Porém, ambos com suporte somente a DOCSIS 2.0. Também consegui testar em um terceiro ponto com o modem IGUAL ao meu. Surpresa?! Funcionou perfeitamente! Mas este ponto está ligado a um terceiro roteador na Net (baa1). Então, de três pontos diferentes da Net, 2 funcionam e 1 não. Os roteadores tem o mesmo sistema operacional (OpenWRT) e configuração IPv6 (default). Todos os modems são DOCSIS 2.0 e com o mesmo modelo de modem, de um lugar funciona e outro não. Dá para afirmar com uma certa segurança que o problema é a configuração do baa6. Como se argumenta com a NET desta forma? Vou ligar para eles e tentar falar com alguém que entende...

Alguém aí trabalha na Net ou conhece alguém da área técnica? Compartilha este link ;-) Não queria ter que começar mais uma batalha com a ANATEL.

Para os afetados, sugiro adicionar a regra do firewall e configurar qualquer serviço divulgado na rede (ex: torrent) confirma se ele está usando o endereço IPv6 da LAN e não da WAN.

Dúvidas? Use o fórum deste blog!

Até a próxima.