Conecte-se através de interfaces diferentes ao mesmo servidor (SO_BINDTODEVICE): Host de destino inacessível

2

Eu tenho 2 interfaces: eth0 e wlan0 , cada uma conectada a um roteador diferente. Suas especificações de rede são estas:

eth0:
    ip: 192.168.1.7
    Gateway: 192.168.1.1
    Submask: 255.255.255.0

wlan0:
    ip: 192.168.2.21
    Gateway: 192.168.2.1
    Submask: 255.255.255.0

Eu configurei o roteamento dessa maneira:

ip route add table eth0 to 192.168.1.0/24 dev eth0 scope link
ip route add table eth0 default via 192.168.1.1 dev eth0
ip rule add from 192.168.1.7 table eth0

E o mesmo para wlan0 usando seus valores. Então a saída de roteamento é:

ip rule
    0:      from all lookup local
    32764:  from 192.168.2.21 lookup wlan0
    32765:  from 192.168.1.7 lookup eth0
    32766:  from all lookup main
    32767:  from all lookup default

ip r s
    default via 192.168.1.1 dev eth0  proto static
    192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.7  metric 1
    192.168.2.0/24 dev wlan0  proto kernel  scope link  src 192.168.2.21  metric 9

ip r s table eth0
    default via 192.168.1.1 dev eth0
    192.168.1.0/24 dev eth0  scope link

ip r s table wlan0
    default via 192.168.2.1 dev wlan0
    192.168.2.0/24 dev wlan0  scope link

E também alterou sysctl "net.ipv4.conf.all.rp_filter=0" e sysctl -w "net.ipv4.ip_forward=1" . (Não pense realmente que ip_forward é necessário, mas eu mudei apenas no caso).

Agora, o mais estranho é que quando eu faço ping na interface do Google forçando wlan0 ele diz Destination Host Unreachable . A outra interface funciona bem.

ping -I wlan0 google.es
    PING google.es (173.194.45.183) from 192.168.2.21 wlan0: 56(84) bytes of data.
    From 192.168.2.21 icmp_seq=1 Destination Host Unreachable
    From 192.168.2.21 icmp_seq=2 Destination Host Unreachable
    From 192.168.2.21 icmp_seq=3 Destination Host Unreachable
    From 192.168.2.21 icmp_seq=4 Destination Host Unreachable

ping -I eth0 google.es
    PING google.es (173.194.45.191) from 192.168.1.7 eth0: 56(84) bytes of data.
    64 bytes from mad06s09-in-f31.1e100.net (173.194.45.191): icmp_seq=1 ttl=56 time=21.5 ms
    64 bytes from mad06s09-in-f31.1e100.net (173.194.45.191): icmp_seq=2 ttl=55 time=21.7 ms
    64 bytes from mad06s09-in-f31.1e100.net (173.194.45.191): icmp_seq=3 ttl=56 time=24.6 ms
    64 bytes from mad06s09-in-f31.1e100.net (173.194.45.191): icmp_seq=4 ttl=55 time=31.1 ms
    
por Jorge Fuentes González 04.01.2015 / 19:56

1 resposta

2

Não sei ao certo como a determinação do endereço de origem é feita no caso de uma ligação de interface tão forçada. Se o endereço de origem não for retirado do dispositivo, o problema é que seus ip rule seletores não correspondem, de forma que o pacote seja executado na tabela de roteamento main , ou seja,

default via 192.168.1.1 dev eth0  proto static

que não funciona em wlan0 .

Sugiro que tente isso:

ip rule add from 192.168.1.7  table  eth0
ip rule add oif  eth0         table  eth0
ip rule add from 192.168.2.21 table wlan0
ip rule add oif  wlan0        table wlan0

e amplie o

ip route add table eth0
ip route add table wlan0

comandos pela opção src .

    
por 04.01.2015 / 21:54