Opções DHCP do Sophos Firewall (SFOS)

As opções DHCP são necessárias no Sophos Firewall quando os clientes precisam receber mais do que apenas o endereço IP, gateway e DNS ao iniciar. Casos típicos incluem PXE, WDS, Thin Clients, telefones VoIP ou ambientes RED mais antigos, onde um código de opção específico e tipo de dado devem corresponder exatamente.

As versões atuais do Sophos Firewall suportam opções DHCP diretamente no WebAdmin. Para a maioria dos ambientes, não é mais necessária a configuração via SSH ou CLI. No entanto, os exemplos de CLI continuam importantes, pois runbooks antigos, casos especiais e resolução de problemas ainda utilizam essa sintaxe.

O que são opções DHCP

O DHCP não distribui apenas um endereço IP. Junto com o lease, o servidor DHCP pode passar informações adicionais para o cliente. É para isso que existem as opções DHCP. Exemplos típicos incluem servidores DNS, gateway, servidor TFTP, nome do arquivo de boot, parâmetros específicos do fornecedor ou valores para Thin Clients e telefones.

No Sophos Firewall, as opções DHCP sempre pertencem ao servidor DHCP ou ao escopo que emite o lease. Isso é importante: se um cliente recebe seu endereço de outro servidor DHCP, a opção deve ser configurada lá. Se o Sophos Firewall atua apenas como um relay DHCP, ele encaminha solicitações DHCP, mas não é o local onde a opção para esse escopo é mantida.

Para IPv6, o DHCP nem sempre é tratado da mesma forma que para IPv4. Quando um provedor delega um prefixo IPv6, anúncios de roteador, parâmetros DHCPv6 e regras de firewall estão interligados. O processo é descrito em Configurar delegação de prefixo IPv6 no Sophos Firewall.

Na prática, antes de configurar, deve-se esclarecer três coisas:

• Qual servidor DHCP realmente distribui o lease?
• Em qual escopo ou interface está o cliente?
• Quais códigos de opção, tipos de dados e valores o fabricante do sistema de destino exige?

Pré-requisitos

• Sophos Firewall com servidor DHCPv4 ativado
• Acesso a Network > DHCP
• Um escopo DHCP na interface apropriada
• Os códigos de opção DHCP e valores necessários do fabricante ou sistema de destino
• Para alternativas CLI: acesso SSH permitido ao Sophos Firewall

Antes de fazer alterações, deve-se verificar brevemente o escopo afetado. As opções DHCP só funcionam de forma confiável se forem definidas no servidor DHCP correto, na rede correta e com o tipo de dado correto.

• Servidor DHCP: O Sophos Firewall deve emitir o lease. Com DHCP Relay, as opções normalmente pertencem ao servidor DHCP central.
• Escopo e Interface: Um cliente no VLAN errado ou em outra interface não verá a opção, mesmo que esteja corretamente armazenada.
• Código de opção e tipo de dado: Muitos erros ocorrem porque um cliente espera string, ipaddress, array-of ou um valor de fornecedor de forma diferente do que foi inserido.
• Cliente de teste: Um dispositivo conhecido na rede afetada torna visível se a opção realmente chega na oferta ou ACK DHCP.
• Janela de alteração: PXE, telefones e Thin Clients podem ser afetados imediatamente na troca de lease. As alterações devem, portanto, ser testadas de forma controlada.

Se a opção for relevante para dispositivos em produção, deve-se saber de antemão como removê-la ou restaurá-la ao valor antigo. Isso é especialmente importante para opções de boot, servidores de provisionamento e opções de fornecedor específicas.

1. Criar ou verificar o servidor DHCP

Para que as opções DHCP sejam distribuídas, primeiro é necessário um servidor DHCPv4 no Sophos Firewall. A configuração de base completa, incluindo intervalo, gateway, DNS, duração do lease e teste, é descrita em Configurar o Sophos Firewall como servidor DHCP. Em seguida, o servidor é editado em Network > DHCP.

O mais importante é:

