149 lines
7.5 KiB
Markdown
149 lines
7.5 KiB
Markdown
# 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.
|