Имеется вот такой «сетап»

• Картинка
• Draw.io

Вводные данные:

• Failover IP - IP который может быть переключен на любой из серверов, Хецнер маршрутизирует трафик до главного IP нужного сервера, дальше сам сервер должен маршрутизировать трафик до ВМ. Сами сервера «не знают» направлен на них Failover IP или нет. Можно делать запрос к API и узнавать, но у API лимит 100 запросов в час, особо не разгонишься.
• 3 KVM гипервизора, на 2-х имеются ВМ которые используют Failover IP.
• Failover IP подключен на KVM Host 1
• Настройка vmbr2 на хосте

  auto vmbr2
  iface vmbr2 inet manual
    bridge_ports none
    bridge_stp off
    bridge_fd 0
  

• Настройка интерфейса и маршрутов на ВМ

  2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
      link/ether 86:47:47:fb:a7:ff brd ff:ff:ff:ff:ff:ff
      inet 46.4.100.100 peer 88.99.99.100/32 scope global ens18
         valid_lft forever preferred_lft forever
  
  # ip route show
  default via 172.21.3.1 dev ens19
  88.99.99.100 dev ens18 proto kernel scope link src 46.4.100.100
  
  # ip rule sh
  0:      from all lookup local
  32765:  from 46.4.100.100 lookup 10
  32766:  from all lookup main
  32767:  from all lookup default
  
  # ip route show table 10
  default via 88.99.99.100 dev ens18
  

Задача в том, чтоб внешние клиенты и все ВМ размещенные на гипервизорах могли получать доступ обращаясь к ресурсам которые расположены на Failover IP.

Простейший вариант, чтоб трафик проходил до ВМ, на каждом гиервизоре прописываю маршрут

ip route add 46.4.100.100/32 dev vmbr2

Альтренативный вариант с использованием policy based routing, дающий немного лучший результат

ip route add 46.4.100.100/32 dev vmbr2 table 11
ip rule add to 46.4.100.100 table 11
ip rule add to 46.4.100.100 iif vmbr1 table main

# ip rule sh
0:      from all lookup local
32763:  from all to 46.4.100.100 iif vmbr1 lookup main
32764:  from all to 46.4.100.100 lookup 11
32765:  from all lookup main
32766:  from all lookup default

Можно ли вообще данную задачу решить средствами статической маршрутизации или необходима динамическая маршрутизация?

Приветствую.
Имеется следующий конфиг: несколько серверов, объединенных в «локальную сеть» путем соединения каждого с каждым используя GRE туннели (vpntapX), зашифрованные с помощью IPSec, на каждом сервере туннели объединены в мост (vpnbr0), таким образом все сервера как будто включены в один коммутатор. Если у кого-то есть лучший вариант реализации full-mesh сети поверх интернет - с радостью выслушаю, но текущее решение работало прилично до настоящего момент когда понадобилось добавить 4-й сервер.
Каждый сервер отвечает за свою подсеть в которой «живут» виртуалки, для маршрутизации используется Quagga (OSPF, Zebra) 3 старых сервера на Debian 7 работают нормально, OSPF корректно ходит по туннелям, а вот с новым на Debian 8 проблема, мультикаст нормально проходит через туннели, а OSPF Hello - нет.

( Разнообразная информации о системах: )

Приветствую. Что имеем
3 машины для тестирования, на них следующий конфиг сети, последний октет меняется от 1 до 3:

auto eth1
iface eth1 inet static
  address 192.168.100.1
  netmask 255.255.255.0

auto gre1
iface gre1 inet static
  pre-up ip tunnel add $IFACE mode gre ttl 64 tos inherit key 1001 || true
  address 10.42.43.1
  netmask 255.255.255.0
  post-up ip link set $IFACE multicast on || true
  post-up ip link set $IFACE mtu 1420 || true
  post-down ip tunnel del $IFACE || true
  post-up ip neigh add 10.42.43.2 lladdr 192.168.100.2 dev gre1
  post-up ip neigh add 10.42.43.3 lladdr 192.168.100.3 dev gre1
  post-up  ip route add 224.0.0.0/4 dev $IFACE
  pre-down ip route del 224.0.0.0/4 dev $IFACE

