Problemas de DHCP em ambientes com VLANs

Transcrição

1 1 de 6 27/07/ :03 Problemas de DHCP em ambientes com VLANs LatamBlog 29 Sep :24 PM 1 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 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: Message type: Boot Request (1) Your (client) IP address: ( ) Next server IP address: ( ) Client MAC address: (00:03:ff:3b:2b:29) Option 53: DHCP Message Type = DHCP Discover Option 116: DHCP Auto-Configuration (1 bytes) Option 61: Client identifier 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: = Vendor-Specific Information 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 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: Message type: Boot Reply (2)

2 2 de 6 27/07/ :03 Your (client) IP address: ( ) ( ) Option 53: DHCP Message Type = DHCP Offer Option 1: Subnet Mask = 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 = Option 3: Router = Option 6: Domain Name Server = Option 44: NetBIOS over TCP/IP Name Server = Option 46: NetBIOS over TCP/IP Node Type = H-node 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: 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. Message type: Boot Request (1) Your (client) IP address: ( ) Next server IP address: ( ) Option 53: DHCP Message Type = DHCP Request Option 61: Client identifier Option 50: Requested IP Address = Option 54: Server Identifier = Option 12: Host Name = "XPCLIENT" Option 81: FQDN Flags: 0x = Reserved flags: 0x = Server DDNS: Some server updates = Encoding: ASCII encoding = Server overrides: No override = 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: = Vendor-Specific Information 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. Message type: Boot Reply (2)

3 3 de 6 27/07/ :03 Your (client) IP address: Next server IP address: ( ) 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 = Option 1: Subnet Mask = Option 81: FQDN Flags: 0x = Reserved flags: 0x = Server DDNS: Some server updates = Encoding: ASCII encoding = Server overrides: No override = Server: Client A-RR result: 255 PTR-RR result: 255 Option 3: Router = Option 6: Domain Name Server = Option 44: NetBIOS over TCP/IP Name Server = Option 46: NetBIOS over TCP/IP Node Type = H-node 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 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 /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 /24) e na VLAN 2 ( /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 4 de 6 27/07/ :03 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 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: Relay agent IP address: 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: Next server IP address: Relay agent IP address: Analisando o resultado do network monitor no lado do servidor podemos ver que não existe nenhum pacote DHCPDISCOVER vindo daquele segmento 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 ip helper-address 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 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 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 é /24. Os clientes da VLAN 2 recebem IP designados para a VLAN 1, que por sua vez é / 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: Relay agent IP address: 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: Relay agent IP address: 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 /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.

5 5 de 6 27/07/ :03 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 Escopo A Escopo B Escopo VLAN Escopo VLAN 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 /24 e a nova VLAN 4 ficasse com a faixa /24. Porém que estava acontecendo na prática era que clientes das VLANs 1 e 4 estavam todos obtendo IPs da faixa / 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: Relay agent IP address: 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 /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 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) 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 host eq 67 access-list 100 permit udp host host eq 67

6 6 de 6 27/07/ :03 access-list 100 permit udp host host eq 68 access-list 100 permit udp host host 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 /products_command_reference_chapter09186a008017d159.html#wp 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 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. Comments Joao Delinger de Souza 16 Oct :00 PM Excelente artigo! Não é a toa que você escreve livros :-) O artigo foi muito bem escrito e aprendi muito com esse blog. Parabens e um grande abraço amigo.