V prvním díle jsme se drželi pouze toho, co nabízí jádro a nástroj ip. V praxi se však všechno to, co bylo popsáno v předchozím díle, řeší automaticky. K tomu je zapotřebí na každém konci transportního kanálu či tunelu spustit démona a nechat je mezi sebou autentizovat a domluvit minule probírané bezpečnostní asociace.
Ty stejné aplikace obvykle zároveň nastavují i bezpečnostní politiku, protože je jednodušší udržovat konfiguraci pohromadě. Pro autentizaci a domluvení bezpečnostních asociací se dnes používá protokol IKEv2, popřípadě kombinace starších protokolů IKEv1 a ISAKMP nebo KINK.
Implementace výměny klíčů
Linuxové jádro se nestará o to, kde se vezmou klíče. K tomu slouží výše zmíněné protokoly a software, který jimi komunikuje. Už v minulém článku jsem prozradil, které implementace mě zaujaly natolik, abych se jimi zabýval.
Než se ale pustíme do konkrétních implementací, bylo by dobré alespoň rámcově specifikovat požadavky. Nastavím je podle sebe, čímž se může stát, že pro mnohé z vás nemusí být následné srovnání použitelné. Ale k tomu se ještě na konci vrátím.
Mezi mé požadavky patří jednoznačně podpora IKEv2 a kvůli zpětné kompatibilitě IKEv1. Za samozřejmý požadavek považuji podporu IPv6. Pro většinu uplatnění potřebuji, aby mohla jedna strana připojená z libovolného místa a s libovolnou IP adresou (road warrior). Vzhledem velkému rozšíření považuji za nutnost podporovat IPv4 NAT Traversal.
Kromě toho bych rád mezi požadavky zařadil interoperabilitu s dalšími řešeními včetně těch uzavřených, ale její testování je relativně náročné a případně i nákladné. Dovolím si proto interoperabilitu prozatím zanedbat a zůstat u stejné implementace na obou stranách.
Racoon
Racoon je ve Fedoře kupodivu zabalen pod názvem ipsec-tools. Podporuje pouze protokol IKEv1 a lze v něm horko těžko naskriptovat přístup z dynamické adresy (road warrior). Vypadá, že si poradí s IPv6 i s maškarádou na protokolu IPv4. Už je to starší kus softwaru a jeho hlavní výhodou je to, že je jediný popsaný na ipsec-howto.org.
Racoon2
Samostatný projekt, který není odvozený od Racoonu. Umí nejspíš všechno, co jsem psal do kritérií. Jeho konfigurace je relativně komplikovaná a umožňuje vyladit opravdu jemné detaily. Na druhou stranu jsou dodávané konfigurační soubory uzpůsobené tak, že stačí vyplnit několik proměnných a pomocí include zvolit správný předpřipravený soubor. Z mého pohledu velmi zajímavý nástroj pro experimenty i pro nějaké komplikovanější nasazení.
Při balení Racoon2 pro Fedoru jsem narazil na hodně problémů s build systémem. Ten systém se prostě nechtěl jen tak nechat zkompilovat a nainstalovat dle zadaných cest. Projekt jako takový nejeví známky nějaké větší aktivity. Unikátní podpora protokolu KINK je bohužel závislá na konkrétním způsobu kompilace krb5, takže jsem byl stejně nucen ji vypnout.
Openswan
Mnohem jednodušší a příjemnější konfigurace ve stylu „řekni co chceš a my to uděláme“. Openswan je jako jediný součástí RHELu. Náznakem funguje prakticky každá jednotlivá vlastnost, kterou jsem popisoval v kritériích, ale nesmí se kombinovat.
Konkrétně mi při testech nefungoval protokol IKEv2 v kombinaci s road warrior nebo NAT traversal. Stejně tak nefungoval road warrior ani s IPv6. Zapsání adres IPv6 vedlo často k nesrozumitelným a zbytečným chybovým hláškám. Nebylo možné nechat Openswan dohodnout hybridní tunel (například síť IPv6 tunelovanou přes IPv4). Několik IPv4 na jednom síťovém rozhraní mu rovněž dělalo problém.
Openswan jsem testoval ve verzi 2.6.33.
Strongswan
Konfigurace vypadá téměř stejně jako u Openswanu. Rozdíl byl v tom, že se mi podařilo nakonfigurovat vše, co jsem chtěl. Strongswan mi podle mých kritérií vyšel jako nejpoužitelnější. Pro Fedoru a EPEL jsem zabalil verzi 4.6.1 a průběžně přidávám nové verze. Strongswan mě natolik potěšil, že všechny praktické ukázky předvádím na něm.
Ukázky konfigurace (Strongswan)
Začneme tím nejjednodušším. Vytvoříme tentokrát už oboustranný transportní kanál autentizovaný pomocí PSK.
conn test
auto=route
type=transport
left=2001:db8::a
right=2001:db8::b
authby=psk
mobike=no
Popis spojení je ve Strongswanu velmi přímočarý. V konfiguraci se nerozlišuje lokání a vzdálená strana, ale levá a pravá. Kterákoli z nich se může stát lokální nebo vzdálenou v závislosti na konfiguraci IP adres na rozhraní.
Direktiva auto umožňuje konfigurovat chování spojení při startu Strongswanu. Volba add znamená pouze to, že Strongswan konfiguraci načte (oproti výchozímu ignore), route způsobí zavedení bezpečnostní politiky a start otevře transportní kanál. Bezpečnostní politika samotná se používá k aktivaci výměny klíčů, až když začnou proudit data. Nemůžu říct, že mi vše 100% fungovalo, ale neměl jsem zatím čas to testovat důkladněji.
Volba type rozlišuje transportní a tunelové ESP. Levá a pravá strana jsou různé konce kanálu. Direktiva authby nastavená na psk znamená, že se k autentizaci bude používat sdílený klíč. Volba mobike umožňuje vypnout nebo zapnout protokol MOBIKE pro zabezpečení mobilních stanic. MOBIKE zatím při všech testech vypínám, protože generuje nějaké pakety navíc, takže se bez něj lépe vyznám ve výstupu tcpdumpu.
# ping6 2001:db8::b PING 2001:db8::b(2001:db8::b) 56 data bytes 64 bytes from 2001:db8::b: icmp_seq=2 ttl=64 time=83.7 ms 64 bytes from 2001:db8::b: icmp_seq=3 ttl=64 time=4.08 ms
Všimněte si, že první paket nedošel vůbec, druhý opožděně. Tak se chová volba route v kombinaci s linuxovým jádrem, které nezadržuje počáteční pakety do doby, než se vyřeší výměna klíčů.
19:44:59.334377 IP6 2001:db8::a.isakmp > 2001:db8::b.isakmp:
isakmp: parent_sa ikev2_init[I]
19:44:59.375153 IP6 2001:db8::b.isakmp > 2001:db8::a.isakmp:
isakmp: parent_sa ikev2_init[R]
19:44:59.478870 IP6 2001:db8::a.isakmp > 2001:db8::b.isakmp:
isakmp: child_sa ikev2_auth[I]
19:44:59.484953 IP6 2001:db8::b.isakmp > 2001:db8::a.isakmp:
isakmp: child_sa ikev2_auth[R]
19:45:00.196900 IP6 2001:db8::a > 2001:db8::b: ESP(spi=0xcc21c264,seq=0x1), ...
19:45:00.280492 IP6 2001:db8::b > 2001:db8::a: ESP(spi=0xc2779c7b,seq=0x1), ...
19:45:01.198069 IP6 2001:db8::a > 2001:db8::b: ESP(spi=0xcc21c264,seq=0x2), ...
19:45:01.202001 IP6 2001:db8::b > 2001:db8::a: ESP(spi=0xc2779c7b,seq=0x2), ...
Autentizovaná výměna klíčů IKEv2 je realizována výměnou celkem čtyř paketů. Při úspěchu následují po čtvrtém paketu už zašifrovaná data.
Road warrior
Výše uvedený způsob navazoval transportní kanál mezi dvěma předem známými adresami. Typicky je potřeba připojovat i cestovní stroje s dynamicky přidělenou adresou či dokonce adresou skrytou za IPv4 NATem.
Dosud byl kanál naprosto symetrický. Kterákoli strana ho mohla navázat jako první. V případě cestovního stroje je potřeba mít k dispozici pevně daný přípojný bod. Od té chvíle je jejich vztah spíše ve stylu klient a server. Řešení je jednoduché. Na straně serveru stačí umožnit připojení libovolné klientské adresy (%any).
conn test
auto=add
type=transport
left=%any
right=2001:db8::b
authby=psk
mobike=no
Klient naopak potřebuje použít adresu, kterou má přidělenou na rozhraní, které vede „do internetu“, tedy na rozhraní, na kterém je nastavena výchozí brána, od toho mírně zavádějící %defaultroute.
conn test
auto=add
type=transport
left=%defaultroute
leftid=@alpha.example.net
right=2001:db8::b
authby=psk
mobike=no
Další příklad už ukazuje tunelovou variantu. Tunelová varianta toho umí více než transportní díky tomu, že je v ESP schována celá další IP hlavička, která umožňuje místní routování. Kterákoli strana tunelu může být router, který takto zpřístupňuje celou síť. Nebo může být druhá IP hlavička využita pro virtuální IP adresu cestovního počítače, což se hodí zvláště na IPv4, kde je cestovní počítač za maškarádou a může mít IP adresu z kolizního rozsahu.
conn test
auto=route
type=tunnel
left=2001:db8::a
leftsubnet=2001:db8:a:a::/64
right=2001:db8::b
leftsubnet=2001:db8:b:b::/64
authby=psk
mobike=no
Závěr
Software se vyvíjí. Navíc při testování člověk může udělat chybu, takže budu rád, když mě upozorníte na jakékoli nejasnosti v tomto článku. Rovněž se může stát, že jsem vůbec netestoval pro vás zajímavý setup či interoperabilitu s vaším oblíbeným zařízením. To můžu napravit pouze za předpokladu, že mi poskytnete přístup k takovémuto zařízení a případnou pomoc s jeho konfigurací.
V tuto chvíli, při použití mezi různými stroji s Fedorou nebo jinou linuxovou distribucí s relativně aktuální verzí Strongswanu, nemám důvod používat komplikovaný a zastaralý Racoon, ani Openswan, který sice jednotlivě poskytuje všechny moderní vymoženosti, ale bohužel nefungují dohromady. Zatím jsem ale neměl možnost testovat interoperabilitu s dalšími implementacemi.
Jediný z uvedených projektů, který by se mohl funkčně vyrovnat Strongswanu (nebo ho možná i přesáhnout), je Racoon2. Má relativně komplikovanou konfiguraci, ale má připravené šablony pro konkrétní konfigurace. Aktivitou se tento projekt bohužel nemůže se Strongswanem srovnávat.