Но проще это представить в виде команд ip

ip tunnel add gre1 mode gre ttl 64 tos inherit key 1001
ip link set dev gre1 up
ip link set dev gre1 multicast on
ip link set dev gre1 mtu 1420
ip addr add 10.42.43.1/24 broadcast 10.42.43.255 dev gre1

ip neigh add 10.42.43.2 lladdr 192.168.100.2 dev gre1
ip neigh add 10.42.43.3 lladdr 192.168.100.3 dev gre1

ip a s gre1
7: gre1@NONE: <MULTICAST,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default
    link/gre 0.0.0.0 brd 0.0.0.0
    inet 10.42.43.1/24 brd 10.42.43.255 scope global gre1
       valid_lft forever preferred_lft forever

ip neigh show dev gre1
10.42.43.3 lladdr 192.168.100.3 PERMANENT
10.42.43.2 lladdr 192.168.100.2 PERMANENT

Проверим что пакеты ходят в принципе

ping 10.42.43.2
PING 10.42.43.2 (10.42.43.2) 56(84) bytes of data.
64 bytes from 10.42.43.2: icmp_seq=1 ttl=64 time=0.818 ms

ping 10.42.43.3
PING 10.42.43.3 (10.42.43.3) 56(84) bytes of data.
64 bytes from 10.42.43.3: icmp_seq=1 ttl=64 time=0.361 ms

Проверяем мультикаст с помощь ssmping, на 10.42.43.2-3 запускаем ssmpingd, c 10.42.43.1 пингуем:

ssmping 10.42.43.2
ssmping joined (S,G) = (10.42.43.2,232.43.211.234)
pinging S from 10.42.43.1
  unicast from 10.42.43.2, seq=1 dist=0 time=1.289 ms
  unicast from 10.42.43.2, seq=2 dist=0 time=1.017 ms

ssmping 10.42.43.3
ssmping joined (S,G) = (10.42.43.3,232.43.211.234)
pinging S from 10.42.43.1
  unicast from 10.42.43.3, seq=1 dist=0 time=0.680 ms
  unicast from 10.42.43.3, seq=2 dist=0 time=0.763 ms

Для пробы делаем так ip route replace 224.0.0.0/4 dev eth1 на каждом хосте. Запускаем ssmpingd, проверям:

ssmping 192.168.100.2 -c 1
ssmping joined (S,G) = (192.168.100.2,232.43.211.234)
pinging S from 192.168.100.1
  unicast from 192.168.100.2, seq=1 dist=0 time=0.548 ms
multicast from 192.168.100.2, seq=1 dist=0 time=0.556 ms

ssmping 192.168.100.3 -c 1
ssmping joined (S,G) = (192.168.100.3,232.43.211.234)
pinging S from 192.168.100.1
  unicast from 192.168.100.3, seq=1 dist=0 time=0.549 ms
multicast from 192.168.100.3, seq=1 dist=0 time=0.557 ms

Проблема
Суть отражена в заголовке. Если настроить обычные p2p GRE тоннели с явным указанием конечных точек подключения - то мультикаст отлично в таком тоннеле ходит. Минус обычных тоннелей в тоннах конфигов на каждой машине, и кроме того если соединить хотя бы 3 машины в сеть «каждый с каждым», то правила вроде ip route add 224.0.0.0/4 dev gre1 уже недостаточно нам ведь надо отправлять мультикаст во все туннели. На данный момент я даже не представляю как это реализуется, но это тема отдельного вопроса.

Всех приветствую. Имеем следующее

Хост А

