Configurar o Sophos Firewall como servidor DHCP

O Sophos Firewall pode distribuir diretamente aos clientes endereços IPv4, gateway, servidores DNS e outras definições de rede. Para isso, cria-se em Network > DHCP um servidor para a interface dos clientes, define-se o intervalo de endereços e verifica-se depois se o cliente recebe um lease adequado.

Procedimento rápido: abrir Network > DHCP > Server > Add, selecionar a interface e o intervalo de endereços, ativar Use interface IP as gateway, configurar cuidadosamente as definições de DNS e guardar. Em seguida, verificar o serviço DHCP server em System services > Services e controlar o endereço atribuído em IPv4 lease.

Este guia aborda um servidor DHCPv4 para clientes na rede diretamente ligada. Se um servidor DHCP central tiver de servir outra sub-rede, consultar Configurar e testar o DHCP Relay no Sophos Firewall. PXE, VoIP e valores específicos do fabricante são descritos em Configurar opções DHCP no Sophos Firewall.

Em IPv6, a atribuição de endereços e o gateway têm funções diferentes. O procedimento completo está em Configurar e testar um servidor DHCPv6 no Sophos Firewall.

Exemplo e planeamento de endereços

O exemplo utiliza uma VLAN de clientes com os seguintes valores:

Interface: VLAN20 - 10.20.0.1/24
Intervalo dinâmico: 10.20.0.100 a 10.20.0.199
Gateway: 10.20.0.1
Mapeamento estático para uma impressora: 10.20.0.20
Servidores DNS internos: 10.10.0.10 e 10.10.0.11
Domain Name: corp.example

O intervalo dinâmico encontra-se na rede da interface, mas não inclui o endereço de rede, o endereço de broadcast nem o gateway. No exemplo, os endereços abaixo de 10.20.0.100 ficam reservados para infraestrutura e mapeamentos estáticos. Assim, este intervalo DHCP não atribui dinamicamente os endereços reservados. No entanto, esta separação não protege contra outro dispositivo no qual tenha sido configurado manualmente o mesmo endereço IP.

Antes da ativação, deve verificar-se quais os endereços já utilizados por switches, access points, impressoras ou servidores. Se ainda existir outro servidor DHCP na mesma VLAN, é necessário determinar primeiro qual será o servidor responsável no futuro. Dois servidores não coordenados podem distribuir gateways ou servidores DNS diferentes e causar problemas intermitentes.

A própria interface já deve ter o endereço IP estático correto. A relação entre interface, zona e VLAN é explicada em Configurar uma interface VLAN no Sophos Firewall.

Configurar o servidor DHCP

Abrir Network > DHCP.
Em Server, clicar em Add.
Introduzir um nome inequívoco, como dhcp-vlan20-clients.
Em Interface, selecionar a interface dos clientes VLAN20 - 10.20.0.1.
Em Dynamic IP lease, adicionar o intervalo 10.20.0.100 a 10.20.0.199.
Introduzir 255.255.255.0 como Subnet mask para a rede /24 do exemplo.
Ativar Use interface IP as gateway. Os clientes recebem então 10.20.0.1 como Gateway.
Definir servidores DNS, Domain name e durações dos leases de acordo com a rede.
Se necessário, adicionar mapeamentos estáticos MAC-IP.
Guardar com Save.

Para clientes ligados diretamente, a interface selecionada determina em que rede o firewall responde aos pedidos DHCP. Por isso, o intervalo dinâmico deve pertencer à sub-rede desta interface. Os servidores DHCP podem ser configurados em interfaces físicas e em interfaces VLAN, Wireless e Bridge, mas não num Interface Alias. Não é possível configurar simultaneamente um servidor DHCPv4 numa interface já utilizada como DHCP Relay.

Para clientes ligados diretamente, deixar Accept client request via relay desativado. Esta opção só é necessária quando esta configuração do servidor deve aceitar, através de um relay agent, pedidos de uma sub-rede remota de clientes. Cada rede remota requer uma configuração de servidor adequada com o seu próprio gateway; a arquitetura completa é explicada no guia de DHCP Relay.

