Настройка прокси сервера на centos 7 (squid+ad+sams2)

4. Test Keepalived keepalived.conf configuration syntax is OK

I’ve experienced this error because first time I’ve configured keepalived, I did not mention the user with which the vrrp script haproxy should run, in prior versions of keepalived, leaving the field empty did automatically assumed you have the user with which the vrrp script runs to be set to root as of RHELs keepalived-2.1.5-6.el8.x86_64, i’ve been using however this is no longer so and thus in prior configuration as you can see I’ve set the user in respective section to root. The error Unknown keyword ‘lvs_sync_daemon_interface’ is also easily fixable by just substituting the lvs_sync_daemon_interface and lvs_sync_daemon and reloading keepalived etc.

Once keepalived is started and you can see the process on both machines running in process list.

Next step is to check the keepalived statuses as well as /var/log/keepalived.log

If everything is configured as expected on both keepalived on first node you should see one is master and one is slave either in the status or the log

a. Fix Keepalived SECURITY VIOLATION – scripts are being executed but script_security not enabled.  

When configurating keepalived for a first time we have faced the following strange error inside keepalived status inside keepalived.log   

To fix keepalived SECURITY VIOLATION error:

Add to /etc/keepalived/keepalived.conf on the keepalived node hosts inside 

After chunk  

include

Configuring HAProxy

Next, edit /etc/haproxy/haproxy.cfg on both nodes to contain:

global
    log /dev/log    local0
    log /dev/log    local1 notice
    chroot /var/lib/haproxy
    stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
    stats timeout 30s
    user haproxy
    group haproxy
    daemon

    # Default SSL material locations
    ca-base /etc/ssl/certs
    crt-base /etc/ssl/private

    # Default ciphers to use on SSL-enabled listening sockets.
    # For more information, see ciphers(1SSL). This list is from:
    # An alternative list with additional directives can be obtained from
    #  https://mozilla.github.io/server-side-tls/ssl-config-generator/?server=haproxy
    ssl-default-bind-ciphers ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESGCM:RSA+AES:!aNULL:!MD5:!DSS
    ssl-default-bind-options no-sslv3

defaults
    log global
    mode    http
    option  httplog
    option  dontlognull
        timeout connect 5000
        timeout client  50000
        timeout server  50000
    errorfile 400 /etc/haproxy/errors/400.http
    errorfile 403 /etc/haproxy/errors/403.http
    errorfile 408 /etc/haproxy/errors/408.http
    errorfile 500 /etc/haproxy/errors/500.http
    errorfile 502 /etc/haproxy/errors/502.http
    errorfile 503 /etc/haproxy/errors/503.http
    errorfile 504 /etc/haproxy/errors/504.http

frontend www.mysite.com
    bind 192.168.3.135:80
    default_backend web_servers

backend web_servers
    balance roundrobin
    server server1 192.168.3.131:80 check
    server server2 192.168.3.132:80 check
    server server3 192.168.3.133:80 check

We can use the following command to validate the configuration file and fix any syntax errors that will prevent HAProxy from starting:

Tutorial

Step 1. Install Keepalived

Keepalived is usually available in most Linux repositories. Here’s the command to install Keepalived service in both servers:

sudo yum -y install keepalived

Step 2. Backup Default Keepalived Config File

Let’s back up the default Keepalived configuration file if in case you’d like to use it later as a template or for reference.

mv /etc/keepalived/keepalived.conf /etc/keepalived/keepalived.conf.back

Step 3. Configure Keepalived Config File in Master Server

You can copy the following configuration block below but you have to make appropriate changes for your environment which include the IPs and interfaces, priority and .

Location: /etc/keepalived/keepalived.conf

vrrp_script chk_mysql {
script "pidof mysqld"
interval 2                       # every 2 seconds
weight 2
}

vrrp_instance VI_1 {
interface enp0s3                 # the network interface to which the virtual address is assigned
state MASTER                     # MASTER for master server
virtual_router_id 50             # the virtual router ID must be unique to each VRRP instance
unicast_src_ip 192.168.40.222    # IP address of Master Server

unicast_peer {

192.168.40.223                   # IP address of Slave Server
}

priority 102                     # master server should always have a higher priority number 
                                 # than the slave

track_script {
     chk_mysql
}

virtual_ipaddress {
192.168.40.224/24 dev enp0s3     # Virtual IP address
}              
}