• туннель gre1 172.20.128.1/30
• бридж vmbr0 11.11.11.1/26
• бридж vmbr1 172.21.1.0/24
• dummy0 172.20.252.1/32

Хост Б

• туннель gre1 172.20.128.2/30
• бридж vmbr0 22.22.22.2/24
• бридж vmbr1 172.21.2.0/24
• dummy0 172.20.252.2/32

Связь между ними через туннель gre1, маршрутизация с использованием OSPF все интерфейсы пингуются в обе стороны. Общая сеть которая покрывает весь диапазон 172.20.0.0/15. Хостов будет больше поэтому общая сеть выделенная под бриджи vmbr1 172.21.0.0/16 и на каждом хосте от нее берется /24 подсеть. Бридж vmbr0 «смотрит» в интернет и через него ВМ могут получать публичные IP. В бридже vmbr1 «живут» виртуалки, которым нужно «видеть» соседние ВМ и ВМ на другом хосте. Адреса на vmbr1 раздаются по DHCP и регистрируются в DNS.

• Сценарий 1 В ВМ один сетевой интерфейс прикрепленный к vmbr0 - все хорошо, весь трафик идет в интернет через маршрут по-умолчанию.
• Сценарий 2 В ВМ один сетевой интерфейс прикрепленный к vmbr1 - все хорошо, весь трафик идет в через основной хост по маршруту по-умолчанию.
• Сценарий 3 В ВМ два интерфейса, одни на vmbr0 второй на vmbr1, т.е. хотим ходить в интернет прямиком, но при этом еще видеть все другие ВМ в локальнйо сети на 2-м интерфейсе и вот тут начинаются сложности. Маршрут по-умолчанию смотрит в интернет понятное дело, а далее варианты:
  • На втором интерфейсе настроим IP 172.21.1.2 маска /24 в таком случае виртуалка будет «видеть» лишь свой хост и своих соседей. Для того чтоб виртуалка «видела» машины на других хостах, надо настроить на ней маршруты, как вариант видится передача маршрутов через DHCP опцию 129/249 (linux/win) или используя динамическую маршрутизацию (минус - настраивать quagga на каждом хосте с 2-мя интерфейсами) этот вариант я еще не опробовал толком.
  • На втором интерфейсе настраиваем 172.21.1.2 и маску /15 таким образом охватываем всю сеть, на хосте включаем proxy_arp на интерфейсе vmbr1, после этого с виртуалки пингуются все доступные хосту адреса, т.е. все что надо, этот вариант уже проверил все работает.
  • Какой-то еще вариант настройки о котором я не подумал / не знаю

С proxy arp выходит нужно меньшее количество телодвижений, и все уже работает «автомагически», но с другой стороны proxy arp такая штука которая потенциально может скрывать ошибки в настройке сети, с маршрутизацией еще надо повозиться будет, наверное есть и другие варианты.

Посоветуйте на каком варианте остановиться и почему. Любая информация как это лучше сделать очень приветствуется. Спасибо всем кто дочитал )

Внезапно возникла проблема, при перезапуске nginx выдал ошибку

Starting nginx: nginxnginx: invalid option: "^~"

nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

В конфиге целая куча строк с «^~», что-то не приходит ничего в голову как разобраться что конкретно ему «не нравиться»?

Советы, рекомендации?

Есть, вроде бы, не хитрая задача, перенести несколько десятков почтовых ящиков с одного сервера (sendamil + dovecot), назовем его «старый сервер» на другой сервер (Zimbra 8), назовем его «новый сервер».

Перенести все ящики одномоментно не представляется возможным, поэтому необходимо добиться такой конфигурации, когда функционируют оба сервера. С настройкой Zimbra проблемы нет, там легко можно настроить так, чтоб почта для тех учетных записей которые присутствуют на Zimbra сервере принималась им же, а для тех которые на Zimbra сервере отсутствуют пересылалсь на другой сервер. Или же как вариант для любой учетной записи можно индивидуально указать сервер для доставки. Т.е. можно создать такие же учетные записи как и на старом сервере и включить для них переадресацию на старый, а затем по одному уже переносить их на новый.

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

