rede-domestica/CLAUDE.md

Contexto: Rede Doméstica do Ronaldo

Este arquivo dá contexto ao Claude Code sobre a infraestrutura de rede doméstica do Ronaldo (Fedora 44, KVM/libvirt, mesh Wi-Fi). Mantenha atualizado conforme a rede mudar.

Visão geral da topologia

Internet (fibra)
    │
    ▼
ZTE ZXHN F6645P (ONT da Claro)
    │  [modo BRIDGE — sem Wi-Fi, sem DHCP, apenas conversor óptico→Ethernet]
    ▼
Mesh Mercusys Halo H80X — Unidade SALA (router/DHCP/Wi-Fi principal)
    │
    ├─ Porta 1: ZTE (uplink/WAN)
    ├─ Porta 2: OrangePi PC (cabeado)
    ├─ Porta 3: Backhaul cabeado ──────────► Mesh Halo H80X — Unidade ESCRITÓRIO
    │                                              ├─ Porta 1: Backhaul (recebido)
    │                                              ├─ Porta 2: Laptop Fedora (cabeado)
    │                                              └─ Porta 3: spare/livre
    │
    └─ Wi-Fi: celulares (Ronaldo, Juliana, Roberto), TV da sala,
              2x Chromecast, Xbox (em teste — pode migrar para cabo
              via switch Gigabit adicional se a performance não for boa)

Notas da topologia

• ZTE F6645P: ONT da Claro. Será colocado em modo bridge (função oficial da Claro, sem necessidade de desbloqueio/hack). Em bridge, perde Wi-Fi e DHCP próprios; só repassa o sinal da fibra como Ethernet puro por uma única porta.
• Mesh Mercusys Halo H80X (kit com 2 unidades, Wi-Fi 6 AX3000, 3 portas Gigabit cada): assume 100% do roteamento, DHCP e Wi-Fi da casa após o bridge do ZTE. Tem Address Reservation nativo (DHCP Binding via app, em More → Advanced → Address Reservation) — diferente do ZTE da Claro, que não expõe essa opção na interface web.
• Backhaul cabeado entre as duas unidades mesh (cabo já existente entre sala e escritório) — preferível ao backhaul wireless padrão, pois libera o espectro de rádio das duas unidades para os clientes em vez de gastar banda com a comunicação entre nós.
• Xbox: testando primeiro via Wi-Fi (Wi-Fi 6, deve ser suficiente). Se a performance/latência não for boa, Ronaldo cogita comprar um switch Gigabit não-gerenciado para a sala, já que as 3 portas da unidade da sala estarão todas ocupadas (ZTE + OrangePi + backhaul). O switch permitiria conectar Xbox, TV e eventualmente um Wii, tudo cabeado.
• TV da sala: permanece no Wi-Fi.

Inventário de dispositivos (IPs e MACs)

Estado atual (antes da mesh — IPs fixos via nmcli manual)

O ZTE F6645P da Claro não expõe DHCP Binding na interface web (limitação do firmware customizado pela operadora). Por isso, os dispositivos críticos têm IP fixo configurado manualmente no próprio SO (nmcli ... ipv4.method manual), fora da faixa DHCP dinâmica do roteador (192.168.0.2–.50).

Dispositivo	MAC	IP fixo	Método
fedora (Ethernet, br0)	30:24:A9:FB:C7:6F	192.168.0.60	nmcli manual (interface br0)
fedora (Wi-Fi)	22:90:26:F9:0D:6F	192.168.0.64	nmcli manual (CLARO_F76183)
orangepipc (end0)	02:81:49:3B:6E:5D	192.168.0.61	nmcli manual (Wired connection 1)
win11 (VM, KVM bridge)	52:54:00:D9:C3:41	192.168.0.62	IP estático configurado no Windows
sandbox (VM, KVM bridge)	52:54:00:F5:4F:0E	192.168.0.63	nmcli manual (Wired connection 1)