Tip

Run this command to show the current network configuration and see the configured network interface in the server:

ip addr show

Through this command, you can also see the Virtual IP Address assigned to the Master Server as shown below:

Take note that the Virtual IP Address () is assigned to the Master Server ()

Step 4. Configure Keepalived config File in Slave Server

Again, you can copy the following configuration block below, but you need to make appropriate changes for your environment.

Location: /etc/keepalived/keepalived.conf

vrrp_script chk_mysql {
script "pidof mysqld"
interval 2                       # every 2 seconds
weight 2
}

vrrp_instance VI_1 {
interface enp0s3                 # the network interface to which the virtual address is assigned
state BACKUP                     # BACKUP for slave server
virtual_router_id 50             # the virtual router ID must be unique to each VRRP instance
unicast_src_ip 192.168.40.223    # IP address of Slave Server

unicast_peer {
192.168.40.222                   # IP address of Master Server
}

priority 101                     # slave server should have a priority number lower than the slave

track_script {
     chk_mysql
}

virtual_ipaddress {
192.168.40.224/24 dev enp0s3     # Virtual IP address
}               
}

Step 5. Run Command on Both Servers

Run this command on both servers for the firewall:

firewall-cmd --direct --permanent --add-rule ipv4 filter INPUT 0 
--in-interface enp0s3 --destination 224.0.0.18 --protocol vrrp -j ACCEPT;

firewall-cmd --direct --permanent --add-rule ipv4 filter OUTPUT 0 
--out-interface enp0s3 --destination 224.0.0.18 --protocol vrrp -j ACCEPT;

firewall-cmd –reload;

Configure the Keepalived service to automatically start at the start of the server:

systemctl enable keepalived

Start the Keepalived service:

systemctl start keepalived

Step 8. Check Status of Keepalived

Now check the status of the Keepalived on Master and Slave servers by:

service keepalived status

You will know if you have configured the Keepalived service properly if the status indicated is active as shown below:

Notes

Here are the following commands you will need to control Keepalived:

service keepalived start    - used to start the Keepalived service
service keepalived stop     - used to stop the Keepalived service
service keepalived restart  - used to restart the Keepalived service
service keepalived status   - used to check the status of the Keepalived service

If you encountered a problem like this:

Keepalived: WARNING - default user 'keepalived_script' 
for script execution does not exist - please create.

Resolve this by:

sudo useradd -g users -M keepalived_script

and restart the Keepalived service:

sudo systemctl restart keepalived

You can check the logs of the keepalived here:

/var/log/messages

Installing the latest version of Keepalived 2.0.14

The version v1.2.24 of Keepalived in Ubuntu 16.04.4 default apt repositories is outdated, the latest available version of Keepalived v2.0.14 was released on March 25, 2019. So in this tutorial we will install the latest version of Keepalivedfrom source.

Setup the build environment for Keepalived

First of all we will install the Keepalived build dependencies.

1. We install  package, this will install different packages required for build process in general.
2. Install  SSL libraries, Keepalived requires () as build dependency.

Build and Install Keepalived

First of all, setup Keepalived on all three ubuntu servers using following steps.

1. Download the latest available release of Keepalived.
2. Extract the downloaded package using  command.
3. Above command will extract the contents of  file to directory named , change directory to this one.
4. Create Makefiles file by running the  shell script.
5. Run the  command to generate the executable binaries.
6. Now run the  command to copy the built artifacts to their proper location.Setup Keepalived as systemd serviceIn this section we will setup Keepalived as systemd service.
7. Create systemd service unit file for Keepalived service.
8. Copy following contents into  file, save file and exit the nano editor .
9. Enable the Keepalived service for auto start on system boot.Output
10. If you try to start keepalived service using  command, it will fail with following status report. Don’t worry, this error will get fixed in upcoming sections of this article where we setup configuration files for Keepalived MASTER and BACKUP node.

Basic configuration

Image

Network symbols in the diagrams available via VRT Network Equipment Extension, CC BY-SA 3.0.

