contexto
Hay 2 servidores:
servidor1 - eth0 10.129.76.16 eth0.2 192.168.0.103
servidor2 - eth0 10.129.79.1 eth0.2 192.168.62.101
Las direcciones 192.xxx están conectadas a la misma vlan (vlan2) y pueden verse entre sí. Las direcciones 10.xxx están conectadas a diferentes VLAN que no pueden verse entre sí.
a petición de David Swartz: la tabla de enrutamiento en el servidor 1 es:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
10.129.76.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
0.0.0.0 192.168.61.254 0.0.0.0 UG 100 0 0 eth0.2
la tabla de enrutamiento en el servidor 2 es:
~$ sudo route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 <public IP gw> 0.0.0.0 UG 100 0 0 eth0.11
10.129.79.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
<public IP> 0.0.0.0 255.255.255.128 U 0 0 0 eth0.11
192.168.0.0 0.0.0.0 255.255.192.0 U 0 0 0 eth0.2
Problema:
Cuando hago ping desde el servidor 1 al servidor 2, parece que no llegan paquetes y viceversa. Cuando reviso las rutas (ruta -n), veo que el gw predeterminado usa eth0.2 en ambos servidores. Pero cuando uso arping, obtengo una respuesta en un sentido (del servidor 2 al servidor 1), pero no obtengo respuesta al revés.
arping 192.168.62.101
ARPING 192.168.62.101 from 10.129.76.16 eth0
^CSent 2 probes (2 broadcast(s))
Received 0 response(s)
Como puede ver, utiliza la dirección 10.xxx en lugar de 192.xxx. Y como dije antes, la dirección 10.xxx es inaccesible desde el otro servidor.
Cuando fuerzo a arping a usar eth0.2, funciona.
No tengo ningún problema para hacer ping a otros servidores desde cualquiera de esos 2 servidores.
Vi esto en las tablas arp:
~# arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
y
~# arp -n | grep 192.168.62.101
Pregunta
bastante obvio... ¿Cómo puedo hacer que estos servidores se vuelvan a ver?
Cosas que he atado
borre las entradas apropiadas en arptable e intente deshacerse de las (incompletas). Pero creo que el mayor problema es que se usa eth0 en lugar de eth0.2 para los paquetes del servidor 1 al servidor 2.
Debido al comentario de David Swartz sobre las tablas de enrutamiento, agregué una ruta allí para definir el host. yo añadí
192.168.0.103 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
y
192.168.62.101 0.0.0.0 255.255.255.255 UH 0 0 0 eth0.2
a los servidores apropiados, pero esto no resolvió el problema, así que supongo que el problema no está en el enrutamiento.
Mi conjetura
Supongo que el problema radica en lo siguiente.
~$ arp -n | grep 192.168.0.103
192.168.0.103 (incomplete) eth0
pero no puedo eliminar esta entrada. (arp -d 192.168.0.103 no tiene ningún efecto)
¡Gracias por leer y aún más gracias por responder!
Respuesta1
Aquí hay un fragmento:
arpping no respeta la tabla de enrutamiento local:
== mbrownnyc [gateway/web/freenode] has joined ##networking
[10:14] <mbrownnyc> mAniAk-_-: any idea why, if his routing table reflects the proper interface to route 192.168.0.0/18 packets, why when he `arping 192.168.62.101` the kernel would think to make the source address that of the other interface?
[10:14] <mbrownnyc> it's very very weird to me
[10:16] <mbrownnyc> tafelpoot: unless arping has a bug in the code or something?
[10:17] <mbrownnyc> can you use another piece of software? like hping?
[10:17] <catphish> mbrownnyc: arping doesn't respect the routing table
[10:17] <catphish> you have to specify the interface manually
[10:17] <mbrownnyc> catphish: voila!
[10:18] <catphish> no idea why, it's just never been a feature of it, it seems to use the first ethernet interface unless you tell it otherwise
[10:19] <mbrownnyc> catphish: interesting catphish that's the whole "problem" here, the testing mechanism, I guess
use icmp para probar:
[10:25] <catphish> mbrownnyc: that guy is testing with arping which makes no sense since arping doesn't use the routing table
[10:26] <catphish> it should be ping
[10:26] <catphish> and if ping fails, arping with an interface specified
[10:26] <mAniAk-_-> GG
[10:26] <catphish> oh, it does work when forcing arping to use the right address
[10:27] <catphish> so im not sure what the problem might be
[10:27] <mAniAk-_-> ARPING 192.168.62.101 from 10.129.76.16 eth0
[10:27] <mAniAk-_-> not eth0.2
[10:28] <catphish> indeed
[10:28] <catphish> because the interface wasn't specified
[10:28] <catphish> apparantly it works when the interface is specified
[10:28] <catphish> so i don't see the problem
¿Están bien tus VLAN?
[10:29] <catphish> it's also possible the the vlan config is messed up, i don't like mixing native and tagged vlans like that
[10:29] <mAniAk-_-> yeah i thought so too
Respuesta2
No mencionaste qué kernel estás usando ni qué versión arping, y existe la posibilidad de que haya un error en uno u otro. El hecho de que pueda hacerlo correctamente arpingal especificar la subinterfaz indica que todas sus redes de capa 2 se están comportando correctamente.
Intente usarlo ip route get 192.168.62.101en el servidor1 para preguntarle directamente al kernel cómo enviaría su tráfico. Según las tablas de enrutamiento que ha publicado, enviar a través de eth0.2 es claramente el comportamiento correcto y, si ip route getdevuelve una respuesta diferente, es posible que esté ante un error del kernel. Si devuelve la respuesta correcta, entonces arpinges el culpable, pero eso parece poco probable.
(incomplete)No es necesario eliminar la entrada; es un marcador de posición que le permite al kernel saber que intentó ARP esa IP, por lo que una respuesta ARP debe considerarse válida y noun ataque de veneno ARP, pero que no obtuvo respuesta. Se acabará el tiempo.