Estas configurações de servidor podem partilhar a mesma interface DHCP na qual o servidor recebe os pedidos reencaminhados. É necessário distinguir a interface de escuta da sub-rede remota de clientes: o intervalo de endereços, a máscara de sub-rede e o gateway de cada configuração pertencem à respetiva rede de clientes. O servidor atribui endereços da sub-rede do endereço de origem do relay agent; partilhar uma interface de escuta não substitui, por isso, uma configuração separada para cada rede de clientes.

Escolher corretamente gateway e DNS

Numa rede normal de clientes, o gateway é o endereço IP do Sophos Firewall nesta interface. Por isso, no exemplo, os clientes recebem 10.20.0.1.

Com Use device’s DNS settings, o firewall distribui aos clientes os servidores DNS que tem configurados. Isto é adequado se esses servidores conseguirem resolver tanto nomes públicos como os nomes internos necessários. Num ambiente AD, normalmente introduzem-se os servidores DNS internos para que controladores de domínio, serviços internos e domínios de pesquisa funcionem de forma fiável. Normalmente, os resolvers públicos por si só não são suficientes.

Domain name fornece um sufixo DNS ao adaptador de rede. Com corp.example, por exemplo, o cliente pode completar o hostname fileserver como fileserver.corp.example. Isto não substitui um registo DNS nem um servidor DNS acessível; ambos devem ser testados separadamente.

Se os clientes receberem o IP do firewall como servidor DNS, o Sophos Firewall pode encaminhar pedidos de determinadas zonas internas para os servidores responsáveis. Este caso é descrito em Configurar DNS Request Routes no Sophos Firewall. Se, pelo contrário, o DHCP distribuir diretamente os endereços de outros servidores DNS, os pedidos dos clientes não chegam às Request Routes do firewall.

Os campos WINS server 1 e WINS server 2 destinam-se apenas a ambientes NetBIOS antigos. Devem ficar vazios enquanto nenhum cliente ou aplicação necessitar de um serviço WINS. Se o WINS ainda estiver em utilização, é necessário introduzir os endereços reais dos servidores e testar a resolução de nomes num cliente afetado.

Definir durações de lease adequadas

Default lease time é a duração normal do lease atribuída ao cliente. Max lease time é o limite máximo; depois de expirar, o cliente tem de enviar um novo pedido ao servidor DHCP. Ambos os valores são indicados em minutos.

Em redes estáveis de escritórios ou dispositivos, leases mais longos são adequados porque o conjunto de equipamentos raramente muda. Em redes de convidados, formação ou WLAN com muita rotatividade, um lease mais curto evita que dispositivos que já não estão ligados ocupem o intervalo durante muito tempo.

Leases muito curtos, por outro lado, geram renovações desnecessárias. Por isso, não existe um valor ideal universal: são determinantes a dimensão do intervalo e a frequência com que os clientes mudam.

Conflict detection verifica um endereço antes da atribuição e ajuda a identificar endereços IP já utilizados. A função é particularmente útil quando ainda existem dispositivos configurados manualmente ou um endereçamento antigo que não está completamente documentado.

Criar um mapeamento estático IP-MAC

Um mapeamento estático garante que um determinado dispositivo recebe sempre o mesmo endereço por DHCP. Isto é útil para impressoras, access points ou outros dispositivos que devem permanecer acessíveis, mas continuar a receber centralmente valores como gateway e DNS.

Em Static IP MAC mapping, introduzem-se o hostname, o endereço MAC e o endereço IP pretendido. No exemplo, a impressora com o seu endereço MAC real recebe sempre 10.20.0.20. Este endereço fica intencionalmente fora do intervalo dinâmico.

Um mapeamento DHCP não é o mesmo que um endereço IP configurado manualmente no dispositivo: o dispositivo continua a ser um cliente DHCP, mas o firewall reserva o lease correspondente. Se um notebook ou smartphone utilizar um endereço MAC privado ou aleatório na WLAN, o mapeamento tem de corresponder ao endereço MAC que o dispositivo utiliza efetivamente nessa WLAN.

Um único endereço MAC pode receber no máximo cinco endereços IP estáticos, desde que estejam em sub-redes diferentes. Um mapeamento normal numa só rede não requer a definição global.

No SFOS 23, quando o mesmo endereço MAC está associado em várias configurações de servidor DHCP, definir Lease scope for static binding como Global em Network > DHCP > Advanced server settings. Os clientes podem então obter um endereço de qualquer servidor DHCP configurado no firewall, independentemente de onde esteja configurada a associação IP-MAC estática. Network limita esta atribuição ao servidor que contém a associação. Primeiro, registar o valor anterior e depois testar cada âmbito afetado com um novo lease de cliente. Para reverter, repor exatamente o valor registado.

