Pesquisa de site

Um guia do administrador de sistemas para arquivos de configuração de interface de rede


Simplifique o mundo complexo dos arquivos de configuração de interface com este prático tutorial.

No primeiro artigo desta série, Primeiros passos com o NetworkManager no Linux, examinei o que o NetworkManager faz e algumas das ferramentas que ele fornece para visualizar conexões e dispositivos de rede. Discuti o uso do comando nmcli para visualizar o status dos dispositivos de rede e conexões em um host. Também mencionei que o NetworkManager não precisa de arquivos de configuração de interface para a maioria dos hosts. No entanto, ele pode criar seus próprios arquivos de configuração de conexão no estilo INI e reconhece os arquivos de configuração de interface de rede mais antigos e agora obsoletos.

Este artigo explora três questões:

  • Por que não uso arquivos de configuração de interface?
  • Por que uso arquivos de configuração de interface?
  • Por que uso os arquivos antigos de configuração da interface de rede?

Parece confuso? Leia.

Minha filosofia de rede

Falo muito sobre filosofia. Até escrevi um livro, The Linux Philosophy for SysAdmins, que contém princípios que se aplicam ao design e à estrutura de computadores, sistemas operacionais e redes. Não vou aborrecê-lo com todos os detalhes, mas há algumas coisas a considerar ao projetar – ou redesenhar – uma rede.

Como "Lazy SysAdmin", gosto de "Encontrar a Simplicidade" - sim, esses são dois dos princípios - e criar um design de rede elegante. Não se trata apenas do design físico e do layout dos componentes e da fiação da rede, embora as redes melhores, mais elegantes e mais fáceis de trabalhar sejam bem dispostas fisicamente e tenham boa aparência. No entanto, esta discussão é sobre a estrutura lógica da rede.

Por que não uso arquivos de configuração de interface?

Não uso arquivos de configuração de interface em minha rede principalmente porque cada host é configurado dinamicamente no momento da inicialização usando o servidor DHCP (Dynamic Host Configuration Protocol). Isso permite configuração e gerenciamento centralizados de alguns computadores até centenas ou até milhares de sistemas. O resultado final é que todos os dados de configuração necessários para cada host são armazenados no arquivo de configuração DHCP, /etc/dhcp/dhcpd.conf, onde são gerenciados centralmente.

Imponho simplicidade à minha rede usando ferramentas que fornecem gerenciamento central para a maioria dos hosts conectados – todos exceto os hosts que funcionam como roteadores e fornecem serviços de servidor. A idéia é que o uso do DHCP para fornecer todos os dados de configuração de rede necessários à maioria dos hosts da rede simplifique meu trabalho e me permita ser o "Lazy SysAdmin". Suponha que algo mude na rede, como o endereço IP do gateway padrão ou do servidor de nomes primário. Alterar essas informações em um único local, o arquivo dhcpd.conf, é muito menos trabalhoso do que alterar uma configuração estática em dez ou mil hosts.

O NetworkManager não precisa de arquivos de configuração local quando o DHCP fornece as informações de configuração da rede. Por padrão, todos os hosts Fedora e Red Hat obtêm sua configuração de rede de um servidor DHCP. Isso torna a instalação de novos hosts em uma rede fácil e simples. Tudo que você precisa é de um servidor DHCP.

Para a maioria das redes com um único host, como em um escritório doméstico com um ou dois laptops e alguns outros dispositivos, o roteador sem fio fornecido pelo ISP contém o servidor DHCP necessário para oferecer um conjunto completo de dados de configuração a todos os seus dispositivos. O servidor DHCP do roteador fornece os dados de configuração da rede mesmo se você usar o switch com fio de 4 portas na parte traseira da maioria dos roteadores sem fio para conectar um computador desktop com fio.

Por que uso arquivos de configuração de interface?

A maioria dos meus hosts de rede não precisa de configurações de rede estáticas e usa DHCP.

No entanto, existem dois hosts nos quais uso configuração de rede estática: meu servidor de rede – aquele que executa o servidor DHCP – e o host Linux que uso para minha rede/firewall. Esses dois hosts são melhor configurados usando configurações estáticas que não dependem de configurações externas.

