Konfiguracja klastra HA OPNsense

Z Thomas-Krenn-Wiki
Przejdź do nawigacji Przejdź do wyszukiwania

Bezpłatny firewall OPNsense może być skonfigurowany jako redundantny firewall z automatycznym przełączaniem awaryjnym (fail-over). W tym artykule pokazujemy jak skonfigurować taki klaster HA firewalla na dwóch maszynach (w tym przykładzie na dwóch systemach LES compact 4L).

Wymagania podstawowe

W tym przykładzie do konfiguracji klastra HA z OPNsense zostały wykorzystane dwa systemy LES compact 4L (każdy z czterema portami sieciowymi na tylnej ścianie).

Do redundantnej konfiguracji firewalla OPNsense wymaga są:

  • dwa komputery z oprogramowaniem firewalla, każdy z co najmniej trzema portami sieciowymi.
  • WAN: uplink z co najmniej trzema dostępnymi adresami IP (po jednym stałym adresie IP dla firewalla 1 i firewalla 2 oraz dodatkowy wirtualny adres IP dla firewalla Master).
  • LAN: trzy wolne adresy IP w sieci LAN (po jednym stałym adresie IP dla firewalla 1 i firewalla 2 oraz dodatkowy wirtualny adres IP dla firewalla Master).

Jeśli węzły klastra OPNsense działają w maszynach wirtualnych, to muszą one mieć możliwość zmiany adresów MAC. Konieczne jest to dla korzystania z protokołu Common Address Redundancy Protocol - CARP. Odpowiednimi ustawieniami są tutaj:

  • VMware ESXi: Należy włączyć Allow forged transmits i Allow MAC changes.

    VMware ESXi: Należy włączyć Allow forged transmits i Allow MAC changes.

  • Hyper-V: Należy włączyć Enable MAC address spoofing.

    Hyper-V: Należy włączyć Enable MAC address spoofing.

Podstawowe informacje

W przypadku redundantnej zapory sieciowej OPNsense stosowane są następujące technologie:

  • Common Address Redundancy Protocol (CARP):[1] Jest to protokół sieciowym, który pozwala wielu hostom w tej samej sieci lokalnej na współdzielenie zestawu adresów IP.
    • Używa jak VRRP protokołu IP 112.
    • Wykorzystuje pakiety multicast do przekazywania bieżących informacji o stanie innych komputerów wchodzących w skład klastra.
  • pfsync:[2] protokół replikacji informacji o stanie poszczególnych połączeń sieciowych (State Table Synchronisation).
    • Uwaga: aby informacje o stanie zostały prawidłowo zastosowane na wszystkich firewallach, obie zapory muszą używać tych samych nazw interfejsów dla tych samych sieci. Na przykład, jeśli sieć wewnętrzna (LAN) jest podłączona do firewalla 1 przez interfejs igb0, wówczas igb0 musi być również przypisana do sieci LAN na firewallu 2. Jeśli mamy do czynienia z różnymi zaporami sieciowymi, z różnymi kartami sieciowymi (i tym samym nazwami interfejsów), to można skonfigurować LAGG jako workaround.
    • Dla pfSync zaleca się użycie dedykowanego interfejsu na obu firewallach. Zwiększa to bezpieczeństwo (State Injection) i wydajność.
  • XMLRPC sync: synchronizacja konfiguracji firewalli.

Konfiguracja

Konfiguracja sieci klastra HA OPNsense.

Zalecenie: podczas konfigurowania nowej zapory sieciowej, najpierw należy skonfigurować klaster. Po skonfigurowaniu klastra HA, należy rozpocząć konfigurowanie dodatkowych ustawień firewalla (reguł firewalla, usług, ...). Procedura ta zmniejsza liczbę możliwych źródeł błędu.

