Quão quebrada é a estratégia de roteamento que causa um pacote marciano (até agora apenas) durante o tracepath?

Question

Eu acredito que eu consegui uma tabela que roteia pacotes de e para eth1 / 192.168.3.x através de 192.168.3.1 , e pacotes de e para eth0 / 192.168.1. x até 192.168.1.1 ( fonte útil ).

Pergunta : ao fazer o tracepath a partir de 192.168.3.20 (de dentro do vserver), estou obtendo kernel: [318535.927489] martian source 192.168.3.20 from 212.47.223.33, on dev eth0 no IP de destino ou próximo dele, enquanto os saltos intermediários ficam sem log (log abaixo). / p>

Eu não entendo porque este pacote está chegando na eth0, ao invés de eth1, mesmo depois de ler isto :

Note que você pode ver pacotes de endereços IP não-roteáveis ao executar os comandos traceroute ou tracepath. Embora os pacotes não possam ser roteados para esses roteadores, os pacotes enviados entre dois roteadores precisam saber apenas o endereço do próximo salto dentro das redes locais, o que poderia ser um endereço não roteável.

Alguém pode explicar esse parágrafo em linguagem humana? Com base em testes iniciais curtos até agora, tudo o mais parece funcionar sem causar marcianos. Isso está contido na natureza da operação do tracepath ou eu tenho algum outro problema de roteamento maior que causará quebra no tráfego de trabalho?

Nota lateral: é possível inspecionar o pacote marciano com tcpdump ou wireshark ou qualquer coisa do tipo? Eu não consegui que ele aparecesse sozinho.

vserver-20 / # tracepath -n 212.47.223.33
 1:  192.168.3.2                                           0.064ms pmtu 1500
 1:  192.168.3.1                                           1.076ms
 1:  192.168.3.1                                           1.259ms
 2:  90.191.8.2                                            1.908ms
 3:  90.190.134.194                                        2.595ms
 4:  194.126.123.94                                        2.136ms asymm  5
 5:  195.250.170.22                                        2.266ms asymm  6
 6:  212.47.201.86                                         2.390ms asymm  7
 7:  no reply
 8:  no reply
 9:  no reply
^C

Roteamento de host :

$ sudo ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
2: sit0: <NOARP> mtu 1480 qdisc noop state DOWN 
    link/sit 0.0.0.0 brd 0.0.0.0
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:24:1d:de:b3:5d brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.2/24 scope global eth0
4: eth1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:0c:46:46:a3:6a brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.2/27 scope global eth1
    inet 192.168.3.20/27 brd 192.168.3.31 scope global secondary eth1  # linux-vserver instance

$ sudo ip route
default via 192.168.1.1 dev eth0  metric 3 
unreachable 127.0.0.0/8  scope host 
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.2 
192.168.3.0/27 dev eth1  proto kernel  scope link  src 192.168.3.2

$ sudo ip rule
0:      from all lookup local 
32764:  from all to 192.168.3.0/27 lookup dmz 
32765:  from 192.168.3.0/27 lookup dmz 
32766:  from all lookup main 
32767:  from all lookup default

$ sudo ip route show table dmz
default via 192.168.3.1 dev eth1  metric 4 
192.168.3.0/27 dev eth1  scope link  metric 4

Roteamento de gateway

# ip route
10.24.0.2 dev tun0  proto kernel  scope link  src 10.24.0.1 
10.24.0.0/24 via 10.24.0.2 dev tun0 
192.168.3.0/24 dev br-dmz  proto kernel  scope link  src 192.168.3.1 
192.168.1.0/24 dev br-lan  proto kernel  scope link  src 192.168.1.1 
$ISP_NET/23 dev eth0.1  proto kernel  scope link  src $WAN_IP 
default via $ISP_GW dev eth0.1

Histórico adicional

Opções para isolamento da interface de rede não virtualizada?

    

Answer 1

Se você receber o pacote marciano, o wireshark deve ser capaz de mostrá-lo.

Também vejo que você desabilitou o loopback definindo uma rota inacessível para 127.0.0.0/8. Isso não é compatível com os padrões e provavelmente não é útil, mas duvido que tenha muito a ver com esse problema.

O parágrafo de documentação significa simplesmente que você provavelmente verá endereços RFC1918 ou outras coisas inacessíveis no traceroute, pois esses endereços podem ser usados entre roteadores em muitos casos (por exemplo, dentro de um AS), mas serão o endereço do roteador dá quando o pacote excede seu TTL lá. Isso não significa que você deve esperar marcianos. Eu também duvido que tenha algo a ver com este pacote em particular.

O pacote marciano pode não ter nada a ver com o traceroute. No entanto, isso pode acontecer. É freqüentemente causado por um gateway que não está usando o nat nativo quando deveria, mas também é possível que você tenha uma regra NAT quebrada em algum lugar traduzindo o endereço de destino dos pacotes de saída de eth1 para o IP de eth0. Isso parece mais provável, dada a origem do pacote. Isso também pode significar que você está esquecendo de fazer NAT de origem em pacotes de saída do seu gateway.

Você deve executar uma captura wireshark em eth1 e eth0 e tentar encontrar o pacote em eth0 e ver se você pode correlacioná-lo com um da eth1. Além disso, verifique suas regras de NAT.

    

Answer 2

Eu acredito que o "problema" é que ambas as interfaces estão conectadas à mesma rede. Em algum momento você está recebendo pacotes com o IP 192.168.3.20 na sua interface eth0, o que faz com que a entrada de configuração log_martians seja ativada.

Tenho certeza de que você tem o rp_filter ativado e que isso desaparecerá se você desativá-lo (por exemplo, / proc / sys / net / ipv4 / conf / all / rp_filter), mas leia abaixo:

Isso pode ser por dois motivos:

1. Você está recebendo pacotes legítimos de sua própria rede a partir dessa interface (ou seja, errada). No seu caso, em teoria, todos os pacotes para a sub-rede 192.168.3.0/27 devem chegar à eth1, a menos que você tenha um roteamento de vários caminhos, caso em que você precisa desabilitar o rp_filter.
2. Durante o seu tracepath, um dos links intermediários usa endereços IP da sub-rede 192.168.3.0/27. Ou seja imagine que um dos ISPs intermediários entre você e o destino usa endereços IP dessa sub-rede em seus roteadores. Devido à maneira como o traceroute funciona, você estará recebendo pacotes ICMP TTL EXCEEDED com esse IP de origem (já que o roteador os estará enviando). E como sua rota padrão é via eth0, o kernel irá reclamar (porque está esperando que tudo, de 192.168.3.0/27, chegue à eth1 - por causa do rp_filter).

Existem várias maneiras de solucionar isso e sim, você pode usar o tcpdump (por exemplo, tcpdump -ni eth0 'host 192.168.3.20').

    

Answer 3

Eu posso responder sua pergunta intermediária. Eu tenho um / 29 do qual eu direciono cada / 32 independentemente:

ip route add 8.4.3.3/32 via 192.168.17.33.

Dessa forma, posso usar todos os oito / 32 em vez de perder um para o endereço de broadcast e o outro para a interface do roteador nessa sub-rede.

Quanto à interface errada; você pode mostrar suas regras NAT? Obrigado seria:

iptables -vnL -t nat