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

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

• Полное раскрытие информации: я не работаю на Hetzner, но в прошлом и в настоящее время работал в разных компаниях, которые размещали оборудование в 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, также известное как «автоматизация всего»: не выполняйте переключение вручную, а внедрите систему, которая делает это автоматически с помощью тактов (для проверки работоспособности) между двумя машинами: для этого существует несколько решений, например Протокол резервирования виртуального маршрутизатора и (полное раскрытие: мой личный фаворит, я использую это уже много лет в производстве для таких задач): коросинхронизация и кардиостимулятор, который де-факто является стандартом для создания кластеров, обеспечивающих высокую доступность в Linux. (Также посмотрите этот.) Если вы хотите попробовать более поздний способ, прекрасные люди Кумина разработали (и опубликовали) агент ресурсов несколько лет назад именно для того, чтобы справиться с этой ситуацией в Hetzner. Агент ресурса заботится об обновлении информации о маршрутизации, обращаясь к API.
• Чтобы закончить (пока): я не совсем уверен, что вам нужно. Я попытался описать основную причину проблемы, с которой вы сейчас сталкиваетесь. Кроме того, я попытался высказать некоторые мысли о возможных решениях. На случай, если я не понял, что вы пытаетесь сделать, есть вещи, которые остались неясными или у вас есть дополнительные вопросы: пожалуйста, дайте отзыв, я рад помочь (или, по крайней мере, попытаюсь).
• (Кроме того: не могли бы вы переместить свои конфигурации и т. Д. В свой пост, чтобы сохранить все в одном месте, чтобы этот вопрос мог быть полезен в будущем другим людям?)

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

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

https://github.com/mrkamel/heartbeat

Вы можете добавлять и удалять плавающий IP-адрес удаленного узла с помощью функций hooks / after и hooks / 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. Машина, на которой вы запускаете Heartbeat, и машины, которым назначены плавающие IP-адреса, должны иметь логин без пароля без пароля с использованием обмена ключами ssh в первую очередь (проверьте совместное использование id_rsa).
2. Библиотека slacktee.sh используется для простой отправки Slack-уведомлений.