The configuration file for is located at . As discussed in the previous article, does more than just implement basic . This leads to a configuration file that might seem daunting if you look at the Keepalived man page. However, a simple topology like the one above can be achieved with minimal configuration.

The most basic configuration enables a shared IP address between two servers. In the above topology, server1 is the master, and server2 is the backup. The configuration for both servers is simple.

Server 1 configuration:

Server 2 configuration:

The configuration directives should be obvious from their naming conventions, but I will walk through each one:

• defines an individual instance of the protocol running on an interface. I have arbitrarily named this instance VI_1.
• defines the initial state that the instance should start in.
• defines the interface that runs on.
• is the unique identifier that you learned about in the first article of this series.
• is the advertised priority that you learned about in the first article of this series. As you will learn in the next article, priorities can be adjusted at runtime.
• specifies the frequency that advertisements are sent at (1 second, in this case).
• specifies the information necessary for servers participating in to authenticate with each other. In this case, a simple password is defined.
• defines the IP addresses (there can be multiple) that is responsible for.

If you’re using a host-based firewall, such as or , then you need to add the necessary rules to permit IP protocol 112 traffic. Otherwise, ’s advertisement method won’t work. Configuring a host-based firewall is out of scope for this article, but be sure to check out some of Enable Sysadmin’s other articles about iptables and firewalld for more information.

With the above configuration in place, you can start on both servers using and observe the IP addresses on each machine. Notice that server1 has started up as the master and owns the shared IP address (192.168.122.200), while server2’s IP addresses remain unchanged:

Once you’ve confirmed that has started on both servers and server1 is the active master, you can test out failover functionality by “flipping” the VIP to the other server. By stopping on server1, the active master stops sending out advertisements, and server2 takes over the VIP:

And that’s it! You now have a basic pair of redundant servers.

1: Установка прокси-сервера Squid

Помимо маршрутизации исходящего трафика отдельного пользователя, у Squid есть много вариантов применения. В контексте крупномасштабных развертываний его можно использовать в качестве механизма распределенного кэширования, балансировщика нагрузки или другого компонента стека маршрутизации. Однако многие методы горизонтального масштабирования серверного трафика, которые обычно включали бы прокси-сервер, отошли на второй план – их место заняли платформы контейнеризации, такие как Kubernetes. В то же время использование прокси-серверов для перенаправления веб-запросов отдельного пользователя становится все более популярным средством защиты конфиденциальности. Об этом следует помнить при работе с открытыми прокси-серверами, которые могут обслуживать десятки функций с более низким приоритетом. Варианты использования прокси со временем изменились, но фундаментальная технология осталась прежней.

Начнем со следующих команд (они обновят списки пакетов и установят Squid Proxy):

Squid автоматически настроит сервис и запустится после установки. Вы можете проверить работу сервиса с помощью команды:

Вы получите:

squid.service - Squid Web Proxy Server
     Loaded: loaded (/lib/systemd/system/squid.service; enabled; vendor preset: enabled)
     Active: active (running) since Wed 2021-12-15 21:45:15 UTC; 2min 11s ago

По умолчанию Squid не позволяет клиентам вне пределов этого сервера подключаться к нему. Чтобы включить эту возможность, вам нужно внести некоторые изменения в его конфигурации – этот файл хранится в /etc/squid/squid.conf. Откройте его в nano или в другом текстовом редакторе:

Имейте в виду, конфигурационный файл Squid по умолчанию очень, очень длинный и содержит огромное количество опций, которые были закомментированы (то есть временно отключены с помощью символа # в начале строки). Скорее всего, вам нужно будет выполнить поиск по файлу и найти строки, которые нужно отредактировать. Чтобы сделать это в nano, нажмите Ctrl+W, введите поисковый запрос, нажмите Enter, а затем нажмите Alt+W несколько раз (это позволяет перемещаться между результатами поиска, если это необходимо).

Найдите строку http_access deny all. Вы должны увидеть блок текста, объясняющий правила доступа Squid по умолчанию:

. . .
#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*
# Example rule allowing access from your local networks.
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost

# And finally deny all other access to this proxy
http_access deny all
. . .

Из этого вы можете понять текущее поведение сервера — localhost разрешен, а другие подключения нет

Обратите внимание, эти правила обрабатываются последовательно, поэтому рекомендуется оставить правило deny all в конце этого блока конфигурации. Вы можете изменить это правило на allow all, если хотите разрешить всем подключаться к вашему прокси-серверу (вероятно, вы не захотите этого делать)

Вместо этого перед http_access allow localhost лучше добавить строку, которая включает ваш собственный IP-адрес:

#
# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*
# Example rule allowing access from your local networks.
acl localnet src your_ip_address
# Adapt localnet in the ACL section to list your (internal) IP networks
# from where browsing should be allowed
#http_access allow localnet
http_access allow localhost

Рассмотрим ее подробнее:

• acl – это сокращение Access Control List, общий термин для политик разрешений.
• localnet в данном случае — это имя вашего списка ACL.
• src — это место, откуда должен исходить запрос из этого ACL, то есть ваш IP-адрес.

Если вы не знаете свой локальный IP-адрес, проще всего обратиться к сайту What’s my IP, который подскажет вам, откуда вы к нему обращались. После внесения этого изменения сохраните и закройте файл. Если вы используете nano, нажмите Ctrl+X, а затем Y и Enter.

На этом этапе вы можете перезапустить сервер Squid и подключиться к нему, но сначала рекомендуем получше защитить его.

Запретить загрузки файлов определенного типа

Для выполнения этой задачи нам нужно будет познакомиться с основами Регулярных Выражений (Regular Expressions, RegExp).

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

Элементы регулярных выражений (RegExp)

• Символ * означает любое количество символов.
• Символ $ символизирует конец строки. *\.avi$ будет соответствовать всем путям, заканчивающимся на «.avi».
• Символ \ разделяет блоки в строке. Если вы хотите наложить строкое правило, на присутствие двух характерных последовательностей символов с троке, то вам следует это сделать так: sex.*\.avi$ Это выражение будет соответствовать всем путям, заканчивающимся на .avi и содержащих в пути слово sex.

Для использования регулярных выражений при описании переменной вам следует указать ее тип urlpath_regex.

Параметр -i определяет НЕ чувствительность выражений к синтаксису. Буква m будет соответствовать и M и m в пути.

Составим правила для блокировки всех .mp3 и .avi файлов:

1. Опишем переменную с выражениями, соответствующими URL с именами mp3 и avi файлов:

acl media urlpath_regex -i \.mp3$ \.avi$

2. Опишем сеть NET155 (если она еще не описана)

acl NET155 src 192.168.155.0/255.255.255.0

3. Создадим правило запрета скачивания mp3 и avi файлов для сети NET155

http_access deny media NET155

4. Перезапустим squid для применения правила

sudo /etc/init.d/squid restart

Установка и первоначальная настройка

Установка Debian Wheezy 7.0 происходит в текстовом режиме на русском языке и, как правило, не  вызывает сложностей. Отдельно стоит только остановится на списке ролей: из предложенного нас, пожалуй, может заинтересовать только OpenSSH, для удаленного доступа, однако воспользовавшись пунктом Manual package selection опытный пользователь может сразу установить необходимые ему пакеты.

Если же это ваш первый сервер, то лучше всего продолжить не выбирая никакого варианта, все необходимые пакеты мы доустановим позже. Это позволит иметь более четкое представлении о назначении того или иного пакета и позволит успешно справляться с возможными неполадками. По окончании установки система перезагрузится и встретит нас черным экраном командной строки. Непривычного к консоли Windows-администратора это может неприятно удивить, однако ситуация на сегодняшний день такова, что все серверные роли Linux настраиваются исключительно через консоль и файлы конфигурации.

В первую очередь настроим сетевые соединения. Вводим в консоли:

nano /etc/network/interfaces

Эта команда откроет в консольном редакторе nano конфигурационный файл с сетевыми интерфейсами, аналогичный рисунку ниже. 

Пока там прописан единственный интерфейс eth0, настроенный на работу по DHCP. К eth0 у нас подключен ADSL модем (или любая сеть провайдера), а eth1 смотрит во внутреннюю сеть. IP адрес на внешнем интерфейсе 192.168.1.2, шлюз (ADSL модем) 192.168.1.1, внутренняя сеть лежит в диапазоне 192.168.3.1 — 254. Тогда настройки будут выглядеть следующим образом:

auto eth0
iface eth0 inet static
address 192.168.1.2
netmask 255.255.255.0
gateway 192.168.1.1


auto eth1
iface eth1 inet static
address 192.168.3.1
netmask 255.255.255.0

Сохраняем изменения Ctrl+O и выходим Ctrl+X. Теперь нужно настроить DNS, для этого выполняем: 

nano /etc/resolv.conf

В этом файле необходимо указать адреса DNS серверов, лучше всего указать DNS провайдера или, как в нашем случае, Google DNS.

#Google DNS
nameserver 8.8.8.8
nameserver 8.8.4.4

Сохраняем. Теперь нужно перезапустить сетевые службы (либо перезагрузиться):

/etc/init.d/networking restart

Собственно сеть настроена, можно переходить к следующему этапу, однако мы рекомендуем установить еще несколько пакетов для удобства администрирования.  Сначала обновим список доступных пакетов:

aptitude update

Также рекомендуем обновить версии пакетов до актуальных:

aptitude upgrade

Теперь установим Midnight Commander (mc), файловый менеджер по образу и подобию Norton Commander или Far:

aptitude install mc

Для запуска Midnight Commander достаточно набрать в консоли его краткое имя: mc. Сразу рекомендуем включить встроенный редактор, более удобный чем nano: F9 — Настройки — Конфигурация — Встроенный редактор. 

Для удаленного управления сервером (не бегать же к нему каждый раз) установим OpenSSH, что позволит подключаться к нему из любого места, даже из дома, по защищенному протоколу:

aptitude install ssh

Для подключения с Windows станций можно использовать программу PuTTY (скачать), для корректного отображения символов перед подключением необходимо на закладке Window — Translation выбрать кодировку UTF8. 

Для ограничения доступа к серверу можно дописать в файл /etc/ssh/sshd_config параметр AllowUsers с указанием пользователя имеющего доступ по SSH, например для пользователя admin:

AllowUsers admin

Также можно разрешить доступ определенной группе пользователей используя параметр AllowGroups, либо запретить доступ определенным пользователям / группам использовав DenyUsers и DenyGroups.

Авторизация по логину и паролю

Открываем конфигурационный файл:

vi /etc/squid/squid.conf

Вставляем следующее:

#  TAG: auth_param
…
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/auth_users
auth_param basic children 25
auth_param basic realm SQUID PROXY
auth_param basic credentialsttl 3 hours

* где /usr/lib/squid/basic_ncsa_auth — расположение ncsa_auth (в зависимости от системы может находиться в другом каталоге); /etc/squid/auth_users — файл с логинами и паролями; children 25 разрешает 25 одновременных подключений; SQUID PROXY — произвольная фраза для приветствия; credentialsttl 3 hours будет держать сессию 3 часа, после потребуется повторный ввод логина и пароля.

Создаем acl для пользователей, которые прошли регистрацию. Сделаем регистрацию обязательной:

#  TAG: acl
…
acl auth_users proxy_auth REQUIRED

Находим опцию:

http_access deny !Safe_ports

И после нее добавляем:

http_access allow auth_users

Устанавливаем утилиту apache2-utils:

apt-get install apache2-utils

Создаем файл с пользователями и создаем первую пару логина и пароля:

htpasswd -c /etc/squid/auth_users user1

Создаем второго пользователя:

htpasswd /etc/squid/auth_users user2

И перечитываем конфигурацию squid:

squid -k reconfigure

Install and Configure keepalived on CentOS

We will install and configure the keepalived on a two Linux servers (proxy-serv01 and proxy-serv02) running CentOS 7 with Squid installed. In our scheme, we will use the simplest method of load balancing — Round Robin DNS. This method suggests that a single DNS name has multiple registered IP addresses, and clients get these addresses one by one. So we will need two virtual IP addresses registered for one DNS name (proxy-serv). Here is the network diagram:

Each Linux server has two physical network interfaces: eth1 with the public (white) IP address and eth0 in the local network.

The following server IP addresses are used as real ones:

192.168.2.251 — for proxy-server01
192.168.2.252 — for proxy-server02

The following IP addresses will be used as virtual ones that are automatically switched between servers in case of a failure:

192.168.2.101
192.168.2.102

Important. When you configure VRRP, never use the real server IP address as a virtual one, since in case a server fails its address will move to the next server, and after the failback the first server may get isolated from the network. The matter is that to get the IP address back, a server has to send a VRRP packets to the network, but it has no IP address to do it from.

You can install the keepalived on both servers using yum package manager (or on CentOS 8):

After the installation is completed on both servers, change the keepalived configuration file on both servers:

The lines with different parameters are highlighted:

proxy-serv01	proxy-serv02
1	2

Let’s describe the options in more detail:

1. vrrp_instance <name> — is the section that defines a VRRP instance;
2. state <MASTER|BACKUP> — is the initial node state at the startup;
3. interface <interface name> — is the interface VRRP is running on;
4. virtual_router_id <number from 0 to 255> — is the unique VRRP instance identifier, it must be the same on all servers;
5. priority <number from 0 to 255> — sets the server priority, a server with a higher priority becomes a MASTER;
6. virtual_ipaddress — is a block of virtual IP addresses active on a server in the MASTER state. They must be the same on all servers inside the VRRP instance

Note. You can find many examples when the authentication option is used in the VRRP configuration. However, the keepalived documentation mentions that the authentication was removed from VRRPv2 in the RFC3768 specification (https://tools.ietf.org/html/rfc3768) in 2004, since it had not provided real security. It is not recommended to use this configuration option.

If the current network configuration doesn’t allow to use multicast, keepalived provides a unicast option, i. e. VRRP heartbeat packets will be sent to servers directly according to the list. To use unicast, you will need the following options:

• unicast_src_ip — is the source address for VRRP packates
• unicast_peer — is the block of server IP addresses, to which VRRP packets will be sent.

Thus, our configuration defines two VRRP instances, proxy_ip1 and proxy_ip2. At the regular operation, proxy-serv01 will be the MASTER for the virtual IP 192.168.2.101 and the BACKUP for 192.168.2.102, and vice versa, proxy-serv02 will be the MASTER for the virtual IP 192.168.2.102, and the BACKUP for 192.168.2.101.

If a firewall is activated on a server, you will have to add allowing rules for the multicast traffic and VRRP using iptables:

Enable the keepalived service for autostart on system boot and run it on both servers

After keepalived has been started, virtual IP addresses will be assigned to the interfaces from your configuration file. Let’s view the current eth0 IP addresses of the servers:

On proxy-serv01:

On proxy-serv02:

User case 2

I have two IPFire and wanted a hardware failover, but I only have one ISP. If one (the MASTER) has maintenance (or goes down) the other (BACKUP) takes over and EVERYONE can continue to surf (in my case a family of 3 and maybe a quest ;).

The services that will failover are:

• Internet access
• DHCP server

Otherwise they are similarly installed with IDS, Guardian and Blocklists.

I also use OpenVPN and though I took a backup from MASTER to BACKUP, I right now use different dynamic DNS names for the two IPFires to connect to them (both IPFires get different IPs from the ISP). When I know more, maybe also this will be failovered.

• My MASTER IPFire has the IP 192.168.0.251
• My BACKUP IPFire has the IP 192.168.0.252
• The «virtual» IPFire failover firewall has the IP 192.168.0.254

These are the steps I used:

2/6 Edit keepalived.conf

On both firewalls edit /etc/keepalived/keepalived.conf. For more info about keepalived parameters, see http://www.keepalived.org/manpage.html

MASTER

BACKUP

4/6 Make «same» DHCP work during failover

On both IPFires. Add the same «virtual» IPFire failover firewall IP to /var/ipfire/dhcp/dhcpd.conf.local (copy from /var/ipfire/dhcp/dhcpd.conf and edit)

E.g

6/6 Make keepalived run at boot

On both IPFires, edit /etc/sysconfig/rc.local and add /etc/init.d/keepalived start

If you are here, reboot both IPFires (or do 3 manually and run /etc/init.d/keepalived stop and /etc/init.d/keepalived start manually)