Resolução de nomes Debian winbind dando múltiplos endereços - como selecionar um?

Question

Estou tentando configurar o winbind em uma instalação Debian como alternativa para quando o nosso servidor DNS não funciona. Eu tenho que usar winbind (em vez de uma alternativa como mDNS / Avahi) desde que eu tenho que usar um método que irá trabalhar com a nossa configuração de servidor existente.

A instalação Debian consiste em:

• Convidado do Debian squeeze no Virtualbox (4.1.18)
• SO host do Windows XP com rede NAT
• Endereço IP do convidado Debian 10.0.2.15
• Usado para o Subversion / Bugzilla com autenticação LDAP para o controlador de domínio

A máquina host do Windows possui o endereço IP 192.168.1.25.

Nosso controlador de domínio do Windows é o Server 2011 Essentials e não tenho acesso para consertar o que quer que esteja com ele, portanto, só posso procurar uma solução alternativa (usando o winbind) até que ele seja classificado. O endereço IP deste é 192.168.1.1.

Eu instalei winbind, libnss_winbind e libpam_winbind na instalação Debian. Alterei minha linha hosts em /etc/nsswitch.conf para hosts: files dns wins . Se eu usar nmblookup servername , recebo a seguinte saída:

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

Parece que existem duas placas de rede no servidor, uma tem um endereço privado e a outra tem um endereço na nossa rede interna (o 192 ... endereço). Eu verifiquei que é o que a saída representa procurando por outro computador, onde posso verificar os endereços de todos os NICs.

Meu problema é que, se eu usar algo como ping , ele usará o primeiro endereço relatado (o endereço particular 169 ...), que não pode ser acessado. O mesmo se aplica a qualquer outro código de rede, como quando o apache executa autenticação LDAP para o Subversion ou o BugZilla.

Existe alguma maneira de configurar os valores retornados pelo winbind ou fazer uma verificação de status para ver se o endereço IP está acessível antes de retorná-lo? Eu não encontrei nada na documentação do winbind ou on-line.

Editar: route -n relata o seguinte:

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

O conteúdo do meu /etc/network/interfaces é o seguinte, mas atualmente não tenho certeza do que isso tem a ver com a configuração de sub-rede ou roteamento (ou seja, não parece que tenha algo lá):

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

Aqui está a tabela de roteamento do 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

Aqui está o resultado do ping manualmente dos endereços IP na rede. Minha saída traceroute mostra apenas o destino final (se eu usar a opção -I ) ou todos os asteriscos. Portanto, o destino deve ser acessível com a tabela de roteamento acima no host. Presumo que os intervalos de endereços de convidados do VirtualBox não apareçam, uma vez que eles são gerenciados pelo próprio aplicativo do VirtualBox e não são expostos ao host. Descobri que 10.0.2.2 é o gateway do VirtualBox dentro da rede NAT. 192.168.56.1 é o endereço IP do 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

E o VirtualBox está definitivamente usando o NAT (já que o gateway NAT está acessível no log acima) e não está usando uma rede somente de host. O Host Only Adapter na minha tabela de roteamento de host era um arenque vermelho, pois eu o desativei e ainda posso executar o ping acima. Veja também o screengrab abaixo que mostra as configurações de rede do convidado do VirtualBox: .Amenosquehajaalgumbugqueimpeçaousodaminhaconfiguraçãocorretamente.Aseçãorelevantedaconfiguração:

<Network><Adapterslot="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>

    

Answer 1

A rede 169.254.0.0 no Debian é a rede de configuração zero. É descrito na Wikipedia como:

Zero configuration networking allow novice users to interconnect network enabled devices without any (zero) configuration, it is used when there is no DHCP and DNS servers available on the network.

Zeroconf provides:

Auto assignment of network address (link-local) Auto resolution of hostnames via multicast DNS Automatic location of network services (i.e. printing) after auto discovering DNS servers.

Ele pode ser desativado com segurança em uma VM. Para fazer isso, você modifica o arquivo / etc / default / avahi-daemon para conter essa linha:

AVAHI_DAEMON_DETECT_LOCAL=0

Quando você faz isso (e depois de reiniciar o serviço avahi-daemon), o servidor 169 ... irá desaparecer.

EDIT: De qualquer forma, se você testar a conectividade, este pequeno script serve:

#!/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

Isso retornará automaticamente o IP do seu gateway

    

Answer 2

Primeiro de tudo, gostaria de declarar que você está procurando o problema no lugar errado.

• Todos os protocolos, incluindo multicast DNS e winbind , devem ser capazes de retornar com segurança todos endereços disponíveis.
• Em seguida, seu aplicativo (incluindo ping ) deve usar a API do sistema operacional para obter a lista de registros de informações de endereço.
• Finalmente, seu aplicativo deve tentar os registros de informações um por um até que ele se conecte com sucesso ( ping pode não ser a ferramenta de teste correta aqui).

O truque é que, mesmo que o winbind (ou qualquer outro plugin) retorne uma lista contendo vários endereços, todos eles devem ser endereços válidos que você possa contatar. Caso contrário, existe um problema no servidor ou na configuração da rede. Mas, mesmo assim, quando o aplicativo tenta se conectar, ele deve ser recusado com host de destino inacessível e deve imediatamente tentar o próximo item na lista.

Mesmo que o acima não se aplique e você não consiga corrigir o servidor nem a configuração de rede nem o aplicativo local, você não estará perdido. A API de resolução de nomes dos sistemas operacionais (a função getaddrinfo() ) reordena a lista de acordo com alguns critérios. E você pode influenciar esse critério editando /etc/gai.conf , que foi introduzido principalmente para configurar um equilíbrio entre os endereços IPv4 e vários tipos de endereços IPv6. Dessa forma, enquanto o seu plugin winbind nsswitch retorna um número de endereços, é você quem tem a palavra final sobre qual deles será o preferido.

Como afirmado em outras respostas, 169.254/16 espaço de endereço é reservado para endereços locais de links IPv4. Os sistemas operacionais geralmente não têm um suporte muito bom para endereços locais de links IPv4 (em oposição aos endereços IPv6 locais de link, que têm suporte muito melhor). A maneira usual é evitar os endereços locais de links IPv4 para hosts que tenham um endereço IPv4 apropriado.

Se nenhuma das opções acima for possível, seria uma boa idéia despriorizar os endereços IPv4 pelo /etc/gai.conf em suas instalações e, provavelmente, até por padrão nas distribuições Linux.

Além disso, como seu sistema local provavelmente não tem um endereço da sub-rede 169.254/16 , sua biblioteca de resolvedor deve ser capaz de remover tal endereço do resultado porque é inacessível . Pode valer a pena considerar começar uma discussão com os mantenedores de distribuição.

Outra solução é manter suas máquinas winbind em um único segmento ethernet, onde os endereços locais de links IPv4 funcionam como esperado. Você teria que usar a ponte de rede em vez de NAT para a sua virtualização.

    

Answer 3

Por curiosidade, como sua rota mostra a rota padrão? Algo como: route -n mostrará a rota padrão no seu sistema.

Estou curioso se, por alguma razão estranha, a sub-rede 169.254.0.0/16 estiver definida como o gateway padrão em algum lugar. Talvez em sua configuração de rede, ou em / etc / network / interfaces, você tenha uma sub-rede, rede e potencialmente rotear a configuração para sua interface "padrão".