Pense sobre isto por um minuto. Se o servidor DHCP precisar ter um endereço IP para enviar informações de configuração de rede, incluindo um endereço IP, para si mesmo... Bem, isso simplesmente não funcionará – uma espécie de equivalente de rede à situação do ovo e da galinha.

Os clientes DHCP solicitam a configuração da rede usando uma transmissão na rede, e o servidor responde a essa solicitação usando o endereço MAC do cliente solicitante. O servidor DHCP também não pode ser um cliente DHCP, então isso simplesmente não funcionará.

Mesmo que o uso do servidor DHCP para definir seu próprio endereço IP - e outros atributos de configuração de rede - pudesse funcionar, todas as recomendações que vejo na Internet sugerem que seria uma idéia realmente terrível e que nenhum bom administrador sequer faria isso. considere fazer uma coisa dessas.

O host Linux que uso para roteador e firewall possui quatro interfaces de rede, três das quais estão ativas no momento e uma na placa-mãe, que está com defeito. Ele também possui um conjunto de regras de encaminhamento e roteamento que devem ser sempre consistentes. Essa configuração é melhor tratada usando configurações de rede estática.

Por exemplo, uma interface do meu roteador se conecta ao lado WAN do meu roteador sem fio. O roteador sem fio fornece um servidor DHCP interno para hosts conectados ao lado LAN e WiFi, mas depende da configuração estática ou DHCP no lado WAN. Portanto, configuro o lado WAN do roteador sem fio e a NIC que o conecta ao meu roteador Linux usando uma configuração estática.

Outra interface nesse roteador Linux se conecta ao mundo externo por meio de um endereço IP estático fornecido pelo meu ISP. Se eu definir essa interface para ser configurada por DHCP, o roteador do ISP servirá a ela um dos outros endereços IP restantes no bloco de oito endereços que me foi atribuído.

Qualquer tipo de configuração de rede estática, ao contrário do DHCP, requer arquivos de configuração de rede.

Por que ainda uso os arquivos ifcfg- de estilo antigo

A resposta para isso é muito simples. Só não consegui fazer a troca. Esses arquivos estão localizados no diretório /etc/sysconfig/network-scripts e, felizmente para mim, o NetworkManager ainda os procurará e usará se não tiver nenhum de seus próprios arquivos de conexão de rede. Não haverá arquivos de conexão de rede porque eles não são criados automaticamente e não precisei criá-los.

Pretendo fazer a mudança na Parte 3 desta série e atualizar minha rede com as práticas de configuração atuais. Por enquanto, porém, ainda é uma boa ideia conhecer os arquivos de configuração de rede antigos, porque ainda existem muitos deles por aí.

O que eu tenho agora

Analisarei o estado atual da rede no meu roteador. Além do loop local (lo) – que está sempre presente em hosts Unix e Linux – este host possui atualmente três placas de interface de rede (NICs) ativas. Devido aos problemas com a NIC on-board descritos na Parte 1 desta série, desativei-a no UEFI/BIOS deste host para que ela não apareça mais. Também desativei o IPv6 na minha rede porque não preciso dele.

A seguir está o comando nmcli que mostra o estado das NICs no meu host roteador/firewall:

[root@wally ~]# nmcli
np4s0: connected to enp4s0
        "Realtek RTL8111/8168/8411"
        ethernet (r8169), 84:16:F9:04:44:03, hw, mtu 1500
        ip4 default
        inet4 45.20.209.41/29
        route4 45.20.209.40/29 metric 102
        route4 default via 45.20.209.46 metric 102
 
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 metric 101
 
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 metric 100
 
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: enp2s0
 
        servers: 192.168.0.52 8.8.8.8
        interface: enp1s0

Cada uma dessas NICs possui um arquivo de configuração de interface no diretório /etc/sysconfig/network-scripts/. Isso ocorre porque eles foram instalados originalmente no momento em que o NetworkManager — ou o serviço de rede anterior — criava esses arquivos automaticamente durante a instalação. Como o NetworkManager continua a reconhecer esses arquivos, não há necessidade urgente de fazer nada diferente.

Nomenclatura do arquivo de configuração da interface

