☰

keepalived 호스트에 대한 경로가 없습니다. 방화벽에 문제가 있습니까?

tag-icon • tag-icon networking firewall load-balancing
keepalived 호스트에 대한 경로가 없습니다. 방화벽에 문제가 있습니까?

나는 간단한 연결 유지 두 서버 구성을 가지고 있습니다. 기본/백업 선택은 제대로 작동하지만 백업 서버에서 VIP에 연결할 수 없습니다. 연결하려고 하면 기본 서버에서 백업 서버의 ARP 요청과 기본 서버의 응답을 볼 수 있지만 백업 서버에서는 요청만 볼 수 있습니다(즉, 기본 서버의 ARP 응답을 볼 수 없습니다).

마스터 컨트롤 keepalived.conf:

vrrp_script haproxy-check {
    script "/usr/bin/pgrep python"
    interval 5
}
 
vrrp_instance haproxy-vip {
    state MASTER
    priority 101
    interface eth0
    virtual_router_id 47
    advert_int 3
 
    unicast_src_ip 192.168.122.4
    unicast_peer {
        192.168.122.9
    }
 
    virtual_ipaddress {
        192.168.122.250
    }
 
    track_script {
        haproxy-check weight 20
    }
}

keepalived.conf를 백업하십시오:

vrrp_script haproxy-check {
    script "/usr/bin/pgrep python"
    interval 5
}

vrrp_instance haproxy-vip {
    state BACKUP
    priority 99
    interface eth0
    virtual_router_id 47
    advert_int 3

    unicast_src_ip 192.168.122.9
    unicast_peer {
        192.168.122.4
    }

    virtual_ipaddress {
        192.168.122.250
    }

    track_script {
        haproxy-check weight 20
    }
}

마스터의 IP 주소:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1458 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:9e:e8:18 brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.4/24 brd 192.168.122.255 scope global noprefixroute dynamic eth0
       valid_lft 55567sec preferred_lft 55567sec
    inet 192.168.122.250/32 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::571a:df5f:930c:2b57/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

그리고 백업하는 동안:

2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1458 qdisc pfifo_fast state UP group default qlen 1000
    link/ether fa:16:3e:2e:59:3d brd ff:ff:ff:ff:ff:ff
    inet 192.168.122.9/24 brd 192.168.122.255 scope global noprefixroute dynamic eth0
       valid_lft 79982sec preferred_lft 79982sec
    inet6 fe80::f816:3eff:fe2e:593d/64 scope link 
       valid_lft forever preferred_lft forever

마스터의 tcpdump:

# tcpdump -nni eth0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:44:06.299398 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:06.299435 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28
11:44:07.298939 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:07.298985 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28
11:44:08.300920 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:08.300954 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28
11:44:09.303039 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:09.303062 ARP, Reply 192.168.122.250 is-at fa:16:3e:9e:e8:18, length 28

그리고 백업에서:

# tcpdump -nni eth0 arp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:44:39.430367 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:40.431810 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:41.433847 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:42.435979 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28
11:44:43.437814 ARP, Request who-has 192.168.122.250 tell 192.168.122.9, length 28

방화벽 문제는 아닌 것 같습니다( iptables -L | grep -i arp아무것도 표시되지 않음). 문제를 일으킬 수 있는 커널 설정이 있습니까? 디버깅에 대한 제안 사항이 있나요?

운영 체제는 Centos 7이고 keepalived는 2.1.5입니다.

답변1

이 문제는 다른 분의 질문에 언급되었기 때문에 알게 되었습니다.GitHub. 나는 이 질문을 본 기억이 없다.keepalived-사용자keepalived아마도 관련 질문을 게시하기에 가장 좋은 곳일 것입니다.

VRRP 섹션은 keepalivedIP 주소(및 일부 경우(이 구성은 아님) 구성 nftables또는 iptables규칙)를 구성합니다. 완료 되면 keepalived커널은 모든 패킷의 전송 및 수신을 처리합니다.

구성에 아무런 문제가 없습니다 keepalived.

귀하의 문제는 범위를 벗어난 백업 시스템에서 ARP 응답이 수신되지 않는 것과 관련된 것으로 보입니다. keepalived따라서 응답이 수신되지 않는 이유를 이해하려면 다른 곳을 조사해야 합니다.

답변2

한 서버의 동일한 VLAN에 있는 여러 VIP와 매우 유사한 문제가 있었습니다.

https://github.com/acassen/keepalived/issues/1876

doc/source/software_design.rst에 설명된 대로

net.ipv4.conf.all.arp_ignore = 1

net.ipv4.conf.all.arp_announce = 1

IP 대상 문제가 해결되었습니다.

관련 정보