Aby skonfigurować redundantny firewall OPNsense, należy wykonać następujące czynności:[3]

  1. Zainstalować firewall OPNsense na komputerach klastra.
  2. Skonfigurować statyczne adresy IP na firewallu 1 i 2. Jeśli używane jest tylko IPv4, to zalecamy wyłączenie IPv6 na obu firewallach. W tym przykładzie wykorzystujemy następujące adresy IP:
    • igb0 (LAN): 192.168.1.251/24 (firewall 1); 192.168.1.252/24 (firewall 2)
    • igb1 (WAN): 10.1.102.251/24 (firewall 1); 10.1.102.252/24 (firewall 2)
    • igb2 (pfSync): 10.0.0.1/24 (firewall 1); 10.0.0.2/24 (firewall 2). Szczegółowe informacje na temat konfiguracji dodatkowego interfejsu sieciowego są opisane w artykule Nowy interfejs sieciowy w OPNsense.
  3. Wyłączyć serwer DHCP na obu firewallach (pod Services ‣ DHCPv4 ‣ [LAN]).
  4. Skonfigurować reguły na obu firewallach. W Firewall ‣ Rules wymagane są następujące zasady dla trzech interfejsów:
    • LAN: zezwolenie dla pakietów CARP (wybór Protocol: CARP)
    • WAN: zezwolenie dla pakietów CARP (wybór Protocol: CARP)
    • PFSYNC: zezwolenie na dowolny ruch sieciowy, gdyż jest to bezpośrednie połączenie kablowe.
  5. Konfiguracja wirtualnych adresów IP dla sieci WAN i LAN pod Firewall ‣ Virtual IPs ‣ Settings.
    Skonfigurować wirtualne adresy IP:
    • Na firewallu 1 (Master) pod Firewall ‣ Virtual IPs ‣ Settings kliknąć na + Add i stworzyć nowy wirtualny adres IP dla sieci WAN o następujących parametrach:
      • Mode: CARP
      • Interface: WAN
      • Address: 10.1.102.253/24
      • Virtual password: zalecamy użycie losowego hasła składającego się z 30 znaków, które może zostać stworzone, np. w systemie Linux lub FreeBSD, następującą komendą z wiersza poleceń:[4]
        cat /dev/random | hexdump -n 30| cut -d \ -f 2-| head -n 1 | tr -d " "
      • VHID Group: 1
      • Advertising Frequency: Base 1 / Skew 0
      • Description: Virtual WAN IP
    • Na firewallu 1 (Master) kliknąć na + Add i stworzyć nowy wirtualny adres IP dla sieci LAN o następujących parametrach:
      • Mode: CARP
      • Interface: LAN
      • Address: 192.168.1.1/24
      • Virtual password: zalecamy użycie losowego hasła składającego się z 30 znaków.
      • VHID Group: 3 (numer ten jest używany jako ostatni oktet adresu MAC dla wirtualnego adresu IP, w tym przykładzie adres MAC to 00:00:00:5e:00:01:03)[5]
      • Advertising Frequency: Base 1 / Skew 0
      • Description: Virtual LAN IP
  6. Konfiguracja translacji wychodzących adresów sieciowych (NAT).
    Skonfigurować NAT dla wychodzących adresów IP. Pod Firewall ‣ NAT ‣ Outbound należy wybrać opcję Manual outbound NAT rule generation i przez kliknięcie na + Add stworzyć nową regułę:
    • Interface: WAN
    • Source address: LAN net
    • Translation / target: 10.1.102.253 (Virtual WAN IP)
  7. Opcjonalnie skonfigurować serwer DHCP. Na obu firewallach należy wybrać następujące parametry pod Services ‣ DHCPv4 ‣ [LAN]:
    • DNS servers: 192.168.1.1 (odpowiada wirtualnemu adresowi IP LAN)
    • Gateway: 192.168.1.1 (odpowiada wirtualnemu adresowi IP LAN)
    • Failover peer IP: 192.168.1.252 (adres IP drugiego firewalla), na firewallu 2 adres 192.168.1.251 (adres IP pierwszego firewalla)
  8. Konfiguracja synchronizacji HA na firewallu 1.
    Skonfigurować synchronizację HA (xmlrpc) i pfSync na firewallu 1. Pod System ‣ High Availability ‣ Settings należy skonfigurować:
    • Synchronize States: ✔
    • Synchronize Interface: PFSYNC
    • Synchronize Peer IP: 10.0.0.2 (adres IP interfejsu PFSYNC firewallu 2)
    • Synchronize Config to IP: 10.0.0.2
    • Remote System Username: root
    • Remote System Password: (hasło firewallu 2)
    • Wybór usług, które mają być zsynchronizowane. W tym przykładzie:
      • Dashboard: ✔
      • Firewall Rules: ✔
      • Aliases: ✔
      • NAT: ✔
      • DHCPD: ✔
      • Virtual IPs: ✔
  9. Informacje o statusie synchronizacji HA (na firewallu 1).
    Konfigurować pfSync na firewallu 2. Pod System ‣ High Availability ‣ Settings należy skonfigurować następujące ustawienia:
    • Synchronize States: ✔
    • Disable preempt: diese Option deaktiviert belassen (damit bleibt preemt weiterhin aktiv). Dadurch ist sichergestellt, dass bei einem Ausfall einer einzelnen Netzwerkverbindung (z.B. WAN-Anbindung von Firewall 1) alle IP Adressen (WAN und LAN in diesem Beispiel) auf die zweite Firewall umgezogen werden.[6]
    • Synchronize Interface: PFSYNC
    • Synchronize Peer IP: 10.0.0.1 (adres IP interfejsu PFSYNC firewalla 1)
    • Uwaga: Nie należy konfigurować synchronizacji HA (xmlrpc) na firewallu 2. Późniejsza konfiguracja (np. reguł zapory sieciowej itp.) jest wykonywana wyłącznie na firewallu 1 i synchronizowana na firewall 2.
  10. Na dashbordzie firewalla 1 należy dodać widget CARP, przez kliknięcie na + Widget i wybór CARP, następnie należy zapisać ustawienia klikając na Safe Settings.
  11. Na koniec należy restartować oba systemy.

