Resolución de nombres de Debian Winbind que proporciona varias direcciones: ¿cómo seleccionar una?

Estoy tratando de configurar winbind en una instalación de Debian como alternativa para cuando nuestro servidor DNS no funciona. Tengo que usar winbind (en lugar de alternativas como mDNS / Avahi) ya que tengo que usar un método que funcione con nuestra configuración de servidor existente.

La instalación de Debian consta de:

• Debian squeeze guest en Virtualbox (4.1.18)
• Sistema operativo host de Windows XP con redes NAT
• Dirección IP del invitado Debian 10.0.2.15
• Utilizado para Subversion / Bugzilla con autenticación LDAP para controlador de dominio

La máquina host de Windows tiene la dirección IP 192.168.1.25.

Nuestro controlador de dominio de Windows es Server 2011 Essentials y no tengo acceso para solucionar lo que ocurra, por lo que solo puedo buscar una solución (usando winbind) hasta que se solucione. La dirección IP de este es 192.168.1.1.

Instalé winbind, libnss_winbind y libpam_winbind en la instalación de Debian. Cambié mi hostslínea /etc/nsswitch.confa hosts: files dns wins. Si lo uso nmblookup servername, obtengo el siguiente resultado:

querying servername on 10.0.2.255
169.254.2.33 servername<00>
192.168.1.1 servername<00>

Parece que hay dos NIC en el servidor, uno tiene una dirección privada y el otro tiene una dirección en nuestra red interna (la 192 ... dirección). Verifiqué lo que representa la salida al buscar otra computadora donde puedo verificar las direcciones de todas las NIC.

Mi problema es que si uso algo así, pingentonces usa la primera dirección que se informa (la dirección privada 169 ...), que es inalcanzable. Lo mismo se aplica para cualquier otro código de red, como cuando apache realiza la autenticación LDAP para Subversion o BugZilla.

¿Hay alguna forma de configurar los valores que devuelve winbind o hacer que realice una comprobación de estado para ver si se puede acceder a la dirección IP antes de devolverla? No he encontrado nada en la documentación de winbind o en línea.

Editar: route -ninforma lo siguiente:

Desintation Gateway  Genmask       Flags Metric Ref Use Iface
10.0.2.0    0.0.0.0  255.255.255.0 U     0      0   0   eth0
0.0.0.0     10.0.2.2 0.0.0.0       UG    0      0   0   eth0

El contenido de mi /etc/network/interfaceses el siguiente, pero actualmente no estoy seguro de qué tiene que ver con la subred o la configuración de enrutamiento (es decir, no parece que tenga nada allí):

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

Aquí está la tabla de enrutamiento del host:

===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 13 72 e0 93 4d ...... Broadcom NetXtreme 57xx Gigabit Controller - Pac
ket Scheduler Miniport
0x3 ...08 00 27 00 90 b3 ...... VirtualBox Host-Only Ethernet Adapter - Packet S
cheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0    192.168.1.254    192.168.1.25       20
        127.0.0.0        255.0.0.0        127.0.0.1       127.0.0.1       1
      192.168.1.0    255.255.255.0     192.168.1.25    192.168.1.25       20
     192.168.1.25  255.255.255.255        127.0.0.1       127.0.0.1       20
    192.168.1.255  255.255.255.255     192.168.1.25    192.168.1.25       20
     192.168.56.0    255.255.255.0     192.168.56.1    192.168.56.1       20
     192.168.56.1  255.255.255.255        127.0.0.1       127.0.0.1       20
   192.168.56.255  255.255.255.255     192.168.56.1    192.168.56.1       20
        224.0.0.0        240.0.0.0     192.168.1.25    192.168.1.25       20
        224.0.0.0        240.0.0.0     192.168.56.1    192.168.56.1       20
  255.255.255.255  255.255.255.255     192.168.1.25    192.168.1.25       1
  255.255.255.255  255.255.255.255     192.168.56.1    192.168.56.1       1
Default Gateway:    192.168.1.254
===========================================================================
Persistent Routes:
  None

