Adguardhome: Expanda / esclareça as opções de DHCP

Como um projeto de código aberto com uma equipe de mantenedores dedicada, mas pequena, às vezes pode levar muito tempo para que os problemas sejam resolvidos, então seja paciente e entraremos em contato com você assim que possível.

Pré-requisitos

• [x] Estou executando a versão mais recente
• [x] Eu verifiquei a documentação e não encontrei resposta
• [x] Eu verifiquei para ter certeza de que este problema ainda não foi arquivado

Descrição do Problema

Eu gostaria de mais controle sobre o domínio local. No momento, isso está codificado para lan , consulte também # 2393.

Também estou confuso com o requisito de ip ou hex para as opções de campo dhcpv4 . Isso só permite definir opções / valores numéricos. Tentei transmitir o domínio para clientes DHCP usando a opção 15 das opções DHCP / RFC2132 , mas não há como definir a string lan . Tentei com pontos de código ASCII / UTF-8, mas isso não faz sentido dado como é analisado:

https://github.com/AdguardTeam/AdGuardHome/blob/7fab31beaeb8c7d1c9892746bbf37e99d4f9dc01/internal/dhcpd/dhcpd.go#L289

que parece retornar apenas ints ?

Nesse ponto, isso também ultrapassa meu nível de competência.

Solução proposta

Adicione mais opções para o campo dhcpv4 , semelhante a dnsmasq . Este exemplo de configuração é uma boa descrição do que se poderia desejar para isso, eu acho.

Atualmente, ao usar o AGH como servidor DHCP e também como servidor DNS, o domínio local lan funciona bem. No entanto, embora as consultas a local_machine.lan sejam respondidas pelo AGH localmente e corretamente, elas também são encaminhadas para servidores de internet upstream em minha configuração. Isso é um pouco confuso. Adicionar [/lan/]192.168.0.2 , onde 192.168.0.2 é o endereço da máquina AGH, à lista de servidores DNS upstream resolve o seguinte: as solicitações não são mais encaminhadas. Definir 0.0.0.0 ou 127.0.0.1 também funciona, mas eu realmente não sei o que estou fazendo lá. Pelo menos eles não "vazam" mais. Veja também # 2582.

Como efeito colateral, isso, por exemplo, trava e, eventualmente, atinge o tempo limite:

# Before, *without* [/lan/] filter
$ host local_machine.lan
local_machine.lan has address 192.168.0.50 # IMMEDIATE
Host local_machine.lan not found: 3(NXDOMAIN) # Almost immediate
#  ^ NXDOMAIN from upstream internet DNS server.
# Of course it doesn't know that domain.

# Now *with* the custom [/lan/] upstream DNS in place:
$ host local_machine.lan
local_machine.lan has address 192.168.0.50  # Again, IMMEDIATE
;; connection timed out; no servers could be reached  # 10s, then timeout

Com o novo [/lan/] no lugar, coisas como ssh ainda funcionam instantaneamente porque eu acho que depois que o primeiro IP chega, ele é executado.

Podemos ter uma instrução dnsmasq -like local , veja o link acima para o exemplo de configuração? Em /etc/dnsmasq.conf , uma instrução

local=/mydomain/

nunca vazaria para fora. Perfeito! Além disso,

domain=mydomain

seria incrível ter. Talvez jogar em um domain-needed -equivalente?

Alternativas consideradas

Neste ponto, pode-se executar uma configuração como # 2514: se todas as opções dnsmasq -equivalentes forem necessárias, basta executar um servidor DNS + DHCP dnsmasq como o servidor primário. Nele, defina uma instância AGH (sem DHCP) como o único DNS upstream. Deve funcionar bem, só requer mais coisas. Por exemplo, se rodando em uma máquina, o AGH precisaria de uma porta diferente de 53. Fácil o suficiente se não rodar com network_mode: host , que só precisamos se usar DHCP. No entanto, essa configuração "exigiria" add-mac / add-subnet , conforme descrito nessa edição.

Informações adicionais