Gateway: 192.168.0.1 (ZTE). DNS: 1.1.1.1 / 1.0.0.1 (Cloudflare). Faixa DHCP dinâmica do ZTE: 192.168.0.2–192.168.0.50 (lease time 12h / 43200s) — usada por celulares, Chromecasts, Xbox, TV, etc.

Plano para quando a mesh entrar

• Migrar as reservas de IP para o Address Reservation nativo da mesh (DHCP Binding de verdade, via MAC).
• Possivelmente reverter fedora e orangepi de IP manual (nmcli) para DHCP automático, já que a reserva da mesh garante o mesmo IP de qualquer forma — mais simples de manter.
• win11 e sandbox (VMs no host Fedora, via bridge br0 do libvirt) também podem ser migradas para reserva via mesh.

Outras infraestruturas relevantes

VMs no host Fedora (KVM/libvirt)

• Bridge br0 no host Fedora, ligada à interface física enp1s0 (substituiu a rede NAT default/virbr0 do libvirt).
• win11: VM Windows 11, interface type='bridge' em br0, modelo e1000e.
• sandbox: VM Linux (Fedora Server), interface type='bridge' em br0, modelo virtio. Tem Docker e Tailscale instalados.
• Funções Fish criadas para gerenciar as VMs sem digitar virsh diretamente: win11start, win11stop, win11kill, sandboxstart, sandboxstop, sandboxkill (em ~/.config/fish/functions/). stop = shutdown gracioso; kill = virsh destroy (força bruta, só usar se a VM estiver travada).

Resolução de nomes (/etc/hosts no host Fedora)

mDNS (Avahi) entre Fedora e OrangePi não funciona de forma confiável nessa rede (diagnosticado: a query mDNS chega ao OrangePi via tcpdump, mas o Avahi dele não responde — causa raiz não 100% confirmada, suspeita de dependência anterior do Tailscale para essa resolução). Solução adotada: entradas estáticas em /etc/hosts:

192.168.0.60   fedora
192.168.0.61   orangepi
192.168.0.62   win11
192.168.0.63   sandbox
137.131.145.213   oracle
62.84.180.13   contabo

win11 resolve nome via NetBIOS/Samba (nmblookup) como alternativa — funciona nativamente pois é Windows. Para isso ser possível, foi necessário liberar ICMP no Firewall do Windows Defender dentro da VM (perfil de rede "Público" bloqueia ping por padrão).

Servidores remotos (fora da LAN)

Nome	IP	Observação
oracle	137.131.145.213	Responde ping normalmente.
contabo	62.84.180.13	Ping bloqueado por padrão pelo Contabo Firewall (firewall de borda, separado do ufw interno da VPS). Foi liberado via painel de controle da Contabo (regra de Inbound ICMP).

Firewall do host Fedora (firewalld)

• Zona ativa: FedoraWorkstation, aplicada às interfaces wlp0s20f3, br0, enp1s0.
• Serviço mdns foi adicionado a essa zona (firewall-cmd --add-service=mdns --permanent) durante o diagnóstico de mDNS — mantido, mesmo que o mDNS para o OrangePi não tenha funcionado por outro motivo.
• Outros serviços liberados na zona: dhcpv6-client, samba, samba-client, ssh.

Coisas a evitar / lições aprendidas

• Não usar virsh edit sem EDITOR=nano — o padrão é vim, que o Ronaldo não gosta de usar.
• STP da bridge br0 demora a estabilizar (listening → learning → forwarding, ~15s por estágio) após qualquer mudança de configuração via nmcli. Um estado momentâneo de NO-CARRIER/state DOWN logo após mudar a bridge não é necessariamente um erro — pode só ser o STP em progresso. Verificar com bridge link show antes de assumir que algo quebrou.
• Tailscale: removido do Fedora (host). Ainda presente no OrangePi e na VM sandbox. Avaliar se vale remover dos dois também por consistência.
• Pretende-se criar um repositório GitHub para versionar este inventário (provavelmente como README.md + um CSV com a tabela de dispositivos), no lugar de (ou complementando) este arquivo.