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>
fuente
Respuestas:
La red 169.254.0.0 en Debian es la red de configuración cero. Se describe en Wikipedia como:
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:
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á:
Esto devolverá automáticamente su IP de puerta de enlace
fuente
ifconfigresultado) no tiene un enlace de dirección IPv4 local. Las direcciones locales de enlace que informa winbind pertenecen a las segundas NIC de otras computadoras que no están conectadas a nada, por lo tanto, Windows les proporciona una dirección local de enlace. El host de destino parece informar todas las direcciones IP que ha ordenado de alguna manera y winbind informa la primera para la búsqueda del nombre de host y resulta ser la dirección local del enlace que no está conectada a nada.En primer lugar, me gustaría decir que está buscando el problema en el lugar equivocado.
ping) debe usar la API del sistema operativo para obtener la lista de registros de información de direcciones.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.
fuente
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".
fuente