Multihomed Routing - Linux: permite que o tráfego seja respondido em outra interface

1

Liguei-me a dois ISPs e anunciei o meu próprio espaço IP (/ 24 IPv4) para que os dois ISPs encaminhassem o tráfego destinado à minha sub-rede para o meu router (um servidor Linux).

Dois ISPs estão conectados à interface diferente no roteador Linux, digamos eth0 e eth1 .

Agora, quando eu tento ping um endereço, tudo que eu tenho é o tempo limite do pedido. No entanto, ao fazer tcpdump , posso ver a resposta da máquina remota, mas não na mesma interface da qual a solicitação de envio do roteador Linux. (ou seja, envie de eth0 , obteve resposta em eth1 ):

eth0:

17:11:26.136885 IP tky01.jp.nat.moe > syr.edu: ICMP echo request, id 22910, seq 1, length 64
17:11:27.139627 IP tky01.jp.nat.moe > syr.edu: ICMP echo request, id 22910, seq 2, length 64
17:11:28.163632 IP tky01.jp.nat.moe > syr.edu: ICMP echo request, id 22910, seq 3, length 64
17:11:29.187715 IP tky01.jp.nat.moe > syr.edu: ICMP echo request, id 22910, seq 4, length 64
17:11:30.211766 IP tky01.jp.nat.moe > syr.edu: ICMP echo request, id 22910, seq 5, length 64

eth1:

17:11:26.314683 IP syr.edu > tky01.jp.nat.moe: ICMP echo reply, id 22910, seq 1, length 64
17:11:27.317398 IP syr.edu > tky01.jp.nat.moe: ICMP echo reply, id 22910, seq 2, length 64
17:11:28.341461 IP syr.edu > tky01.jp.nat.moe: ICMP echo reply, id 22910, seq 3, length 64
17:11:29.365671 IP syr.edu > tky01.jp.nat.moe: ICMP echo reply, id 22910, seq 4, length 64
17:11:30.389885 IP syr.edu > tky01.jp.nat.moe: ICMP echo reply, id 22910, seq 5, length 64

Eu tentei fazer o roteamento de políticas:

ip rule add from x.x.x.x/24 lookup isp2 # where x.x.x.x is my subnet.
ip route add default via y.y.y.y dev eth1 table isp2 # where y.y.y.y is ISP2's gateway

Isso faz com que ping funcione normalmente, mas agora qualquer usuário optar por entrar no meu AS usando o ISP1 (eth0) não poderá acessar nada.

Como faço para o Linux saber que eth0 e eth1 podem responder a solicitação?

    
por Morichika Maho 04.05.2017 / 19:16

1 resposta

2

Acabei de descobrir. rp_filter precisa ser desativado para permitir a resposta de um caminho diferente:

for iface in eth{0,1}; do echo 0 > /proc/sys/net/ipv4/conf/$iface/rp_filter; done

Para torná-lo permanente, defina net.ipv4.conf.<iface>.rp_filter = 0 no sysctl.

    
por 04.05.2017 / 20:36