Felizmente, a maioria de vocês perdeu um pouco da diversão que todos nós, administradores de sistemas antigos, costumávamos ter ao adicionar, remover ou apenas mover o hardware NIC em hosts com vários NICs. Parecia que todas as NICs seriam renomeadas sempre que alguma coisa mudasse. Isso significava que eu precisaria determinar qual nome foi dado a cada NIC e modificar os arquivos de configuração da interface para corresponder aos nomes corretos.

Existem agora convenções de nomenclatura de NIC muito consistentes com base na posição lógica da NIC nos barramentos de dados PCIe ou USB. Esta convenção foi criada por volta de 2009 para eliminar esses problemas.

Como funciona - mais ou menos

O gerenciador de dispositivos udev detecta quando um novo dispositivo foi adicionado ao sistema, como uma nova NIC, e cria uma regra para identificá-lo e nomeá-lo, caso ainda não exista. Durante a parte inicial da fase de inicialização, o kernel do Linux usa o udev para identificar dispositivos conectados, incluindo controladores de interface de rede. Nesta fase, os dispositivos ainda são conhecidos pelos nomes tradicionais de ethX. Pouco depois disso, o systemd renomeia os dispositivos de acordo com uma série de esquemas de nomenclatura hierárquicos.

Usei meu sistema de firewall como exemplo de sistema com múltiplas conexões de rede. Você também pode fazer isso em seus próprios hosts Linux.

[root@wally ~]# dmesg | grep eth
[    2.081738] r8169 0000:01:00.0 eth0: RTL8168e/8111e, 84:16:f9:03:e9:89, XID 2c2, IRQ 126
[    2.081830] r8169 0000:01:00.0 eth0: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    2.089218] r8169 0000:02:00.0 eth1: RTL8168e/8111e, 84:16:f9:03:fd:85, XID 2c2, IRQ 127
[    2.089303] r8169 0000:02:00.0 eth1: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    2.094383] r8169 0000:04:00.0 eth2: RTL8168e/8111e, 84:16:f9:04:44:03, XID 2c2, IRQ 128
[    2.094467] r8169 0000:04:00.0 eth2: jumbo features [frames: 9194 bytes, tx checksumming: ko]
[    2.142068] r8169 0000:01:00.0 enp1s0: renamed from eth0
[    2.152128] r8169 0000:04:00.0 enp4s0: renamed from eth2
[    2.161346] r8169 0000:02:00.0 enp2s0: renamed from eth1

[root@wally ~]#

Este exemplo mostra que pouco mais de dois segundos após a sequência de inicialização do Linux, os dispositivos de rede ethX foram localizados e, menos de um segundo depois, eles foram renomeados para enpXs0.

Todas as versões atuais do RHEL, CentOS e Fedora usam as mais recentes convenções de nomenclatura NIC. A maioria das outras distros também usa esta convenção de nomenclatura.

A convenção de nomenclatura NIC para essas distribuições é descrita detalhadamente no documento RHEL 7, "Networking Guide", com uma explicação de como os nomes são derivados. O uso das ferramentas NetworkManager para gerenciar redes é abordado no documento RHEL 8, "Configurando e gerenciando redes".

A seguir está um trecho do Capítulo 11 do RHEL 7 "Networking Guide":

  • Esquema 1: Nomes que incorporam números de índice fornecidos pelo Firmware ou BIOS para dispositivos integrados (exemplo: eno1), são aplicados se essas informações do firmware ou BIOS forem aplicáveis e disponíveis, caso contrário, voltando ao esquema 2.
  • Esquema 2: Nomes que incorporam firmware ou BIOS fornecidos com números de índice de slot hotplug PCI Express (exemplo: ens1) serão aplicados se essas informações do firmware ou BIOS forem aplicáveis e disponíveis, caso contrário, retornarão ao esquema 3.
  • Esquema 3: Nomes que incorporam a localização física do conector do hardware (exemplo: enp2s0) são aplicados se aplicável, caso contrário, retornam diretamente ao esquema 5 em todos os outros casos.
  • Esquema 4: Nomes que incorporam o endereço MAC da interface (exemplo: enx78e7d1ea46da), não são usados por padrão, mas estão disponíveis se o usuário assim desejar.
  • Esquema 5: O tradicional esquema de nomenclatura imprevisível do kernel é usado se todos os outros métodos falharem (exemplo: eth0).

