stunnel
Keepalived를 사용하여 회사 데이터 센터의 공용 IP 주소에 대해 활성-수동 설정을 구성하려고 합니다 . 다음 시나리오에서 라우터 또는 스위치 재구성이 권장되는지 알고 싶습니다.
stunnel
현재 두 개의 CentOS 6 상자 각각에 다른 (내부) 서버의 테스트 페이지에 대한 연결을 프록시하는 작동이 확인된 설치가 있습니다 . 나는 구성을 기반으로이 튜토리얼. ( eth1
무고한 자를 보호하기 위해 기기 에 존재하는 외부 가상 IP를 수정했습니다 .)
# Box 1 (primary)
vrrp_script chk_stunnel { # Requires keepalived-1.1.13
script "killall -0 stunnel" # cheaper than pidof
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance stunnel_cluster {
state MASTER
interface eth0
virtual_router_id 51
priority 101
advert_int 1
virtual_ipaddress {
<VIRTUAL IP>/32 dev eth1
}
track_script {
chk_stunnel
}
}
# Box 2 (secondary)
vrrp_script chk_stunnel { # Requires keepalived-1.1.13
script "killall -0 stunnel" # cheaper than pidof
interval 2 # check every 2 seconds
weight 2 # add 2 points of prio if OK
}
vrrp_instance stunnel_cluster {
state BACKUP
interface eth0
virtual_router_id 51
priority 100
advert_int 1
virtual_ipaddress {
<VIRTUAL IP>/32 dev eth1
}
track_script {
chk_stunnel
}
}
의 기본 인스턴스를 종료하면 stunnel
syslogs는 보조 상자가 예상대로 불필요한 ARP 패킷을 보내기 시작하지만 테스트 웹 페이지가 장애 조치되지 않고 대신 사용할 수 없게 된다는 것을 나타냅니다. 어느 정도 시간이 지나면(최소 몇 시간) 마침내 두 번째 상자가 이어집니다.
나에게 이것은 적어도 하나의 Juniper 장치(공용 라우터 및 별도의 스위치)에서 ARP 캐싱처럼 들립니다. 기본 시간 초과(6시간으로 생각됨)를 무시하는 대신 무료 ARP가 예상대로 작동하고 라우팅 테이블 업데이트를 트리거하도록 하는 것이 더 좋습니다.
나는 믿는다gratuitous-arp-reply
여기서 설정이 유용할 수 있습니다. 시스템을 변경하기 전에 누군가가 다음 사항을 알아주기를 바랍니다.
- 장애 조치 실패의 원인일 가능성이 더 높은 범인을 간과했나요?
- ARP 캐싱이 문제인 경우 이 변경 사항이 내가 하려는 작업을 수행하는 "표준" 방법처럼 들립니까?
- 회사 네트워크 경계가 합리적으로 보호되어 있다고 가정할 때 이 설정을 변경하면 불합리한 보안 위험이 발생합니까?
- 제가 알아야 할 다른 "문제점"이 있나요?
감사합니다.