V práci jsem dostal za úkol otestovat funkcionalitu firewalu
pfSense verze 1.2.3 a zejména jeho Hardware Redundancy (CARP) a to ještě IPSec tunnel mezi router A a B. Tento firewal hojně používám, ale CARP jsem ještě nekonfiguroval. Stanovil jsem si cíl a tím bylo postavit za pomoci virtualizace celkem 4 routery, vždy dva a dva, které jsem umístil do jednotlivých DMZ rozsahů s veřejnými IP adresami.
Nejprve poznamenám, co že je to ten CARP. Ze zakoupené
knihy jsem vyčel historii protokolu
CARP - Common Address Redundancy Protocol, který vznikl jako svobodné řešení failover, jež vzniklo díky projektu
OpenBSD. Společnost Cisco má svůj protokol VRRP a HSRP. Bohužel patenty znemožňují jejích implementaci ve svobodných otevřený systémech. CARP je tedy znám hlavně v *BSD systémech.
Mé kroky k zprovoznění
pfSense Hardware Redundancy (CARP) vedly logicky na
dokumentaci projektu pfSense. Zde je stručný popis failover firewallu. Dále je tu
klikací tutorial, který objasní dané řešení. Zprovoznil jsem již zmíněné routery v ESXi 4.1, ktré vyžaduji 3 IP od ISP (veřejné adresy), dále pak potřebujeme 3 IP z LAN. Vždy dvě IP jsou přiřazeny jednotlivým routerům a jedna IP tvoří onen CARP interface, který zajišťuje přehození provozu z MASTER na BACKUP a případně naopak. Jednou z důležitých součástí tohoto řešení je
pfsync, kterým si firewaly předávají informace jako FW Rule, NAT, IPSec, Virtual IP atd. Vše je patrné v tutorialu. Po zprovoznění funkční synchronizace, vytvoříme CARP interface, které přiřadíme do oddělených VHID Group. Na konzoli firewalu se nám objeví carpX device.
# ifconfig carp0
carp0: flags=49 metric 0 mtu 1500
inet 80.250.16.10 netmask 0xffffff80
carp: MASTER vhid 1 advbase 1 advskew 0
# ifconfig carp1
carp1: flags=49 metric 0 mtu 1500
inet 192.168.0.1 netmask 0xffffff00
carp: MASTER vhid 2 advbase 1 advskew 0
Po vytvoření CARP device na FW A se do pár sekund konfigurace přenese na FW B. Vše zajiťuje pfsync mechanizmus. Popisovat jednotlivé kroky není třeba, vše je jasně vidět v tutoriálu.
Dalším úkolem bylo nastavení IPSec tunelu mezi dvěma faiover firewall clustery (úžasná věta). Nastavením VPN / IPSec se nám zapne podpora IPSec, tím mám hlavně na mysli aktivace programu
Racoon, který je soužástí ditribuce pfSense. Podpora IPSec je v *BSD díky implementaci
KAME.net. Racoon zajišťuje výměnu klíčů mezi routery pomocí protokolu
ISAKMP.
Nastavení VPN
IPSec politik se opět přenese na druhý firewall v clusteru. Obdobná konfigurace proběhne i na druhé straně tunelu. A ejhle již např. ping ICMP jde z LAN A do DMZ A, kde se zabalí do ESP a předá na druhou stranu tunelu, kde se opět ESP otevře a vydá svůj poklad z LAN A na druhém konci tunelu.
Ohledně ESXi bylo nutno vytvořit a povolit v
port groups nastavení, dle
doporučení. Pozor, je to jistý bezpežnostní ústupek.
Pro otestování průchodů tunelu jsem si zprovoznil dva
Ubuntu servery, které jsem posadil do LAN za failover routery. Mám oblíbený nástroj nesoucí jméno
TTCP, který změří rychlost přenosu tunelem.
nasloucháme:
ubu-a:root:~> ttcp -v -r -s -f M -l 25600
ttcp-r: buflen=25600, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: socket
ttcp-r: accept from 192.168.2.10
ttcp-r: 52428800 bytes in 68.72 real seconds = 0.73 MB/sec +++
ttcp-r: 52428800 bytes in 0.57 CPU seconds = 87.72 MB/cpu sec
ttcp-r: 8981 I/O calls, msec/call = 7.84, calls/sec = 130.68
ttcp-r: 0.0user 0.5sys 1:08real 0% 0i+0d 416maxrss 0+6pf 8662+13csw
ttcp-r: buffer address 0xd94000
spojíme se s nasluchačem:
ubu-b:root:~> ttcp -v -t -s -f m -l 25600 192.168.1.10
ttcp-t: buflen=25600, nbuf=2048, align=16384/0, port=5001 tcp -> 192.168.10.100
ttcp-t: socket
ttcp-t: connect
ttcp-t: 52428800 bytes in 68.45 real seconds = 5.84 Mbit/sec +++
ttcp-t: 52428800 bytes in 0.03 CPU seconds = 13333.33 Mbit/cpu sec
ttcp-t: 2048 I/O calls, msec/call = 34.22, calls/sec = 29.92
ttcp-t: 0.0user 0.0sys 1:08real 0% 0i+0d 414maxrss 0+8pf 455+0csw
ttcp-t: buffer address 0x2468000
na routeru pfhaA je možno sledovat ESP šifrovaný provoz:
tcpdump -i em1 host 80.250.16.10 and host 193.179.144.106
13:11:04.453352 IP 193.179.144.106 > 80.250.16.10: ESP(spi=0x07d761dc,seq=0x1aaf8), length 116
13:11:04.453696 IP 80.250.16.10 > 193.179.144.106: ESP(spi=0x06061ce4,seq=0xd580), length 116
13:11:04.468895 IP 193.179.144.106 > 80.250.16.10: ESP(spi=0x07d761dc,seq=0x1aaf9), length 116
13:11:04.469151 IP 80.250.16.10 > 193.179.144.106: ESP(spi=0x06061ce4,seq=0xd581), length 116
Zde je právě probíhající vyměna klíčů o kterou se stará Racoon
13:12:31.622854 IP 193.179.144.106.isakmp > 80.250.16.10.isakmp: isakmp: phase 1 I agg
13:12:31.638247 IP 80.250.16.10.isakmp > 193.179.144.106.isakmp: isakmp: phase 1 R agg
13:12:40.712942 IP 193.179.144.106.isakmp > 80.250.16.10.isakmp: isakmp: phase 1 I agg
13:12:40.713083 IP 80.250.16.10.isakmp > 193.179.144.106.isakmp: isakmp: phase 1 R agg
Pracovně jsem se více seznámil se zajimavým autentizačním serverem nebo spíše systémem, který kombinuje řadu funkcí a vlastností v oblasti autentizace a authorizace. Je jím produkt společnosti RCDevs SA - Luxembourg - OpenOTP.
Doposud jsem se domů připojoval jen pomocí Secure Shell a když bylo třeba pomoci Wake on LAN jsem si zapnul domácí PC. Jelikož se občas potřebuji připopjit domů a dostat se na nějaké to domací HTTP je již potřeba VPN.