A principal função dos esquemas de nomenclatura revisados é fornecer um conjunto consistente de nomes de NIC, de modo que a instalação de uma nova NIC ou mesmo apenas uma reinicialização não faça com que os nomes das NIC sejam alterados. Isso por si só vale a pena as mudanças. Tive muitas oportunidades de lutar contra a renomeação aparentemente aleatória de vários dispositivos ethX em um único host. Isso foi muito menos divertido do que aprender os esquemas de nomenclatura revisados.

Noções básicas sobre arquivos de configuração de interface

Esses arquivos de configuração de interface são fáceis de criar e modificar. Os seguintes arquivos de configuração em meu host de firewall/roteador estão todos localizados no diretório /etc/sysconfig/network-scripts. Este diretório continha anteriormente todos os scripts usados para gerenciar as conexões de rede, mas o NetworkManager os tornou obsoletos. Somente os arquivos de configuração de interface obsoletos podem permanecer neste diretório.

-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 924 Mar 31 14:24 ifcfg-enp4s0

Este é o arquivo de configuração da interface que conecta o host do firewall à minha rede doméstica, como você pode ver no comentário:

[root@wally network-scripts]# cat ifcfg-enp2s0
# Interface configuration file for enp2s0 / 192.168.0.254
# This interface is for the internal network
# Correct as of 20220711
HWADDR=84:16:f9:03:fd:85
NAME="enp2s0"
TYPE=Ethernet
ONBOOT=yes
BOOTPROTO=static
IPADDR=192.168.0.254
PREFIX=24
DNS1=192.168.0.52
DNS2=8.8.8.8
DEFROUTE=no
PEERDNS=yes
PEERROUTES=no
IPV4_FAILURE_FATAL=no

Este arquivo é para uma configuração estática bastante simples que fornece o endereço IP, o prefixo CIDR e dois endereços IP do servidor DNS. Nenhum endereço IP de rota padrão (gateway) é especificado, pois está configurado em um dos outros arquivos de configuração de interface.

O bloco de código abaixo mostra o arquivo de configuração da interface para a conexão do meu roteador Linux ao roteador do ISP. Ele usa um dos endereços IP estáticos fornecidos pelo meu ISP.

##############################################################################
# Interface configuration file for enp4s0 / 45.20.209.41
# This NIC was installed to circumvent problems with motherboard NIC, eno1.
------------------------------------------------------------------------------
# This interface is for the WAN - the AT&T fiber optic external network
# Correct as of 20220711
##############################################################################
TYPE= "Ethernet"
BOOTPROTO="static"
NM_CONTROLLED= "yes"
DEFROUTE= "yes"
NAME=enp4s0
UUID="fa2117dd-6c7a-44e0-9c9d-9c662716a352"
ONBOOT= "yes"
HWADDR=84:16:f9:04:44:03
IPADDR=45.20.209.41
PREFIX=29
GATEWAY=45.20.209.46
DNS1=192.168.0.52
DNS2=8.8.8.8
DNS3=8.8.4.4
PEERDNS=no
IPv6INIT=no
IPv6_AUTOCONF=no
IPv6_DEFROUTE=no
	 

Como não uso IPv6 e o desativei, poderia excluir a instrução IPv6 em ambos os arquivos.

Variáveis de configuração de rede

A tabela abaixo lista as variáveis de configuração de rede mais comuns, juntamente com algumas breves explicações para cada uma. Muitas opções de IPv6 são funcionalmente equivalentes às de IPv4 com nomes semelhantes. As definições das variáveis de configuração local substituem aquelas fornecidas por um servidor DHCP. Você pode usar o DHCP para configurar um host, mas usar um arquivo de configuração de interface para substituir uma ou mais variáveis de configuração do DHCP.

TYPE

Tipo de rede, como Ethernet ou token ring.

PROXY_METHOD

Método de configuração de proxy. "nenhum" significa que nenhum proxy está em uso.

BROWSER_ONLY

Se uma configuração de proxy é apenas para navegadores.

BOOTPROTO

