By João Peterson on 16 Jan 2023 | 10:20 .

Categories | Linux | Home Lab / Home server | Tutorials | Sysadmin

Tempo de leitura: #

Visualizações: #

Olá pessoal, neste artigo gostaria de compartilhei com vocês como configurar um servidor de DNS local, para podermos criar domínios em nossa rede local e que princialmente funciona como um filtro de DNS, bloqueando acesso a certos sites, sendo estes sites servidores de anúncios, tornando se assim um Adblock a nível de rede.

Estaremos utilizando a mesma máquina linux configurada no artigo Configurando uma máquina Linux e acesso remoto via SSH. Lembre se de conectar-se a máquina remota antes de fazer os procedimentos.

Sumário

Sumário
Instalação
Proxy reverso e firewall
Configuração
Nginx

Instalação

No Archlinux pra instalar o Pihole necessitamos utilizar uma imagem docker, há suporte nativo para distribuições como CentOS, Fedora, Ubuntu e Debian. Farei um serviço no systemd para essa imagem, como discutido no artigo Como criar um serviço systemd para uma imagem docker

Primeiramente vamos baixar o docker se você ainda não tiver instalado:

$ sudo pacman -S docker

E habilitar o serviço

$ sudo systemctl enable docker.service --now

Agora baixar a imagem:

$ sudo docker pull pihole/pihole

Para o serviço eu configurei o arquivo da seguinte forma:

/usr/lib/systemd/system/pihole.service:

[Unit]
Description=pihole
Requires=docker.service multi-user.target
After=docker.service network-online.target dhcpd.service

[Service]
Restart=always
ExecStartPre=/bin/bash -c "/usr/bin/docker container inspect pihole 2> /dev/null || /usr/bin/docker run -d --privileged -p 53:53/tcp -p 53:53/udp -p 3080:80 -e TZ="America/Sao_Paulo" -v /etc/pihole:/etc/pihole/ -v /etc/unbound:/etc/unbound/ -v /etc/dnsmasq:/etc/dnsmasq.d/ --dns=1.1.1.1 --hostname pihole -e VIRTUAL_HOST="pihole" -e FTLCONF_LOCAL_IPV4="127.0.0.1" --name pihole pihole/pihole"
ExecStart=/usr/bin/docker start -a pihole
ExecStop=/usr/bin/docker stop -t 1 pihole
ExecReload=/usr/bin/docker restart -t 1 pihole

[Install]
WantedBy=multi-user.target

E por fim vamos iniciar o serviço:

$ sudo systemctl enable pihole.service --now

Proxy reverso e firewall

E mais ainda, se você seguiu o artigo de configuração do sistema, viu que estamos usando o firewall ufw, e portanto devemos liberar acesso a algumas portas para que clientes possam usar o pihole. Assim vamos habilitar as seguintes portas:

53 - Porta comum para servidor DNS
3080 - Interface Web

$ sudo ufw allow 53
$ sudo ufw allow 3080

Por enquanto não temos um proxy reverso e domínios para a interface web, então liberaremos a porta direto, porém assim que configuramos o Nginx devemos fechar essa porta em nosso firewall.

Futuramente para remover basta usar o seguinte comando, por exemplo, onde as regras serão 5 e 10:

$ sudo ufw status numbered

     To                         Action      From
     --                         ------      ----
[ 1] 22                         ALLOW IN    Anywhere
[ 2] 53                         ALLOW IN    Anywhere
[ 3] 80                         ALLOW IN    Anywhere
[ 4] 443                        ALLOW IN    Anywhere
[ 5] 3080                       ALLOW IN    Anywhere
[ 6] 22 (v6)                    ALLOW IN    Anywhere (v6)
[ 7] 53 (v6)                    ALLOW IN    Anywhere (v6)
[ 8] 80 (v6)                    ALLOW IN    Anywhere (v6)
[ 9] 443 (v6)                   ALLOW IN    Anywhere (v6)
[10] 3080 (v6)                  ALLOW IN    Anywhere (v6)

$ sudo ufw delete 10
$ sudo ufw delete 5

Para a criação do proxy reverso veja a seção Nginx.

Configuração

Primeiramente devemos configurar a senha de acesso da interface web, para isso vamos entrar na imagem docker do pihole:

$ sudo docker exec -ti pihole bash

E então alterar a senha:

$ root@pihole: pihole -a -p PASSWORD

E sair da shell:

$ root@pihole: exit

Abra no seu navegador http://SERVER_IP:3080/admin e tente logar, caso o processo não tenha funcionado, aconselho as seguintes fontes para auxiliar na resolução de erros:

A partir deste momento você terá acesso a interface web do pihole, podendo verificar em tempo real as queries dns feitas, agora vamos fazer algumas coisas, configurar o nosso servidor DNS de forma que todos os dispositivos de rede o usem, habilitar DNS recursivo para mitigar o rastreio de nossas queries DNS e por fim configurar domínios customizados para podermos utilizar em nossa rede local, de forma que não precisaremos mais lembrar IP’s e portas para cada serviço que gostaríamos de utilizar.

Servidor DNS padrão da rede

A forma mais fácil de fazer isto é através do seu gateway padrão, o que é dependente de cada fabricante, no meu caso um roteador TP-link Archer.