SFOS 22: associação global através da Device Console

Antes de alterar a atribuição global, após o login SSH, consultar na Device Console a ajuda local específica dos comandos conf-generation-method e static-entry-scope na versão SFOS instalada. Determinar e registar o método e o âmbito atuais através de uma consulta de leitura aí suportada ou de uma indicação disponível na interface de utilizador; verificar também antecipadamente a sintaxe de reposição correspondente. Não se confirma aqui uma forma de show válida para todas as versões. Se não for possível determinar de forma fiável o estado inicial ou o procedimento de reversão, não efetuar qualquer alteração e esclarecer primeiro o estado com o suporte.

Em seguida, alterar apenas os valores que diferem do estado de destino necessário:

system dhcp conf-generation-method new
system dhcp static-entry-scope global

A definição afeta todas as configurações de servidores DHCP. Não é necessária para mapeamentos normais e únicos, pelo que só deve ser alterada neste caso de vários âmbitos DHCP.

Quando os endereços MAC estão associados mais do que uma vez, o estado de destino apresentado acima é importante para que os clientes recebam os dados DHCP corretos, como servidores DNS e gateway. Não substituir um estado já adequado nem assumir valores predefinidos como estado inicial. Para reverter, repor exatamente os valores registados anteriormente com a sintaxe confirmada para a versão instalada. Se os valores iniciais eram efetivamente network e old, podem utilizar-se system dhcp static-entry-scope network e system dhcp conf-generation-method old, desde que a ajuda local confirme estas formas. Depois, verificar cada âmbito afetado com um novo lease de cliente. A alteração e a reversão não foram testadas aqui num firewall.

Verificar o serviço e testar o lease

Depois de guardar, verificar em System services > Services se o DHCP server está em execução. Se o serviço estiver parado, iniciá-lo nessa secção.

⚠️ Num cluster HA, a Sophos suporta o serviço DHCP no modo Active-passive, mas não no modo Active-active. Confirmar este limite antes da entrada em produção; alterar o modo HA não é uma medida de diagnóstico para um único âmbito.

Em seguida, ligar um cliente de teste controlado à VLAN correta. No Windows, pode pedir-se e verificar-se um novo lease da seguinte forma:

⚠️ ipconfig /release interrompe a ligação IPv4 atual. Não executar o comando através dessa mesma ligação remota se não estiver disponível um acesso alternativo.

ipconfig /release
ipconfig /renew
ipconfig /all

O cliente deve receber um endereço entre 10.20.0.100 e 10.20.0.199, o gateway 10.20.0.1 e os servidores DNS previstos. Em Network > DHCP > IPv4 lease, o firewall mostra o endereço atribuído com as horas de início e fim, o endereço MAC e o hostname.

Para verificar o funcionamento, devem estar corretos pelo menos os seguintes pontos:

O cliente recebe um endereço do intervalo correto.
O gateway e os servidores DNS correspondem ao planeamento.
O gateway está acessível.
Os nomes internos e externos são resolvidos.
O cliente só alcança as redes e os serviços permitidos pela respetiva regra de firewall.

Não é recebido qualquer endereço ou é recebido um endereço incorreto

Se o cliente não receber um lease, verificar primeiro a interface, a VLAN e o estado do serviço. Depois, estes são os erros mais frequentes:

Interface errada: o servidor DHCP não está associado à interface da rede dos clientes.
A VLAN não chega ao firewall: o uplink do switch não permite a VLAN tagged ou a porta do cliente está atribuída incorretamente.
O intervalo de endereços não corresponde: o endereço inicial ou final está fora da sub-rede da interface.
O intervalo está esgotado: comparar o número e a duração dos leases ocupados com a dimensão do intervalo configurado. A lista de leases mostra os endereços atribuídos, mas não uma lista separada de endereços livres.
Responde outro servidor DHCP: o cliente recebe um endereço, mas um gateway ou servidores DNS incorretos.
Policy rule denied para a origem 0.0.0.0: se não estiver configurado na interface nem um servidor DHCP nem um relay, um pedido do cliente pode ser descartado com esta entrada. A mensagem não prova, portanto, que a causa seja uma regra de firewall normal. Verificar primeiro o servidor DHCP, o relay e a atribuição da interface.
Seria necessário DHCP Relay: o cliente não se encontra na rede diretamente ligada ao servidor.
O mapeamento estático não é aplicado: o endereço MAC introduzido não corresponde ao endereço MAC que o cliente utiliza efetivamente.