• O servidor DHCP está associado a uma interface.
• O escopo corresponde à rede onde os clientes estão.
• Servidores DNS, gateway e tempo de lease estão corretamente definidos.
• O nome do DHCP não contém espaços ou caracteres especiais desnecessários.
• Casos especiais de PXE, VoIP, Thin Client ou RED estão documentados antecipadamente.

O nome do DHCP é especialmente relevante para comandos CLI. Se o nome contiver espaços ou caracteres especiais, comandos e runbooks futuros serão desnecessariamente propensos a erros. Nomes compreensíveis como DHCP_Server_Avanet_LAN, Home_Scope ou DHCP_VoIP são mais fáceis na prática.

2. Configurar opções DHCP no WebAdmin

Assim que o servidor DHCPv4 for criado, as opções podem ser adicionadas diretamente no mesmo diálogo.

1. Abra Network > DHCP.
2. Edite o servidor DHCPv4 existente ou crie um novo servidor.
3. Vá para a seção DHCP options.
4. Adicione uma opção.
5. Para opções próprias, defina Options como Custom e insira Code, Type e Value.
6. Salve as alterações.
7. Verifique com um cliente de teste se a opção foi realmente adotada.

Os campos significam:

• Options ou Option: Seleção entre opções DHCP predefinidas e opções customizadas. Em opções Custom, o código da opção é inserido manualmente.
• Code: Código numérico da opção DHCP, por exemplo 66, 67, 161 ou um valor específico do fabricante.
• Type: Tipo de dados usado para codificar Value, por exemplo IP address, String, Boolean ou um dos tipos numéricos e de array disponíveis na lista.
• Value: Valor concreto que o cliente deve receber, como um endereço IP, um hostname, um caminho ou uma porta.

Os valores corretos geralmente são fornecidos pelo fabricante do sistema de destino. Especialmente para valores de string, caminhos ou opções específicas do fornecedor, vale a pena verificar na documentação do fabricante. Um valor formalmente armazenado não significa automaticamente que o cliente o interpretará como esperado.

No SFOS 22, o caminho completo para um novo escopo é Network > DHCP > Server > Add. Para um escopo existente, abre-se a ação de edição e depois DHCP options. As opções predefinidas usam os valores oferecidos pelo SFOS. Numa opção personalizada, Code, Type e Value têm de corresponder à documentação atual do cliente ou fabricante. A tabela oficial distingue, entre outros, String, IP address, Boolean e valores numéricos ou arrays de diferentes tamanhos.

Para verificar as referências, a ajuda do SFOS 23 separa as opções DHCPv4 no Appendix A das opções DHCPv6 no Appendix B. As duas tabelas distinguem Data type, Data format e Data value (example) e indicam a RFC correspondente. Portanto, o tipo de dados por si só não basta: o formato do valor também deve corresponder à opção. Os valores de exemplo não são configurações obrigatórias para a própria rede. Os códigos e valores das opções DHCPv4 não devem ser transferidos sem alterações para DHCPv6; é necessário verificar a correspondência específica para DHCPv6. A ampliação das tabelas de referência não comprova que uma opção tenha sido introduzida pela primeira vez no SFOS 23.

Preparar a alteração e a reversão

Antes de Save, deve-se registar cada linha afetada com opção, código, tipo e valor anterior. Primeiro testa-se num único escopo controlado. Se o teste falhar, edita-se o mesmo servidor DHCPv4, remove-se apenas a nova linha ou restaura-se o valor registado e guarda-se. Depois renova-se novamente o lease do cliente de teste e verifica-se no DHCP Offer ou ACK se o estado inicial voltou a ser distribuído. Não se deve apagar precipitadamente uma definição global pela CLI, pois outro servidor DHCP pode continuar a utilizá-la.

3. Casos de uso típicos

As opções DHCP são geralmente necessárias quando um cliente precisa de informações adicionais ao iniciar. Casos comuns incluem PXE, WDS, Thin Clients, telefones VoIP, pontos de acesso ou cenários legados específicos.

PXE e WDS

Para ambientes PXE ou WDS, as opções 66 e 67 são frequentemente usadas:

• 66 refere-se ao servidor TFTP ou de implantação.
• 67 contém o nome do arquivo de boot.

