[Tutorial] Como Proteger sua Rede e Implementar IPv6 Interno com NAT66/NPt

[millerwissen]

Fiz um tutorial sobre isto nos fóruns do pfSense (firewall de código aberto baseado em FreeBSD) e o meu objetivo era publicá-lo aqui também, já que uso ambos apesar que hoje em dia me inclino mais para o OPNsense por causa das políticas da Netgate.. mas, pessoalmente, prefiro a UI (User Interface, interface gráfica) do pfSense, apenas velhos hábitos e tudo mais, a versão original deste tutorial foi feita em Inglês e como também tenho um pouco de conhecimento da língua portuguesa devido à experiência com empresas de telecomunicações no passado decidi também adaptar este a português.

-- If you're interested on the original english version by all means do go here instead it will make a lot more sense to english speakers, no need to translate this portuguese version: https://forum.opnsense.org/index.php?topic=47644.0 --

Estou literalmente cansado de ler sobre pessoas que não sabem como o IPv6 (protocolo de endereçamento da Internet versão 6) funciona na internet em geral, assumindo que suas únicas opções são "endereços públicos ou nada"; qualquer coisa fora de ULAs (Unique Local Addresses, endereços locais únicos) sem acesso à Internet ou IPv6 público = impossível. A pior parte é que usam isso como desculpa para não implementar IPv6 na sua rede, mas agora isso não será mais um problema este tutorial vai explicar tudo.

O objetivo deste tutorial é mudar esse conceito de uma vez por todas e, com sorte, alterar ideologia incorreta estabelecida no passado. Com este tutorial quero realmente estabelecer o conceito, padronizar prefixos e responder a todas as perguntas de uma vez por todas.

Se você só quer o tutorial, pule para o capítulo onde falo disso, mas antes uma introdução ao escopo do problema. E desculpem o desabafo :)

1 - Introdução
NAT44 (Network Address Translation IPv4-to-IPv4, tradução de endereços IPv4-para-IPv4) surgiu para resolver um problema: a falta de endereços IPv4 (protocolo de endereçamento da Internet versão 4) ou pelo menos muitos presumiriam isso à primeira vista. Se você perguntar ao pessoal da IANA (Internet Assigned Numbers Authority, órgão que distribui endereços IP) sobre o RFC 1918 (documento que define faixas privadas IPv4), depois de eles recobrarem a consciência dos ataques de pânico ao ouvir esse RFC, você receberá muitos comentários zangados, desdenhosos e carrancudos sobre quão horrível foi, e que o IPv6, com todos os endereços públicos, veio exatamente para resolver esse problema; ou seja, todo o propósito do IPv6 seria sanar a escassez de endereços do IPv4.

A realidade é que o NAT44 trouxe um grande benefício de segurança: seus computadores podem ficar em uma rede interna segura sem ficarem imediatamente expostos à Internet ou dependerem de um firewall de sistema sobre o qual você pode ou não ter controle. Você também não precisa se preocupar com tráfego não criptografado sendo "sniffado" (sniffed/farejado/interceptado) pelo seu ISP (Internet Service Provider, provedor de Internet) no trânsito entre máquinas internas. Isso significa que o NAT é um recurso de segurança? Sim e não. O ponto de ter um edge router (roteador de borda) e um core router (roteador de núcleo) é controlar e direcionar tráfego com muito mais poder de processamento do que o seu telefone/geladeira/câmera de segurança possui em termos de roteamento e firewall.

O motivo de existência do NAT (Network Address Translation, tradução de endereços) é simples: controle. Sua rede, suas regras; ninguém mais tem direito de forçá-lo a desenhar/criar sua rede interna de certa maneira. Em termos de segurança, o NAT dá controle avançado de portas onde necessário: você pode rotear portas por links diferentes, fazer load-balancing (balanceamento de carga) e, em geral, ter controle absoluto de onde o tráfego vem e por onde sai. Mas isso significa que, se você tiver uma máquina cujo serviço ficaria comprometido caso certa porta estivesse exposta à Internet, mantê-la em uma rede interna inalcançável externamente coloca o NAT como o recurso de segurança mais importante. Obviamente, se você rotear essa porta para um IP público (v4 ou v6, tanto faz), estará igualmente comprometido; o importante aqui é o controle que o NAT disponibiliza sendo este algo extremamente simples mas extremamente importante, roteamento básico.