Com uma captura de pacotes em port 67 or port 68, é possível verificar se são trocados Discover, Offer, Request e ACK e qual o servidor que responde. A utilização é descrita em Utilizar Packet Capture no WebAdmin do Sophos Firewall.

Se um Discover chegar ao firewall, mas não houver Offer, verificar adicionalmente o estado de dhcpd e o log dhcpd.log. Os comandos e caminhos de log adequados são apresentados em Verificar serviços e logs do Sophos Firewall através da CLI.

Se o cliente receber um endereço IP correto, mas não conseguir resolver nomes, verificar primeiro os endereços DNS distribuídos por DHCP. Se estiverem errados ou ausentes, o erro continua na configuração DHCP. Se estiverem corretos, verificar em seguida a resolução interna de nomes e o acesso de rede ao servidor DNS.

Uma interface RED tem ainda um caso específico: se o respetivo endereço for alterado para um endereço fora do intervalo dinâmico existente, o SFOS desativa o servidor DHCP RED associado. É então necessário adaptar Dynamic IP lease, os mapeamentos estáticos e os valores DNS à sub-rede resultante da interface, ou criar uma nova configuração de servidor. Só depois se volta a colocar o âmbito em serviço e se testa com um cliente.

Substituir um servidor DHCP existente

Durante uma migração, não se deve simplesmente ativar também o novo servidor DHCP. Os clientes ativos mantêm o lease anterior; o novo servidor não conhece estas atribuições e pode voltar a oferecer um endereço que ainda está a ser utilizado.

Para uma transição controlada, proceder da seguinte forma:

Documentar o intervalo, as opções, os mapeamentos estáticos e os leases ativos do servidor existente.
Reduzir antecipadamente a duração do lease no servidor antigo e esperar até que os clientes ativos tenham renovado o lease com o valor mais curto.
Parar o servidor existente e ativar inicialmente o novo servidor com um intervalo de transição sem sobreposição.
Renovar o lease em vários clientes diferentes e verificar gateway, DNS e acessibilidade.
Depois de os leases antigos expirarem, ativar o intervalo definitivo e repor a duração normal do lease.

Conflict detection é útil durante uma migração, mas não substitui este planeamento. A função verifica um endereço antes da atribuição, mas não mantém uma base de dados de leases partilhada com o servidor antigo.

Para permitir o recuo, manter um registo completo da configuração anterior. Se o novo âmbito distribuir valores incorretos, desativar ou remover apenas essa nova configuração de servidor e voltar a colocar o servidor anterior em serviço de forma controlada. Em contrapartida, System services > Services > DHCP server > Stop termina o serviço DHCP global e, por conseguinte, todos os âmbitos locais; esta ação só é adequada quando se pretende exatamente esse impacto total. Em seguida, renovar os leases em vários clientes de teste.

Valores especiais, como servidores de arranque PXE, controladores VoIP ou opções específicas do fabricante, têm de ser comparados separadamente antes da mudança. Não fazem automaticamente parte da distribuição normal de endereço, gateway e DNS.

Automação: estado de uma configuração DHCP identificada pelo nome

A documentação da API XML para SFOS 22 e 23 descreve DHCPServerStatus com os campos obrigatórios DHCPServerNamedhcpname e Status. DHCPServerNamedhcpname é a grafia literal documentada, não um nome de campo corrigido aqui. O nome identifica a configuração de servidor DHCP selecionada, por exemplo dhcp-vlan20-clients, e não o serviço DHCP global. Uma alteração de estado deste âmbito identificado pelo nome não deve ser confundida com o Stop global descrito acima.