Se o cliente alcançar o servidor, mas não inicializar, o problema geralmente não está no firewall, mas em um caminho de arquivo incorreto, um tipo de dado inadequado ou um arquivo de arquitetura incompatível. Clientes UEFI e BIOS frequentemente requerem arquivos de boot diferentes.

Importante em versões atuais do SFOS: Next-server e Boot file são campos de boot options separados no servidor DHCPv4. Desde o SFOS 20.0 MR1, eles não são mais tratados automaticamente apenas como opções DHCP 66 e 67. Se um dispositivo espera explicitamente a opção 66 ou 67, esses valores devem ser mantidos conscientemente em DHCP options e não apenas nos campos de boot options.

Ao atualizar para SFOS 20.0 MR1 ou posterior, os valores existentes de Next-server e Boot file são mantidos como boot options e também como opções DHCP 66 e 67. Depois de uma migração, deve-se verificar se os valores existem em duplicado e se o cliente avalia a variante esperada.

O SFOS aceita em Next-server um endereço IP ou FQDN, mas não um URL. Boot file requer o caminho completo, incluindo o nome do ficheiro. Ambos os valores têm de corresponder ao servidor de arranque efetivamente utilizado e à arquitetura do cliente.

Thin Clients

Thin Clients podem precisar de opções para servidores de gerenciamento, servidores de imagem ou parâmetros de conexão, dependendo do fabricante. Em runbooks antigos encontram-se, por exemplo:

• 161 para o servidor
• 192 para uma porta ou parâmetro adicional

Se esses códigos estão corretos, depende do fabricante e do modelo de Thin Client usado. Portanto, não se deve adotar os códigos cegamente, mas sempre verificar na documentação do fabricante.

Telefones IP Avaya como exemplo concreto do fabricante

A ajuda do SFOS 22 apresenta as opções 176 e 252 como valores String para telefones Avaya. Os endereços IP e a porta indicados são apenas valores de documentação e devem ser substituídos pelos servidores reais de comunicação, TFTP e HTTP do ambiente:

Option 176, String: MCIPADD=192.168.30.99,MCPORT=1719,TFTPSRVR=192.168.30.201
Option 252, String: ConfigHttpSrvr=192.168.30.102

Depois de renovar o lease, verificar no DHCP Offer ou ACK se o cliente recebe exatamente estas strings. Em seguida, os logs do telefone e dos servidores devem confirmar que o dispositivo utiliza realmente os serviços previstos. Este exemplo não é uma configuração Avaya universal.

Casos especiais de RED mais antigos

Em ambientes mais antigos, houve casos em que um Sophos RED 15w não reconhecia corretamente o ponto de acesso integrado. Para isso, às vezes era usada uma opção DHCP específica do fabricante, por exemplo, com o código de opção 234 e um valor como 10.10.10.12.

Isso não é um padrão geral para instalações modernas de SD-RED. Como exemplo legado, ainda é útil, pois mostra como definir códigos de opção próprios e vinculá-los a um servidor DHCP.

Para designs RED atuais, o artigo Configurar e solucionar problemas do Sophos SD-RED é mais útil. Quando se trata de designs de interface, VLAN, bridge ou RED, Planejar e configurar zonas e interfaces do Sophos Firewall também pode ajudar.

4. Enquadrar corretamente o DHCP Relay

Com DHCP Relay, o Sophos Firewall encaminha os pedidos dos clientes para um servidor noutra rede. Por isso, as opções DHCP são configuradas no servidor que atribui o lease, não no firewall relay.

A escolha da interface, vários servidores, redes locais e IPsec policy-based ou route-based são descritos com valores de exemplo, regras, comandos e Packet Capture em Configurar e testar o DHCP Relay no Sophos Firewall.

5. Usar a CLI de forma controlada

O SFOS 22 continua a documentar ambos os passos da CLI: definir uma opção com system dhcp dhcp-options add e associá-la a um servidor DHCP com system dhcp dhcp-options binding add. A visão geral atual da Device Console apresenta apenas um resumo abreviado do comando; a documentação oficial da Avaya mostra a sintaxe completa. O WebAdmin continua a ser mais claro para novas configurações padrão, enquanto a CLI é sobretudo útil para runbooks existentes, casos de suporte e migrações controladas.

