Estou tentando fazer um servidor rodar com 2 placas de rede. Uma placa de rede terá um ip dinâmico (DHCP) e a outra terá um ip estático 192.168.0.24. Tenho 2 placas de rede neste servidor, 1 GB (enp4s0) e 10 GB (enp5s0)
Minha instalação atual do novo sistema operacional:
oven@oven-f1:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04
Codename: jammy
Este netplan é o padrão que vem com uma nova instalação do sistema operacional usando configurações de rede padrão:
oven@oven-f1:~$ sudo cat /etc/netplan/50-cloud-init.yaml
# This file is generated from information provided by the datasource. Changes
# to it will not persist across an instance reboot. To disable cloud-init's
# network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
enp4s0:
dhcp4: true
version: 2
wifis: {}
status das placas de rede com este netplan:
oven@oven-f1:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether d8:43:ae:90:b8:2e brd ff:ff:ff:ff:ff:ff
3: enp5s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 74:fe:ce:ea:db:b5 brd ff:ff:ff:ff:ff:ff
rotas padrão com esta configuração netplan:
oven@oven-f1:~$ ip route
default via 192.168.0.1 dev enp4s0 proto dhcp src 192.168.0.27 metric 100
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.27 metric 100
192.168.0.1 dev enp4s0 proto dhcp scope link src 192.168.0.27 metric 100
Abaixo está a nova configuração do netplan que estou tentando implementar:
network:
version: 2
renderer: networkd
ethernets:
enp4s0:
dhcp4: true
enp5s0:
dhcp4: true
addresses:
- 192.168.0.24/24
routes:
- to: 0.0.0.0/0
via: 192.168.0.1
nameservers:
addresses: [8.8.8.8, 8.8.4.4]
O problema é que quando executo um sudo netplan --debug applycom a nova configuração:
oven@oven-f1:~$ sudo netplan --debug apply
** (generate:1778): DEBUG: 07:51:08.869: starting new processing pass
** (generate:1778): DEBUG: 07:51:08.869: enp5s0: adding new route
** (generate:1778): DEBUG: 07:51:08.869: starting new processing pass
** (generate:1778): DEBUG: 07:51:08.869: We have some netdefs, pass them through a final round of validation
** (generate:1778): DEBUG: 07:51:08.869: enp4s0: setting default backend to 1
** (generate:1778): DEBUG: 07:51:08.869: Configuration is valid
** (generate:1778): DEBUG: 07:51:08.869: enp5s0: setting default backend to 1
** (generate:1778): DEBUG: 07:51:08.869: Configuration is valid
** (generate:1778): DEBUG: 07:51:08.869: Generating output files..
** (generate:1778): DEBUG: 07:51:08.869: Open vSwitch: definition enp4s0 is not for us (backend 1)
** (generate:1778): DEBUG: 07:51:08.869: NetworkManager: definition enp4s0 is not for us (backend 1)
** (generate:1778): DEBUG: 07:51:08.869: Open vSwitch: definition enp5s0 is not for us (backend 1)
** (generate:1778): DEBUG: 07:51:08.869: NetworkManager: definition enp5s0 is not for us (backend 1)
** (process:1776): DEBUG: 07:51:09.042: starting new processing pass
** (process:1776): DEBUG: 07:51:09.042: enp5s0: adding new route
** (process:1776): DEBUG: 07:51:09.042: starting new processing pass
** (process:1776): DEBUG: 07:51:09.042: We have some netdefs, pass them through a final round of validation
** (process:1776): DEBUG: 07:51:09.042: enp4s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.042: Configuration is valid
** (process:1776): DEBUG: 07:51:09.042: enp5s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.042: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: enp5s0: adding new route
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: We have some netdefs, pass them through a final round of validation
** (process:1776): DEBUG: 07:51:09.128: enp4s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: enp5s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: enp5s0: adding new route
** (process:1776): DEBUG: 07:51:09.128: starting new processing pass
** (process:1776): DEBUG: 07:51:09.128: We have some netdefs, pass them through a final round of validation
** (process:1776): DEBUG: 07:51:09.128: enp4s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid
** (process:1776): DEBUG: 07:51:09.128: enp5s0: setting default backend to 1
** (process:1776): DEBUG: 07:51:09.128: Configuration is valid
status das placas de rede com este novo netplan:
oven@oven-f1:~$ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp4s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether d8:43:ae:90:b8:2e brd ff:ff:ff:ff:ff:ff
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
link/ether 74:fe:ce:ea:db:b5 brd ff:ff:ff:ff:ff:ff
rotas padrão com esta nova configuração netplan:
oven@oven-f1:~$ ip route
default via 192.168.0.1 dev enp5s0 proto static
default via 192.168.0.1 dev enp4s0 proto dhcp src 192.168.0.27 metric 100
192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.24
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.27 metric 100
192.168.0.1 dev enp4s0 proto dhcp scope link src 192.168.0.27 metric 100
Não há erros com minha configuração , mas perco acesso ssh ao servidor . Ainda consigo acessar a internet do servidor e ssh para outras máquinas , mas não consigo ssh no servidor do meu laptop.
Não consigo fazer ping no servidor, mas ainda consigo ver seu endereço:
s@M1 ~ % nslookup oven-f1
Server: 2001:8003:d44e:7600::1
Address: 2001:8003:d44e:7600::1#53
Name: oven-f1.modem
Address: 192.168.0.27
s@M1 ~ % ping oven-f1
PING oven-f1.modem (192.168.0.27): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- oven-f1.modem ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss
Não tenho certeza do porquê não consigo fazer ssh no servidor depois de habilitar 2 placas de rede, qualquer ajuda seria muito apreciada, pois estou bastante travado
Editar resposta atualização
abaixo está a configuração do netplan funcionando. Eu simplesmente dividi os cartões de 10 GB e o switch de 10 GB em sub-redes diferentes 192.168.1.0/24e mantive os cartões de 1 GB e o switch ligados 192.168.0.0/24.
network:
version: 2
renderer: networkd
ethernets:
enp4s0:
dhcp4: true
enp5s0:
dhcp4: false
addresses:
- 192.168.1.24/24
também atualizou o arquivo hosts nos servidores para mapear hosts na 192.168.1.0/24sub-rede
O primeiro problema aqui é que você tem duas sub-redes independentes que usam a mesma numeração de endereço.
Não faça isso. Se o switch 10Gbit 1 não tiver conexão com o switch LAN principal de 1Gbit, eles devem usar números de rede diferentes – por exemplo, 192.168.1.0/24 para um e 192.168.10.0/24 para o outro – independentemente de ser a causa raiz do seu problema ou não.
Isso ocorre porque os sistemas operacionais roteiam principalmente suas sub-redes locais como uma única unidade e também porque eles roteiam respostas independentemente das solicitações (com algumas exceções). Então, quando você tenta contatar 192.168.0.26, mas tem duas placas de rede conectadas a duas sub-redes 192.168.0.0/24 diferentes, o SO não tentará determinar qual rede tem esse endereço (com o Windows possivelmente sendo uma exceção) – em vez disso, toda a rota /24 através da placa A é definida para ter prioridade mais alta do que a rota idêntica através da placa B.
Por exemplo, quando seu servidor Linux tem essas rotas:
e ele precisa responder à solicitação de conexão SSH do seu PC, ele enviará essa resposta através
dev enp5s0(da sua placa de 10 Gbit) porque essa rota tem o mesmo comprimento de prefixo (/24) e métrica menor (menor custo); e como a placa de 10 Gbit não tem conexão com a sub-rede de 1 Gbit, esse pacote nunca chegará ao PC.Conectar o switch de 10 Gbit ao switch de 1 Gbit seria a maneira mais fácil de fazê-lo funcionar, unindo os dois em uma única rede (sem nenhuma perda de desempenho) – embora isso tornasse a placa de 1 Gbit desnecessária para começar.
Mas como você não tem mais portas livres no switch de 10 Gbit e precisa manter as sub-redes separadas por necessidade, então você deve renumerar uma delas – e isso por si só deve fazer tudo funcionar, pelo menos por enquanto (contanto que você tenha apenas duas sub-redes em geral).
Como observação lateral (depois de organizar a numeração de sub-rede), é tecnicamente suficiente ter a segunda placa em apenas um servidor, que pode então atuar como um roteador entre as sub-redes de "1 Gbit" e "10 Gbit" — embora, se você tiver portas e placas suficientes, instalar a segunda placa em cada servidor certamente tornará a configuração mais simples.
Outro problema é que você tem uma rota padrão em enp5s0, mesmo que você diga que isso vai para um switch não conectado a nenhum roteador – o que significa que 192.168.0.1 provavelmente não existe nesta rede, e mesmo que exista, não terá acesso à Internet de qualquer maneira. Isso provavelmente leva a outra instância do problema anterior, ou seja, que a rota inútil "0.0.0.0/0 através de enp5s0" tem prioridade mais alta sobre a rota funcional "0.0.0.0/0 através de enp4s0".
Não configure um gateway padrão se a rede não tiver um. A rota padrão não é necessária para que a interface funcione. (Comunicações de mesma sub-rede acontecem sem usar um gateway, por definição!)
1 Observe que "GB" (maiúsculas) significa "giga byte ", o que é uma diferença de 8x–10x de "Gb" (gigabit).
O motivo disso acontecer é que você tem 2 nics na mesma sub-rede de transmissão e os pacotes serão enviados somente em uma das nics.
Você está tentando acessar o servidor (ssh) da mesma sub-rede, portanto a rota padrão não será um fator, serão apenas as rotas 192.168.0.0/24.
Na interface estática você tem a rota: 192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.24
No DHCP você tem: 192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.27 metric 100
Como a métrica no dhcp é 100, e o estático é 0 devido a nenhuma métrica ser atribuída, a rota 0 será a rota que será usada. Isso significa que todo o tráfego para 192.168.0.0/24 será enviado via enp5s0. Isso causa problemas, pois o endereço mac que o cliente receberá é diferente daquele para o qual ele enviou, também, a menos que você tenha habilitado route_localnet, as duas interfaces não podem rotear o tráfego entre elas.
Se você deseja ter os dois nic na mesma sub-rede, você tem muitas opções, algumas dependerão do tipo de switch que você está usando. Duas opções que funcionarão não importa o switch que você esteja usando.
ip a adicionar 192.168.0.27/32 dev enp4s0 ip a deletar 192.168.0.27/24 dev enp4s0
você precisará atualizar sua configuração netplan para aplicar o novo endereço ip e desabilitar dhcp naquela interface. Caso contrário, ele obterá a sub-rede /24 novamente.
você também precisará habilitar route_localnet
sysctl -w net.ipv4.conf.all.route_localnet=1
Para tornar isso persistente em reinicializações
eco net.ipv4.conf.all.route_localnet=1 >> /etc/sysctl.conf
Isso resultará em quaisquer pacotes endereçados a 192.168.0.27 a serem enviados dessa interface, a métrica não importará, pois a sub-rede mais alta sempre será usada, a métrica é apenas um fator quando as sub-redes são as mesmas. Usar um endereço /32 também desabilitará a transmissão nessa interface, o que interromperá o loop de transmissão.
No Ubuntu: apt install bridge-utils
brctl addbr br0 brctl addif br0 enp4s0 brctl addif br0 enp5s0
conjunto de links ip enp4s0 promisc em conjunto de links ip enp5s0 promisc em
link ip definido br0 up dhclient br0 ip a del 192.168.0.27/24 dev enp4s0 ip a del 192.168.0.24/24 dev enp5s0
Isso dará à interface da ponte um novo endereço IP.
Esta configuração pode causar um loop de transmissão. Se isso acontecer, tente stp.
brctl pare com isso br0
certifique-se de que você pode acessar o terminal localmente ou com algum gerenciamento fora de banda, como iDrac ou iLo. Mudar para bridge pode fazer com que a conexão caia durante a mudança.
****Observação, eu não recomendo essa configuração, você não deve ter 2 nics na mesma sub-rede de broadcast (vlans são uma maneira de criar sub-redes de broadcast separadas). Agregação de links seria a melhor solução.
Se as interfaces de rede estiverem conectadas a diferentes segmentos físicos da rede, a opção de ponte é a melhor opção e é recomendada, pois ponte é outro termo para switch. Portanto, seu servidor atuará como um switch entre os dois segmentos físicos, unindo os dois físicos em uma rede lógica.