Aquí es el resultado de hacer ping manualmente a las direcciones IP a lo largo de la red. Mi salida de traceroute solo muestra el destino final (si uso la -Iopción) o todos los asteriscos. Por lo tanto, el destino debe ser accesible con la tabla de enrutamiento anterior en el host. Supongo que los rangos de direcciones de invitados de VirtualBox no se muestran, ya que son administrados por la aplicación VirtualBox y no están expuestos al host. Descubrí que 10.0.2.2 es la puerta de enlace VirtualBox dentro de la red NAT. 192.168.56.1 es la dirección IP para el host

PING 10.0.2.2 (10.0.2.2) 56(84) bytes of data.
64 bytes from 10.0.2.2: icmp_req=1 ttl=63 time=0.498 ms
64 bytes from 10.0.2.2: icmp_req=2 ttl=63 time=0.490 ms
64 bytes from 10.0.2.2: icmp_req=3 ttl=63 time=0.516 ms
64 bytes from 10.0.2.2: icmp_req=4 ttl=63 time=0.515 ms

--- 10.0.2.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3000ms
rtt min/avg/max/mdev = 0.490/0.504/0.516/0.029 ms
PING 192.168.56.1 (192.168.56.1) 56(84) bytes of data.
64 bytes from 192.168.56.1: icmp_req=1 ttl=128 time=0.755 ms
64 bytes from 192.168.56.1: icmp_req=2 ttl=128 time=1.04 ms
64 bytes from 192.168.56.1: icmp_req=3 ttl=128 time=0.545 ms
64 bytes from 192.168.56.1: icmp_req=4 ttl=128 time=0.606 ms

--- 192.168.56.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 0.545/0.738/1.047/0.194 ms
PING 192.168.1.25 (192.168.1.25) 56(84) bytes of data.
64 bytes from 192.168.1.25: icmp_req=1 ttl=128 time=0.610 ms
64 bytes from 192.168.1.25: icmp_req=2 ttl=128 time=0.639 ms
64 bytes from 192.168.1.25: icmp_req=3 ttl=128 time=0.570 ms
64 bytes from 192.168.1.25: icmp_req=4 ttl=128 time=0.659 ms

--- 192.168.1.25 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 0.570/0.619/0.659/0.041 ms
PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_req=1 ttl=128 time=1.15 ms
64 bytes from 192.168.1.1: icmp_req=2 ttl=128 time=0.934 ms
64 bytes from 192.168.1.1: icmp_req=3 ttl=128 time=0.941 ms
64 bytes from 192.168.1.1: icmp_req=4 ttl=128 time=0.856 ms

--- 192.168.1.1 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.856/0.971/1.154/0.112 ms

Y VirtualBox definitivamente está utilizando NAT (ya que se puede acceder a la puerta de enlace NAT en el registro anterior) y no está utilizando una red de solo host. El Adaptador de solo host en mi tabla de enrutamiento de host era un arenque rojo, ya que lo he deshabilitado y todavía puedo hacer ping como se indicó anteriormente. También ver la Screengrab a continuación que muestra la configuración de red de invitados VirtualBox: . A menos que haya algún error que evite que use mi configuración correctamente. La sección relevante de la configuración:

  <Network>
    <Adapter slot="0" enabled="true" MACAddress="08002780662C" cable="true" speed="0" type="82540EM">
      <DisabledModes/>
      <NAT>
        <DNS pass-domain="true" use-proxy="false" use-host-resolver="false"/>
        <Alias logging="false" proxy-only="false" use-same-ports="false"/>
        <Forwarding name="http" proto="1" hostport="80" guestport="80"/>
        <Forwarding name="https" proto="1" hostport="443" guestport="443"/>
      </NAT>
    </Adapter>

La red 169.254.0.0 en Debian es la red de configuración cero. Se describe en Wikipedia como:

Las redes de configuración cero permiten a los usuarios novatos interconectar dispositivos habilitados para la red sin ninguna configuración (cero), se utiliza cuando no hay servidores DHCP y DNS disponibles en la red.

Zeroconf proporciona:

Asignación automática de la dirección de red (enlace local) Resolución automática de nombres de host mediante DNS de multidifusión Ubicación automática de servicios de red (es decir, impresión) después de descubrir automáticamente servidores DNS.

Se puede deshabilitar de forma segura en una máquina virtual. Para hacerlo, modifique el archivo / etc / default / avahi-daemon para que contenga esta línea:

AVAHI_DAEMON_DETECT_LOCAL=0

Cuando haga esto (y después de reiniciar el servicio avahi-daemon), el servidor 169 ... desaparecerá.

EDITAR: En cualquier caso, si prueba la conectividad, este pequeño script hará:

#!/bin/sh
ping -c1 TheIpWhoseConnectionYouWantToTest
if [ $? -eq 0 ]; then 
    Specify here the actions you wish to insert IF there is connection
fi

If you also wish to determine the Gateway automatically, you can do it as follows:

IP=$(route -n | grep UG | awk '{print $2}')
echo $IP

Esto devolverá automáticamente su IP de puerta de enlace

En primer lugar, me gustaría decir que está buscando el problema en el lugar equivocado.

• Todos los protocolos, incluidos el DNS de multidifusión y winbind, deberían poder devolver de forma segura todas las direcciones disponibles.
• Luego, su aplicación (incluida ping) debe usar la API del sistema operativo para obtener la lista de registros de información de direcciones.
• Finalmente, su aplicación debe probar los registros de información uno por uno hasta que se conecte con éxito ( pingpuede que no sea la herramienta de prueba correcta aquí).

El truco es que a pesar de que winbind (o cualquier otro complemento) devuelve una lista que contiene varias direcciones, todas ellas deben ser direcciones válidas con las que puede contactar. De lo contrario, hay un problema en el servidor o en la configuración de la red. Pero incluso entonces, cuando la aplicación intenta conectarse, debe rechazarse con el host de destino inalcanzable e inmediatamente debe probar el siguiente elemento de la lista.

Incluso si lo anterior no se aplica y no puede reparar el servidor ni la configuración de red ni la aplicación local, no está perdido. La API de resolución de nombres de sistemas operativos (la getaddrinfo()función) reordena la lista de acuerdo con algunos criterios. Y puede influir en ese criterio editando, /etc/gai.confque se introdujo principalmente para configurar un equilibrio entre las direcciones IPv4 y varios tipos de direcciones IPv6. De esa manera, mientras su complemento winss nsswitch devuelve varias direcciones, es usted quien tiene la última palabra sobre cuál de ellas será la preferida.

Como se indicó en otras respuestas, el 169.254/16espacio de direcciones está reservado para direcciones de enlace local IPv4. Los sistemas operativos generalmente no tienen muy buen soporte para las direcciones locales de enlace IPv4 (a diferencia de las direcciones locales de enlace IPv6, que tienen mucho mejor soporte). La forma habitual es evitar las direcciones locales de enlace IPv4 por completo para los hosts que tienen una dirección IPv4 adecuada.

Si nada de lo anterior es posible, sería una buena idea privar las direcciones IPv4 mediante /etc/gai.conf en sus instalaciones y probablemente incluso de manera predeterminada en las distribuciones de Linux.

Además, dado que su sistema local probablemente no tiene una dirección de la 169.254/16subred, su biblioteca de resolución debería poder eliminar dicha dirección del resultado porque es inalcanzable . Puede valer la pena considerar comenzar una discusión con los responsables de distribución.

Otra solución es mantener sus máquinas winbind en un solo segmento de ethernet donde las direcciones locales de enlace IPv4 funcionan como se espera. Tendría que usar puentes de red en lugar de NAT para su virtualización.

Por curiosidad, ¿cuál es su ruta que muestra la ruta predeterminada? Algo así como: route -n le mostrará la ruta predeterminada en su sistema.

Tengo curiosidad si, por alguna extraña razón, la subred 169.254.0.0/16 está configurada como la puerta de enlace predeterminada en alguna parte. Tal vez en la configuración de su red, o / etc / network / interfaces, ¿tiene una subred, una red y una configuración potencial de rutas para su interfaz "predeterminada".