Суть проблемы - sendmail, у меня не выходит настроить его так, что бы почта для определенного домена отправлялась через внешний сервер, но при этом продолжали приниматься входящие сообщения для этого домена. Если убрать домен из «local-host-names» - то сервер прекращает принимать почту для домена, а если домен присутствует в «local-host-names» то игнорируются записи из «mailertable» которые указывают отправлять почту для домена через внешний сервер.

В итоге вкратце вопросы в следующем, как для sendmail настроить:
1) Отправку всей почты для определенного домена через внешний сервер, с сохранением возможности получать входящие письма для этого домена.
либо
2) Пересылку почты на новый сервер индивидуально для каждой учетной записи.

Столкнулся с непонятным для меня случаем маршрутизации, подскажите пожалуйста как и что настроить в нижеприведенной ситуации, какими средствами воспользоваться.

Имеем следующую картину:

┌─────────────────────┐
│ канальный провайдер │
│ xxx.xxx.xx6.12      │
└─────────┬───────────┘
          │
          │
          │       ┌───────────────┐
          v       │ Asus  WL700GE │
┌─────────────────┴────┬────┬─────┴─────────────────┐
│ местный провайдер    │    │ LAN                   │
│ IP xxx.xxx.xx6.13    │    │ IP xxx.xxx.xx5.32     │
│ MASK 255.255.255.254 │NAT │ MASK 255.255.255.240  │
│ GW xxx.xxx.xx6.12    │    │                       │
├──────────────────────┴────┴───────────────────────┤
│   так выглядят текущие настройки маршрутизатора   │
└─────────────────────────────────────┬─────────────┘
                                      │
                                      │
                                      v
                             ┌──────────────────────┐
                             │ Мой хост (конфиг     │
                             │ продиктован местным  │
                             │ провайдером)         │
                             │                      │
                             │ IP xxx.xxx.xx5.39    │
                             │ MASK 255.255.255.240 │
                             │ GW xxx.xxx.x6.13     │
                             └──────────────────────┘

Провайдер выдал такие данные:
IP xxx.xxx.xx6.13
MASK 255.255.255.254
GW xxx.xxx.xx6.12

«Дополнительные адреса» (что бы это ни значило) которые выдал канальный провайдер
IP xxx.xxx.xx5.32
MASK 255.255.255.240

Т.е. мне по сути надо подсобить местному провайдеру с настройками чтоб получить у себя полноценный прямой IP, а не «как бы прямой IP» за NAT-ом

Из того что я нашел по этой теме мне видимо нужно настроить псевдо-мост с Proxy ARP, но на 100% я не уверен, возможно есть другие средства. Так же ситуация осложняется тем что местный администратор не хочет расставаться с Asus WL700GE и поставить Linux/FreeBSD в чистом виде, максимум он согласен на что либо конфигурируемое через Web-интерфейс вроде pfSense или ClearOS.

Подскажите пожалуйста направление движения.

Проблема следующая, Debian Etch установленный в минимальной конфигурации не загружается без подключенного монитора.

Загрузка останавливается на моменте

Booting "Debian GNU/Linux... "
root (hd0,0)
kernel /boot/vmlinuz-2.6.18 ...
...
initrd /boot/initrd.img-2.6.18 ...
...
savedefault

Если же монитор подключен то далее идет

Uncompressing Linux ...

Если подключить монитор к уже подвисшей системе - то видим «Booting Debian GNU/Linux...» и практически всегда в течении минуты загрузка продолжается. Пробовал отключать acpi apic apm крутил настройки в БИОСе, все бесполезно, без монитора дальше вышеуказанного места загрузка не идет.

Уже не знаю даже в какую сторону рыть, подскажите пожалуйста если у кого-нибудь есть какие идеи.