Ubuntu 16.04, Keepalived VMAC

Я ' m пытается создать два избыточных балансировщика нагрузки с прямым выходом (с использованием IPVS или NGINX), но сначала я пытаюсь заставить плавающий виртуальный IP-адрес VRRP / mac работать должным образом, прежде чем двигаться дальше по процессу.

I у меня есть стандартная виртуальная машина Ubuntu 16.04 на VMware vSphere 6 с последними обновлениями. ВМ находится в группе портов DvSwitch с включенным неразборчивым режимом, изменением MAC-адреса и поддельной передачей. Виртуальная машина использует VMXNET3 для сетевой карты. Я использую стандартную поддержку активности в репозитории.

keepalived/xenial-updates,now 1:1.2.19-1ubuntu0.1 amd64 [installed]

Я пытаюсь использовать следующую конфигурацию для поддержки активности ...

root@lb1:~# cat /etc/keepalived/keepalived.conf
vrrp_instance VI_1 {
    state MASTER
    interface ens192
    virtual_router_id 150
    priority 150
    use_vmac vrrp150
        vmac_xmit_base
    advert_int 1
    virtual_ipaddress {
        10.0.4.55
    }
}

При первоначальной настройке на эхо-запросы к интерфейсу macvlan (vrrp150) ARP отвечает MAC родительского интерфейса (что плохо по нескольким причинам). Я попытался использовать множество различных комбинаций настроек net.ipv4.conf, выложенных в Интернете, все они, похоже, полностью нарушают ARP для интерфейса macvlan. Насколько мне известно, iptables и ufw полностью отключены, а tcpdump показывает следующее ...

root@lb1:~# tcpdump -s0 -i vrrp150
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on vrrp150, link-type EN10MB (Ethernet), capture size 262144 bytes
10:05:19.271979 ARP, Request who-has 10.0.4.55 tell 10.0.4.31, length 46
10:05:20.215301 ARP, Request who-has 10.0.4.55 tell 10.0.4.31, length 46
10:05:21.215474 ARP, Request who-has 10.0.4.55 tell 10.0.4.31, length 46
10:05:22.219300 ARP, Request who-has 10.0.4.55 tell 10.0.4.31, length 46
10:05:23.215514 ARP, Request who-has 10.0.4.55 tell 10.0.4.31, length 46
10:05:24.223971 ARP, Request who-has 10.0.4.55 tell 10.0.4.31, length 46
10:05:25.224262 ARP, Request who-has 10.0.4.55 tell 10.0.4.31, length 46

Итак, запросы ARP действительно попадают в правильный интерфейс. Я попытался использовать неразборчивый режим на физическом интерфейсе, но это не имеет значения (и запросы ARP попадают туда независимо).

Как я могу заставить виртуальный интерфейс macvlan keepalived правильно отвечать на ARP с виртуальным MAC-адресом чтоб трафик можно было перенаправить? Я пытаюсь получить такую ​​же комбинацию виртуального IP / MAC для MASTER> РЕЗЕРВНОЕ КОПИРОВАНИЕ во время переходов, чтобы на таблицы ARP не воздействовали никакие брандмауэры восходящего направления (GARP не является надежным / не соблюдается, и переключение при отказе должно быть быстрым и максимально плавным).

0
задан 11 January 2017 в 18:35
1 ответ

Mi-am rezolvat propria problemă ... pentru curioși, iată suflarea cu suflarea.

Mai întâi, asigurați-vă că vă verificați cu atenție sistemele, deoarece Ubuntu are unele activate de către implicit nu v-ați aștepta să fie activat în mod implicit, și anume verificări RP.

sysctl -a | grep net.ipv4.conf.*

S-ar putea să fiți surprins de ceea ce găsiți aici.

Pe Ubuntu 16.04, setați următoarele în /etc/sysctl.conf ...

net.ipv4.conf.all.arp_ignore = 1
net.ipv4.conf.all.arp_announce = 2
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.ens192.rp_filter = 0
net.ipv4.conf.vrrp150.rp_filter = 0

Datorită setărilor implicite RP în sysctl, va trebui să o faceți la nivelul „all”, precum și la fiecare interfață (așa cum se arată aici).

Efectuați următoarele pentru a o activa live (sau doar pentru a reporni)

sysctl -p

Al doilea lucru este să vă asigurați că setările DvSwitch sunt corecte (din nou, ca mai sus, grupul de porturi trebuie să aibă un mod promiscu, schimbarea adresei Mac și transmisiile falsificate activate). Nu trebuie să fie același grup de porturi ca și restul VM-urilor, chiar dacă VLAN-ul în care locuiesc este același. Acest lucru vă ajută să păstrați securitate maximă pe celelalte VM-uri, expunând în același timp doar trafic suplimentar VM-urilor care au absolut nevoie de el.

Dacă se află pe aceeași gazdă, chiar dacă sunt în grupuri de porturi VM diferite pe DvSwitch, trafic va fi activat local pe vSwitch în cadrul gazdei, fără a ieși niciodată dintr-un port de legătură în sus.

Pentru cei cu adevărat paranoici, puteți învârti un DvSwitch complet diferit cu legături în sus diferite (dacă aveți multe de ars) și un VLAN separat pentru acestea (tăiat pe comutatorul fizic). Acest lucru asigură faptul că acestea sunt complet containerizate și nu vor vedea alt trafic decât traficul pe care urmează să îl vadă.

Dacă utilizați difuzarea implicită cu keepalived și aveți mai multe porturi de legătură în sus pe DvSwitch la care sunt atribuiți (ceea ce este cea mai bună practică) , asigurați-vă că setați ...

Advanced Settings > Net > Net.ReversePathFwdCheckPromisc to 1 on each host

pentru a preveni traficul cu difuzare multiplă înapoi la gazdă (similar cu https://doc.pfsense.org/index.php/CARP_Configuration_Troubleshooting ).

poate fi omis dacă utilizați unicast_peer în configurația dvs. păstrată.

2
ответ дан 4 December 2019 в 13:36

Теги

Похожие вопросы