Проблема DNS с отказоустойчивым IP от Hetzner

Предположим, у нас есть два сервера A и B с "реальными" и внешними IP-адресами, и мы можем переключить так называемый "отказоустойчивый IP- адрес " (WXYZ) для указания на конкретный внешний IP-адрес A или B. Это работает "извне" и было легко сделать В качестве фона: ip отработки отказа настроен как новая запись в /etc/network/interfaces:

auto eth0:0  
iface eth0:0 inet static
  address W.X.Y.Z
  netmask 255.255.255.224

Теперь давайте предположим, что WXYZ настроен динамически для использования аппаратного обеспечения A. Теперь я вызываю curl domain.com из B, и он использует правильный аварийный переходный IP-адрес WXYZ, но затем разрешает каким-то образом неверный внешний IP B (или localhost?) Вместо использования настроенный A:

Trying W.X.Y.Z ...
* connect to W.X.Y.Z port 443 failed: Connection refused
* Failed to connect to domain.com port 443: Connection refused
* Closing connection 0
curl: (7) Failed to connect to domain.com port 443: Connection refused

Когда я запускаю локальный nginx, он может успешно свернуть domain.com

Нужно ли как-то настраивать DNS локально? Как я могу узнать больше о цепочке DNS?

Использование mtr просто печатает domain.com, если это делается с сервера B

Это связано с этим вопросом?

The failover IP is W.X.Y.Z and is also the A record of domain.com

The /etc/hosts file for both nodes serverA and serverB looks like:

    127.0.0.1       localhost
    127.0.1.1       luminarhost            
    xxx    serverA
    xxx    serverB        

The /etc/network/interfaces of serverA

    ### Hetzner Online AG - installimage
    # Loopback device:
    auto lo
    iface lo inet loopback

    # device: eth0
    auto  eth0
    iface eth0 inet static
      address   xxx
      broadcast xxx
      netmask   xxx
      gateway   xxx
      # default route to access subnet
      up route add -net xxx netmask 255.255.255.224 gw xxx eth0

    iface eth0 inet6 static
      address xxx
      netmask xxx
      gateway xxx

    # failover ip
    auto eth0:0
    iface eth0:0 inet static
      address W.X.Y.Z
      netmask 255.255.255.224

and of serverB it is:

    ### Hetzner Online AG - installimage
    # Loopback device:
    auto lo
    iface lo inet loopback

    # device: eth0
    auto  eth0
    iface eth0 inet static
      address   xxx
      broadcast xxx
      netmask   xxx
      gateway   xxx
      # default route to access subnet
      up route add -net xxx netmask 255.255.255.192 gw xxx eth0

    iface eth0 inet6 static
      address xxx
      netmask xxx
      gateway xxx

    # failover ip
    auto eth0:0
    iface eth0:0 inet static
      address W.X.Y.Z
      netmask 255.255.255.224
Источник

2 ответа

