1

Я пытаюсь настроить winbind при установке Debian в качестве запасного варианта, когда наш DNS-сервер не работает. Я должен использовать winbind (вместо альтернатив, таких как mDNS/Avahi), так как я должен использовать метод, который будет работать с нашей существующей настройкой сервера.

Установка Debian состоит из:

  • Debian сжимает гостя в Virtualbox (4.1.18)
  • ОС Windows XP с сетью NAT
  • Гостевой IP-адрес Debian 10.0.2.15
  • Используется для Subversion/Bugzilla с аутентификацией LDAP на контроллере домена

Хост-компьютер Windows имеет IP-адрес 192.168.1.25.

Наш контроллер домена Windows - это Server 2011 Essentials, и у меня нет доступа, чтобы исправить все, что с ним случилось, поэтому я могу только искать обходной путь (используя winbind), пока он не будет отсортирован. IP-адрес этого 192.168.1.1.

Я установил winbind, libnss_winbind и libpam_winbind при установке Debian. Я изменил мою строку hosts в /etc/nsswitch.conf на hosts: files dns wins . Если я использую nmblookup servername я получаю следующий вывод:

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

Кажется, что на сервере есть две NIC, одна имеет частный адрес, а другая - адрес нашей внутренней сети (адрес 192 ...). Я проверил, что представляет собой вывод, посмотрев на другой компьютер, где я могу проверить адреса всех сетевых карт.

Моя проблема в том, что если я использую что-то вроде ping то он использует первый сообщаемый адрес (частный 169 ... адрес), который недоступен. То же самое относится к любому другому сетевому коду, например, когда apache выполняет аутентификацию LDAP для Subversion или BugZilla.

Есть ли способ настроить значения, которые возвращает winbind, или заставить его выполнить проверку состояния, чтобы увидеть, доступен ли IP-адрес, прежде чем возвращать его? Я не нашел ничего в документации по winbind или в Интернете.

Редактировать:route -n сообщает следующее:

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

Содержимое моего /etc/network/interfaces выглядит следующим образом, но в настоящее время я не уверен, что он имеет отношение к настройке подсети или маршрутизации (то есть не похоже, что там что-то есть):

auto lo
iface lo inet loopback

allow-hotplug eth0
iface eth0 inet dhcp

Вот таблица маршрутизации от хоста:

===========================================================================
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

Вот результат ручного пингования IP-адресов по сети. Мой вывод traceroute показывает только конечный пункт назначения (если я использую опцию -I ) или все звездочки. Таким образом, пункт назначения должен быть доступен с помощью приведенной выше таблицы маршрутизации на хосте. Я предполагаю, что диапазоны гостевых адресов VirtualBox не отображаются, поскольку они управляются самим приложением VirtualBox и не отображаются на хосте. Я обнаружил, что 10.0.2.2 является шлюзом VirtualBox в сети NAT. 192.168.56.1 - это IP-адрес хоста 

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

И VirtualBox определенно использует NAT (так как шлюз NAT доступен в журнале выше) и не использует сеть только хоста. Адаптер Host Only в моей таблице маршрутизации хоста представлял собой красную сельдь, так как я его отключил и могу пинговать, как указано выше. Также см. Скриншот ниже, который показывает настройки гостевой сети VirtualBox: Настройки гостевой сети VirtualBox , Если нет какой-либо ошибки, которая мешает ему правильно использовать мою конфигурацию. Соответствующий раздел конфига:

  <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>
|источник

3 ответа3

1

Прежде всего я хотел бы заявить, что вы ищете проблему не в том месте.

  • Все протоколы, включая многоадресную DNS и winbind, должны безопасно возвращать все доступные адреса.
  • Тогда ваше приложение (включая ping) должно использовать API операционной системы для получения списка записей информации об адресе.
  • Наконец, ваше приложение должно проверять информационные записи одну за другой до тех пор, пока оно не соединится успешно (ping может оказаться неподходящим средством тестирования).

Хитрость в том, что даже если winbind (или любой другой плагин) возвращает список, содержащий несколько адресов, все они должны быть действительными адресами, с которыми вы можете связаться. В противном случае возникает проблема либо на сервере, либо в конфигурации сети. Но даже тогда, когда приложение пытается подключиться, оно должно быть отклонено с недоступным целевым хостом и должно немедленно попробовать следующий элемент в списке.

Даже если вышеприведенное не применимо и вы не можете исправить ни сервер, ни конфигурацию сети, ни локальное приложение, вы не потерялись. API разрешения имен операционных систем ( функция getaddrinfo() ) упорядочивает список в соответствии с некоторыми критериями. И вы можете повлиять на эти критерии, отредактировав /etc/gai.conf который был введен в основном для настройки баланса между адресами IPv4 и различными типами адресов IPv6. Таким образом, в то время как ваш плагин winbind nsswitch возвращает несколько адресов, именно вы решаете, какой из них предпочтительнее.

Как указано в других ответах, адресное пространство 169.254/16 зарезервировано для локальных адресов IPv4. Операционные системы обычно не имеют очень хорошей поддержки локальных адресов IPv4 (в отличие от локальных адресов IPv6, которые имеют гораздо лучшую поддержку). Обычный способ состоит в том, чтобы вообще избегать локальных адресов IPv4 для хостов, имеющих правильный адрес IPv4.

Если ничего из вышеперечисленного невозможно, было бы неплохо удалить IPv4-адреса с помощью /etc/gai.conf в ваших установках и, возможно, даже по умолчанию в дистрибутивах Linux.

Кроме того, поскольку ваша локальная система, вероятно, не имеет адреса из подсети 169.254/16 , ваша библиотека распознавателя должна быть в состоянии удалить такой адрес из результата, поскольку он недоступен. Возможно, стоит подумать о начале обсуждения с сопровождающими дистрибутива.

Другое решение состоит в том, чтобы хранить ваши winbind- машины в одном сегменте Ethernet, где локальные IPv4-адреса работают должным образом . Вам придется использовать сетевой мост вместо NAT для вашей виртуализации.

|источник
1

Сеть 169.254.0.0 в Debian является сетью с нулевой конфигурацией. Это описано в Википедии как:

Сеть с нулевой конфигурацией позволяет начинающим пользователям подключать сетевые устройства без какой-либо (нулевой) конфигурации, она используется, когда в сети нет доступных серверов DHCP и DNS.

Zeroconf обеспечивает:

Автоматическое назначение сетевого адреса (link-local). Автоматическое разрешение имен хостов через многоадресный DNS. Автоматическое обнаружение сетевых служб (т. Е. Печать) после автоматического обнаружения DNS-серверов.

Его можно безопасно отключить на виртуальной машине. Для этого вы измените файл /etc /default /avahi-daemon так, чтобы он содержал следующую строку:

AVAHI_DAEMON_DETECT_LOCAL=0

Когда вы сделаете это (и после перезапуска службы avahi-daemon) сервер 169 ... исчезнет.

РЕДАКТИРОВАТЬ: В любом случае, если вы хотите проверить подключение, этот небольшой скрипт будет делать:

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

Это автоматически вернет IP вашего шлюза

|источник
0

Из любопытства, что ваш маршрут показывает как маршрут по умолчанию? Что-то вроде: route -n покажет вам маршрут по умолчанию в вашей системе.

Мне любопытно, если по какой-то странной причине подсеть 169.254.0.0/16 где-то установлена как шлюз по умолчанию. Возможно, в конфигурации вашей сети или /etc /network /interfaces, у вас есть подсеть, сеть и, возможно, настройки маршрутов для вашего интерфейса "по умолчанию".

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .