Comece a usar o NetworkManager no Linux
Aprenda o que é NetworkManager e como usá-lo para visualizar conexões de rede e dispositivos para hosts Linux.
A maioria das distribuições Linux atuais usa o NetworkManager para criar e gerenciar conexões de rede. Isso significa que preciso entendê-lo como administrador de sistema. Em uma série de artigos, compartilharei o que aprendi até agora e por que acho que o NetworkManager é uma melhoria em relação às opções anteriores.
A Red Hat introduziu o NetworkManager em 2004 para simplificar e automatizar a configuração e as conexões de rede, especialmente as conexões sem fio. A intenção era aliviar os usuários da tarefa de configurar manualmente cada nova rede sem fio antes de usá-la. O NetworkManager pode gerenciar conexões de rede com fio sem arquivos de configuração de interface, embora use arquivos de conexão de rede para conexões sem fio.
Neste artigo, revisarei o que é NetworkManager e como usá-lo para visualizar conexões de rede e dispositivos para hosts Linux. Vou até resolver alguns problemas no processo.
O que o NetworkManager substitui
NetworkManager é um substituto para ferramentas de gerenciamento de rede anteriores. O comando de configuração de interface original, ifconfig, e seus arquivos de configuração de interface estão obsoletos. Você pode ver isso nas páginas de manual ifconfig, que contêm uma nota informando exatamente isso.
O comando ip substitui o comando ifconfig e executa essencialmente as mesmas tarefas. Ambos os comandos coexistem há algum tempo, permitindo que os administradores de sistemas usem qualquer um deles, o que mantém os scripts dependentes do ifconfig funcional. Embora suas páginas de manual ainda não indiquem isso, o comando ifconfig está obsoleto e o NetworkManager o tornou na prática.
Agora é hora de reescrever esses scripts, porque usar comandos do NetworkManager faz mais sentido.
Como funciona o NetworkManager
NetworkManager é executado como um serviço systemd e está habilitado por padrão. NetworkManager funciona com D-Bus para detectar e configurar interfaces de rede conforme elas são conectadas ao computador Linux. Esse gerenciamento plug-and-play de interfaces de rede torna a conexão a novas redes – com e sem fio – trivialmente fácil para o usuário. Quando interfaces de rede instaladas anteriormente são detectadas durante a inicialização do Linux, elas são tratadas exatamente como um dispositivo conectado depois que o sistema já está instalado e funcionando. Tratar todos os dispositivos como plug-and-play em todas as instâncias facilita o manuseio desses dispositivos para o sistema operacional, já que há apenas uma base de código para lidar com ambos os conjuntos de circunstâncias.
O daemon udev cria uma entrada para cada placa de interface de rede (NIC) instalada no sistema no arquivo de regras de rede. O D-Bus sinaliza a presença de um novo dispositivo de rede – com ou sem fio – para o NetworkManager. O NetworkManager então escuta o tráfego no D-Bus e responde criando uma configuração para este novo dispositivo. Tal configuração é, por padrão, armazenada apenas na RAM e não é permanente. Deve ser criado sempre que o computador for inicializado.
O NetworkManager usa as informações do D-Bus para inicializar cada NIC. Primeiro ele procura arquivos de configuração que forneçam uma configuração estática mais permanente. Quando notificado sobre um novo dispositivo, o NetworkManager verifica a existência de arquivos de configuração de interface de rede antigos (ifcfg-*) em /etc/sysconfig/network-scripts. O plugin ifcfg-rh permite o uso desses arquivos legados para compatibilidade com versões anteriores.
Em seguida, o NetworkManager procura seus próprios arquivos de conexão de interface, localizados no diretório /etc/NetworkManager/system-connections. A maioria das distribuições, incluindo o Fedora, mantém seus arquivos de conexão de rede no diretório /etc/NetworkManager/system-connections, usando o nome da rede como nome do arquivo.
Por exemplo, meu laptop System76 Oryx Pro usava originalmente POP!_OS. Eu substituí isso pelo Fedora, que está atualmente na versão 35, e cada conexão sem fio que fiz com ele tem um arquivo em /etc/NetworkManager/system-connections. Eles mantêm um registro do identificador do conjunto de serviços (SSID) e das senhas sem fio de cada rede. O servidor Dynamic Host Configuration Protocol (DHCP) no roteador sem fio fornece o restante dos dados de configuração de rede para essas conexões sem fio. Por motivos de segurança, como esses arquivos contêm senhas, eles são lidos/gravados apenas pelo usuário root, assim como os arquivos de conta do sistema /etc/passwd e /etc/shadow.
O diretório /etc/NetworkManager/system-connections naquele laptop continha arquivos para a rede com fio, bem como para cada uma das redes sem fio às quais me conectei. A estrutura desses arquivos é diferente dos antigos arquivos ifcfg, mas eles estão em formato de texto simples ASCII e são legíveis e facilmente compreensíveis.
Este processo é sensível à sequência. O primeiro conjunto de arquivos de configuração encontrado é usado. Se nenhum arquivo de configuração for encontrado, o NetworkManager gera uma configuração usando os dados de um servidor DHCP. Se um arquivo de configuração de interface não existir, conectar um novo dispositivo ou conectar-se a uma nova rede sem fio faz com que o udev notifique o NetworkManager sobre o novo dispositivo ou conexão sem fio. No Fedora até a versão 28, o NetworkManager cria o novo arquivo de configuração da interface. A partir do Fedora 29 e superior, o NetworkManager cria apenas a conexão e não cria um arquivo de configuração de interface.
Se nenhum arquivo de configuração ou servidor DHCP for encontrado, nenhuma conexão de rede será possível.
Visualizando a configuração da interface
O programa de interface de linha de comando do NetworkManager, nmcli, oferece diversas opções para determinar o estado atual de qualquer hardware de interface de rede instalado no host, bem como das conexões atualmente ativas. O programa nmcli pode gerenciar redes em qualquer host, quer ele use uma interface gráfica de usuário (GUI) ou não, portanto, também pode gerenciar hosts remotos por meio de uma conexão de shell seguro (SSH). Funciona em conexões com e sem fio.
Começarei com algumas informações básicas para usar a ferramenta nmcli. Estou usando um sistema Fedora que configurei como roteador, pois um exemplo com múltiplas interfaces de rede será mais interessante do que um simples host de estação de trabalho com apenas uma interface.
Começarei com o comando mais fácil, nmcli sem opções. Este comando simples mostra informações semelhantes ao agora obsoleto comando ifconfig, incluindo o nome e modelo da NIC, o endereço de controle de acesso à mídia (MAC) e o endereço IP (protocolo de internet), e qual NIC está configurada como gateway padrão. Também mostra a configuração DNS para cada interface.
O comando nmcli requer privilégios de administrador. A maioria das distribuições recomenda que você use sudo mas eu apenas mudo para o usuário root.
$ su -
# nmcli
enp4s0: connected to enp4s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:04:44:03, hw, mtu 1500
ip4 default, ip6 default
inet4 45.20.209.41/29
route4 0.0.0.0/0
route4 45.20.209.40/29
inet6 2600:1700:7c0:860:8616:f9ff:fe04:4403/64
inet6 fe80::8616:f9ff:fe04:4403/64
route6 2600:1700:7c0:860::/64
route6 ::/0
enp1s0: connected to enp1s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:03:E9:89, hw, mtu 1500
inet4 192.168.10.1/24
route4 192.168.10.0/24
inet6 fe80::8616:f9ff:fe03:e989/64
route6 fe80::/64
enp2s0: connected to enp2s0
"Realtek RTL8111/8168/8411"
ethernet (r8169), 84:16:F9:03:FD:85, hw, mtu 1500
inet4 192.168.0.254/24
route4 192.168.0.0/24
inet6 fe80::8616:f9ff:fe03:fd85/64
route6 fe80::/64
eno1: unavailable
"Intel I219-V"
ethernet (e1000e), 04:D9:F5:1C:D5:C5, hw, mtu 1500
lo: unmanaged
"lo"
loopback (unknown), 00:00:00:00:00:00, sw, mtu 65536
DNS configuration:
servers: 192.168.0.52 8.8.8.8 8.8.4.4
interface: enp4s0
servers: 192.168.0.52 8.8.8.8
interface: enp1s0
servers: 192.168.0.52 8.8.8.8
interface: enp2s0Use o comando nmcli device show para obter informações completas sobre dispositivos conhecidos e nmcli connection show para obter uma visão geral dos perfis de conexão ativos. Consulte as páginas de manual nmcli(1) e nmcli-examples(7) para obter detalhes completos de uso. Você também pode emitir o comando de ajuda, nmcli -h, como usuário root para visualizar os comandos básicos de nível superior nmcli:
# nmcli -h
Usage: nmcli [OPTIONS] OBJECT { COMMAND | help }
OPTIONS
-a, --ask ask for missing parameters
-c, --colors auto|yes|no whether to use colors in output
-e, --escape yes|no escape columns separators in values
-f, --fields <field,...>|all|common specify fields to output
-g, --get-values <field,...>|all|common shortcut for -m tabular -t -f
-h, --help print this help
-m, --mode tabular|multiline output mode
-o, --overview overview mode
-p, --pretty pretty output
-s, --show-secrets allow displaying passwords
-t, --terse terse output
-v, --version show program version
-w, --wait <seconds> set timeout waiting for finishing operations
OBJECT
g[eneral] NetworkManager's general status and operations
n[etworking] overall networking control
r[adio] NetworkManager radio switches
c[onnection] NetworkManager's connections
d[evice] devices managed by NetworkManager
a[gent] NetworkManager secret agent or polkit agent
m[onitor] monitor NetworkManager changesObserve que os objetos podem ser escritos por extenso ou abreviados até o primeiro caractere. Esses objetos são todos únicos, portanto, apenas o primeiro caractere é necessário para especificar qualquer objeto único.
Experimente nmcli g para ver o status geral.
# nmcli g
STATE CONNECTIVITY WIFI-HW WIFI WWAN-HW WWAN
connected full enabled enabled enabled enabled Essa saída não mostra muito. Também sei que o host, neste caso, não possui hardware WiFi, portanto este é um resultado enganoso. Você não deve usar o comando nmcli g por esse motivo. Os melhores comandos de objeto são c[onnection] e d[evice], que são os que uso com mais frequência.
# nmcli c
NAME UUID TYPE DEVICE
enp4s0 b325fd44-30b3-c744-3fc9-e154b78e8c82 ethernet enp4s0
enp1s0 c0ab6b8c-0eac-a1b4-1c47-efe4b2d1191f ethernet enp1s0
enp2s0 8c6fd7b1-ab62-a383-5b96-46e083e04bb1 ethernet enp2s0
enp0s20f0u7 0f5427bb-f8b1-5d51-8f74-ac246b0b00c5 ethernet --
enp1s0 abf4c85b-57cc-4484-4fa9-b4a71689c359 ethernet --
# nmcli d
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet connected enp4s0
enp1s0 ethernet connected enp1s0
enp2s0 ethernet connected enp2s0
eno1 ethernet unavailable --
lo loopback unmanaged -- Há muitas informações realmente interessantes aqui. Observe que as duas últimas entradas usando o comando c object não possuem entradas na coluna do dispositivo. Este resultado pode significar que eles não estão ativos ou não existem ou que há um ou mais erros de configuração.
As informações adicionais que obtemos usando o comando d object nem sequer mostram o dispositivo enp0s20f0u7. Também mostra o dispositivo eno1 (um dispositivo da placa-mãe), que não foi exibido usando o comando c object.
Sua saída deve ser mais parecida com esta, embora o nome do dispositivo seja diferente e dependa do local específico no barramento PCI ao qual a NIC está conectada.
# nmcli c
NAME UUID TYPE DEVICE
Wired connection 1 6e6f63b9-6d9e-3d13-a3cd-d54b4ca2c3d2 ethernet enp0s3
# nmcli d
DEVICE TYPE STATE CONNECTION
enp0s3 ethernet connected Wired connection 1
lo loopback unmanaged -- Parece que tenho algumas anomalias para explorar. Primeiro, quero saber qual dispositivo enp0s20f0u7 está na lista de conexões. Como o NetworkManager não reconhece este dispositivo na lista de dispositivos, provavelmente existe um arquivo de configuração de rede em /etc/sysconfig/network-scripts mesmo que tal dispositivo de hardware não exista no host. Verifiquei esse diretório, encontrei o arquivo de configuração da interface e exibi o conteúdo.
# ls -l
total 20
-rw-r--r-- 1 root root 352 Jan 2 2021 ifcfg-eno1
-rw-r--r-- 1 root root 419 Jan 5 2021 ifcfg-enp0s20f0u7
-rw-r--r-- 1 root root 381 Jan 11 2021 ifcfg-enp1s0
-rw-r--r-- 1 root root 507 Jul 27 2020 ifcfg-enp2s0
-rw-r--r-- 1 root root 453 Jul 27 2020 ifcfg-enp4s0
cat ifcfg-enp0s20f0u7
# Interface configuration file for ifcfg-enp0s20f0u7
# This is a USB Gb Ethernet dongle
# This interface is for the wireless routers
# Correct as of 20210105
TYPE="Ethernet"
BOOTPROTO="static"
NM_CONTROLLED="yes"
DEFROUTE="no"
NAME=enp0s20f0u7
UUID="fa2117dd-6c7a-44e0-9c9d-9c662716a352"
ONBOOT="yes"
HWADDR=8c:ae:4c:ff:8b:3a
IPADDR=192.168.10.1
PREFIX=24
DNS1=192.168.0.52
DNS2=8.8.8.8Depois de examinar este arquivo, lembrei-me de que usei um dongle USB Gigabit por um tempo porque a NIC da placa-mãe instalada naquele host aparentemente falhou. Essa foi uma solução rápida e mais tarde instalei uma nova NIC no barramento da placa-mãe PCIe, para poder remover esse arquivo de configuração da interface. Contudo, não o apaguei; Mudei-o para o diretório /root caso precise dele novamente.
Observe os comentários que usei para garantir que meu futuro eu ou outro administrador do sistema entenderia por que esse arquivo existe.
A segunda anomalia é porque a entrada para enp1s0 aparece duas vezes. Isso só pode ocorrer quando o nome da NIC é especificado em mais de um arquivo de configuração de interface. Então, tentei as etapas a seguir e, com certeza, enp1s0 aparece erroneamente no arquivo de configuração ifcfg-eno1 , bem como no arquivo ifcfg-enp1s0 .
# grep enp1s0 *
ifcfg-eno1:NAME=enp1s0
ifcfg-enp1s0:# Interface configuration file for enp1s0 / 192.168.10.1
ifcfg-enp1s0:NAME=enp1s0
# cat ifcfg-eno1
## Interface configuration file for eno1 / 192.168.10.1
## This interface is for the wireless routers
## Correct as of 20200727
TYPE="Ethernet"
BOOTPROTO="static"
NM_CONTROLLED="yes"
DEFROUTE="no"
NAME=enp1s0
ONBOOT="yes"
HWADDR=04:d9:f5:1c:d5:c5
IPADDR=192.168.10.1
PREFIX=24
DNS1=192.168.0.52
DNS2=8.8.8.8Mudei o NAME para NAME=eno1 e reiniciei o NetworkManager. As alterações nos arquivos de configuração da interface não são ativadas até que eu reinicie o NetworkManager. Os resultados do dispositivo e da conexão agora são assim. Ainda não estou usando a NIC integrada, o que provavelmente está bom agora que removi o nome errado do arquivo de configuração da interface ifcfg-eno1. Isso exigirá tempo de inatividade para esse roteador.
# systemctl restart NetworkManager
# nmcli d
DEVICE TYPE STATE CONNECTION
enp4s0 ethernet connected enp4s0
enp1s0 ethernet connected enp1s0
enp2s0 ethernet connected enp2s0
eno1 ethernet unavailable --
lo loopback unmanaged --
# nmcli c
NAME UUID TYPE DEVICE
enp4s0 b325fd44-30b3-c744-3fc9-e154b78e8c82 ethernet enp4s0
enp1s0 c0ab6b8c-0eac-a1b4-1c47-efe4b2d1191f ethernet enp1s0
enp2s0 8c6fd7b1-ab62-a383-5b96-46e083e04bb1 ethernet enp2s0
eno1 abf4c85b-57cc-4484-4fa9-b4a71689c359 ethernet -- Outra opção é mostrar apenas as conexões ativas. Esta é uma boa opção com resultados limpos, mas também pode mascarar outros problemas se usada exclusivamente.
# nmcli connection show --active
NAME UUID TYPE DEVICE
enp4s0 b325fd44-30b3-c744-3fc9-e154b78e8c82 ethernet enp4s0
enp1s0 c0ab6b8c-0eac-a1b4-1c47-efe4b2d1191f ethernet enp1s0
enp2s0 8c6fd7b1-ab62-a383-5b96-46e083e04bb1 ethernet enp2s0 Tendo alterado o nome do dispositivo no arquivo ifcfg-eno1 para o nome correto, suspeito que a NIC da placa-mãe, eno1, funcionará novamente. Vou experimentar isso na próxima vez que tiver uma sessão de manutenção nesse host.
Isso não é mais interessante do que um host com uma única NIC? E encontrei alguns problemas no processo.
O uso de ferramentas NetworkManager para gerenciar redes é abordado no documento Red Hat Enterprise Linux (RHEL) 8 "Configurando e Gerenciando Redes".
Pensamentos finais
Sou fã da filosofia “se não está quebrado, não conserte”. No entanto, mesmo o uso mais simples do NetworkManager na linha de comando, visualizando o estado atual dos dispositivos e conexões de rede, me mostrou duas anomalias em minhas configurações anteriores que eu havia perdido. Agora sou um fã do NetworkManager. As ferramentas mais antigas eram boas, mas o NetworkManager é melhor; as informações adicionais que ele fornece são inestimáveis.
Na parte 2 desta série, discutirei o gerenciamento de interfaces de rede.