Dia 30: Projeto Final — Rede PME Completa

Chegamos ao trigésimo e último dia do curso de redes. Este artigo fecha a série com um projeto prático que integra todos os conceitos abordados ao longo de 29 dias: topologia de rede, VLANs, encaminhamento, firewall nftables, VPN WireGuard e monitorização. O objetivo é construir uma rede PME (Pequena e Média Empresa) completa, funcional e segura, desde o cabo até ao painel de monitorização.

Este projeto final segue uma abordagem incremental — cada secção constrói sobre a anterior, como numa implementação real. No final, terá uma rede segmentada por departamentos, com firewall configurado, acesso remoto VPN e monitorização ativa.

1. Introdução ao Projeto Final

Uma rede PME típica precisa de separar tráfego por departamentos, proteger contra acessos externos, permitir trabalho remoto seguro e ter visibilidade sobre o estado dos equipamentos. Durante os dias anteriores deste curso cobrimos cada um destes tópicos individualmente — desde o modelo OSI (Dia 1) até ao encaminhamento dinâmico (Dia 11), firewalls (Dia 12) e VPNs (Dia 20).

O projeto final propõe um cenário realista: uma empresa com três departamentos (Vendas, TI, Servidores) mais uma VLAN de gestão, ligada à Internet através de um router/firewall Linux com nftables, acesso remoto via WireGuard e monitorização com Zabbix e Netdata.

1.1 Requisitos do projeto

A rede deve cumprir os seguintes requisitos: segmentação de tráfego com VLANs; encaminhamento entre VLANs controlado por ACLs; firewall stateful com política predefinida drop; VPN para acesso remoto de funcionários; monitorização de largura de banda, CPU, memória e disponibilidade de serviços.

2. Topologia da Rede PME

A topologia usa uma arquitetura em estrela hierárquica: a Internet liga ao router/firewall Linux, que por sua vez liga a um switch L3 gerível. O switch distribui a rede em quatro VLANs, cada uma servindo um departamento ou função específica.

# Topologia PME
# Internet -> Router/Firewall (nftables) -> Switch L3 (VLANs)
# VLANs: 10-Vendas, 20-TI, 30-Servidores, 99-Gestao

A VLAN 99 (Gestão) é dedicada à administração dos equipamentos — switches, access points e IPs de gestão. Separar a gestão do tráfego de utilizadores é uma boa prática de segurança que limita o acesso à administração de infra-estrutura. O router/firewall faz NAT para a Internet e encaminhamento entre VLANs com regras de firewall a controlar que tráfego pode circular entre segmentos.

3. Configuração de VLANs e Encaminhamento

As VLANs são configuradas no switch L3 usando Cisco IOS como exemplo. Cada VLAN recebe um identificador numérico e um nome descritivo. Depois, as portas do switch são atribuídas às VLANs correspondentes — portas de acesso para equipamentos finais e portas trunk para interligação entre switches e com o router.

# Configurar VLANs no switch (Cisco IOS)
vlan 10
  name Vendas
vlan 20
  name TI
vlan 30
  name Servidores
vlan 99
  name Gestao
!
# Porta de acesso para Vendas (interface Fa0/10)
interface FastEthernet0/10
  switchport mode access
  switchport access vlan 10
!
# Porta trunk para o router/firewall
interface GigabitEthernet0/1
  switchport mode trunk
  switchport trunk allowed vlan 10,20,30,99

No router/firewall Linux, cria-se sub-interfaces VLAN (802.1Q) para cada VLAN. O encaminhamento entre VLANs é feito pelo próprio Linux, que actua como router inter-VLAN. É fundamental activar o IP forwarding no kernel.

# Ativar IP forwarding
echo 1 > /proc/sys/net/ipv4/ip_forward
# Tornar persistente
echo "net.ipv4.ip_forward = 1" >> /etc/sysctl.conf
sysctl -p
# Criar sub-interfaces VLAN (ex: eth0 trunk)
ip link add link eth0 name eth0.10 type vlan id 10
ip addr add 10.10.10.1/24 dev eth0.10
ip link set eth0.10 up
ip link add link eth0 name eth0.20 type vlan id 20
ip addr add 10.10.20.1/24 dev eth0.20
ip link set eth0.20 up

Com as VLANs configuradas e o encaminhamento ativo, cada departamento consegue comunicar com o seu gateway. O passo seguinte é restringir o tráfego entre VLANs com regras de firewall — nem todos os departamentos precisam de aceder a todos os outros. Por exemplo, Vendas não precisa de aceder à VLAN de Servidores diretamente, apenas aos serviços publicados.

4. Firewall com nftables

O nftables é o sucessor do iptables, coberto no Dia 12 do curso. Para este projeto, configuramos um firewall stateful com política predefinida drop na chain de input — apenas tráfego estabelecido, loopback e portas explicitamente abertas são aceites. A chain forward controla o encaminhamento entre VLANs.

# Firewall nftables
table inet filter {
    chain input {
        type filter hook input priority 0; policy drop;
        ct state established,related accept
        iif lo accept
        tcp dport { 22, 80, 443 } accept
    }
    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state established,related accept
        # Vendas -> Servidores: apenas HTTP/HTTPS
        iif eth0.10 oif eth0.30 tcp dport { 80, 443 } accept
        # TI -> todas as VLANs
        iif eth0.20 accept
        # VPN -> Servidores: SSH
        iif wg0 oif eth0.30 tcp dport 22 accept
        # Restantes bloqueados por predefinida drop
    }
    chain output {
        type filter hook output priority 0; policy accept;
    }
}