Para Status, o exemplo mostra ON/OFF, enquanto a tabela de parâmetros indica INTEGER. Não é fornecida nenhuma correspondência numérica nem valor predefinido; ambos os campos são obrigatórios. Não é possível deduzir uma codificação segura nem o comportamento quando se omitem campos. Por isso, não automatizar uma alteração de estado XML a partir deste exemplo. Até esclarecer o esquema dos campos e a codificação do estado para a versão instalada, continuar a utilizar o procedimento GUI existente em Network > DHCP para a configuração de servidor selecionada; controlar o serviço global separadamente em System services > Services.

Antes de uma alteração, registar o nome, a interface, o intervalo de endereços e o estado anterior do âmbito de destino. Depois, verificar exatamente essa configuração e que os outros âmbitos permanecem inalterados, e efetuar com clientes controlados as verificações de lease, gateway, DNS e acessibilidade descritas acima. Ao desativar, verificar que este âmbito já não atribui novos leases; um lease de cliente ainda existente não o comprova. Os resultados API documentados 200 (Operation Successful) e 500 (Operation Fail) não são testes funcionais; HTTP 200 por si só também não confirma o destino correto nem o estado do cliente. Para reverter, repor exatamente o estado registado e repetir as verificações dos clientes.

Alterar as definições DHCP globais apenas quando necessário

Em SFOS 23, Network > DHCP > Advanced server settings contém estes dois campos da interface:

Allow only one lease per client limita cada cliente a um único lease DHCP. Quando a opção está ativada, cada cliente recebe apenas um endereço IP em lease.
Negative acknowledgement ativa respostas DHCPNAK quando um cliente pede um endereço fora da sub-rede configurada do servidor ou um endereço já atribuído. Conflict detection é, por sua vez, a verificação separada de um endereço antes da atribuição.

Antes de uma alteração na interface, registar o valor anterior. Depois, renovar um lease de cliente, verificar IPv4 lease e, se necessário, uma captura de pacotes UDP 67/68. Para reverter a alteração, repor exatamente o valor registado. Continuam a aplicar-se as indicações CLI seguintes sobre o impacto global, a identidade do cliente e os riscos dos NAK.

Dois parâmetros adicionais da Device Console aplicam-se a todo o serviço DHCP. Antes de uma alteração, consultar a ajuda local específica dos comandos one-lease-per-client e send-dhcp-nak na versão instalada. Registar o estado atual de ambos os parâmetros através de uma consulta de leitura aí suportada ou de uma indicação disponível na interface de utilizador e confirmar a sintaxe de alteração e de reposição. Não se pressupõe aqui uma forma específica de show nem um valor predefinido para todas as versões. Se não for possível determinar de forma fiável o estado inicial ou o procedimento de reversão, não efetuar qualquer alteração e contactar primeiro o suporte.

one-lease-per-client, quando ativado, limita a atribuição de leases por cliente. É necessário esclarecer localmente como a versão instalada identifica o cliente em casos especiais. A ativação aplica-se a todas as configurações de servidor DHCP neste firewall; por isso, inicialmente limita-se apenas o teste a um cliente controlado e verificam-se depois a tabela de leases, a renovação e os dispositivos com várias interfaces ou com um endereço MAC variável.

A ativação de send-dhcp-nak permite respostas DHCPNAK. Um DHCPNAK rejeita um endereço que o servidor não aceita e obriga o cliente a regressar à negociação DHCP. A desativação pode prolongar estados inválidos dos clientes e não é uma correção geral para leases falhados.

Só se a ajuda local confirmar esta sintaxe para a versão instalada e estiverem registados o estado inicial e o procedimento de reversão se alteram os parâmetros da seguinte forma:

system dhcp one-lease-per-client [enable|disable]
system dhcp send-dhcp-nak [enable|disable]

Os parênteses retos são marcadores de posição; executar apenas o valor necessário. Após a alteração, verificar novamente o valor através da mesma consulta de leitura suportada ou indicação na interface de utilizador, renovar um lease, consultar IPv4 lease e, se necessário, efetuar uma captura de pacotes em UDP 67/68. Para reverter, repor exatamente os valores registados antes da alteração com a sintaxe confirmada antecipadamente e verificar novamente ambos os parâmetros. system dhcp one-lease-per-client disable e system dhcp send-dhcp-nak enable só são valores de reposição adequados se o primeiro parâmetro estava anteriormente desativado e o segundo estava anteriormente ativado, respetivamente, e se a ajuda local confirmar esta sintaxe. A alteração e a reversão não foram testadas aqui num firewall.