Interfaz de direcciones IP discrepancia

Esto es muy extraño.

Salida de la ip route show :

 default via 192.168.1.1 dev eth0 metric 100 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.1.10 192.168.1.0/24 dev eth2 proto kernel scope link src 192.168.1.11 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.58 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 

Desde los loggings de cortafuegos: (ligeramente abreviado)

 Mar 8 09:17:12 vmhost kernel: [ 562.808036] ''IN-dmz-lan-face':'IN=eth1 OUT= MAC=... SRC=192.168.1.108 DST=192.168.1.58 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=28218 DF PROTO=TCP SPT=47365 DPT=22 WINDOW=14600 RES=0x00 SYN URGP=0 

¿Observe la extravagante discrepancia?

El logging de cortafuegos enumera eth1 en la dirección 192.168.1.58 , pero la tabla de routing lo pone en 192.168.1.10 .

De alguna manera, eth1 y eth0 están intercambiando, o sus direcciones IP.

No hay tablas adicionales de routing en juego.

¿Cómo puede suceder esto? ¿Cómo puedo arreglarlo?


Editar (más información)

Salida de ip addr | grep "inet " ip addr | grep "inet " :

 inet 127.0.0.1/8 scope host lo inet 192.168.1.58/24 brd 192.168.1.255 scope global eth0 inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1 inet 192.168.1.11/24 brd 192.168.1.255 scope global eth2 inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 

One Solution collect form web for “Interfaz de direcciones IP discrepancia”

No hay discrepancia.

 IN=eth1 OUT= SRC=192.168.1.108 DST=192.168.1.58 PROTO=TCP SPT=47365 DPT=22 

El logging de cortafuegos enumera eth1 en la dirección 192.168.1.58, pero la tabla de routing lo pone en 192.168.1.10.

No, el firewall le informa que ha recibido un package de eth1 con el destino 192.168.1.58. Esto no es sorprendente: cualquier persona en su networking puede enviar cualquier package falso en la interfaz en la que está conectado su server. Si esto es un problema, culpe al remitente.

Tenga en count, sin embargo, que el kernel de Linux utiliza un model de host débil por defecto. Eso significa que aceptará un package como suyo si la dirección de destino coincide con uno en cualquiera de su interfaz. Así que el kernel aceptará el package como legítimo.

Este model de host débil también se refleja en el comportamiento de ARP: el kernel responderá a un ARP para la dirección 192.168.1.58 en cualquiera de sus interfaces de forma pnetworkingeterminada. Si todas las interfaces están conectadas al mismo segmento de networking, entonces alguien que solicita 192.168.1.58 puede terminar en cualquiera de sus 3 interfaces. Si no se desea, configure arp_ignore sysctl como 1.

Además, las tablas de routing son inusuales, si no equivocadas. Si pide que el kernel se conecte a 192.168.1.108, ¿qué interfaz debe usar? La respuesta real es dada por el command ip route get 192.168.1.108 . Puede que no sea la que usted espera.

  • Autenticación de contraseña de MySQL con usuarios proxy y asignación de grupos
  • Ubuntu es muy lento en esxi5
  • Reenvío de puertos con iptables en Ubuntu
  • Reiniciar rsyslog vuelve a enviar los loggings de nuevo
  • cartero no retransmitir correo electrónico a la dirección externa
  • MySQL Crashing y no reiniciar
  • Ubuntu Xen DomU Boot Error
  • mkfs no puede crear una nueva partición xfs
  • Apache: apachectl restart no recarga envvars
  • ¿Cómo hacer que Chef-Server utilice Ruby 1.9 en Ubuntu?
  • apt-get no se encuentra en mi VPS?
  • ¿Por qué es upstart comiendo toda mi RAM?
  • Chef 'notifica' falla al reiniciar o recargar services
  • El linux y los temas del servidor de Windows, como ubuntu, centos, apache, nginx, debian y consejos de red.