As opções são dhcp, bootp, none e static. A opção "nenhum" implica DHCP.

DEFROUTE

Esta interface é a rota padrão deste host para o mundo exterior.

IPv4_FAILURE_FATAL

Se estiver definido como "não", a falha na obtenção de uma conexão IPv4 não afetará nenhuma tentativa de estabelecer uma conexão IPv6.

NAME

O nome da interface, como enp0s3. Isso deve corresponder ao nome da interface no nome do arquivo de configuração da interface.

UUID

Um identificador universalmente exclusivo para a interface. Ele é criado com um hash do nome da interface. O HWADDR é um meio mais antigo de vincular o arquivo à interface de hardware, e descobri que o UUID pode ser comentado ou excluído sem problemas.

DEVICE

O nome da interface à qual este arquivo de configuração está vinculado.

ONBOOT

Se sim, isso inicia a interface na inicialização (na verdade, na hora da inicialização). Se definido como não, a interface não será iniciada até que um usuário efetue login na GUI ou inicie manualmente a interface.

HWADDR

O endereço MAC da interface. Este é um dos campos mais importantes do arquivo, pois é usado para vincular o arquivo à interface de hardware correta. O UUID é uma adição mais recente e também pode ser usado, mas o HWADDR foi o primeiro e é mais amplamente utilizado.

DNS1, DNS2

Até dois servidores de nomes podem ser especificados.

USERCTL

Especifica se usuários não privilegiados podem iniciar e parar esta interface. As opções são sim/não.

IPADDR

O endereço IP atribuído a esta NIC.

BROADCAST

O endereço de transmissão para esta rede, como 10.0.2.255.

NETMASK

A máscara de rede para esta sub-rede, como 255.255.255.0. Use NETMASK ou PREFIX, mas não ambos.

PREFIX

O prefixo CIDR para a rede, como 24. Use NETMASK ou PREFIX, mas não ambos.

NETWORK

O ID de rede desta sub-rede, como 10.0.2.0.

SEARCH

O nome de domínio DNS a ser pesquisado ao fazer pesquisas em nomes de host não qualificados, como usar studentvm1 em vez de studentvm1.example.com.

GATEWAY

O roteador de rede ou gateway padrão para esta sub-rede, como 10.0.2.1.

PEERDNS

O valor yes indica que /etc/resolv.conf deve ser modificado inserindo as entradas do servidor DNS especificadas pelas opções DNS1 e DNS2 neste arquivo. Não significa não alterar o arquivo resolv.conf. Sim é o padrão quando DHCP é especificado na linha BOOTPROTO.

IPv6INIT

Seja para inicializar o IPv6 ou não. O padrão é sim.

IPv6_AUTOCONF

Sim significa usar DHCP para configuração de IPv6 nesta interface.

IPv6_DEFROUTE

Esta interface é a rota padrão IPv6 deste host para o mundo externo.

IPv6_FAILURE_FATAL

Se estiver definido como "não", a falha na obtenção de uma conexão IPv6 não afetará nenhuma tentativa de estabelecer uma conexão IPv4.

IPv6_ADDR_GEN_MODE

Configure o endereçamento de privacidade estável IPv6.

Existem muito mais variáveis de configuração do que as listadas aqui, mas estas são as usadas com mais frequência.

Pensamentos finais

Ainda existem muitos hosts Linux que usam os arquivos de configuração de interface descritos neste artigo. Apesar de estar obsoleto, o NetworkManager ainda reconhece esses arquivos e pode usá-los para configurar interfaces de rede. No entanto, a maioria dos sistemas Linux modernos usa o NetworkManager, portanto, nenhum arquivo de configuração é necessário, a menos que sirva a um caso de uso especial, como um servidor ou roteador.

Tenho alguns hosts que exigem mais do que apenas a configuração padrão do NetworkManager. Para mim, simplesmente não foi uma prioridade mudar dos arquivos de configuração de interface antigos para os arquivos de configuração de conexão atuais usados pelo NetworkManager. Para evitar problemas futuros com minha rede, preciso mudar para os arquivos de conexão de rede do NetworkManager. O próximo artigo desta série descreverá como faço essa mudança.

Artigos relacionados: