Usando a internet sem conexão IPv4
(jamesmcm.github.io)- Mesmo em uma situação em que a conexão IPv4 foi interrompida, passou a ser possível usar toda a internet por meio de IPv6, WireGuard e um VPS da Hetzner
- Devido ao Carrier Grade NAT (NAT em larga escala), a falha afetou apenas o IPv4, enquanto o IPv6 não foi impactado
- Ao configurar um túnel WireGuard e tunelar o tráfego IPv4 por um VPS, foi possível restaurar um ambiente normal de navegação em sites
- Também são mostradas formas de usar namespaces de rede e Docker, além de como resolver problemas de MTU
- O texto destaca a experiência de resolver por conta própria um problema de rede complexo graças ao ambiente Linux e às ferramentas open source
Visão geral
Há alguns dias, após uma queda de energia, o autor enfrentou um problema em que o acesso IPv4 parou de funcionar no roteador de casa. Felizmente, o acesso via IPv6 continuou normal, então ainda era possível entrar em alguns sites (como Google e Meta), mas a maioria dos sites (como GitHub) ficou inacessível. O texto organiza o processo de restaurar um ambiente completo de uso da internet usando apenas IPv6 com Linux, WireGuard e um VPS da Hetzner.
Causa da falha e contexto
Descoberta de anomalias no ambiente de rede
- Durante a recuperação após a queda de energia, foi confirmado que servidores IPv6 eram acessíveis, enquanto servidores IPv4 não eram
- Os resultados de comandos de diagnóstico (
ping -6,traceroute) também mostravam apenas diferenças conforme a versão do IP - Após contato com a operadora, descobriu-se que havia um problema na camada de CG-NAT (Carrier Grade NAT) responsável pela conversão de IPv4
- Como a manutenção por parte do ISP levaria alguns dias, tornou-se necessário encontrar uma solução por conta própria
Explicação sobre NAT e CG-NAT
- NAT (Network Address Translation): método que permite que vários dispositivos compartilhem um único endereço IPv4 público
- No roteador, os IPs internos são convertidos em um IP público e portas exclusivas para gerenciar o tráfego; no caminho de volta, as informações de mapeamento restauram o destino interno
- Essa estrutura cria o efeito de um firewall implícito e a necessidade de encaminhamento de portas
- CG-NAT (Carrier Grade NAT): estrutura em camadas em que o ISP aplica NAT mais uma vez para cada roteador residencial
- O ISP aplica NAT de forma sobreposta internamente por causa da escassez de endereços IPv4
- Em ambientes com CG-NAT, a oferta de serviços como port forwarding fica ainda mais limitada
- O motivo de a falha ter afetado apenas o tráfego IPv4 foi justamente um problema no processamento de pacotes IPv4 nessa camada
Vantagens do IPv6
- O espaço de endereçamento do IPv6 é imensamente maior, permitindo atribuir endereços diretamente a cada dispositivo sem NAT
- A maioria dos roteadores domésticos recebe uma sub-rede
/64, permitindo o uso de trilhões de endereços
- A maioria dos roteadores domésticos recebe uma sub-rede
- Como NAT não é necessário, a comunicação direta é possível, mas as configurações de firewall se tornam ainda mais importantes
- Como o CG-NAT se aplica apenas ao IPv4, neste incidente somente o IPv6 continuou funcionando normalmente
- Porém, muitos servidores ainda não são acessíveis apenas por IPv6 (por exemplo, GitHub)
Restaurando o IPv4 com um túnel WireGuard
Visão geral da implementação
- Usando um VPS da Hetzner (com suporte a pilha IPv4/IPv6) e WireGuard, foi criado um ambiente com acesso completo à internet mesmo quando a conexão disponível era apenas por IPv6
- O VPS roda como servidor WireGuard e estabelece um túnel com o equipamento cliente
- O tráfego é desviado até o VPS por IPv6, e a partir dele é possível acessar todos os sites (incluindo IPv4)
- O princípio é semelhante ao do Dual-Stack Lite
Exemplo de configuração do servidor e do cliente
- Na configuração do servidor WireGuard, tanto o tráfego IPv4 quanto o IPv6 são tratados
- Inclui exemplos de regras MASQUERADE (conversão dinâmica de IP) e SNAT (conversão com IP fixo)
- Como há IPv6 global atribuído diretamente, é possível conectar peers WireGuard sem NAT
- É possível escrever várias entradas PostUp/PostDown para executar cada comando em sequência
- Exemplo de configuração do cliente
- Explica combinações possíveis com endereço IPv6 atribuído diretamente ou ULA atrás de NAT
- Ao definir
AllowedIPscomo0.0.0.0/0, ::/0, é possível tunelar todo o tráfego - Também são mostradas formas de configurar o DNS do Google (IPv4 e IPv6) e o MTU
Túnel funcionando corretamente
- Depois de concluir a configuração do WireGuard em ambos os lados, tanto IPv4 quanto IPv6 passaram a ser tunelados normalmente
- O mesmo método foi aplicado também ao PC da esposa, com instalação simples do cliente WireGuard no Linux
- No entanto, como em geral não é possível manter conexão simultânea com a VPN corporativa, torna-se necessário usar namespaces de rede adicionais
Namespaces de rede e Docker
Funcionalidades e formas de uso
- Com ferramentas como o vopono, é possível criar namespaces de rede por aplicação e especificar diretamente a VPN ou a interface WireGuard dentro desse namespace
- É necessário definir regras MASQUERADE separadas para forçar o tráfego interno a passar pelo túnel WireGuard
- Também há dicas de configuração para DNS isolado do ambiente externo e para
gai.conf(preferência de DNS/IPv4)
- Exemplo de implementação do modelo de conectar à VPN e executar a aplicação dentro do namespace
- Executar vários serviços no mesmo namespace ajuda a evitar conflitos de rede com antecedência
Combinação com contêineres Docker
- Como o daemon do Docker usa por padrão o socket de rede do host, não é possível acessá-lo apenas executando em um namespace comum
- O texto apresenta workarounds com técnicas de virtualização Unix, como mount namespace e bind mount de
/sys - Ao executar o
dockerddentro do namespace e definir um socket e um data root separados, foi possível restaurar a conectividade de internet dentro dos contêineres - Também é mencionado que ambientes com bridges de rede mais complexas podem exigir configuração adicional
- O texto apresenta workarounds com técnicas de virtualização Unix, como mount namespace e bind mount de
Problemas de MTU no WireGuard (MTU: unidade máxima de transmissão)
- Após estabelecer a conexão WireGuard, ocorreu um problema em que apenas alguns sites ficavam inacessíveis (por exemplo, com SSL), embora o ping respondesse normalmente
- Com testes de ping em vários tamanhos, identificou-se que a causa era um MTU alto demais, fazendo com que pacotes grandes fossem descartados no caminho
- Reduzir o MTU para 1280 resolveu o problema imediatamente
- MTU é o tamanho máximo de pacote que pode ser transmitido de uma vez
- É necessário definir um MTU adequado considerando o overhead do túnel/encapsulamento; caso contrário, podem ocorrer falhas de conexão ao transmitir pacotes maiores
- No IPv6, o MTU mínimo definido pela especificação é 1280
Conclusão e recomendações de uso
- O texto destaca a experiência de diagnosticar e resolver problemas de rede por conta própria usando Linux e ferramentas open source, incluindo montagem de servidor VPN com WireGuard, gerenciamento de namespaces de rede, configurações especiais para Docker e troubleshooting de MTU
- Serviços como os VPS da Hetzner oferecem boa estabilidade pelo preço e facilitam operar serviços de rede legítimos, como WireGuard
- Há também uma reavaliação do valor de firmwares de roteador open source (OpenWRT) e de técnicas de rede no Linux
- A flexibilidade de gerenciar e modificar a rede diretamente oferece uma grande vantagem em ambientes de trabalho remoto
- Com entendimento e prática suficientes, até falhas complexas de rede podem ser resolvidas por conta própria
Referências
- Tailscale – How NAT Traversal Works
- ArchWiki – exemplo de caso de uso do WireGuard
- Unix StackExchange – truques para Docker dentro de namespaces
- AskUbuntu – configuração de prioridade de DNS
(Consulte o texto original para scripts, configs, dicas e links de referência relacionados)
1 comentários
Comentários do Hacker News
O título parece um pouco enganoso; na prática, este texto está mais para “acessar a internet IPv4 conectando-se a um VPS por meio de um túnel IPv6”, o que normalmente é chamado de 4in6
De qualquer forma, é uma abordagem interessante
Na nossa ISP, quando o IPv4 falha, tudo cai de uma vez e o problema de suporte acaba sendo relativamente simples; já quando o IPv6 falha, aparecem comportamentos estranhos e parciais, como conexão lenta ou interrupções intermitentes
Principalmente quando o gateway acha que tem IPv6, o problema fica mais chato para o usuário, parecendo que só algumas funções não funcionam
Recentemente, quando o IPv4 caiu por um momento, percebi isso só porque o Github não funcionava
Hoje em dia, a maioria dos sites de consumo funciona normalmente por IPv6
Mas quem tem roteador que fornece apenas DNS IPv4 teve o problema de ficar totalmente sem internet
Dá a sensação de que a Microsoft poderia prestar mais atenção nisso
Para verificar se o IPv4 tinha voltado, ainda era preciso lembrar o hostname mDNS atribuído ao roteador
Sinceramente, já aconteceu de o IPv4 cair aqui em casa, e minha esposa nem percebeu
Google, Facebook, Apple/iCloud e quase todos os serviços baseados em CloudFlare funcionam bem por IPv6
Minha experiência é parecida
Problemas de IPv6 são realmente difíceis de diagnosticar e reproduzir, e vira aquele ciclo de “mas no meu computador funciona?”
A maioria das ISPs ainda bloqueia IPv6, e até pequenas empresas às vezes tentam usar IPv6 mas esquecem coisas como registros AAAA
Aí os usuários acabam vendo situações em que algo funciona na casa de um amigo ou num café, com uma ISP mais barata, mas não funciona em casa
Pode soar estranho, mas não parece haver uma boa solução além de simplesmente torcer para o IPv4 desaparecer
Existem técnicas como Happy Eyeballs (tentar IPv4/IPv6 ao mesmo tempo e escolher o mais rápido), mas na prática os problemas aparecem mais na camada da aplicação, e faltam soluções genéricas para isso
No meu caso, faço um meio-termo: deixo o IPv6 ativado na rede, mas desativo DNS por IPv6 no navegador, e não é uma solução muito satisfatória
Se você quer usar IPv6, mas sua ISP não oferece, a Hurricane Electric (HE) oferece um serviço gratuito de túnel há muito tempo
Alguns links úteis são tunnelbroker.net, ipv6.he.net, como configurar no Fedora, blog do Brandon Rozek, como configurar no DD-WRT, script de atualização automática no fórum Mikrotik, guia do RockyLinux e várias outras formas de setup
Um cuidado importante: muitos serviços de streaming bloqueiam esse túnel, como se o reconhecessem como uma forma de contornar VPN, por causa de restrições geográficas de conteúdo
Ainda assim, graças a RA (Router Advertisement), qualquer dispositivo de rede pode anunciar uma rede IPv6 em blocos /64, então vários dispositivos da rede podem usar endereços IPv6 mesmo que o roteador não suporte diretamente o túnel HE (desde que o roteador não filtre RA por motivos de segurança)
Também é muito prático quando você quer hospedar algo em casa sem precisar de port forwarding, usando apenas IPv6
O serviço da Hurricane Electric é bom, mas agora que cada vez mais ISPs oferecem IPv6 por padrão, os usuários comuns estão deixando os serviços de túnel
E alguns serviços de rede passaram a bloquear túneis da he.net por considerá-los abuso ou uso malicioso, então no fim tive de desativar o uso de IPv6 na maior parte da minha rede
Só um detalhe: o túnel da Hurricane Electric só funciona se você receber um IPv4 público da sua ISP
Se você estiver atrás de NAT, como carrier-grade NAT, vai precisar procurar outra solução para levar IPv6 para casa
Sou “cliente” do túnel gratuito 6in4 da HE no OpenBSD há 5 anos
Funciona de forma estável apenas com configuração de rede, usando coisas como o arquivo /etc/hostname.gif0
Também uso para me comunicar com um cluster de VPS configurado de propósito na AWS sem IPv4
Como a AWS cobra agressivamente por endereços IPv4, isso ajuda muito a economizar custos
Se você realmente está em um ambiente only-v6 e precisa acessar v4, uma forma fácil é usar um gateway público de DNS64+NAT64
Veja a lista de provedores públicos do nat64.net
Normalmente basta trocar o servidor DNS
O DNS64 sintetiza registros AAAA para sites que não têm AAAA, apontando para uma caixa NAT64
Então o NAT64 recebe o tráfego e faz a conversão de protocolo + NAT
Dá para testar na prática com comandos como
digoucurle acessar lugares como o github na horaNa Europa, dá para usar diretamente o nat64.net com bastante conforto
Minha experiência com isso foi realmente boa
Com o Cloudflare WARP, a sensação de velocidade é muito melhor
Pelo WARP também é possível acessar diretamente endereços IPv4
Às vezes acho curioso existirem usuários IPv6-only
Antigamente, no caso oposto (ambiente IPv4-only precisando de acesso IPv6), se você tivesse controle total do servidor, a melhor solução rápida era usar um proxy SOCKS5 com
ssh -DBastava configurar só o navegador para usar o proxy socks e pronto
Fazer isso no sistema inteiro já dá um pouco de medo, porque pode até derrubar a própria conexão ssh
Estou numa situação parecida
Já tem umas duas semanas que existe um ticket aberto sobre falha no IPv4, e a resposta é sempre “um técnico vai cuidar disso em breve”
Como o IPv6 funciona, aparentemente eles não tratam como indisponibilidade total
Na Alemanha existem regras sobre compensação ao consumidor nesses casos, então vou verificar se este caso se encaixa
O problema da abordagem sugerida no post é que faixas de IP de datacenter acabam bloqueadas por vários serviços, exigem captcha ou são tratadas como IP de VPN, então não há muito como evitar isso
No meu caso eu precisava resolver isso para a casa inteira, então configurei regras de roteamento e NAT com Wireguard no roteador, e dei sorte de usar um equipamento mais aberto como o Ubiquiti EdgeRouter
Se fosse um FritzBox, acho que seria bem mais difícil
Ainda assim, o desempenho do roteador é limitado, então com muitas conexões tudo fica lento; por isso estou pensando em trocar para IPSec com suporte a hardware offloading
O FritzBox também oferece um processo de configuração por GUI muito bom para conexões VPN
A ideia padrão é FritzBox com FritzBox, mas qualquer VPN compatível serve
Ele também permite configurar rotas IPv4/IPv6 fixas
O maior problema é descobrir que configurações de criptografia IPSec a outra ponta exige; Wireguard é mais fácil, mas em compensação tem a questão da aceleração por hardware
Se necessário, também existe a técnica de fazer backup da configuração inteira do FritzBox, editar manualmente e depois recalcular o checksum para reenviar
A AVM esconde uma quantidade enorme de configurações avançadas que não expõe ao usuário, e isso é intencional
Em parte, é para dificultar um pouco e evitar que alguém quebre o roteador sem querer
Não conheço bem a situação da Alemanha, mas na Holanda, se você usa a mesma ISP para internet fixa e móvel, dá para pedir dados móveis grátis quando a rede fixa cai
Se possível, vale a pena perguntar à ISP se essa opção existe
Mesmo depois de tanto tempo, ainda não encontrei um motivo claro para migrar todos os equipamentos e meu homelab para IPv6
Port forwarding e firewall ainda me parecem mais intuitivos, enquanto mudar para IPv6 parece significar semanas de troubleshooting, firewall e reconfiguração de endereços
Queria saber se estou deixando escapar alguma coisa
Na prática, neste momento você quase não está deixando nada escapar
No futuro, se empresas grandes como Google e Cloudflare não conseguirem mais absorver o custo crescente dos endereços IPv4, talvez passem a criar incentivos para IPv6, como limitar velocidade em conexões IPv4
A AWS antes cobrava só por Elastic IP IPv4 não utilizado, mas agora cobra mesmo quando está em uso
Quando você for atualizar gateway ou roteador no futuro, provavelmente vale a pena simplesmente deixar o IPv6 ativado; por enquanto, usando dual-stack, seus equipamentos e serviços atuais continuam funcionando normalmente
Sobre alocação automática de endereços no IPv6, historicamente houve uma bagunça de abordagens, mas parece haver uma convergência para SLAAC, enquanto no lado das ISPs o DHCPv6 ainda deve continuar por bastante tempo
Na verdade, não é tão difícil assim
Se sua rede doméstica não for particularmente complexa, dá para configurar IPv6 investindo só um tempinho à noite
No caso da Comcast, basta ativar a opção de IPv6 no roteador que a ISP fornece o prefixo, e isso já é anunciado automaticamente na rede; aí é só abrir no firewall as portas que você quiser
Você não está perdendo nada
Em ambiente enterprise, os pontos negativos e a complexidade da adoção de IPv6 pesam mais do que os benefícios
Eu administro cerca de 3.500 equipamentos, 7 prédios, 2 links WAN de 10 Gbps, 1 de 4 Gbps e 26 endereços IPv4 públicos
Até agora não houve absolutamente nenhum motivo para eu precisar usar IPv6
Operar em dual-stack cria carga e complexidade desnecessárias na rede
Aliás, recentemente tentei solicitar um bloco fixo de IPv6 duas vezes e fui recusado nas duas
Na prática não há ganho, e ainda é difícil até conseguir a alocação
Pelo guia da ARIN para primeira solicitação de IPv6,
→ possuir alocação IPv4
→ ter multihoming IPv6 planejado de imediato
→ ter 13 sites finais (escritórios etc.) em 1 ano
→ precisar de 2.000 endereços IPv6 em 1 ano
→ precisar de 200 sub-redes /64 em 1 ano
é necessário cumprir pelo menos um desses critérios para se candidatar
Gosto muito da política da Apple App Store que exige que todos os apps funcionem em redes IPv6-only
Para quem desenvolve, a primeira experiência pode surpreender, mas do ponto de vista do consumidor esse tipo de exigência é muito bem-vindo
Mas essa política não exige que o servidor tenha endereço IPv6
Então fiquei curioso se, por app, o github é acessível também por v6
No trabalho, operamos várias VPNs IPv6-only para acesso à infraestrutura interna
O maior problema é que clientes Windows e macOS exigem um servidor DNS v6
Como o cliente pode ou não estar em uma rede com suporte a v6, rodamos um servidor DNS dentro da própria VPN e o entregamos automaticamente ao cliente
Mas, quando a VPN cai, o app do Wireguard não consegue restaurar o DNS original, e isso gera vários problemas
Não lembro exatamente o método, mas o macOS funcionava sem problemas recebendo apenas endereço v6
Basta atribuir um endereço ULA ao host, e isso é fácil se o usuário souber como fazer
O app de VPN pode usar um script para adicionar esse ULA diretamente à rede IPv6-only
Só não dá para esquecer esse ULA lá para sempre, porque isso pode causar problemas quando o usuário mudar para outra rede v6
Se você passar pela mesma situação, dá para montar facilmente um ambiente de proxy socks com
ssh -D 8080 user@hostnameDepois disso, é só definir o proxy do navegador como
localhost:8080Eu ia dar exatamente esse conselho
Como solução temporária é muito simples, e também funciona muito bem como ferramenta permanente quando necessário
Só precisa que
AllowTcpForwardingesteja ativado nosshd_configEu sempre uso esse método em Wi‑Fi público
Não preciso pagar por um serviço de VPN, nem confiar nele; basta mandar tudo como proxy socks pelo meu servidor da infomaniak
Pessoalmente, tenho muitas reclamações sobre o IPv4, principalmente porque minha ISP me força a usar só IPv4, o que é ainda mais frustrante
Vejo a lentidão da adoção do IPv6 como um grande fracasso da indústria de tecnologia
Fico pensando quem deveria ser responsabilizado
Se é culpa de fabricantes de roteador com firmware ruim, da liderança das ISPs empurrando IPv4, dos especuladores de endereços IPv4, da falta de treinamento de engenheiros e equipes de suporte de rede etc.; acho que precisamos discutir mais a fundo as causas
Assim como a internet conseguiu migrar relativamente bem do TLS 1.0, parece que também deveria conseguir superar o IPv4
Talvez no futuro algo como proxies com IA para código legado possa virar uma solução
A migração do TLS 1.0 foi mais fácil por causa do princípio end-to-end
Bastava servidor e cliente suportarem o novo protocolo; os equipamentos intermediários (roteadores, switches etc.) só precisavam olhar para a camada de rede (IP), sem se importar com a nova versão do TLS
Quando você muda o protocolo da camada de rede (IP), todos os equipamentos intermediários da rede são afetados
Aliás, até na adoção do TLS 1.3 houve o absurdo de middleboxes quebrarem o princípio end-to-end ao inspecionar e alterar tráfego, a ponto de o TLS 1.3 precisar se disfarçar de reconexão TLS 1.2 por compatibilidade
A diferença é que, no TLS, basta servidor e cliente suportarem, e os equipamentos intermediários só precisam enxergar pacotes TCP
Já o IPv6 exige suporte de todos os equipamentos no caminho entre servidor e cliente, então é uma tecnologia dependente do “mínimo denominador comum”
A atualização de TLS não mudou tanta coisa assim, enquanto o IPv6 mudou coisas demais ao mesmo tempo
Olhando em retrospecto, dá a sensação de que teria sido mais fácil adotar se o IPv6 simplesmente tivesse ampliado os endereços para 64 bits e só
Na prática, muita gente é resistente à migração porque o benefício concreto é muito pequeno ou quase inexistente
Não existe nenhuma grande teoria conspiratória do IPv4; simplesmente o retorno não compensa o trabalho e o risco
Existe uma piada no setor de redes: “IPv6 é uma solução acadêmica enfiada à força em um problema de engenharia”
Quando se pensa em adoção real em campo, operação e manutenção em larga escala mantendo compatibilidade com IPv4, o IPv6 é complexo demais
O IPv4, fora a escassez de endereços, praticamente não tem outros problemas concretos, então dificilmente vai desaparecer
Por isso, no mundo real, o IPv6 não tem conseguido se tornar uma solução prática de verdade