Conexão com fio tomando precedência de conexão sem fio

Question

Eu conectei duas máquinas Linux. Uma máquina tem uma conexão sem fio com meu roteador enquanto a outra não. A máquina sem acesso sem fio (PC1) é configurada de tal forma que possui um IP estático exclusivo e a outra máquina (PC2) é definida como seu gateway padrão. O PC2 é configurado de tal forma que também possui um IP exclusivo e usa o roteador como um gateway padrão. Quando eu habilito a conexão com fio, o PC1 pode se comunicar com as interfaces eth0 e wlan0 do PC2, e o PC2 pode se comunicar com o PC1. Infelizmente quando a conexão com fio está habilitada, o PC2 não pode se comunicar com o roteador e, portanto, nem o PC1. Essencialmente, as conexões com fio e sem fio PC2 não podem operar ao mesmo tempo.

PC2 (NOTA: route-n é o mesmo, independentemente de o cabo estar ou não ativado)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.138      0.0.0.0         UG    0      0        0 wlan0
10.0.0.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     9      0        0 wlan0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0

docker0   Link encap:Ethernet  HWaddr 56:84:7a:fe:97:99  
          inet addr:172.17.42.1  Bcast:0.0.0.0  Mask:255.255.0.0
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

eth0      Link encap:Ethernet  HWaddr 60:a4:4c:62:ee:86  
          inet addr:10.0.0.140  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::62a4:4cff:fe62:ee86/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:155 errors:0 dropped:0 overruns:0 frame:0
          TX packets:7744 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:12554 (12.5 KB)  TX bytes:1509568 (1.5 MB)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:2179347 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2179347 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:217854881 (217.8 MB)  TX bytes:217854881 (217.8 MB)

wlan0     Link encap:Ethernet  HWaddr c0:4a:00:66:58:98  
          inet addr:10.0.0.103  Bcast:10.0.0.255  Mask:255.255.255.0
          inet6 addr: fe80::c24a:ff:fe66:5898/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1605422 errors:0 dropped:0 overruns:0 frame:0
          TX packets:669649 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:1405768536 (1.4 GB)  TX bytes:83997471 (83.9 MB)

PC1 (NOTA: Não consigo recuperar o ifconfig do PC1)

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.0.0.139      0.0.0.0         UG    0      0        0 eth0
10.0.0.0        0.0.0.0         255.255.255.0   U     1      0        0 eth0

    

Answer 1

A configuração atual da tabela de roteamento PC2 é o seu problema. Eu o reproduzi aqui com colunas sem importância removidas e convertidas da netmask para a notação CIDR:

Destination     Gateway         Metric Iface
0.0.0.0/0       10.0.0.138      0      wlan0
10.0.0.0/24     0.0.0.0         1      eth0
10.0.0.0/24     0.0.0.0         9      wlan0

A primeira linha significa em inglês simples "O tráfego para todos os outros sites é enviado pelo gateway 10.0.0.138".

A segunda e terceira linha fornecem o mesmo destino, então a métrica mais baixa ganha. A linha 3 pode nem estar lá. Significado em inglês simples "Para alcançar o gateway 10.0.0.138 e todos os outros 10.0.0. * Peers, envie por meio de eth0"

Juntos, isso resulta em tráfego destinado à Internet passando pela eth0, daí a sua falta de conectividade.

O problema surge porque você tem a mesma sub-rede usada em dois domínios de bridging diferentes na mesma rede, o que não é permitido. Pare com isso!

Mude a máscara de rede da interface eth0 do PC2 para 255.255.252.0 e forneça um endereço IP mais distante do roteador, o que mudará a tabela de roteamento para (por exemplo, dando o PC2 eth0 10.0.0.21 e PC1 eth0 10.0.0.22)

Destination     Gateway         Metric Iface
0.0.0.0/0       10.0.0.138      0      wlan0
10.0.0.20/30    0.0.0.0         1      eth0
10.0.0.0/24     0.0.0.0         9      wlan0

Agora, o tráfego para o gateway 10.0.0.138 não corresponderá à segunda linha e usará a terceira linha corretamente.

Melhor ainda seria usar um intervalo não sobreposto para a conexão com fio, por exemplo, 10.0.1.x

Para que o acesso à Internet também funcione para o PC1, o roteador precisará enviar o tráfego destinado ao PC1 via PC2. Há duas maneiras de configurar isso: altere a tabela de roteamento do roteador ou configure o PC2 para executar o proxy ARP.

    

Answer 2

Existem algumas coisas que podem estar causando problemas:

1. Você afirma que o PC1 está usando o PC2 como seu gateway padrão, no entanto, a tabela de roteamento do PC1 infact mostra 10.0.0.139 como o gateway padrão, em vez da interface eth0 do PC2 10.0.0.140
2. Se o PC2 for responsável pelo roteamento de tráfego do PC1, você ativou o encaminhamento de IP no PC2? Eu não acredito que isso esteja ativado por padrão no Linux. Verifique com cat /proc/sys/net/ipv4/ip_forward . Se for 0, o PC2 descartará todo o tráfego roteável enviado para ele pelo PC1. Guia se você precisar ativá-lo .
3. Se o encaminhamento de ip estiver realmente habilitado no PC2, o iptables foi configurado para aceitar o tráfego que atinge sua cadeia de encaminhamento? iptables -nvL para verificar as regras da cadeia Forward.