Posto recebe IP da VLAN de convidados após atribuição incorreta da porta

Problema

Um posto que abria uma página web interna deixa de conseguir aceder-lhe após uma alteração na porta do switch. O browser também não abre o serviço pelo endereço IP. O DHCP continua a atribuir um endereço, pelo que a falha não significa necessariamente que o serviço DHCP esteja indisponível.

Ambiente e comportamento esperado

Este caso foi testado num laboratório Cisco Packet Tracer. Não representa um incidente de produção. A topologia usa um switch Cisco 2960, um router com subinterfaces 802.1Q, pools DHCP no router e uma ACL estendida aplicada à entrada da subinterface de convidados.

O posto de utilizador liga-se à Fa0/1; o servidor liga-se à Fa0/4). A Gig0/1do switch é um trunk 802.1Q para o router. A subinterfaceGigabitEthernet0/0.30do router tem uma ACL de entrada que bloqueia192.168.30.0/24para192.168.20.0/24`.

Em condições normais, a Fa0/1 pertence à VLAN 10 e o posto abre http://ikw.test ou http://192.168.20.20. O posto convidado não consegue aceder ao servidor pelo IP. Os nomes, endereços e interfaces são apenas do laboratório fictício.

Comportamento observado e evidências

Durante o exercício, a Fa0/1 foi colocada deliberadamente na VLAN 30. Após renovar o DHCP, o router mostrou uma nova concessão 192.168.30.22 para o mesmo identificador de cliente que anteriormente tinha recebido 192.168.10.21. A concessão antiga manteve-se em show ip dhcp binding; esta tabela, por si só, não prova qual é o IP atualmente configurado no posto.

O show vlan brief do switch mostrou Fa0/1 e Fa0/3 na VLAN 30, enquanto a VLAN 10 não tinha portas de acesso. O show interfaces trunk, executado no switch, mostrou Gig0/1 em trunk, com as VLANs 10, 20 e 30 ativas e em forwarding. O contador de bloqueios da ACL tinha ocorrências acumuladas. Depois de repor a Fa0/1 na VLAN 10 e renovar o DHCP, o acesso ao site voltou a funcionar.

O contador da ACL é acumulado: o valor isolado não identifica o posto nem prova que uma tentativa específica do browser foi bloqueada. Num teste controlado, regista o contador antes e depois da tentativa.

Causas possíveis a distinguir

• Porta de acesso atribuída à VLAN errada.
• Posto ainda com IP ou gateway antigo após uma mudança de porta.
• VLAN ausente do trunk.
• Subinterface do router ou rota indisponível.
• ACL a bloquear a rede de origem.
• Falha de resolução DNS quando o acesso direto por IP funciona.
• Serviço web indisponível para vários clientes.

Diagnóstico passo a passo

1. Verificar o endereço atual do posto

No PC do Packet Tracer, abre Desktop > Command Prompt:

ipconfig
ping 192.168.20.20

Regista IP, máscara e gateway. Um IP na rede 192.168.30.0/24, com gateway 192.168.30.1, mostra que o posto está a operar como cliente da rede de convidados. A falha no ping ou no acesso web por IP afasta uma explicação exclusivamente baseada em DNS, mas ainda não identifica o equipamento que bloqueia o tráfego.

2. Verificar a VLAN da porta no switch

No prompt privilegiado Switch#:

show vlan brief
show interfaces trunk

show vlan brief associa as portas de acesso às VLANs. Neste caso, a Fa0/1 apareceu na VLAN 30 em vez da VLAN 10. show interfaces trunk confirma que a Gig0/1 está em trunk e que as VLANs relevantes estão ativas e em forwarding. Este comando deve ser executado no switch; executá-lo no router não mostra o trunk do switch.

Se estiveres em Switch(config-if)#, usa end antes dos comandos de consulta ou acrescenta do antes do comando.

3. Relacionar DHCP e ACL no router

No prompt privilegiado Router#:

show ip dhcp binding
show ip interface brief
show access-lists

show ip dhcp binding mostra concessões e identificadores de cliente. Compara-os com o ipconfig atual do posto: após mudar de VLAN, podem coexistir uma concessão antiga e uma nova para o mesmo cliente.

show ip interface brief ajuda a confirmar o estado das subinterfaces. show access-lists apresenta as regras de bloqueio e permissão e os respetivos contadores acumulados. A ACL do laboratório bloqueia 192.168.30.0/24 para 192.168.20.0/24 e permite o tráfego para outros destinos.

Causa confirmada

A falha controlada foi a atribuição da Fa0/1 à VLAN 30. O posto recebeu um IP de convidados e passou a estar sujeito à ACL que bloqueia o acesso à rede de servidores. O trunk estava operacional; alterar a sua configuração não resolveria esta falha.

Resolução

Confirma primeiro que Fa0/1 é a porta do posto de utilizador e que a VLAN 10 é o segmento aprovado. No switch:

enable
configure terminal
interface fastEthernet0/1
 switchport access vlan 10
end
write memory

No PC do Packet Tracer, renova o DHCP em Desktop > IP Configuration: seleciona Static e depois DHCP. Num ambiente real, utiliza o método normal de renovação do cliente e respeita o controlo de alterações da porta.

Validação

1. show vlan brief apresenta Fa0/1 na VLAN 10.
2. ipconfig no posto mostra um IP em 192.168.10.0/24 e gateway 192.168.10.1.
3. http://192.168.20.20 abre no posto de utilizador. http://ikw.test também abre se o DNS estiver corretamente configurado.
4. O posto convidado continua sem aceder a 192.168.20.20 pelo IP.
5. O trunk mantém as VLANs esperadas em forwarding.

No laboratório, o acesso ao site foi confirmado após a correção. Os outputs registados comprovam a VLAN errada no switch e a nova concessão DHCP da rede de convidados; não incluem uma captura do ipconfig após a correção.

Reversão e prevenção

Se a porta tiver sido deliberadamente atribuída à rede de convidados, repõe a VLAN anterior documentada; não assumas que a VLAN 10 é sempre a correta. Antes de uma alteração em produção, regista a configuração original da porta e, depois, valida o acesso do utilizador e a política de segurança.

Para a rede simulada completa, consulta Construir uma rede empresarial segmentada no Packet Tracer.

Mantém um inventário das portas e dispositivos e documenta a VLAN prevista para cada ligação. Numa falha isolada de conectividade, compara cedo o IP e gateway atuais do cliente com show vlan brief. Não enfraqueças a ACL de convidados para compensar uma porta colocada na VLAN errada.