Uwaga: Jeżeli skonfigurowane są jeszcze inne usługi (np. OpenVPN), to synchronizacja konfiguracji musi być najpierw aktywowana pod System ‣ High Availability ‣ Settings. Podczas konfigurowania usługi jako interfejs dla usługi należy wybrać wirtualny adres IP sieci WAN.

Symulacja awarii

Po wykonaniu polecenia "ip n" klient w testowej sieci LAN pokazuje wirtualny adres MAC 00:00:5e:00:01:03 dla bramy domyślnej 192.168.1.1: 

wfischer@ubuntu:~$ ip n
192.168.1.1 dev eth0 lladdr 00:00:5e:00:01:03 REACHABLE

Teraz, w celu przetestowania zostaje na firewallu 1 (dotychczasowy Master) odłączony kabel portu WAN (igb1). Połączenia klienta z internetem (np. połączenie SSH lub połączenie wirtualnego pulpitu) pozostają zachowane.

Poniższe wyjście pokazuje zapisy logów w /var/log/system.log oraz wartości z sysctl net.inet.carp na firewallu 1. Interfejs igb1 przechodzi w stan "interface down", a "Demotion Counter" wskazuje wartość 240: 

root@fw1:~ # clog -f /var/log/system.log
Aug 26 11:39:17 fw1 kernel: carp: 1@igb1: MASTER -> INIT (hardware interface down)
Aug 26 11:39:17 fw1 kernel: carp: demoted by 240 to 240 (interface down)
Aug 26 11:39:17 fw1 kernel: igb1: link state changed to DOWN
Aug 26 11:39:17 fw1 kernel: carp: 3@igb0: MASTER -> BACKUP (more frequent advertisement received)
Aug 26 11:39:17 fw1 kernel: ifa_maintain_loopback_route: deletion failed for interface igb0: 3
Aug 26 11:39:18 fw1 opnsense: /usr/local/etc/rc.linkup: DEVD Ethernet detached event for wan 
Aug 26 11:39:18 fw1 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn:
                    Carp cluster member "192.168.1.1 - Virtual LAN IP (3@igb0)" has resumed the state "BACKUP" for vhid 3 
[Ctrl]+[c]
root@fw1:~ # sysctl net.inet.carp
net.inet.carp.ifdown_demotion_factor: 240
net.inet.carp.senderr_demotion_factor: 240
net.inet.carp.demotion: 240
net.inet.carp.log: 1
net.inet.carp.preempt: 1
net.inet.carp.allow: 1

Poniższe wyjście pokazuje zawartość logów w /var/log/system.log oraz wartości z sysctl net.inet.carp na firewallu 2: 

root@fw2:~ # clog -f /var/log/system.log
Aug 26 11:39:17 fw2 kernel: carp: 3@igb0: BACKUP -> MASTER (preempting a slower master)
Aug 26 11:39:18 fw2 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn:
                    Carp cluster member "192.168.1.1 - Virtual LAN IP (3@igb0)" has resumed the state "MASTER" for vhid 3 
Aug 26 11:39:19 fw2 kernel: carp: 1@igb1: BACKUP -> MASTER (master timed out)
Aug 26 11:39:20 fw2 opnsense: /usr/local/etc/rc.syshook.d/carp/20-openvpn:
                    Carp cluster member "10.1.102.253 - Virtual WAN IP (1@igb1)" has resumed the state "MASTER" for vhid 1 
[Ctrl]+[c]
root@fw2:~ # sysctl net.inet.carp
net.inet.carp.ifdown_demotion_factor: 240
net.inet.carp.senderr_demotion_factor: 240
net.inet.carp.demotion: 0
net.inet.carp.log: 1
net.inet.carp.preempt: 1
net.inet.carp.allow: 1