O pessoal da IANA (a IANA é responsável por distribuir e reservar prefixos de IPv4 e IPv6, eles estão abaixo do IETF (Internet Engineering Task Force) que decidem nos padrões porém a IANA é responsável pela distribuição logo quando menciono IANA aqui obviamente significa IANA e IETF, eles decidiram que a implantação IPv6 "normal" DEVERÁ ser pública e que NAT é algo "maligno"; seu sistema deve lidar com segurança individualmente (sem firewall de rede no meio como o OPNsense). Isso é comum para pessoas que apenas recebem o modem do seu provedor de internet em casa, não é todo mundo que conhece os benefícios de ter um firewall para toda a rede, e podem perceber isso como gasto desnecessário porque "simplesmente funciona sem". Na realidade, ter um firewall é muito importante, e não estou fazendo propaganda de plataformas de firewall seja OPNsense, pfSense ou outra solução paga ou gratuita - isso se aplica a qualquer firewall que controla o tráfego de fora para dentro.

Pergunte a si mesmo: você quer ou precisa de um endereço IP público na sua geladeira inteligente, no seu telefone, na sua câmera de segurança, até mesmo no seu computador? Você realmente precisa disso? Está acessando os recursos do dispositivo diretamente pela Internet (sem usar um túnel site-to-site criptografado como WireGuard (software de VPN) com rotas estáticas/iBGP)? Você quer que uma botnet tenha o mesmo acesso aos seus dispositivos que você em termos de roteamento enquanto essa tenta métodos comuns de 'hackear' ou força bruta enquanto você dorme? Isso faz algum sentido pra você? Parece um bom jeito de montar rede? Porque é assim que a IANA acha que deveria ser: você compra um dispositivo "smart/inteligente" sem acesso às suas configurações de firewall, estes podem ser por exemplo geladeiras modernas, ar-condicionados, e todos dispositivos que se conectam à sua rede e têm funções "smart", usam app/integração com outros sistemas, muitos destes (infelizmente) dependem de um servidor remoto na internet (um que você não tem controle algum obviamente) para funcionar e obter atualizações/updates; se o fabricante declarar EOL (End-of-Life, fim de vida) e você manter o dispositivo conectado à rede vai eventualmente ter problemas pois provavelmente nunca forneceram acesso para você controlar serviços/portas diretamente.

Sim, estou absolutamente furioso com a IANA por estas e outras muitas razões. Tentei fazer um "ID" (Internet Draft, rascunho de padrão da internet) no passado para reconhecer e padronizar prefixos para NAT66 (Network Address Translation IPv6-para-IPv6), mas, ao ser recebido com hostilidade por praticamente todos lá, desisti e decidi simplesmente fazer tutoriais etc. No fim das contas, você não precisa da permissão de ninguém para fazer nada internamente; pode usar qualquer prefixo IP dentro da sua rede privada. A única vantagem de ter prefixos padronizados é evitar a possibilidade de não conseguir alcançar uma rede externa que alguém usa o mesmo prefixo um problema que neste caso não será jamais importante com endereços locais. Eles padronizaram alguns prefixos, praticamente todos dentro da sub-rede "f000::/4" (sub-rede IPv6 especial) feita para muitos propósitos, não só NAT/ULA; o prefixo "F" foi projetado para usos especiais: multicast, ula, link-local, site-local etc.

O que é f000::/4? Vai de f000:0000:0000:0000:0000:0000:0000:0000 até ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff. Consiste de 8 hextets (blocos hexadecimais de 16 bits; em IPv4 este se chama octetos). É perfeito para NAT66 e NPt (NPT significa Network Prefix Translation, tradução de prefixo) NAT66 permite personalizar os 8 hextets e NPt 4 hextets externos e 8 internos vou explicar a seguir, esta flexibilidade permite muita liberdade para organizar endereços internos. Você pode fazer algo assim, por exemplo:

f1:33:3:1a::1:2:3:4

f1 = Rede 1 / Organização 1
33 = País (neste exemplo França)
3 = Cidade (neste exemplo Strasbourg)
1a = Local 1 Prédio A
:: = Separador
1 = 1.ª Separação Interna
2 = 2.ª Separação Interna
3 = 3.ª Separação Interna
4 = 4.ª Separação Interna

Isso lhe dá a rede f1:33:3:1a::/64 para esse local neste exemplo. Novamente: só um exemplo - sinta-se livre para personalizar; afinal, a rede é sua.

Algo como f1:33:3:1a::77:2a (poderia significar, por exemplo, 77 = Máquinas Virtuais, 2a = VM 2 e a letra A é o primeiro IP virtual, ou simplesmente 2 para NICs/placas de redes físicas). f1:33:3:1a::/64 sendo a rede neste exemplo, tamanho conveniente, fácil de rotear, organizado e, se o IPv6 público mudar (ou o prefixo inteiro), os endereços internos permanecem estáticos/dinâmicos atribuídos pela sua infraestrutura, sem interrupções.

Viu como isso é personalizável? Em vez de usar endereços aleatórios do ISP, você tem flexibilidade e muitos endereços graças ao f000::/4. Nem tudo está disponível para uso, exploremos mais:

f000::/8 - f999::/8 = "números", disponível para uso
fa::/8 e fb::/8 = também não usados, disponível para uso
fc::/8 e fd::/8 = ULAs padronizadas (RFC 4193). Muitos usam porque é "oficial", análogo ao RFC 1918, mas usar estes pode causar problemas. Por exemplo, o protocolo "Matter" (comum em lâmpadas inteligentes conectadas via Wi-Fi) atribui endereços fd::/8 para comunicação interna. Se você usa Matter em casa, evite fd::/8. fc::/8 pode ser usado por VPNs etc., então costumo não tocá-los. Tecnicamente fa, fb, fc também são opções. Gosto de usar fa e fb para redes SAN.
fe80::/8 - não uso o prefixo "fe" porque fe80::/10 é link-local (RFC 4291). fec0::/10 era site-local, mas está obsoleto (RFC 3879)
ff00::/8 = multicast (RFC 4291)

Em resumo, você pode usar qualquer coisa de f000::/4 exceto fe, ff, e deve evitar fc, fd por via das dúvidas. O resto é seu - ex.: f1f3::, f333::, f16::, f22::, f35::, f117:: etc.

Para uma SAN (Storage Area Network, rede de armazenamento), algo como fa::3:1a/64, seguindo o exemplo da VM acima, até fa::1 seria um IPv6 curtinho fácil de lembrar, talvez mais fácil de memorizar que IPv4. Tudo isso pode ser sua realidade. IPv6 não precisa ser complicado ou difícil e certamente não é mais difícil que IPv4.

2 - Entendendo suas opções no nível de design de rede

A - IPv6 Direto
Às vezes desejado, como servidores com IPv4 público direto na máquina. Se você tem recursos limitados, uma VM ou máquina com um único IPv4 e até um prefixo IPv6 grande mas propósito simples, talvez queira apenas IPv6 e IPv4 públicos sem nada no meio além de ufw/iptables (firewall de host). Tem uso, mas certamente não deveria ser o padrão ou ser a única forma "real" de IPv6 a ser ensinada em geral. Assim como usar IPv4 público, mesmo que houvesse endereços suficientes, pareceria inseguro (e é, se não tomar os cuidados necessários), mas significa zero complexidade extra de roteamento.

B - NAT66/NPt
Isto é basicamente o mesmo que RFC 1918 (os velhos endereços 192.168.x.x). A diferença entre NAT66 e NPt é como portas são tratadas. Com NAT66, você terá a mesma limitação do IPv4 em termos de portas - 65.536 portas por IP público. Se não for suficiente, use múltiplos IPs públicos. Cada um dá o mesmo número de portas. Note que isso é a quantidade de conexões concorrentes, não o total que você pode fazer na vida. Para a maioria dos usuários domésticos, não é problema. Além disso, tráfego via VPN site-to-site (WireGuard + rotas estáticas/iBGP) não conta. Se suas redes estão interligadas por VPN, NAT66 continua ótimo.

A outra opção é NPt (Network Prefix Translation), que traduz todos os endereços internos para o prefixo externo. Isso presume que você tem prefixo (por exemplo, um prefixo externo /64) delegado a você pelo provedor. Muitos assumem: "todo ISP que suporta IPv6 me dará pelo menos um /64 delegável totalmente aberto, certo?" Errado.

Exemplo:

IPv6 Interno = f1:33:3:1a::1:2:3:4a/64
Prefixo Externo = 2001:4860:4860::/64
Endereço após NPt = 2001:4860:4860::1:2:3:4a/64

Eu não moro no Brasil ou Portugal, por isso vou usar um exemplo com o qual eu sou mais familiar, mas o conceito se aplica a qualquer provedor (talvez até qualquer provedor no mundo). Por exemplo, na Alemanha, se você ligar para a Vodafone pedindo o modo bridge, você recebe 1 IPv4 público (luxo hoje em dia; às vezes é CGNAT ou DS-Lite dependendo dos provedores por aí). Mas se você configurar para usar 1 endereço IPv6 apenas, como um IPv6 /128, seu IPv6 fica totalmente aberto e pode rotear portas normalmente. Se configurar com Prefix Delegation (Delegação do Prefixo), um prefixo /64 terá portas fechadas e praticamente todas as portas não vão funcionar. Isso é feito de propósito pelo provedor para mitigar problemas citados anteriormente, pois usuários domésticos não sabem desenhar redes - ou pelo menos isso é o que os provedores pensam do usuário "cotidiano". Eles bloqueiam "todas" ou a maioria das portas de entrada por padrão, reduzindo botnets, porém também reduzindo função quando você, por exemplo, quer acessar a porta ou uma aplicação precisa da porta aberta. Com NAT66 você realmente tem todas as 65536 portas disponíveis neste provedor, mas só se usar /128 na WAN e NAT66. Logo, neste exemplo o NAT66 é obviamente superior. Se o ISP liberar prefixo, pode também considerar o NPt.

Também tenho tutorial para pfSense nos fóruns pfSense (em inglês); aqui vou focar só no OPNsense (embora o procedimento é parecido).

3 - Como fazer no OPNsense
Vá em Firewall > NAT > Outbound

Mude NAT Mode para Hybrid, depois Save/Apply Changes

Adicione uma nova Map Rule:

--------
Interface: WAN
TCP/IP Version: IPv6
Protocol: Any
Source Address: LAN net (ou defina manualmente, ex.: f1:33:3:1a::/64)
Translation: WAN Address (ou a interface WAN respectiva)
Description: "F--- IANA BS I have NAT66 and I am Free" ou qualquer outra descrição de sua preferência, comentários vulgares contra IANA/IETF são preferidos aqui
--------
Click no Save e Apply Changes

4 - Coisas adicionais (mas são importantes)
O IPv6 faz as coisas um pouco diferente: não é somente o servidor DHCP que precisa, IPv6 tem também o RA (Router Advertisement, anúncio de roteador) e DHCPv6 (protocolo de configuração dinâmica IPv6). O DHCPv6 tem menos opções que no IPv4, mas a ideia é a mesma. Já o RA trabalha junto com o DHCPv6, atribuindo endereços de modo diferente. Ative ambos; alguns dispositivos não suportam DHCPv6, outros pegam endereços de um ou de outro. Ter múltiplos endereços em uma única NIC é comum - não se assuste se vir 5 IPv6 num mesmo adaptador. Eu, pessoalmente, gerencio com servidor DNS/DHCP separado; você pode também, ou usar só o OPNsense:


- Router Advertisements
Vá em Services > Router Advertisements

Configure assim, por exemplo:

------
Router Advertisements: Assisted
Router Priority: High
Advertise Routes: Prefix f1:33:3:1a:: Length /64
DNS Servers:
1 - f1:33:3:1a::111:1/64
2 - f1:33:3:1a::111:2/64
Domain Search List: dinamico.suarede.seudominio.net
------

Click Save e reinicie o serviço RA

Importante: RA atribui qualquer endereço livre no range - não há como restringir sub-faixas como no DHCP, mas não atribui algo já em uso, então raramente causa problemas.

ISC DHCPv6
Vá em Services > ISC DHCPv6

Configure conforme necessidade (se tem NPt/PD, vai aparecer o prefixo delegado). No IPv6, o Gateway é anunciado via RA; no DHCPv6 só atribuímos endereços.

Salve e reinicie o servidor ISC DHCPv6.

Bloqueando f000::/4 na WAN
Como nem todos os IPs em f000::/4 são "bogon", se o OPNsense não bloquear, tentativas de sair podem ser encaminhadas ao upstream gateway. Se não desejar isso, crie regra para bloquear:

Vá em Firewall > Rules > WAN

Adicione nova regra:

-------
Action: Block
Interface: WAN
TCP/IP Version: IPv6
Protocol: Any
Source: Single Host or Network f000::/4
Destination: Any
Description: Block internal IPv6 (f000::/4) from leaving via WAN
-------

Click no Save e Apply Changes

Reinicie toda a rede, faça todos os testes necessários e pode ficar feliz agora pois sua rede é provavelmente superior a 99.9% da maioria da população.

Sem tráfego? Verifique configurações de gateway e regras em conflito.

E o NAT64?
Isso é outra coisa - está no RFC 6052, que designa 64:ff9b::/96 para tradução IPv6-para-IPv4; não confunda com NAT66 - usos completamente diferentes e fora do escopo deste tutorial.

Pretendo fazer um tutorial sobre VPN multi-site algum dia, mas vale dizer: com esses IPv6 internos você pode configurar túneis site-to-site criptografados e interligar tudo por exemplo seu escritório, servidor no datacenter diretamente, seus amigos etc. Possibilidades são infinitas: basta um lado esquerdo diferente do prefixo /64 para cada local, túnel + rotas estáticas ou iBGP e você terá acesso direto e seguro ponto a ponto desta maneira, sua "Intranet" pessoal.