Problemas de DHCP em ambientes com VLANs
Problemas de DHCP em ambientes com VLANs
Por: Yuri Diógenes
1. Introdução
O tema de DHCP pode parecer algo simples, já maduro e que nunca se terá problemas. Talvez por isso não exista um preocupação maior quando há planos de se fazer uma mudança de infraestrutura, o que muitas vezes é normal. Muitas vezes também existe a pré-disposição de dizer que o problema está no servidor, muitos clientes ao ligarem para o PSS com problemas de DHCP ficam surpresos com o resultado do diagnóstico. A idéia deste artigo é abordar problemas comuns que podem ocorrer em um ambiente com VLANs e com servidor DHCP rodando em um servidor Microsoft Windows.
2. Lembrando Conceitos
Primeiramente é importante lembrar o que é uma VLAN e como funciona.
2.1. LANs Virtuais
· Uma VLAN é uma segmentação no nível 3 (camada de rede do modelo OSI), através desta segmentação conseguimos criar vários domínios de broadcast onde um domínio de broadcast não se comunica diretamente com outro.
· Para que uma VLAN se comunique com outra é necessário que exista um equipamento de nível 3 que faça o roteamento dos pacotes. Este equipamento poderá ser um roteador ou uma Switch de nível 3;
2.2. Serviço DHCP
Quando temos um DHCP na rede, os clientes irão obter IP inicialmente enviando um broadcast UDP na porta 67 que é chamado de DHCPDISCOVER. O pacote conterá um cabeçalho DHCP semelhante ao mostrado abaixo:
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x711eb7fe
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: (00:03:ff:3b:2b:29)
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Discover
Option 116: DHCP Auto-Configuration (1 bytes)
Option 61: Client identifier
Hardware type: Ethernet
Client MAC address: (00:03:ff:3b:2b:29)
Option 12: Host Name = "XPCLIENT"
Option 60: Vendor class identifier = "MSFT 5.0"
Option 55: Parameter Request List
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
31 = Perform Router Discover
33 = Static Route
Unknown Option Code: 249
43 = Vendor-Specific Information
End Option
Padding
Os campos em vermelho são campos que fiz questão de enfatizar para que tenhamos em mente que já no primeiro pacote existe uma identificação do lado do cliente, porém o pacote é um broadcast. O cabeçalho IP tem como endereço de destino o IP 255.255.255.255.
O servidor ao ouvir esta requisição vai então fazer uma oferta, neste momento teremos um envio em formato de broadcast UDP na porta 68 chamado de DHCPOFFER. Este pacote vai conter as opções que foram configuradas no servidor DHCP de forma que as mesmas sejam oferecidas para o cliente, conforme mostrado abaixo:
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x711eb7fe
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 192.168.0.220 (192.168.0.220)
Next server IP address: 192.168.0.10 (192.168.0.10)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: 00:03:ff:3b:2b:29
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Offer
Option 1: Subnet Mask = 255.255.255.0
Option 58: Renewal Time Value = 4 days
Option 59: Rebinding Time Value = 7 days
Option 51: IP Address Lease Time = 8 days
Option 54: Server Identifier = 192.168.0.10
Option 3: Router = 192.168.0.1
Option 6: Domain Name Server = 192.168.0.10
Option 44: NetBIOS over TCP/IP Name Server = 192.168.0.10
Option 46: NetBIOS over TCP/IP Node Type = H-node
End Option
Padding
Observe que o número de cada opção é algo de extrema importância, pois é através dele que é possível identificar o que tal opção significa.
OBS: Para uma lista completa das opções DHCP disponíveis, ver o site do IANA abaixo:
https://www.iana.org/assignments/bootp-dhcp-parameters
O cliente então vai enviar um DHCPREQUEST que neste primeiro momento continua sendo através de broadcast (pois o cliente ainda não tem ainda um IP). Note que caso exista vários servidores DHCP na mesma rede todos os servidores iram receber este pacote, mas apenas o servidor contido na opção 54 é que poderá enviar o próximo pacote, que é a confirmação do aluguel.
Bootstrap Protocol
Message type: Boot Request (1)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x711eb7fe
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 0.0.0.0 (0.0.0.0)
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: 00:03:ff:3b:2b:29
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP Request
Option 61: Client identifier
Hardware type: Ethernet
Client MAC address: 00:03:ff:3b:2b:29
Option 50: Requested IP Address = 192.168.0.220
Option 54: Server Identifier = 192.168.0.10
Option 12: Host Name = "XPCLIENT"
Option 81: FQDN
Flags: 0x00
0000 .... = Reserved flags: 0x00
.... 0... = Server DDNS: Some server updates
.... .0.. = Encoding: ASCII encoding
.... ..0. = Server overrides: No override
.... ...0 = Server: Client
A-RR result: 0
PTR-RR result: 0
Client name: XPCLIENT.ctest.com
Option 60: Vendor class identifier = "MSFT 5.0"
Option 55: Parameter Request List
1 = Subnet Mask
15 = Domain Name
3 = Router
6 = Domain Name Server
44 = NetBIOS over TCP/IP Name Server
46 = NetBIOS over TCP/IP Node Type
47 = NetBIOS over TCP/IP Scope
31 = Perform Router Discover
33 = Static Route
Unknown Option Code: 249
43 = Vendor-Specific Information
End Option
O servidor então vai enviar um DHCPACK (via broadcast também), concordando com o aluguel de endereço IP e reservando aquele IP na sua tabela de endereços.
Bootstrap Protocol
Message type: Boot Reply (2)
Hardware type: Ethernet
Hardware address length: 6
Hops: 0
Transaction ID: 0x711eb7fe
Seconds elapsed: 0
Bootp flags: 0x0000 (Unicast)
0... .... .... .... = Broadcast flag: Unicast
.000 0000 0000 0000 = Reserved flags: 0x0000
Client IP address: 0.0.0.0 (0.0.0.0)
Your (client) IP address: 192.168.0.220
Next server IP address: 0.0.0.0 (0.0.0.0)
Relay agent IP address: 0.0.0.0 (0.0.0.0)
Client MAC address: 00:03:ff:3b:2b:29
Server host name not given
Boot file name not given
Magic cookie: (OK)
Option 53: DHCP Message Type = DHCP ACK
Option 58: Renewal Time Value = 4 days
Option 59: Rebinding Time Value = 7 days
Option 51: IP Address Lease Time = 8 days
Option 54: Server Identifier = 192.168.0.10
Option 1: Subnet Mask = 255.255.255.0
Option 81: FQDN
Flags: 0x00
0000 .... = Reserved flags: 0x00
.... 0... = Server DDNS: Some server updates
.... .0.. = Encoding: ASCII encoding
.... ..0. = Server overrides: No override
.... ...0 = Server: Client
A-RR result: 255
PTR-RR result: 255 Option 3: Router = 192.168.0.1
Option 6: Domain Name Server = 192.168.0.10
Option 44: NetBIOS over TCP/IP Name Server = 192.168.0.10
Option 46: NetBIOS over TCP/IP Node Type = H-node
End Option
Como você pode ver, todos pacotes são em formato de broadcast, desta forma, quando temos uma segmentação no nível 3, tais pacotes não são transmitidos para o outro lado da rede, daí vem a necessidade do uso de um DHCP Relay Agent. O DHCP Relay Agent é responsável por ouvir estes broadcasts em um lado da rede e encaminhar para o outro lado da rede. Esta função pode ser feita por um servidor Windows que esteja sendo utilizado como um roteador, ou também pode ser feita pelo roteador em si. Para isso o roteador precisa ser compatível com a RFC 1542.
2.3. Super Escopo
O super escopo permite que você tenha múltiplos endereçamentos IPs dentro do mesmo segmento físico. Veja bem: vários IPs (independente de serem ou não da mesma classe) dentro do mesmo segmento de nível 3. Algumas empresas tiram proveito do uso do super escopo para expandir a quantidade de computadores existentes no mesmo segmento porém usando diferente intervalos de endereçamento IP.
Agora que temos estes conceitos definidos será possível ir adiante e explicar o cenário.
3. Cenário
O cenário para este artigo é baseado no ambiente abaixo:
Veja que temos um servidor DHCP na VLAN1, este servidor está conectado diretamente na porta da Switch de nível 3. A VLAN 1 por sua vez pertence a faixa de IP 192.168.0.0/24, alguns clientes também estão localizados na VLAN 1 porém estão conectados em uma switch de nível 2. Temos estações clientes nas VLAN 3 (faixa de IP 192.168.2.0/24) e na VLAN 2 (192.168.1.0/24).
A partir deste cenário iremos desenvolver cinco possíveis problemas que podem ocorrer neste ambiente caso a configuração não esteja 100% correta.
4. Problema 1 – Clientes da VLAN 2 não obtém Endereço IP
O problema 1 diz respeito a clientes da VLAN 2 que não conseguem receber IP de maneira alguma. Este problema não acontece nas VLANs 1 nem na 3.
4.1. Obtendo Dados
O plano de ação para coleta dos dados neste caso é:
· Instalar o network monitor no servidor e no cliente da VLAN 2;
· Iniciar a captura em ambos lados e no lado do cliente executar o comando ipconfig /renew
Neste momento o comportamento esperado é que o servidor ouça a requisição de IP vinda através da Switch de nível 3, pois neste caso a switch está configurada para ser o DHCP Relay Agent. Então o pacote de DHCP Offer teria que conter a informação correta do relay, que neste caso é:
Your (client) IP address: 192.168.1.200
Next server IP address: 192.168.0.10
Relay agent IP address: 192.168.1.1
4.2. Analisando
Porém após a captura de pacotes no lado do servidor e do cliente é possível verificar que no lado do cliente o IP ofertado é:
Your (client) IP address: 0.0.0.0
Next server IP address: 0.0.0.0
Relay agent IP address: 0.0.0.0
Analisando o resultado do network monitor no lado do servidor podemos ver que não existe nenhum pacote DHCPDISCOVER vindo daquele segmento.
4.3. Conclusão
Bem, neste está fácil de deduzir que a Switch de nível 3 não está fazendo corretamente o papel de relay. Em alguns casos o cliente diz: “Mais eu configurei correto, tanto é que as outras VLANs estão funcionando”. Para este tipo de questionamento nada melhor que o resultado da captura, se o servidor não está ouvindo discover que vem daquele segmento ele não conseguira ofertar. Isso poderá sim ser a Switch, vejamos como o exemplo uma configuração básica de relay em um equipamento Cisco:
interface Ethernet2
ip address 192.168.1.1 255.255.255.0
ip helper-address 192.168.0.10
Observe que o comando IP helper-address reside na interface Ethernet2, a interface 2 é justamente a interface que está ligada a VLAN2. A configuração de relay aponta para o servidor 192.168.0.10 como DHCP. Em suma, se este comando não for digitado em cada interface da Switch de nível 3 não haverá relay para aquele segmento.
OBS: Os comandos e sintaxe para configuração de roteadores/switches deste exemplo podem variar de acordo com o equipamento, modelo e versão de sistema operacional do fabricante. Para maiores exemplos de configuração de Switches Cisco como DHCP Relay utilize o artigo abaixo:
Cisco IOS DHCP Relay Agent Support
https://www.cisco.com/en/US/products/sw/iosswrel/ps1834/products_feature_guide09186a00800800ed.html
5. Problema 2 – Clientes da VLAN 2 obtém Endereço IP Incorreto
O problema 2 diz respeito a clientes da VLAN 2 não conseguirem obter endereço IP designados para VLAN 2. Como você pode ver na figura anterior o endereçamento da VLAN 2 é 192.168.1.0/24. Os clientes da VLAN 2 recebem IP designados para a VLAN 1, que por sua vez é 192.168.0.0/24.
5.1. Obtendo Dados
O plano de ação para coleta dos dados neste caso é:
· Instalar o network monitor no servidor e no cliente da VLAN 2;
· Iniciar a captura em ambos lados e no lado do cliente executar o comando ipconfig /renew
Neste momento o comportamento esperado é que o servidor ouça a requisição de IP vinda através da Switch de nível 3, pois neste caso a switch está configurada para ser o DHCP Relay Agent. Então o pacote de DHCP Offer teria que conter a informação correta do relay, que neste caso é:
Your (client) IP address: 192.168.1.200
Next server IP address: 192.168.0.10
Relay agent IP address: 192.168.1.1
5.2. Analisando
Porém após a captura de pacotes no lado do servidor e do cliente é possível verificar que no lado do cliente o IP ofertado é:
Your (client) IP address: 192.168.0.200
Next server IP address: 192.168.0.10
Relay agent IP address: 192.168.0.1
5.3. Conclusão
Bem, neste caso o problema não é do servidor, o problema é da Switch. Quando o servidor DHCP recebe um DISCOVER vindo da Switch é necessário que o campo DHCP Relay contenha o IP correspondente de onde a Switch ouviu o DISCOVER. Neste caso a Switch ouviu o DISCOVER do segmento 192.168.1.0/24, mas erroneamente encaminhou o pacote com a informação de relay errada. O servidor DHCP por sua vez só fez verificar este endereço e olhar nos escopos presentes qual iria satisfazer tal requisição.
6. Problema 3 – Clientes de uma Nova VLAN não Obtém Endereço IP Correto
O problema 3 nasce a partir de uma mudança de estrutura na rede. O servidor DHCP tinha a seguinte configuração:
· Super Escopo Rede Principal
o Escopo A
§ 192.168.0.10 – 192.168.0.254
o Escopo B
§ 10.10.10.0 – 10.10.10.254
· Escopo VLAN 2
o 192.168.1.10 – 192.168.1.254
· Escopo VLAN 3
o 192.168.2.10 – 192.168.2.254
Como pode ser visto na VLAN 1 há um super escopo que contém dois tipos distintos de endereçamento IP. Isso estava funcionando normal até o dia em que o administrador de rede resolveu dividir a VLAN 1 em VLAN 1 e VLAN 4. A idéia dele era que a VLAN 1 continuasse com a faixa de endereçamento 192.168.0.0/24 e a nova VLAN 4 ficasse com a faixa 10.10.10.0/24.
Porém que estava acontecendo na prática era que clientes das VLANs 1 e 4 estavam todos obtendo IPs da faixa 192.168.0.0/24.
6.1. Obtendo Dados
O plano de ação para coleta dos dados neste caso é:
· Instalar o network monitor no servidor e no cliente da VLAN 2;
· Iniciar a captura em ambos lados e no lado do cliente executar o comando ipconfig /renew
6.2. Analisando
Bem, neste caso a análise dos pacotes vai mostrar o seguinte comportamento:
Your (client) IP address: 192.168.0.200
Next server IP address: 192.168.0.10
Relay agent IP address: 10.10.10.1
Bem, aqui é possível verificar que o endereço IP do relay está correto, então a pergunta é: porque mesmo estando correto o endereço do Relay o servidor DHCP ofereceu o IP referente ao segmento errado?
6.3. Conclusão
A resposta vem nos conceitos passados no início deste artigo, ou seja, para ambientes com múltiplas VLANs devemos usar um escopo por VLAN. Endereços contidos em superescopos irão atender apenas o mesmo segmento de nível 3. Neste caso, para resolver o problema basta clicar com o botão direito no Escopo B e escolher a opção “Remove from Superscope”. Ao fazer isso você estará colocando aquele escopo de forma independente e quando o servidor receber um DISCOVER vindo do segmento 10.10.10.0/24 ele poderá consultar o escopo correto e fazer a oferta correta.
7. Problema 4 – Clientes de todas VLANs param de Receber Endereço IP
O problema 4 nasceu durante a troca do servidor DHCP para um novo hardware. Foi feito um backup geral da máquina e restaurada em um novo hardware. Após isso nenhuma estação conseguia mais obter endereço IP. Nem os segmentos locais nem os segmentos remotos.
7.1. Obtendo Dados
Antes mesmo de coletar dados é importante obter a resposta para a pergunta: colocando um cabo cruzado entre o servidor e uma estação, a estação consegue obter IP?
Caso a resposta seja sim, então o problema já fica claro que é na Switch. Para eliminar a hipótese de ser um problema generalizado na Switch faça o teste de apenas trocar o servidor de porta. Se funcionar então podemos estar entrando em um cenário de segurança por porta de Switch.
Se os seguintes comandos forem digitados em uma porta de Switch Cisco, teremos então tal comportamento:
switchport port-security maximum 1
switchport port-security mac-address 0003fff1389b
Neste caso estamos “amarrando” esta porta para permitir apenas que este MAC seja permitido.
OBS: Os comandos e sintaxe para configuração de roteadores/switches deste exemplo podem variar de acordo com o equipamento, modelo e versão de sistema operacional do fabricante. Para mais informações sobre estes comandos ver o link abaixo:
Configuring Port Security
8. Problema 5 – Apenas clientes da VLAN 1 Conseguem Obter Endereçamento IP
O problema 5 começou a acontecer depois da equipe de segurança aplicar políticas de segurança nos equipamentos ativos de rede, mas especificamente após aplicarem filtros na switch de núcleo (nível 3).
8.1. Obtendo Dados
Existem alguns casos que nem é necessário ir muito afundo na análise e obtenção dos dados, tudo parte do pressuposto que: antes estava funcionando, então o que mudou? Bem, neste o que mudou foi as regras de acesso da switch de nível 3, então recordemos que:
· Precisamos que as portas UDP 67 e UDP 68 estejam abertas;
· Em regra geral precisamos que o DHCP Relay Agente possa conversar com o DHCP Server nestas portas;
Segue abaixo um exemplo de como deveria estar configurado a lista de acesso para um o DHCP Relay Agent em em equipamento Cisco. Neste caso iremos utilizar a interface que está indo para a VLAN 2:
access-list 100 permit udp host 192.168.1.1 host 192.168.0.10 eq 67
access-list 100 permit udp host 192.168.0.10 host 192.168.1.1 eq 67
access-list 100 permit udp host 192.168.1.1 host 192.168.0.10 eq 68
access-list 100 permit udp host 192.168.0.10 host 192.168.1.1 eq 68
Neste caso estamos liberando o acesso indo e voltando entre estes dois hosts. Com isso a comunicação no que diz respeito a permitir ou não poderá ocorrer sem problemas.
OBS: Os comandos e sintaxe para configuração de roteadores/switches deste exemplo podem variar de acordo com o equipamento, modelo e versão de sistema operacional do fabricante. Para maiores informações sobre lista de acesso ver o artigo abaixo:
IP Access Lists
Algumas vezes acontece o efeito “EU TENHO CERTEZA”, esse efeito geralmente acontece em usuários que dizem ter certeza que tal coisa foi realizada e não aceitam sequer a idéia de que possa ser aquilo que está se sugerindo. Neste caso ao apresentarmos tal solução ao administrador da Switch de nível 3 ele disse: “Eu tenho certeza que tais portas não estão sendo filtradas, o problema não é na Switch” . Bem, quando nos deparamos com este tipo de comportamento precisamos então provar a nossa teoria, neste caso poderíamos provar nossa teoria através dos testes abaixo:
· Iniciar a captura com o network monitor no lado do cliente e no lado do servidor. Forçar a renovação do IP (ipconfig /renew) e verificar se chega algum DHCPOFFER vindo daquele segmento para o servidor. Caso não chegue isso seria suficiente para provar que a Switch está bloqueando o acesso;
· Um outro teste seria pedir para o administrador da Switch fazer um telnet na porta 67 e 68 do servidor DHCP a partir da console da Switch. Este teste mostraria se a Switch pode comunicar-se com o DHCP nestas portas;
· Rodar um Port Scan a partir do servidor tendo como destino a porta da switch que se conecta a VLAN que não recebe IP. Através deste scan das portas será possível verificar quais estão abertas para comunicação e quais estão fechadas. Para efetuar um Port Scan você poderá utilizar a ferramenta Microsoft Port Query. Esta ferramenta está disponível em linha de comando e também em interface gráfica. Faça o download a partir dos links abaixo:
Port Query – Linha de Comando
Port Query – Interface Gráfica
https://download.microsoft.com/download/3/f/4/3f4c6a54-65f0-4164-bdec-a3411ba24d3a/PortQryUI.exe
8. Considerações Finais
Como você pôde ver durante todos os cenários de resolução de problemas utilizamos o Network Monitor, então lembre: Network Monitor é seu melhor amigo nestes tipos de problema. Um outro ponto também para ter em mente é que: nem sempre o problema é no servidor DHCP. Ficou claro nos cenários que a Switch de nível 3 tem um papel fundamental no aluguel de IP em um ambiente com múltiplas VLANs, caso a switch não esteja corretamente configurada é possível se deparar com problemas desta natureza.