A Device Console só deve ser considerada quando:

• um artigo antigo ou runbook já se baseia em comandos CLI
• opções de fornecedor incomuns precisam ser testadas
• deseja-se ver exatamente quais bindings estão armazenados internamente em caso de suporte
• um ambiente foi migrado de uma versão muito antiga do SFOS
• um comando precisa ser replicado ou verificado em uma documentação

Se for necessário usar uma sintaxe confirmada para a versão instalada, consulte primeiro Conectar ao Sophos Firewall via SSH. Após o login, use 4. Device Console, não Advanced Shell. Antes de qualquer alteração, guarde a configuração atual da interface web e os bindings existentes.

Princípio básico da CLI: Definir e vincular a opção

Na configuração CLI, há dois passos:

1. A opção DHCP é definida.
2. A opção é vinculada a um servidor DHCP e recebe um valor lá.

Primeiro, a opção é definida:

system dhcp dhcp-options add optioncode optionname optiontype

Os placeholders significam:

• optioncode: código numérico da opção DHCP
• optionname: nome escolhido livremente para a opção
• optiontype: tipo de dado, por exemplo, ipaddress ou string

Exemplo para um endereço IP como opção DHCP:

system dhcp dhcp-options add optioncode 234 optionname dhcp_magic_ip optiontype ipaddress

Depois, a opção é vinculada a um servidor DHCP:

system dhcp dhcp-options binding add dhcpname optionname(234) value

Os placeholders significam:

• dhcpname: nome do servidor DHCP na configuração do Sophos Firewall
• optionname(234): nome da opção definida anteriormente, incluindo o código de opção entre parênteses
• value: valor a ser distribuído aos clientes

Exemplo:

system dhcp dhcp-options binding add dhcpname dhcp_red_avanet optionname dhcp_magic_ip(234) value 10.10.10.12

6. Exemplos de CLI

A sintaxe para definir e associar opções está oficialmente documentada na documentação atual da Avaya para o SFOS 22. No entanto, os valores de Thin Client, WDS e RED apresentados abaixo são exemplos específicos de cada ambiente: o código da opção, o tipo de dados e o conteúdo têm de ser verificados na documentação atual do fabricante antes da utilização.

Servidor Thin Client

Com esta opção, um Thin Client é informado sobre qual servidor está a imagem ou o componente de gerenciamento:

system dhcp dhcp-options add optioncode 161 optionname ThinClientServer optiontype ipaddress
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServer(161) value '10.10.10.12'

Se uma porta adicional for necessária, ela pode ser definida como string:

system dhcp dhcp-options add optioncode 192 optionname ThinClientServerPort optiontype string
system dhcp dhcp-options binding add dhcpname DHCP_Server_Avanet_LAN optionname ThinClientServerPort(192) value '443'

WDS e PXE

Um valor de opção DHCP para o servidor WDS ou TFTP pode ser definido assim:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname TFTP_Server_Name(66) value 172.16.16.11

O nome do arquivo de boot para o pré-ambiente é fornecido como opção 67:

system dhcp dhcp-options binding add dhcpname Home_Scope optionname Bootfile_Name(67) value \boot\x64\wdsnbp.com

Por pré-ambiente, entende-se o ambiente de boot com o qual um cliente inicia durante a instalação ou recuperação. Dependendo do ambiente, o caminho necessário pode variar, especialmente para clientes UEFI, BIOS, 32 bits e 64 bits.

Exibir opções existentes

Antes de fazer alterações, deve-se exibir as opções existentes:

system dhcp dhcp-options list

A documentação oficial do SFOS 22 indica que, para DHCPv4, a firewall suporta objetos de opção de 1 a 255, mas este comando CLI apenas apresenta as opções de 1 a 76. Para os códigos, tipos e codificação, o Appendix A, o registo da IANA e a documentação do cliente ou fabricante continuam a ser as referências determinantes.

Exibir bindings de um servidor DHCP:

system dhcp dhcp-options binding show dhcpname DHCP_Server_Avanet_LAN

Embora o resumo atual inclua a ação delete, a eliminação global não é, por defeito, uma reversão segura: outros servidores DHCP podem usar a definição. Para um único escopo, deve-se restaurar no WebAdmin o estado anterior registado.

7. Fontes comuns de erro

Quando uma opção DHCP está armazenada, mas não funciona como esperado no cliente, geralmente é devido a um destes pontos:

• O servidor DHCP errado responde à solicitação.
• Escopo ou interface errados foram editados.
• Tipo de dado não corresponde ao valor esperado.
• Endereço IP, FQDN, porta ou caminho está digitado incorretamente.
• Caminho do arquivo de boot não corresponde à arquitetura do cliente.
• Cliente espera uma string, mas a opção foi definida como endereço IP.
• Fabricante usa opções específicas de fornecedor que requerem parâmetros adicionais.
• Lease não foi renovado após a alteração.
• DHCP Relay é usado, embora a opção tenha sido mantida no Sophos Firewall.

Após uma alteração, deve-se renovar o lease no cliente de teste e verificar se o cliente realmente recebe as opções esperadas. Se o comportamento ainda não for adequado, uma captura de pacotes geralmente é mais rápida do que adivinhar: nos pacotes DHCP, pode-se ver qual servidor responde e quais opções são realmente entregues.

8. Testar a alteração

Após salvar uma opção DHCP, não se deve apenas esperar até que o próximo cliente eventualmente obtenha um novo lease. É melhor um teste controlado com um dispositivo conhecido na rede afetada.

Procedimento sensato:

1. Conectar o cliente de teste no VLAN ou interface correta.
2. Renovar o lease antigo ou reiniciar o cliente.
3. Verificar quais endereço DHCP, gateway, servidor DNS e opções adicionais foram recebidos.
4. Testar o sistema de destino, por exemplo, boot PXE, início WDS, registro de Thin Client ou provisionamento de telefone.
5. Verificar no WebAdmin se o lease aparece no escopo DHCP esperado.
6. Se o resultado não for adequado, verificar com Packet Capture qual servidor DHCP responde e quais opções estão no Offer ou ACK.

Para uma captura estreita, geralmente basta um filtro em UDP 67 e 68 entre cliente e servidor DHCP. O uso da ferramenta WebAdmin é descrito em Usar o Packet Capture do Sophos Firewall no WebAdmin.

Em testes PXE e WDS, deve-se documentar adicionalmente se o cliente de teste usa BIOS ou UEFI. Muitos problemas de boot não são causados pelo DHCP em si, mas por um arquivo de boot que não corresponde à arquitetura.

9. Solução de problemas por sintomas

Quando as opções DHCP não funcionam, uma verificação orientada por sintomas geralmente ajuda mais rapidamente do que recriar a mesma opção.

• Cliente não recebe endereço IP: Servidor DHCP, VLAN, interface ou relay não correspondem; Verificar lista de leases, interface, VLAN e DHCP Relay
• Cliente recebe IP, mas não opção: escopo errado ou servidor DHCP errado responde; Verificar Packet Capture no DHCP Offer/ACK
• PXE encontra servidor, mas não inicializa: Opção 67, caminho do arquivo ou arquitetura não correspondem; Verificar arquivo de boot BIOS/UEFI e log TFTP/WDS
• Thin Client não conecta: código de opção, tipo ou valor do fabricante incorretos; Comparar documentação do fabricante e valor fornecido
• Alteração só tem efeito mais tarde: Cliente usa lease antigo; Renovar lease, reiniciar cliente ou observar tempo de lease
• Comando CLI não funciona: nome do DHCP, nome da opção ou notação de parênteses incorretos; Verificar system dhcp dhcp-options list e saída de binding

Se na captura um servidor DHCP diferente responder, deve-se primeiro esclarecer o design da rede. Dois servidores DHCP na mesma broadcast domain são uma causa clássica para comportamento variável. Para questões mais complexas de VLAN, bridge ou interface, Planejar e configurar zonas e interfaces do Sophos Firewall pode ajudar.

Perguntas frequentes