Onde no campo DNS primário iremos colocar o IP de nosso servidor local que está rodando o pihole e como secundário podemos colocar um servidor de backup caso no server caia, por exemplo o da google 8.8.8.8.

DNS recursivo

Para evitar que outras pessoas tenham acesso as nossas queries de DNS, que são não criptografadas e em texto legível, iremos utilizar o DNS recursivo, que auxilia na mitigação de rastreadores e curiosos que desejem olhar os nossos acessos a queries DNS.

O guia oficial pode ser encontrado em Pihole Unbound.

O unbound é um binário separado, e pode ser baixado nativamente no Archlinux, assim podemos instalar unbound da seguinte forma.

$ sudo pacman -S unbound

E então configurar o arquivo:

/etc/unbound/unbound.conf:

server:
    # If no logfile is specified, syslog is used
    # logfile: "/var/log/unbound/unbound.log"
    verbosity: 0

    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes

    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no

    # Use this only when you downloaded the list of primary root servers!
    # If you use the default dns-root-data package, unbound will find it automatically
    #root-hints: "/var/lib/unbound/root.hints"

    # Trust glue only if it is within the server's authority
    harden-glue: yes

    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    harden-dnssec-stripped: yes

    # Don't use Capitalization randomization as it known to cause DNSSEC issues sometimes
    # see https://discourse.pi-hole.net/t/unbound-stubby-or-dnscrypt-proxy/9378 for further details
    use-caps-for-id: no

    # Reduce EDNS reassembly buffer size.
    # IP fragmentation is unreliable on the Internet today, and can cause
    # transmission failures when large DNS messages are sent via UDP. Even
    # when fragmentation does work, it may not be secure; it is theoretically
    # possible to spoof parts of a fragmented DNS message, without easy
    # detection at the receiving end. Recently, there was an excellent study
    # >>> Defragmenting DNS - Determining the optimal maximum UDP response size for DNS <<<
    # by Axel Koolhaas, and Tjeerd Slokker (https://indico.dns-oarc.net/event/36/contributions/776/)
    # in collaboration with NLnet Labs explored DNS using real world data from the
    # the RIPE Atlas probes and the researchers suggested different values for
    # IPv4 and IPv6 and in different scenarios. They advise that servers should
    # be configured to limit DNS messages sent over UDP to a size that will not
    # trigger fragmentation on typical network links. DNS servers can switch
    # from UDP to TCP when a DNS response is too big to fit in this limited
    # buffer size. This value has also been suggested in DNS Flag Day 2020.
    edns-buffer-size: 1232

    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    prefetch: yes

    # One thread should be sufficient, can be increased on beefy machines. In reality for most users running on small networks or on a single machine, it should be unnecessary to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # Ensure kernel buffer is large enough to not lose messages in traffic spikes
    so-rcvbuf: 1m

    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Agora poderemos rodar o serviço:

$ sudo systemctl enable unbound.service --now

Agora no painel administrador pihole, vá para Settings, desmarque todas as caixinhas de Upstream DNS ativas, habilite Custom 1, e coloque o endereço do unbound, 127.0.0.1#5335, lembre de rolar até o final da página e clicar em salvar.

Pronto, agora todas as queries serão recursivas, para testar execute o seguinte comando:

$ sudo pacman -S bind
$ dig google.com @127.0.0.1 -p 5335

; <<>> DiG 9.18.10 <<>> google.com @127.0.0.1 -p 5335
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58690
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		300	IN	A	142.251.129.206

;; Query time: 270 msec
;; SERVER: 127.0.0.1#5335(127.0.0.1) (UDP)
;; WHEN: Mon Jan 16 04:58:08 -03 2023
;; MSG SIZE  rcvd: 55

Note que no retorno, ao final, o SERVER deve possuir ip do localhost, 127.0.0.1, indicando que da fato o nosso servidor retornou esse resultado. Este foi o teste para o serviço unbound sozinho, agora podemos testar par ao pihole, que deverá responder de forma igual.

$ dig google.com @127.0.0.1 -p 53

Feito o teste e verificado o SERVER de retorno novamente, está validado a configuração e agora temos uma configuração pihole + unbound funcionando.

Registro DNS local

Por fim, vamos habilitar o registro de domínios locais, para isto basta criar o seguinte arquivo:

/etc/dnsmasq.d/02-custom-dns.conf:

address=/DOMAIN.lan/192.168.xxx.xxx

Onde DOMAIN é o nome do seu domínio local, assim todo subdomínio apontará para o seu servidor em 192.168.xxx.xxx onde poderemos configurar um proxy reverso para redirecionar o tráfego para aplicações diferentes. Por exemplo:

pihole.server.lan -> http://localhost:3080
jellyfin.server.lan -> http://localhost:3040

Nginx

Caso você já tenha configurado o Nginx você pode usar o seguinte arquivo de configuração para redirecionar o subdomínio pihole para a interface web.

Exemplo de arquivo para proxy reverso de subdomínio para a interface web do pihole:

server {
    listen 80;
    server_name pihole.DOMAIN.lan;

    location / {
        proxy_pass http://127.0.0.1:3080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    }
}

Configurando um servidor DNS local com Pihole em servidor Linux