Dotaz: Pojmenování síťového rozhraní pro ipsec

[Petr Bravenec]

Dobrý den, snažím se rozběhat v kernelu 2.6 openswan 2.4. V dřívějších verzích kernelu (zatím mi to běhá na 2.4) se při vytvoření tunelu vytvořilo nové zařízení pojmenované ipsec0 - nyní se vytvoří nové zařízení pojmenované eth0 - tedy stejně jako původní fyzické zařízení. Na funkčnost to nemá žádný vliv, ale velmi špatně se s tím pracuje v iptables - na síťové kartě, která je připojená ven do internetu, se mi objevuje provoz jak venkovní, tak lokální. Nevíte někdo, jak z toho ven?

Odpovědi

[Michal Kubeček]

Nijak, nativní implementace v jádře není založena na směrování, ale na nastavení security policy, takže tam žádný virtuální interface nevzniká. Ono vůbec roubování FreeS/WAN resp. openswan na jádro 2.6 je dost umělé, spíš bych vám doporučil použít příkazy racoon a setkey.

[Petr Bravenec]

Jo, to už vím několik dní. Přesto, než začnu předělávat fungující a ověřenou konfiguraci a experimentovat s něčím novým, zkusím se zeptat jinak: pokud použiju příkazy racoon a setkey, budu v iptables schopný rozeznat, který paket byl šifrovaný, přišel tunelem, a který paket je pokus o spoofing a přišel ze stejného síťového rozhraní, ale z internetu?

[Michal Kubeček]

Trik je v tom, že máte-li správně nastavenou konfiguraci, žádný takový paket se objevit nemůže. Pokud nastavíte odpovídající security policy např. takto

  spdadd 1.1.1.1 2.2.2.2 any -P out ipsec
          esp/transport//require;
  spdadd 2.2.2.2 1.1.1.1 any -P in ipsec
          esp/transport//require;

způsobí slovo require ve druhé politice, že žádný paket se zdrojovou adresou 2.2.2.2 a cílovou 1.1.1.1 bez ESP headeru přijít nemůže, protože by ho systém ignoroval.

[Petr Bravenec]

Podařilo se mi to vyřešit i trochu jinak - esp paket označkuju pravidlem

iptables -t mangle -p esp -j MARK --set-mark 1

a pak ho v dalším pravidle FORWARD bezpečně poznám - značkování paketu naštěstí přežije rozšifrování:

iptables -A FORWARD --mark 1 -i eth0 -j moje-pravidlo

Nicméně jedna věc mě zaráží: pakety ze sítě A do sítě B tunelem procházejí, odpovědi ze sítě B do sítě A procházejí tunelem také. V případě, že začnu komunikaci v síti B do sítě A, pakety se na tunel vykašlou a lezou do internetu. Pravidla v iptables jsou přitom velmi jednoduchá - v obou směrech jde o jednoduché pravidlo ACCEPT a pakety procházejí vždy stejným pravidlem. Pokud firewall vypnu (zruším všechna pravidla) a nastavím v iptables politiku na ACCEPT, pakety lezou správně.

[Michal Kubeček]

Nemůže za to nějaké příliš obecné pravidlo pro NAT?

[Petr Bravenec]

Ach, pravda. Díky za nakopnutí správným směrem.

[Petr Bravenec]

Ještě pro doplnění - ptám se proto, že openswan je, pokud to dobře chápu, postavený nad stejným kernelovým modulem jako racoon a setkey, takže předpokládám, že po pár dnech experimentování bych jen vyměnil utilitky pro výměnu klíčů a v iptables bych stejně nebyl schopný rozeznat dobrý paket od zlého. Chápu to správně?

[Michal Kubeček]

Ano, funkčně to bude víceméně stejně. Rozdíl vidím spíš v tom, že openswan jakožto FreeS/WAN používá frontend, který byl původně napsán k odlišnému backendu (KLIPS pro jádra 2.4). Později byl sice upraven tak, aby fungoval i se současnou jadernou implementací, ale tím, že udržuje původní syntaxi konfiguračních souborů, není vždy úplně jasné, jakým způsobem se mapují pojmy frontendu FreeS/WAN na odpovídající prvky implementace, která je v jádře. Z tohoto pohledu je použití racoon a setkey průhlednější, protože od základu počítá s implementací IPsec v jádrech 2.6, takže je lépe vidět, co co ve skutečnosti znamená.