W interfejsie sieciowym firewalla 1 (firewall 2 jest teraz MASTER dla sieci LAN i WAN) można zobaczyć następujące informacje:

  • Widget CARP na pulpicie firewalla 1 wyświetla status BACKUP-u.

    Widget CARP na pulpicie firewalla 1 wyświetla status BACKUP-u.

  • Pod Firewall ‣ Virtual IPs ‣ Status znajdują się dodatkowe informacje na temat przejścia w tryb backupu.

    Pod Firewall ‣ Virtual IPs ‣ Status znajdują się dodatkowe informacje na temat przejścia w tryb backupu.

Aktualizacja firewalla

Dzięki redundantnemu klastrowi HA aktiv/passiv, czas przestoju firewalla podczas aktualizacji firewalla może zostać wyraźnie zminimalizowany:

  1. Najpierw należy uaktualnić firewall zapasowy (firewall 2) i poczekać, aż będzie ponownie online.
  2. Na aktywnym firewallu wybrać pod Firewall ‣ Virtual IPs ‣ Status punkt Enter Persistent CARP Maintenance Mode.
  3. Gdy firewall 2 zmieni swój status na MASTER, należy sprawdzić, czy wszystkie usługi takie jak DHCP, VPN, NAT działają prawidłowo po aktualizacji. W mało prawdopodobnym przypadku, gdy aktualizacja firewalla spowoduje problemy z niektórymi usługami, można przełączyć się z powrotem na pierwszy firewall.
  4. Jeśli wszystkie usługi działają zgodnie z wymaganiami po aktualizacji, należy aktualizować firewall 1 i następnie wybrać Leave Persistent CARP Maintenance Mode.
    • Uwaga dotycząca OPNsense 19.2: Jeśli podczas aktualizacji miał miejsce automatyczny restart firewalla 1, to po kliknięciu na Leave Persistent CARP Maintenance Mode należy ponownie restartować firewall 1, tak aby wartości w advskew na firewallu 1 zostały zresetowane do 0.[7] Błąd ten zostanie naprawiony w przyszłej wersji OPNsense. [8]

Często zadawane pytania i analiza błędów

  • Pytanie: Jeżeli podczas awarii pojedynczego połączenia na firewallu 1 (np. połączenie WAN) zostanie przeniesiony tylko adres IP sieci WAN na firewall 2, ale nie adres IP sieci LAN. Jak mogę naprawić ten problem?
    1. Sprawdź, czy opcja Disable preempt pod System ‣ High Availability ‣ Settings jest wyłączona na obu firewallach.
    2. Sprawdź poleceniem ifconfig | grep carp z konsoli wartości przy advbase i advskew na obu firewallach
      • advbase: na wszystkich interfejsach CARP na firewallu 1 i firewallu 2 wartość powinna wynosić "1"
      • advskew: na wszystkich interfejsach CARP na firewallu 1 wartość powinna wynosić "0", a na wszystkich interfejsach CARP na firewallu 2 wartość powinna wynosić "100". Jeśli wartość wynosi 254, to po wykonaniu polecenia Leave Persistent CARP Maintenance Mode należy ponownie uruchomić komputer.[7]

Odnośniki

  1. ↑ Common Address Redundancy Protocol (en.wikipedia.org)
  2. ↑ pfsync Manpage (www.freebsd.org)
  3. ↑ Configure CARP (docs.opnsense.org)
  4. ↑ CARP on FreeBSD 10 with Pf Firewall (calomel.org) We suggest a password of 30 characters which is the maximum length allowed. To assist in making random passwords for carp aliases we suggest the following line. It queries /dev/random and outputs a clean 30 character string which you can cut and paste in place for "pass".
  5. ↑ RFC5798 Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6 - Virtual Router MAC Address (tools.ietf.org)
  6. ↑ OpenBSD PF - Firewall Redundancy (CARP and pfsync) (www.openbsd.org) net.inet.carp.preempt: Allow hosts within a redundancy group that have a better advbase and advskew to preempt the master. In addition, this option also enables failing over a group of interfaces together in the event that one interface goes down. If one physical CARP-enabled interface goes down, CARP will increase the demotion counter, carpdemote, by 1 on interface groups that the carp(4) interface is a member of, in effect causing all group members to fail-over together.
  7. ↑ 7,0 7,1 Enter Persistent CARP Maintenance Mode - advskew 254 causes problems (forum.opnsense.org, 26.08.2019)
  8. ↑ CARP: leaving maintenance mode on unit1 after reboot doesn't change advskew #3671 (github.com/opnsense/core/issues)

Dodatkowe informacje

Autor: Werner Fischer

Powiązane artykuły

Konfiguracja OpenVPN w OpenSense dla Road Warrior
Do artykułu
Konfiguracja systemu Windows 10 jako klienta OpenVPN
Do artykułu
Wymagania sprzętowe OPNsense
Do artykułu