Решение

  • Как и обещал, вот мой ответ:

  • Полное раскрытие: я не работаю на Hetzner, но работал в разных компаниях в прошлом и настоящем, которые раньше размещали оборудование в Hetzner.

  • Если местоположение внутри вашего профиля правильное и вам нужна поддержка: я живу в одном городе и могу предложить одну или две руки.

  • Для всех людей, которые никогда не имели дела с Гетцнером: они фильтруют доступ к сети и т. Д., Что означает, особенно в отношении их отказоустойчивых IP-адресов (IP-адреса, которые можно использовать на разных машинах для обеспечения некоторой высокой доступности), что они отправляют трафик направлен на конкретный IP для конкретного MAC.

  • Если кто-то хочет изменить цель (машину), на которую направлен трафик, нужно отправить POST запрос к API, который подается через HTTPS, Затем API проверяет подлинность (которая представляет собой имя пользователя и соответствующий пароль) и запрос, и, если он действителен, распространяет эту новую конфигурацию на различные маршрутизаторы в сети. Этот метод похож на тот, который используется OVH, крупным поставщиком во Франции.

  • Предостережение: хотя люди используют эти IP-адреса для обеспечения некоторой высокой доступности (как написано) для своих машин / служб, распространение новой конфигурации маршрутизации занимает некоторое время, иногда до ~ 60 секунд. Это означает, например, что при использовании какого-либо автоматического переключения при сбое, если машина, на которую в настоящее время направляется трафик, отключается, на определенное время, что люди заметят, трафик просто сбрасывается, потому что машина не работает, вплоть до момента, когда новый конфигурационный маршрут будет на месте.
  • Что касается введения, давайте посмотрим на вашу конкретную проблему:
  • Как указано в комментариях / чате, используя auto eth0:0, настроит ваш отказоустойчивый IP на интерфейсе eth0:0, как только сеть запускается, обычно во время загрузки. У вас есть две машины с одинаковой конфигурацией, поэтому это приводит к тому, что один и тот же IP-адрес активен на двух разных машинах (что не является запретом, но приводит к ситуации, с которой вы сейчас сталкиваетесь).). Просто примечание: используемый вами синтаксис, многократно именующий один и тот же интерфейс, устарел (но все еще работает). "Новый путь" также описан в вики Debian (эта ссылка), которая просто назначает несколько IP-адресов одному интерфейсу.
  • Итак: вы получили IP-адрес, назначенный локально обеим машинам одновременно. curl в вашем тестовом примере выполняется следующее: он разрешает указанное доменное имя в IP, а затем пытается подключиться к этому IP на порту 443. Поскольку этот IP в любом случае назначается локально и, следовательно, достижим, пакеты никогда не отправляются на сеть. Если nginx (как в вашем тестовом примере) в данный момент не работает локально, вы просто получаете отказ в соединении, что совершенно нормально и допустимо: "IP-адрес локальный, поэтому давайте отправим трафик туда". Он никогда не отправит пакеты на какой-либо маршрутизатор, который может иметь информацию: "Трафик, направленный на этот IP, должен идти на эту машину".
  • Теперь... на самом деле я не совсем уверен, что вы после. Вы только хотите понять, что происходит? Если так, я попытался описать это. Вы хотите найти / реализовать способ, который "решает" эту ситуацию? Если позже, вот некоторые мысли:
  • Решение 1: Удалить директиву auto eth0:0 (но оставьте остальную часть конфигурации eth0:0 на месте) от /etc/network/interfaces, Делая это, не будет назначать IP для машины. Это будет ваша задача (задача скрипта), которая делает ifup eth0:0 (и, может быть, снова говорит API, чтобы гарантировать, что трафик направляется на правильный компьютер).
  • Решение 2, также известное как "автоматизировать все": не выполнять аварийное переключение вручную, а внедрить систему, которая делает это автоматически, с помощью тактовых импульсов (для проверки работоспособности) между двумя компьютерами: для этого существует несколько решений, например, виртуальный маршрутизатор Протокол резервирования и (полное раскрытие: мой личный фаворит, я использую это уже много лет в производстве для подобных задач): corosync и стимулятор, который является стандартом де-факто для настройки кластеров, обеспечивающих высокую доступность в Linux. (Также взгляните на это.) Если вы хотите опробовать более поздний способ, несколько лет назад замечательные ребята из Kumina разработали (и опубликовали) ресурсного агента для точного разрешения этой ситуации в Hetzner. Агент ресурса заботится об обновлении информации о маршрутизации через обращение к API.
  • Чтобы закончить (пока): я не совсем уверен, что вы после. Я попытался описать причину проблемы, с которой вы столкнулись прямо сейчас. Кроме того, я попытался представить некоторые мысли для возможных решений. В случае, если я не понял, что вы пытаетесь сделать, есть вещи, которые остаются неясными, или у вас есть дополнительные вопросы: Пожалуйста, оставьте отзыв, я рад помочь (или, по крайней мере, попытаться).
  • (Кроме того: не могли бы вы перенести свои конфиги и т. Д. В свой пост, чтобы хранить все вещи в одном месте, чтобы этот вопрос мог помочь в будущем другим людям?)
Источник

Мы столкнулись с точно такой же проблемой самоконтроля, как упомянутое @gf_.

Следующая библиотека работала без нареканий, чтобы добиться того же.

https://github.com/mrkamel/heartbeat

Вы можете добавить и удалить плавающий IP-адрес для удаленного узла, используя функцию hooks / after и hooks / before из вышеуказанной библиотеки.

Пример перехватывает / before / sendmail скрипт, который отправляет слабое уведомление и добавляет плавающий ip к машине, на которую он переключается.

#!/bin/sh

echo " Switching to failover ip $1 from $2 to $3" | slacktee.sh  

ssh -o StrictHostKeyChecking=no $3 'ip addr add '"$1"'/32 dev `route | grep "^default" | grep -o "[^ ]*$"`'

Пример перехватывает / после / sendmail скрипт, который отправляет слабое уведомление и удаляет плавающий ip, с которого он удалился

#!/bin/sh

ssh -o StrictHostKeyChecking=no $2 'ip addr del '"$1"'/32 dev `route | grep "^default" | grep -o "[^ ]*$"`'

echo " Switch success for failover ip $1 from $2 to $3"| slacktee.sh

Замечания:
1. Машина, на которой вы запускаете пульс, и машины, которым назначены плавающие IP-адреса, должны сначала иметь пароль без входа в систему с помощью обмена ключами ssh (проверьте совместное использование id_rsa).
2. Библиотека slacktee.sh используется для простой отправки слабых уведомлений.

Источник
Другие вопросы по тегам