205.3 Resolução de Problemas em Redes
Este tópico mostra como identificar e resolver problemas de Redes.
IFCONFIG
Com o comando ifconfig devemos ver se as interfaces estão ativas, se uma interface não estiver ativa ela nem vai aparecer, será necessário usar o parâmetro -a.
# Vendo se uma interface está down:
linux@gw:~$ ifconfig -a | grep -E "^[[:alnum:]]+:" | grep -vi up
eth2: flags=4098<BROADCAST,MULTICAST> mtu 1500
# Vendo as interfaces up:
linux@gw:~$ ifconfig -a | grep -E "^[[:alnum:]]+:" | grep -i up
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
# Usando o comando 'ip' para interfaces UP:
linux@gw:~$ ip a | grep -i " up "
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
# Usando o comando 'ip' para interfaces DOWN:
linux@gw:~$ ip a | grep -i " down "
4: eth2: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
Não esqueça de confirmar a máscara da rede, é importante se certificar que o IP foi configurado na Rede correta. Além diss, verifique se o gateway foi configurado e se está correto.
Outro ponto importante para se ver são os campos de informações do ifconfig.
Verifique também se existe rota padrão e se é possível acessar o destino através da rota padrão, caso não seja, verifique se existe rota para o destino.
TRACEROUTE
Utilize o comando traceroute para testar o caminho até o destino, com isso é possível saber se estamos parando em algum ponto e depois dele não será mais possível passar.
MTR
É igual ao traceroute mas a saída gerada é diferente e possui bastantes parâmetros, eu particularmente prefiro o mtr.
linux@gw:~$ mtr -rn www.lpi.org
Start: 2022-08-06T12:59:07+0000
HOST: gw Loss% Snt Last Avg Best Wrst StDev
1.|-- 192.168.121.1 0.0% 10 0.4 0.3 0.2 0.4 0.1
2.|-- 192.168.1.1 0.0% 10 1.0 1.3 0.6 5.8 1.6
3.|-- 186.230.221.117 0.0% 10 6.0 7.1 5.6 12.9 2.5
4.|-- 10.192.254.14 0.0% 10 6.9 6.8 6.3 8.7 0.7
5.|-- 10.223.238.238 0.0% 10 6.9 6.8 6.1 9.2 0.9
6.|-- 195.22.219.32 0.0% 10 7.0 7.0 6.2 7.7 0.4
7.|-- 89.221.41.181 0.0% 10 112.1 116.5 111.9 150.0 11.9
8.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
9.|-- 154.54.88.233 0.0% 10 193.4 129.2 112.3 193.4 32.4
10.|-- 154.54.28.49 0.0% 10 124.8 125.3 124.6 128.3 1.1
11.|-- 154.54.24.221 0.0% 10 130.9 130.9 130.7 131.4 0.2
12.|-- 154.54.82.253 0.0% 10 143.4 143.1 142.6 143.4 0.3
13.|-- 154.54.31.234 0.0% 10 147.2 146.9 146.5 147.7 0.3
14.|-- 38.32.157.66 0.0% 10 147.5 147.3 146.6 149.4 0.9
15.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
O ? tem o mesmo efeito do * no traceroute.
NETSTAT e SS
Reveja o neststat aqui.
Reveja o ss aqui.
PING
Reveja o neststat aqui.
Configuração de Rede
Vamos ver como deixar as configurações de rede persistentes, para que quando a máquina seja desligada/reiniciada ela não perca essas configurações. Cada Sistema Operacional ou conjunto de familias de distribuições Linux possuem seu próprio método de configuração.
Debian Like
Para Debian e Ubuntu (Ubuntu até a versão 16.04) usa o arquivo
/etc/network/interfaces.Ubuntu
Para o sistema do Ubuntu na versão 17.10 ou mais recente é usado o Netplan, os arquivos de configuração ficam em
/etc/netplan/.RedHat
Para o sistema da RedHat os arquivos de configuração ficam em
/etc/sysconfig/network-scripts/ifcfg-INTERFACE_NAME.
Configuração de Rede no Debian
Vamos ver como configurar a rede no padrão Debian, apenas o básico. Primeiro vamos ver como configurar para usar dhcp.
# Edite o arquivo '/etc/network/interfaces'.
auto eth0
allow-hotplug eth0
iface eth0 inet dhcp
Agora configure um endereço estático:
# Usando IPv4:
auto eth0
iface eth0 inet static
address 192.0.2.7/24
gateway 192.0.2.254
# Usando IPv6:
iface eth0 inet6 static
address 2001:db8::c0ca:1eaf/64
gateway 2001:db8::1ead:ed:beef
Vou deixar abaixo uma configuração usando 4 interfaces com LACP, depois cria-se 3 interfaces lógicas (usando a interface agregada bond0) onde cada interface lógica correponde a uma vlan e com isso cria-se uma interface bridge usando uma interface de vlan, essa é uma configuração bem avançada.
auto lo
iface lo inet loopback
# Defining BONDs
auto eno1 eno2 eno3 eno4
iface eno1 inet manual
iface eno2 inet manual
iface eno3 inet manual
iface eno4 inet manual
# Create bond0 with lacp
auto bond0
iface bond0 inet manual
bond-slaves eno1 eno2 eno3 eno4
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3
# Defining VLANs
auto bond0.1011 bond0.1012 bond0.1013
iface bond0.1011 inet manual
iface bond0.1012 inet manual
iface bond0.1013 inet manual
# Defining Bridge using vlan 1011 (interface bond0.1011)
auto vmbr0
iface vmbr0 inet manual
address IP/MASK
gateway IP
dns-nameserver IP
dns-nameserver IP
dns-search DOMAIN
bridge-ports bond0.1011
bridge-stp off
bridge-fd 0
Para mais detalhes veja no link oficial.
Configuração de Rede no Ubuntu
Vamos ver como configurar a rede no Ubuntu a partir da versão 17.10 que usa o Netplan. Primeiro vamos ver como configurar para usar dhcp.
network:
version: 2
renderer: networkd
ethernets:
eth0:
dhcp4: true
Agora configure um endereço estático sem rota padrão mas inserindo uma rota (que não é rota padrão):
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 10.10.10.2/24
nameservers:
search: [mydomain, otherdomain]
addresses: [10.10.10.1, 1.1.1.1]
routes:
- to: default
via: 10.10.10.1
Agora configure um endereço estático com rota padrão (nesse caso é só inserir o gateway):
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 10.10.10.2/24
gateway4: 10.10.10.1
nameservers:
search: [mydomain, otherdomain]
addresses: [10.10.10.1, 1.1.1.1]
Criando uma interface bridge:
network:
version: 2
renderer: NetworkManager
ethernets:
eth0:
dhcp4: false
bridges:
br0:
dhcp4: yes
interfaces:
- eth0
parameters:
stp: false
forward-delay: 0
version: 2
Vale ressaltar que o
rendererpode serNetworkManagerounetworkd, isso vai depender de quais você está usando, o Netplan é mais como um front-end que converte a sintaxe nele para um dos backend (NetworkManagerounetworkd) para que a configuração possa ter efeito.
Para mais detalhes veja no link oficial.
Configuração de Rede no RedHat
A configuração da rede no padrão RedHat é feita no diretório network-scripts que fica em /etc/sysconfg/network-scripts/ifcfg-INTERFACE. Minha conexão é denominada eth0, então para acessar a configuração dela eu vou em /etc/sysconfg/network-scripts/ifcfg-eth0.
Abaixo segue um exemplo de como pode estar o seu arquivo de configuração original (sem nenhuma alteração):
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=dhcp
DEFROUTE=yes
IPV4_FAILURE_FATAL=no
IPV6INIT=yes
IPV6_AUTOCONF=yes
IPV6_DEFROUTE=yes
IPV6_FAILURE_FATAL=no
IPV6_ADDR_GEN_MODE=stable-privacy
NAME=eth0
UUID=f19db820-09b3-4138-8f5f-ea91e6bb8dde
DEVICE=eth0
ONBOOT=yes
Veja abaixo algumas da opções usadas acima.
| Opções | Descrição |
|---|---|
| DEVICE | É a interface de rede. |
| BOOTPROTO | Aqui escolhemos entre DHCP ou NONE. NONE - Para configurar manualmente a interface; DHCP - Para utilizar DHCP para atribuição dinâmica de IP. |
| ONBOOT | Determina se a interface vai ser levantada na hora do boot yes ou no; |
| USERCTL | Determina se os usuários comuns podem ligar/desligar a interface. |
Todas as outras opções normalmente não são usadas e podem ser omitidas, essas são as mais importantes.
Agora veja como configurar uma interface estática:
TYPE=Ethernet
BOOTPROTO=none
IPADDR=192.168.1.10
NETMASK=255.255.255.0
GATEWAY=192.168.1.1
NETWORK=192.168.1.0
NAME=enp0s3
DEVICE=enp0s3
UUID=f19db820-09b3-4138-8f5f-ea91e6bb8dde
ONBOOT=yes
Normalmente o gateway não fica nesse arquivo, ele fica em /etc/sysconfg/network com a seguinte sintaxe:
GATEWAY=192.168.1.1
Cliente DNS
A principal configuração para o cliente DNS fica no arquivo /etc/resolv.conf, dentro desse arquivo ficam as definições de quem serão os servidores DNS que o cliente vai usar. Por padrão qualquer aplicação que necessite consultar um servidor DNS, vai obter os servidores a partir desse arquivo, não importando se o sistema é um desktop ou servidor. Existe certas aplicações que mudam o comportamento padrão desse arquivo, estou falando de usar um resolver DNS que faz a intermediação das consultas DNS para as aplicações locais, principalmente ao usar o daemon Systemd-resolved.
Os testes foram realizados usando Ubuntu 20.04 LTS.
Systemd-Resolved
O systemd-resolved é um daemon que fornece um Serviço de Resolução de Nomes (DNS) para aplicações locais, com ele podemos ter cache DNS, DNSSEC e muitas outras vantagens. Esse daemon também é conhecido como resolver porque quando o usamos, não é a aplicação solicitante que vai até o servidor DNS realizar a consulta, é esse daemon que vai até o servidor DNS, então ele faz a consulta e retorna o resultado para a aplicação solicitante, veja o esquema abaixo para facilitar a compreensão.
A foto na esquerda representa um sistema com o systemd-resolved instalado e configurado para usar ele, já a foto que está na direita representa um sistema que não usa nenhum sistema para intermediar a comunicação com os servidores DNS, nesse caso o próprio Firefox é o resolver.
Os servidores DNS que serão usados para consulta são determinados a partir das configurações globais em /etc/systemd/resolved.conf, além desse arquivo existem outros que também são consultados, o uso de cada arquivo varia de acordo com o daemon usado para fazer a configuração de Rede, normalmente o systemd-resolved funciona com a maioria dos daemons de Rede para conseguir fornecer um serviço de DNS, mas aqui vou mencionar dois que são os mais comuns de usos em Desktops e Servidores, são eles: SystemD-NetworkD e NetworkManager.
Além do arquivo mencionado acima, é consultado o arquivo /etc/resolv.conf para descobrir mais servidores DNS, mas somente se esse arquivo não for um link simbólico para /run/systemd/resolve/stub-resolv.conf, /usr/lib/systemd/resolv.conf ou /run/systemd/resolve/resolv.conf, caso ele seja, o arquivo /etc/resolv.conf será ignorado quanto ao obter servidores DNS que estiverem dentro dele.
Esse processo acontece porque se /etc/resolv.conf for um link simbólico para /run/systemd/resolve/stub-resolv.conf ou para /usr/lib/systemd/resolv.conf isso configura o sistema para usar o resolver systemd-resolved na porta 53 do IP 127.0.0.53 e se ele apontar para /run/systemd/resolve/resolv.conf, ele vai ignorar o uso do resolver systemd-resolved como um serviço intermediário e passa a fazer as consultas DNS diretamente com os servidores DNS.
resolv.conf e stub-resolv.conf
Como é um pouco confuso, resolvi deixar mais explicito a diferença entre os arquivo /run/systemd/resolve/stub-resolv.conf e /run/systemd/resolve/resolv.conf. Lembrando que ambos são usados para manter a compatibilidade com programas Linux tradicionais e um deles sempre será um link simbólico para /etc/resolv.conf.
/run/systemd/resolve/stub-resolv.conf
Esse arquivo contém uma configuração que informa para o sistema que o servidor DNS é o 127.0.0.53, isso automaticamente faz com que qualquer aplicação que vá usar o DNS use o serviço do systemd-resolved, basicamente é isso que esse arquivo faz.
/run/systemd/resolve/resolv.conf
Nesse arquivo contém informações sobre todos os servidores DNS conhecidos, com isso quero dizer, nesse arquivo ficam todos os servidores DNS que foram obtidos de alguma forma, seja via DHCP ou via configuração estática em algum arquivo. Com isso passamos a ignorar o systemd-resolved já que as aplicações conversam diretamente com os servidores DNS e por isso cria-se uma limitação ao usar esse arquivo.
Essa limitação acontece porque ao usar servidores DNS diretamente, as interfaces não conhecem o conceito de servidores DNS por interface e, portanto, contém apenas definições de servidor DNS em todo o sistema, ou seja, todas as interfaces vão usar o mesmo servidor DNS, para sistemas de servidores isso é até um requisito em 99% dos casos, mas para sistemas de Desktop isso pode impactar quanto ao uso de aplicações via VPN.
Para ver qual resolver está usando (se é que está) podemos usar o comando abaixo:
$ sudo lsof -i :53 -S
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-r 512 systemd-resolve 12u IPv4 21648 0t0 UDP localhost:domain
systemd-r 512 systemd-resolve 13u IPv4 21651 0t0 TCP localhost:domain (LISTEN)
# Outra forma:
$ sudo ss -lp -i sport 53
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 127.0.0.53%lo:domain 0.0.0.0:* users:(("systemd-resolve",pid=512,fd=12))
tcp LISTEN 0 4096 127.0.0.53%lo:domain 0.0.0.0:* users:(("systemd-resolve",pid=512,fd=13))
cubic cwnd:10Caso não apareça nada, provavelmente você não possui um resolver e está fazendo as consultas diretamente nos servidores DNS.
Systemd-networkd
O Systemd-networkd é um serviço do Sistema Operacional Linux usado para gerenciar Redes, ele detecta e configura dispositivos de Rede quando eles aparecem para ele. Normalmente esse serviço é instalado em ambientes que usem SystemD e em sistemas servidores, ou seja, não notei o uso desse serviço em Sistemas de Desktops (para uso de clientes finais), esse serviço é encontrado quando aplicamos pacotes de Desktop num ambiente Servidor, fazendo a conversão do sistema Servidor para Desktop.
Lembrando que usei o Ubuntu Server e Desktop para os testes.
Como curiosidade o principal daemon do NetworkD é
systemd-networkd.service.
Os arquivos contendo a configuração de Rede, incluindo os servidores DNS podem ficar em: /run/systemd/network/* e /etc/systemd/network/*, dando maior prioridade para primeiro diretório. Esses mesmos diretórios são usados pelo daemon do systemd-resolved para obter os servidores DNS, criando-se assim uma compatibilidade direta entre esses daemons (já que todos são pertencentes ao SystemD).
Por padrão o Ubuntu Server vem com o Systemd-resolved e o Systemd-networkd instalados e configurados, na maioria dos casos acho bom remover o Systemd-resolved e usar somente o NetworkD já que com o Systemd-resolved ele acaba fazendo cache das consultas DNS e muitas vezes por ser um servidor precisamos da resultado mais recente possível para uma determinada consulta. Outro detalhe que vale a pena mencionar é que o NetworkD não sobrescreve o que está em /etc/resolv.conf caso você remova o link simbólico e crie um arquivo estático.
Network-Manager
O Network-Manager é um serviço do Sistema Operacional Linux usado para gerenciar Redes assim como o Systemd-networkd, diferente do NetworkD o Network-Manager possui funções e utilitários que fazem muito mais, seu arquivo de configuração principal fica em /etc/NetworkManager/NetworkManager.conf e as informações de Rede, principalmente sobre conexões Wifi ficam em /etc/NetworkManager/system-connections/, já as informações sobre interfaces virtuais e rede cabeada ficam em /run/NetworkManager/system-connections/.
Além dos arquivos mencionados acima ainda temos alguns arquivos para armazenar informações de DNS como o /run/NetworkManager/no-stub-resolv.conf (esse arquivo se assemelha ao /run/systemd/resolve/resolv.conf) e outro arquivo é o /run/NetworkManager/resolv.conf (esse arquivo se assemelha ao /run/systemd/resolve/stub-resolv.conf).
Por padrão no Ubuntu Desktop o Network Manager funciona em conjunto com o Systemd-Resolved, mesmo que não tenha conseguido visualizar explicitamente essa configuração nos arquivos, mas esse comportamente pode ser mudado. A documentação do network manager informa que existem 3 modos de processos para trabalhar com DNS, são eles:
dns=default
O NetworkManager sempre vai atualizar o arquivo
/etc/resolv.conf, mesmo quando ele for um arquivo estático, e nesse modo de operação, servidores DNS de todas as conexões são adicionadas ao/etc/resolv.confe os search domains também são.dns=systemd-resolved e dns=dnsmasq
O NetworkManager sempre vai atualizar o arquivo
/etc/resolv.conf, mesmo quando ele for um arquivo estático, remover o link simbólico que aponta para os arquivos do Systemd-Resolved não surte efeito como acontece com o NetworkD, o Network Manager vai sobrescrever o conteúdo do/etc/resolv.conffazendo com que a configuração de DNS aponte para o IP127.0.0.53(é exatamente o mesmo conteúdo de/run/systemd/resolve/stub-resolv.conf), isso acontece porque ele está configurado para usar dnsmasq ou systemd-resolved.Ambas as configurações usam servidores de DNS divididos, isso quer dizer que, o uso de servidores DNS será fornecido pela conexão somente quando o domínio consultado combinar com o domínio associado a conexão. Veja a imagem abaixo para entender melhor o fluxo.
A imagem mostra que sempre será usado o DNS da interface que combina com o domínio associado a interface, mas e quando o domínio não estiver presente em nenhuma interface? Nesses casos é usado a conexão que tem o search domain igual a
~, por exemplo:# No caso do systemd-resolved:
$ resolvectl -i enxa44cc8f1a2d9
Link 2 (enxa44cc8f1a2d9)
Current Scopes: DNS
DefaultRoute setting: yes
LLMNR setting: yes
MulticastDNS setting: no
DNSOverTLS setting: no
DNSSEC setting: no
DNSSEC supported: no
Current DNS Server: 192.168.1.1
DNS Servers: 192.168.1.1
DNS Domain: ~.
lan
$ resolvectl -i enxa44cc8f1a2d9 domain
Link 2 (enxa44cc8f1a2d9): ~. lanPara desligar esse efeito do Network Manager sobrescrever o arquivo
/etc/resolv.confindependente do modo de operação, faça a configuração abaixo:$ sudo vim /etc/NetworkManager/NetworkManager.conf
## Adicione as opções abaixo dentro da sessão [main]:
dns=none
rc-manager=unmanagednone= NetworkManager não vai modificar/etc/resolv.conf. Isto implica emrc-manager = unmanaged.A opção
rc-managerconfigura o modo de gerenciamento do/etc/resolv.conf, já o modounmanagedinforma para não mexer no arquivo/etc/resolv.conf.
Vejamos um exemplo de cada arquivo, começando com o resolv.conf
$ cat /etc/resolv.conf
# This file is managed by man:systemd-resolved(8). Do not edit.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs must not access this file directly, but only through the
# symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a different way,
# replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 127.0.0.53
options edns0 trust-ad
Debian 11
Fiz um teste com Debian 11, ele não possui Network Manager e nem NetworkD, nesse sistema temos o IfUpDown e apesar da configuração de DNS informar que existe System-resolved eu não o achei instalado por padrão, vale ressaltar que usei uma máquina com uso do Vagrant e pode ter sido alterada.
# Verificando se tenho systemd-resolved:
vagrant@debian11:~$ sudo systemctl is-active systemd-resolved
inactive
# Verificando se tenho systemd-networkd:
vagrant@debian11:~$ sudo systemctl is-active systemd-networkd
inactive
# Verificando se tenho natwork manager:
vagrant@debian11:~$ sudo systemctl is-active NetworkManager
inactive
# Verificando se tenho o IfUpDown:
vagrant@debian11:~$ sudo systemctl is-active networking
active
vagrant@debian11:~$ dpkg -l ifupdown
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-==============-============-============-================================================
ii ifupdown 0.8.36 amd64 high level tools to configure network interfaces
# Ao consultar o resolv.conf é informado que existe systemd-resolved:
vagrant@debian11:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "resolvectl status" to see details about the actual nameservers.
nameserver 8.8.8.8
nameserver 192.168.121.1
Novamente, esse sistema pode ter sido alterado antes de ter sido disponibilizado para o Vagrant Cloud.
Resolv.conf
Agora, tendo o conhecimento de toda essa estrutura que pode e vai mudar o funcionamento do /etc/resolv.conf, vamos ver como funciona esse arquivo num ambiente onde ele não seja influenciado por mais nada além de alguém que vá editar ele (sem resolver intemediário e sem conceito de DNS por interface).
Segue uma tabela com as opções que podemos usar:
| Opção | Descrição |
|---|---|
| domain (dominio) | Fornece um domínio. |
| search (domain1) (domain2) | Fornece os domínios para associar a interface e usar aquele DNS para uma consulta DNS para um daqueles domínios. Além de não precisa ficar colocando sempre o domínio no nome do Host, será testado todos os domínios até achar o correto. Ex: search eng.br Agora pingue: ping www.sysnetbr |
Veja um exemplo desse arquivo:
$ cat /etc/resolv.conf
nameserver 8.8.8.8
search eng.br
/etc/hosts
Era um arquivo usado antes do protocolo DNS, ele fornece resolução de nomes para as aplicações locais, normalmente ele é consultado primeiro e depois é consultado o DNS, mas isso pode mudar de acordo com a configuração do /etc/nsswitch.conf.
Veja um exemplo desse arquivo:
$ cat /etc/hosts
127.0.0.1 localhost
192.168.1.28 keygen.ddns.net
192.168.121.186 www.empresa.com.br
2000:0db8:0:::dddd foo.bar.com
# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
/etc/network
Esse arquivo é usado para dar nome as redes.
$ cat /etc/networks ↵ 1
# symbolic names for networks, see networks(5) for more information
link-local 169.254.0.0
Fontes de leitura importantes
https://man7.org/linux/man-pages/man8/systemd-resolved.service.8.html
https://man7.org/linux/man-pages/man5/resolv.conf.5.html
https://man7.org/linux/man-pages/man5/org.freedesktop.resolve1.5.html
https://wiki.gnome.org/Projects/NetworkManager/DNS
https://access.redhat.com/articles/4409591#audit-record-types-2
https://gist.github.com/zoilomora/f7d264cefbb589f3f1b1fc2cea2c844c
https://man7.org/linux/man-pages/man8/systemd-networkd.8.html