A chain forward implementa a segmentação entre VLANs: Vendas só acede aos servidores via HTTP/HTTPS, TI tem acesso total para administração, e a VPN só permite SSH para a VLAN de Servidores. O NAT para a Internet é configurado numa tabela separada:

# NAT para saida Internet
table ip nat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;
        oif eth0 masquerade
    }
}
# Aplicar regras
nft -f /etc/nftables.conf
# Verificar
nft list ruleset

Ativar o nftables no arranque do sistema depende do init system — em systemd usa-se systemctl enable nftables. Recomenda-se testar as regras com nft -c -f /etc/nftables.conf (modo verificação) antes de aplicar, para evitar erros de sintaxe que possam bloquear acesso ao servidor.

5. VPN WireGuard para Acesso Remoto

O WireGuard, visto no Dia 20, é a escolha para acesso remoto — é leve, rápido e simples de configurar comparado ao OpenVPN. A VPN permite que funcionários acedam à rede interna a partir de casa ou em deslocação, com tráfego encriptado e autenticação por chaves criptográficas.

O servidor WireGuard corre no router/firewall Linux, na interface wg0, com a sub-rede 10.10.0.0/24 para clientes VPN. Cada cliente tem a sua própria chave privada e chave pública, que é adicionada à configuração do servidor.

# VPN WireGuard — servidor (wg0.conf)
[Interface]
Address = 10.10.0.1/24
ListenPort = 51820
PrivateKey = <chave_privada_servidor>
# Encaminhamento de trafego VPN
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT

[Peer]
PublicKey = <chave_cliente>
AllowedIPs = 10.10.0.2/32
# Para aceder VLANs internas via VPN:
# AllowedIPs = 10.10.0.2/32, 10.10.30.0/24

# Cliente WireGuard (cliente.conf)
[Interface]
Address = 10.10.0.2/24
PrivateKey = <chave_privada_cliente>
DNS = 10.10.30.10

[Peer]
PublicKey = <chave_publica_servidor>
Endpoint = empresa.exemplo.pt:51820
AllowedIPs = 10.10.0.0/24, 10.10.30.0/24
PersistentKeepalive = 25

As chaves são geradas com wg genkey e wg pubkey. O campo AllowedIPs no cliente define quais as sub-redes acessíveis através do túnel — incluir apenas as necessárias reduz a superfície de ataque. O PersistentKeepalive mantém o túnel aberto mesmo atrás de NAT.

6. Monitorização com Zabbix/Netdata

A monitorização fecha o ciclo — sem visibilidade, não há gestão. Para este projeto combinamos duas ferramentas complementares: Netdata para métricas em tempo real com baixa sobrecarga, e Zabbix para alertas persistentes, dashboards históricos e monitorização de disponibilidade de serviços.

6.1 Netdata — métricas em tempo real

O Netdata instala-se com um único comando e começa a recolher métricas imediatamente — CPU, memória, disco, rede, processos. É ideal para diagnóstico rápido e dashboards em tempo real.

# Monitorizacao -- instalar Netdata
curl -Ss https://get.netdata.cloud/kickstart.sh | sh
# Apos instalacao, acessivel em:
# http://servidor:19999
# Configurar para restrito a VLAN de TI:
# editar /etc/netdata/netdata.conf
# [web]
#   bind to = 10.10.20.1:19999

6.2 Zabbix — alertas e histórico

O Zabbix corre num servidor dedicado na VLAN de Servidores. Usa agentes instalados em cada máquina monitorizada para recolher métricas. Configura-se triggers para alertar quando CPU excede 80%, disco fica abaixo de 10% livre, ou um serviço deixa de responder.

# Instalar agente Zabbix (Debian/Ubuntu)
wget https://repo.zabbix.com/zabbix/7.0/debian/pool/main/z/zabbix-release/zabbix-release_7.0-1+debian12_all.deb
dpkg -i zabbix-release_7.0-1+debian12_all.deb
apt update
apt install zabbix-agent2 -y
# Configurar /etc/zabbix/zabbix_agent2.conf
# Server=10.10.30.100
# ServerActive=10.10.30.100
# Hostname=servidor-vendas
systemctl enable --now zabbix-agent2

A combinação Netdata + Zabbix oferece visibilidade completa: Netdata para diagnóstico instantâneo (o que está a acontecer agora) e Zabbix para análise histórica e alertas (o que aconteceu ao longo do tempo). Ambos devem ser restritos à VLAN de TI — nunca expostos diretamente à Internet.

7. Resumo do Curso e Próximos Passos

Este projeto final fecha 30 dias de aprendizagem. Desde os fundamentos do modelo OSI e endereçamento IP (Dia 1) até ao encaminhamento dinâmico (Dia 11), firewalls (Dia 12) e VPNs (Dia 20), cada conceito individual encontrou o seu lugar numa arquitetura completa. A tabela seguinte resume como cada bloco do curso se materializa no projeto final:

7.1 Próximos passos

Para evoluir este projeto, considere as seguintes áreas: implementar encaminhamento dinâmico com OSPF para redundância entre routers; adicionar um segundo router para alta disponibilidade com VRRP; integrar autenticação 802.1X para controlo de acesso à rede por utilizador; configurar IPv6 dual-stack nas VLANs; implementar SIIM (Security Information and Event Management) com ELK Stack para análise de registos centralizada.

Parabéns por ter chegado ao fim do curso. A melhor forma de consolidar estes conhecimentos é repetir o projeto num ambiente virtual — use GNS3, EVE-NG ou mesmo VirtualBox para simular a topologia. Modifique os parâmetros, quebre coisas deliberadamente e observe como a rede reage. É na resolução de problemas reais que a teoria se transforma em competência.