IPSec na Linuxu, krok za krokem - 2

24. 3. 2006 | Jan Vondráček

Články - IPSec na Linuxu, krok za krokem - 2  

Pracuji už dlouhou dobu s Cisco zařízeními, routery, pixy a další. Můj takový koníček je zkoušet nahrazovat služby, která Cisco zařízení poskytují, Linuxem. Chci se s vámi podělit o své zkušenosti. Druhá fáze, quick mód, se stará o výpočet vlastního šifrovacího klíče určeného pro přenos dat. Quick mód posílá, jako Main mód, tři zprávy.

IPSEC, KLIPS

Druhá fáze, quick mód, se stará o výpočet vlastního šifrovacího klíče určeného pro přenos dat. Quick mód posílá, jako Main mód, tři zprávy. Zprávy jdou ale již pomocí dvou jednosměrných šifrovaných tunelů, šifrovací klíč pro přenos těchto zpráv je použit z 1. fáze. Tato část je vlastně trochu ořezaný Main mód:

1. Posílají se policy s vygenerovanými čísly pro druhou fázi. Zde je pro nás důležitý parametr pfs, viz tabulka pojmů. První paket jde od A do B.
2. Strana B pošle svá čísla a policy straně A.
3. A pošle B testovací data zašifrovaná již klíčem pro přenos dat. Tato zpráva se již nepotvrzuje a po ní už jedou data.

Quick mód, a pak i samotný přenos dat, probíhá protokolem ESP. To je protokol z rodiny ip a má číslo 50 (jen pro upřesnění TCP má číslo 6, viz /etc/protocols). Tento protokol nemá porty, a proto může být občas problém jej propustit natem, ale iptables s tím nemá problémy, cisca to mají až od nejnovějších iosů. Tady máte příklad, jak dostat ipsec skrz iptablesový firewall (vIPa - je veřejná ip strany A, pIPb - neveřejná ip strany B atd.):

iptables -t nat -A  PREROUTING -i eth0 -p 50 -j DNAT --to-destination pIPb
iptables -t nat -A  PREROUTING -i eth0 -p udp --dport 500 -j DNAT --to-destination pIPb:500
iptables -A FORWARD -s vIPa -d vIPb -p udp --dport 500 -j ACCEPT
iptables -A FORWARD -s vIPa -d vIPb -p 50 -j ACCEPT

V případě, že nepřekládáme a ipsecový stroj má veřejnou IP, natovou částí se vůbec nezabýváme a řetězec FORWARD nahradíme řetězcem INPUT. V tomto případě je eth0 jako veřejný interface a síť je za něj maškarádována. Defaultní politika řetězce INPUT i FORWARD je DROP.

NAT-T

Nat traverzal je způsob, jak dostat ipsec skrz PAT (port address translation), pokud nemáte možnost na překladovém stroji provést statický nat. Příkladem PATu je třeba maškaráda.

Ipsec zjišťuje přítomnost natu ve fázi Main módu, UDP projde patem bez potíží. Pokud je nat-t na zařízení podporován (a podpora je zapnuta), je při první zprávě připojena hash zdrojové IP adresy stroje. Na druhé straně se obdržená hash porovná s nově vytvořenou hashí a pokud se neshodují, stojí v cestě nat. Ipsec se pak v druhé fázi přepíná na jiný protokol než ESP, a to na UDP 4500, který natem projde již bez potíží. Openswan podporu nat-t má, jen se musí zapnout. Cisca ji mají defaultně zapnutou, zapíná se sama podle potřeby.

Program Openswan

V Cisco, nebo jiných zařízeních, je ipsec součástí IOSu, do Linuxu jej musíme dodat. Openswan sestává ze tří částí. První jsou shellové skripty, které usnadňují spouštění. Jsou bashové a perlové, i když perl není pro samotnou funkci nebo kompilaci nutný, a tudíž nemusí být nainstalován. Druhá část jsou binární programy jako pluto pro sestavování spojení. A poslední je kernelový modul, který provádí vlastní šifrování. Protože se o šifrování dat stará jádro, je to velmi výkonné řešení. Můj pokusný stroj, P120 na 512kb lince, byl při plném vytížení linky zatížen zhruba na 10%, což se výkonnostně vyrovná Cisco PIXu 506.

Openswan můžete získat jako balíček pro svou distribuci, ale pokud používáte jiný kernel, než který je v distribuci, stejně vám to k ničemu nebude. Nejjednodušší je program zkompilovat, pro kompilaci budete potřebovat tyto balíčky:

binutils-2.14.90.0.6-i486-1 gcc-g++-3.2.3-i486-1 gcc-objc-3.2.3-i486-1 gcc-3.2.3-i486-2 glibc-2.3.2-i486-1 gmp-4.1.2-i486-2

iproute2-2.4.7_now_ss020116_try-i386-4 kernel-headers-2.4.22-i386-1 kernel-source-2.4.22-noarch-3 make-3.80-i386-1 m4-1.4-i386-2 perl-5.8.0-i486-5

Seznam balíčků je pro Slackware, ale ostatní distribuce to budou mít podobné. Uvádím zde i balík iproute2, který obsahuje program ip. Openswan ho využívá pro to, aby po sestavení spojení automaticky naroutoval přenášenou síť do ipsecového tunelu. Kernel-source můžete použít samozřejmě jiný, než máte právě na stroji spuštěný, ale verzi kernelu je nutno přesně dodržet. U zbytku programů jen nesmíte kompilovat na vyšší verzi gcc, než používá váš systém, jinak je to ok.

Kompilujeme: make KERNELSRC=/usr/src/linux/ programs module pro kernel 2.4 i pro kernel 2.6. Pokud potřebujeme jen modul, pak samozřejmě vynecháme parametr programs. Pak už zbývá jen make install, kernelový modul musíte nakopírovat manuálně. Já jsem modul dal do /lib/modules/2.4.24/kernel/crypto/, nezapomeňte na depmod -a, než modul nahrajete modprobe ipsec. Modul ipsec.o se nachází v podadresáři modobj, tam, kde máme zdroj openswanu.

Méně zkušeným správcům doporučuji, aby své stroje měli vždy postavené na balíčcích příslušné distribuce. Jednak z důvodu přehlednosti, ale také bezpečnosti. Představte si, že postavíte stroj jako bezpečnou bránu a necháte na něm kompilátor i se zdrojovými kódy. Potenciální útočník, pokud se do stroje dostane, má tak k dispozici veškeré nástroje pro tvorbu vlastních programů a nahrazování původních programů. A hackování linuxových strojů je především o tomhle. Proto určitě pro ostrý provoz kompilujte na jiném stroji a openswan instalujte jako balíček. Pro vytvoření instalačních balíčků existuje spousta programů, třeba Checkinstall. Ovšem ten si vytváření balíčku pro openswan vylámal zuby. Co teď? Řešení je jednoduché a zvládne ho každý. Vytvořte si adresář s adresářovou strukturou podle přiloženého souboru, do adresářů nakopírujte zkompilované programy a balíček vám pak vytvoří krásně makepkg. Makepkg je pro Slackware, ale ostatní distribuce také obsahují příslušné nástroje na tvorbu balíčků. Mnou vytvořený balík vám také dám k dispozici, moduly pro kernel 2.4.24 a 2.4.22 se po instalaci nakopírují do homu roota, odkud je musíte ještě podle jádra zkopírovat k ostatním modulům.

Jestli máte v pořádku nainstalováno a zaveden modul ipsecu, můžeme pokročit dále. Příkazem ipsec verify můžete otestovat, podle dokumentace k Openswanu, zda vše v pořádku běží. Testuje to perlový skript a myslím, že to ani nemusíte dělat, není to k ničemu. Test vám bude třeba řvát na nepřítomnost rsa klíčů, záznamy v DNS a dalších. Jenže proč generovat RSA klíče, když je nebudeme používat? Ne, uděláme to jednodušeji. Jen si ověřte přes lsmod, že máte modul ipsec zaveden, ifconfig -a vám musí ukázat nová rozhraní ipsec0 až ipsec4 a vrhneme se rovnou na konfiguraci. Po nakonfigurování stačí napsat ipsec setup start, případně stop nebo restart a VPN se spustí. Při spuštěné VPN si status můžete zkontrolovat příkazem ipsec whack --status, více příkazů potřebovat nebudete.

Konfigurace VPN

Konfiguraci VPN si ukážeme na vzorovém příkladu. Máme dvě lokality, kde na jedné straně máme Cisco router, do internetu připojený sériovou linkou. Na druhé straně linuxové PC připojené přes wifi. Každá strana má vlastní přístup do internetu, potřebujeme je tedy propojit jen jako dvě LAN.

Na linuxové straně musíme provést konfiguraci ve dvou souborech /etc/ipsec.secrets, kde je klíč. A /etc/ipsec.conf, kde je konfigurace spojení.

konfigurace Linuxu
------------------

/etc/ipsec.secrets 
213.211.4.208 194.15.7.21: PSK "abc123"

/etc/ipsec.conf
config setup
        interfaces="ipsec0=eth0"
        klipsdebug=none
        plutodebug=none
				
conn cisco
        type=tunnel
        authby=secret
        left=213.211.4.208
        leftsubnet=192.168.17.0/24
        leftnexthop=213.211.4.1
        leftid=213.211.4.208
        right=194.15.7.21
        rightsubnet=192.168.1.0/24
	ike=3des-md5
        esp=3des-md5
        keyexchange=ike
        pfs=yes
        auto=start


konfigurace cisca
-----------------

crypto isakmp policy 1
 encr 3des
  hash md5 
  authentication pre-share
  group 5  
 crypto isakmp key abc123 address 213.211.4.208 no-xauth
!         
!         
crypto ipsec transform-set MYSET esp-3des esp-md5-hmac 
!         
crypto map MYMAP local-address Loopback0
crypto map MYMAP 1 ipsec-isakmp 
 set peer 213.211.4.208
 set transform-set MYSET 
 set pfs group5
 match address 101
!         
interface Loopback0
 ip address 194.15.7.21 255.255.255.255
!
interface Serial0
 ip unnubered Loopback0
 crypto map MYMAP
!
ip route 0.0.0.0 0.0,0.0 Serial0
!
access-list 101 permit ip 192.168.1.0 0.0.0.255 192.168.17.0 0.0.0.255

Na tomto si vysvětlíme jednotlivé položky konfigurace. Další položky, které zde nemáme, si můžete přečíst v dokumentaci v souboru ipsec.conf. Konfigurace má dvě sekce, config setup, která je společná pro všechna spojení, můžeme ji nazvat globální. A pak konkrétní část pro každé spojení. Každé spojení může tak mít jiné parametry enkrypce.

interfaces určuje, na kterém interface ipsec visí. Pokud budete mít tunelů více, můžete tam dát %defaultroute (interface s defaultní routou) nebo jednotlivé tunely oddělit mezerou ipsec0=eth0 ipsec1=eth0. U cisca je to pověšení cryptomapy na interface, zde Serial0.

klipsdebug a plutodebug je chování openswanu z hlediska debugování. To je užitečné při problémech, ale pro praktický život určitě ne, debug generuje ohromné množství logů. Ale určitě doporučuji, aby si každý alespoň jednou debug zapnul a pak se pořádně na log podíval, aby viděl, jak se ipsec spojuje.

nat_traversal parametr zde není uveden, defaultně je ne. nat_traversal=yes podporu zapne a zároveň doporučuji použít leftid (viz dále).

type=tunnel zapíná tunelovací mód, další volbou je mód transport. Více říká tabulka na začátku článku s popisem terminologie. U cisca je tunelovací mód výchozí, mění se v transform setu.

authby=secret určuje, že autentizace bude prováděna sdílenými klíči. Pozor defaultně je volba na RSA.

left... a right... jsou parametry pro IP adresy. Není řečeno, že levá strana musí být lokální a pravá vzdálená, to proto, aby se stejný konfigurační soubor nechal použít na obou stranách VPN, tedy pokud spojujeme dva openswany. Která strana je lokální, si openswan určí podle adresování interfaců. Subnet určuje provoz, který se bude kryptovat, u cisca je to access-list 101. Je možno zadat i položku %any, což po spojení ipsecu dá defaultní routu do ipsecového tunelu. Samotný parametr left a right určuje konce ipsecového tunelu. Id se používá především u natu nebo pokud máme více interfaců, kterými může provoz odcházet. Takto přesně určíme, jaká IP se má pro daný tunel použít. Ekvivalent u cisca je crypto map local address. Next hop není nutno použít.

keyexchange určí, jaká metoda se má použít pro sestavení tunelu, zde automatická pomocí ike. U cisca je to volba ipsec-isakmp v parametru vytváření cryptomapy.

pfsgroup sice uvedená není, je použitá defaultní skupina 5, ale takto ji můžeme také měnit. pfsgroup=1024 je tedy skupina2. Tento parametr mění skupinu pro ike i ipsec.

ike nastavuje policy, nebo-li metodu šifrování, dh skupiny a hashování pro Main mód. U cisca to vidíme v isakmp policy 1. Přípustné hodnoty jsou:

• 3des-md5-modp1536, 3des-md5-modp1024 (zde navíc měníme i dh skupinu na 2), 3des-md5, 3des-md5-96 (96 říká že MD5 hash 96-bitová)
• 3des-sha1-modp1536, 3des-sha1-modp1024
• aes128-sha1, aes128-sha1-modp1536, aes256-sha1-modp1024 (u aesu je ještě nutno určit šířku klíče, šířky klíče jsou uvedeny v tabulce pojmů)
• aes128-md5, aes128-md5-modp1536
• !aes256-md5 (nařizuje striktní použití aes 256 a md5)

esp nastavuje parametry pro quick mód a pro přenos dat. Hodnoty jsou stejné jako pro ike. U cisca se tyto parametry nastavují v crypto mapě.

pfs zapne pfs pro quick mód.

auto, tento parametr bude nahazovat tunel hned po startu ipsecu (ipsec setup start). To budeme asi také chtít, abychom to nemuseli dělat manuálně.

keylife parametr zde není uveden, určuje životnost šifrovacího klíče. Defaultně je 8 h, maximálně 24 h, což je i defaultní hodnota v ciscu. Mění se keylife=24h. Security asociation zůstává při znovupočítání klíče sestavena, probíhá tedy znovu jen quick mód.

ikelifetime říká, jak dlouho bude sestavená security asociation - neboli jak dlouho si zařízení budou věřit, že se ověřila. Tato hodnota bývá delší než životnost šifrovacího klíče.

Tímto máme nakonfigurováno, pak stačí dát jen ipsec setup start a spojení se nám vytvoří. Po sestavení spojení se nám objeví nový interface, zde ipsec0. Openswan pomocí programu ip sám naroutuje síť uvedenou jako subnetlan do tunelu. Linux přistupuje k interfacu jako k fyzickému, lze ho tedy měřit přes mrtg nebo iptraf. Restart, třeba při přidání nového tunelu, uděláte překvapivě ipsec setup restart a ipsec zastavíte ipsec setup stop. Sestavené tunely uvidíte ve výpisu ipsec whack --status.

V druhém příkladu vám ukážu konfiguraci pixu a také konfiguraci složitější VPN. Linuxové stroje zde máme tři a síť má topologii hvězdy. Stroj Linux1 není ipsecový, běží na něm nat a stroj dělá bránu do internetu. Stroj 2 je ipsecová centrála, končí na něm dva tunely. Pix a Linux3 jsou normální VPN pobočky.

Linux1

Je brána do internetu, firewalluje a natuje maškarádou. Proto na něm musíme udělat prostupy a překlady. Použijeme iptables a v konfiguraci bude tohle:

iptables -t nat -A  PREROUTING -i eth0 -p 50 -j DNAT --to-destination 192.168.17.5
iptables -t nat -A  PREROUTING -i eth0 -p udp --dport 500 -j DNAT --to-destination 192.168.17.5:500
iptables -A FORWARD -s 194.15.7.21 -d 213.211.4.208 -p udp --dport 500 -j ACCEPT
iptables -A FORWARD -s 194.15.7.21 -d 213.211.4.208 -p 50 -j ACCEPT
iptables -A FORWARD -s 194.15.7.25 -d 213.211.4.208 -p udp --dport 500 -j ACCEPT
iptables -A FORWARD -s 194.15.7.25 -d 213.211.4.208 -p 50 -j ACCEPT
route add -net 192.168.1.0/24 gw 192.168.17.5
route add -net 192.168.2.0/24 gw 192.168.17.5

Linux2

Na tomto stroji nesmíte zapomenout zapnout routování (echo 1 > /proc/sys/net/ipv4/ip_forward).

/etc/ipsec.secrets 
213.211.4.208 194.15.7.21: PSK "ajipI$%A*773jHU"
213.211.4.208 194.15.7.25: PSK "prilis_zluty_kun"

/etc/ipsec.conf
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
				
conn Linux3
        type=tunnel
        authby=secret
        left=192.168.17.5
        leftsubnet=192.168.17.0/24
        leftnexthop=192.168.17.1
        leftid=213.211.4.208
        right=194.15.7.21
        rightsubnet=192.168.1.0/24
	ike=aes256-md5
        esp=aes256-md5
        keyexchange=ike
        pfs=yes
        auto=start

conn pix
        type=tunnel
        authby=secret
        left=192.168.17.5
        leftsubnet=192.168.17.0/24
        leftnexthop=192.168.17.1
        leftid=213.211.4.208
        right=194.15.7.25
        rightsubnet=192.168.2.0/24
	ike=3des-md5
        esp=3des-md5
        keyexchange=ike
        pfs=yes
        auto=start

Linux3

/etc/ipsec.secrets 
213.211.4.208 194.15.7.21: PSK "ajipI$%A*773jHU"

/etc/ipsec.conf
config setup
        interfaces=%defaultroute
        klipsdebug=none
        plutodebug=none
				
conn Linux3
        type=tunnel
        authby=secret
        left=192.168.17.5
        leftsubnet=192.168.17.0/24
        leftnexthop=192.168.17.1
        leftid=213.211.4.208
        right=194.15.7.21
        rightsubnet=192.168.1.0/24
	ike=aes256-md5
        esp=aes256-md5
        keyexchange=ike
        pfs=yes
        auto=start

PIX

X Version 6.3(4)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
hostname pix
domain-name openswan.cz
clock timezone CET 1
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
fixup protocol smtp 25
fixup protocol sqlnet 1521
access-list inside permit ip any any
access-list inside permit icmp any any
access-list nonat permit ip 192.168.2.0 255.255.255.0 192.168.17.0 255.255.255.0
access-list ven permit ip 192.168.2.0 255.255.255.0 192.168.17.0 255.255.255.0
pager lines 24
logging on
logging timestamp
logging console warnings
logging buffered debugging
icmp permit any outside
icmp permit any inside
mtu outside 1500
mtu inside 1500
ip address outside 194.15.7.25 255.255.255.128
ip address inside 192.168.2.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 192.168.2.0 255.255.255.0 0 0
route outside 0.0.0.0 0.0.0.0 194.15.7.1 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
ntp server 195.113.144.201 source outside
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set MYSET esp-3des esp-md5-hmac
crypto map mapa 1 ipsec-isakmp
crypto map mapa 1 match address ven
crypto map mapa 1 set peer 213.211.4.208
crypto map mapa 1 set transform-set MYSET
crypto map mapa interface outside
isakmp enable outside
isakmp key ******** address 213.211.4.208 netmask 255.255.255.255 no-xauth
isakmp identity address
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption 3des
isakmp policy 1 hash md5
isakmp policy 1 group 5
isakmp policy 1 lifetime 86400
telnet timeout 5
ssh 213.211.4.208 255.255.255.255 outside
ssh timeout 60
console timeout 0
terminal width 80

Jak vidíte, je to stále variace na jedno téma. Jen si musíte dát pozor na správně napsané adresy, v tom množství se člověk snadno uklepne, a také na zapnuté routování. Sestavené tunely doporučuji testovat pingem a sledovat při tom na jednotlivých routerech, jaké protokoly z nich lezou. Ipsec můžete mít sice spojený, ale chybou v routování vám můžou data téci mimo tunel. Vím o čem mluvím, také se mi to už stalo.

X-auth

Toto je použití ipsecu v případě, že jedna ze stran nemá pevně danou IP adresu. Ipsec je na pevných IP založen a pokud se jedna strana s ip mění, nebude fungovat. Toto je běžné při připojení dial-upem, ADSL bez pevné IP nebo u mobilního připojení. U tohoto způsobu ipsecu se zapíná místo main módu agressive mód. Ten má jen tři pakety jako quick, ale používá ještě další autentizaci uživatele jménem a heslem. Pre-share klíč je nahrazen VPN skupinou s heslem. Klient má nakonfigurovanou pevnou IP VPN serveru a svou IP dynamicky přidělovanou. Sever má svou pevnou a místo klientských má nuly, které znamenají jakoukoliv IP.

X-auth jsem s openswanem nezkoušel, ani proti Ciscu. Existuje totiž mnoho VPN programů, které mi přijdou vyřešeny pro tento účel lépe. Je to především OpenVPN, které má klienty i pro ostatní OS. No a samozřejmě Cisco, které své VPN klienty má také pro všechny OS. Jejich instalace i v Linuxu je snadná a fungování bezproblémové. Pokud někdo tento typ VPN od Cisca používá, klienta si může stáhnout zdarma, takže není co řešit. A na OpenVPN bylo již vydáno dost návodů v češtině, ale i jejich dokumentace je skutečně jednoduchá a popsaná krok za krokem. OpenVPN sice nefunguje na principu ipsecu, ale na SSL šifrování. Z hlediska fungování je to úplně jedno.

Tento způsob nasazení VPN je oproti pevném spojení dvou lokalit z bezpečnostních důvodů dost omezené, protože neumí přenášet routované sítě, které jsou za klientem. Takže jestliže budete chtít propojit dvě lokality, musíte použít způsob nastíněný výše. Cisco VPN klient prostě neumí do šifrovaného kanálu nic jiného než komunikaci od klienta a OpenVPN zase neumí u spojení peer2peer více než jeden tunel. Přestože jsem Openswan takto nezkoušel, popíšu jak se takové spojení konfiguruje podle toho, co jsem vyčetl z dokumentace:

1. Pro autorizaci je využíván unixový PAM model, takže ho musíte mít nainstalovaný. Na webu Openswanu je to také popsáno krok za krokem. Nebo lze použít systém htpasswd.
2. Pak editujete Makefile.inc a dáte položku USE_XAUTH na true. Pro pam ještě musíte zapnout USE_XAUTHPAM, ale pak už normálně kompilujete a instalujete.
3. Po kompilaci přidáte nový modul contrib/pam.d/pluto do /etc/pam.d/ a pro x-auth budou využívána unixová hesla. Nebo si vytvoříte soubor/etc/ipsec.d/passwd se syntaxí username:heslo:connection_name.
4. Na serverové straně vykonfigurujete:

   /etc/ipsec.secrets
   0.0.0.0 1.2.3.4	: PSK "heslo vpn skupiny"
   
   /etc/ipsec.conf
   leftxauthserver=yes
   rightxauthclient=yes

   Logicky ip 1.2.3.4 je jen ukázková IP serveru, nuly v druhé IP znamenají všechny IP. Levou a pravou stranu v ipsec.conf lze samozřejmě prohodit podle vašich potřeb. Z ipsec.conf je to jen krátká ukázka, samozřejmě chybí kryptovací metody atd. Ale to jsme si už ukázali předtím.
5. Na straně klienta je konfigurace podobná:

   /etc/ipsec.secrets
   @groupname    1.2.3.4 : PSK "heslo vpn skupiny"
   
   /etc/ipsec.conf
       conn myclient
   	 left=%defaultroute
   	 leftid=@groupname
   	 leftxauthclient=yes
   	 right=1.2.3.4
   	 rightsubnet=192.168.1.0/24
   	 rightxauthserver=yes
   	 authby=secret
   	 auto=add
   

   Ipsec pak startujeme naprosto normálně. Je zde rozdíl v tom, že server se nepokouší aktivně spojit s klientem jako v případě peer2peer, ale čeká na něj. Při nastartování ipsecu na klientovi se klient začne spojovat se serverem a vyžádá si od uživatele jmého a heslo. Všiměte si, že v konfiguraci ipsecu nikde nefigurují uživatelská jména a hesla, to, co zde máme, je jen VPN skupina s heslem, které nahrazuje pre-share klíč. Uživatelská hesla jsou právě zcela oddělena od vlastní VPN a často bývají ověřována radiusem atd., tedy ovládána zcela vzdáleně mimo vlastní VPN.

A to je vše přátelé. Doufám, že tyto informace využijete a že vám vaše vpn sítě na Linuxu budou fungovat spolehlivě.

Diskuse k tomuto článku

[Michal Kubeček]

V Cisco, nebo jiných zařízeních, je ipsec součástí IOSu, do Linuxu jej musíme dodat.

To platilo dříve, v jádrech řady 2.6 už jsou protokoly ESP i AH implementovány standardně, takže stačí jednoduchý konfigurační interface (setkey) a pro automatické klíčování démon racoon.

[peter]

Pekné, no ja by som skôr potreboval nakonfigurovať Linuxového klienta, tak aby sa dokázal pripojiť do funkčnej firemnej VPN tak, aby na strane firemnej VPN nebolo potrebné nič meniť (nemám k tomu prístup).

Kvôli tomu, aby som sa mohol pripojiť do tejto VPN musím používať Windows a to sa mi vôbec nepáči. Klient na pripojenie je tuším Contiviti, nemáte niekto skúsenosti, ako sa prihlásiť do takejto VPN z Linuxu?

[erchamion]

Na jakem zarizeni je ve firemni siti zakoncen VPN tunel? Pokud je to Cisco, funguje dobre klient vpnc, pro KDE pro nej existuje "nadstavba" kvpnc. Kvpnc ma tu vyhodu, ze dokaze primo pracovat s .pcf soubory z Win Cisco VPN clienta. Sam pouzivam kvpnc na FC4, pripojuju se s tim do firemni site, kde je Cisco 3000 VPN concentrator a funguje to bezchybne.

[peter]

Mal by to byť nejaký Nortel Contivity shitch. Freeswan by s nim mal dokázat komunikovať, len ako to nakonfigurovať (parametrov je veľa a informácií málo - zlá kombinácia). Nikde som nenašiel žiadny návod.

V každom prípade skúsim to vpnc (ak som ho ešte neskúšal).

[PSIkappa]

Ak ten Nortel Contivity je nastaveny tak, ze ako klienta pripusti len Contivity, tak je su len 2 moznosti a to bud patchnut zdrojaky, aby sa ti linux identifikoval ako Contivity klient, alebo pouzivat proprietarneho contivity klienta pre linux, ktory je len pre niektore verzie RH/SuSE kernelov a narozdiel od Win verzie je Lin verzia platena.

[aarwin]

no, k linuxove verzi jen za priplatek se da dodat jen jedno zm*di zas*arny, kolik vam za to m$oft zaplatil ? ))

[Michal Kubeček]

To máte z toho, že se místo standardního IPsec a volně dostupných nástrojů snažíte používat nějaké proprietární náhražky…

[platYpus]

Pokud je to CISCO, tak se da stahnout "CISCO VPN client form Linux".

[lachtan]

Nastavuje access-list pro dany IPSec tunel zaroven i fw pravidla nebo musim tyto pravidla urcit nekde jinde a pokud ano jak? Pravidla svazana s outside rozhranim totiz vubec pro IPSec nejsou brana v uvahu. Pokousim se sice spojit Cisco - Cisco, ale kdyz pritvrdim access-list, nenavaze se mi SA v jinak funkcnim tunelu. Uz to resim dva dny a nemuzu na nic prijit :)

[Jan Vondracek]

PIX umí udělat průstřel pro ipsec sám (sysopt permit ipsec), cisco router ne, musíte mít povoleny stejné věci jako v iptables na linuxu.

[pupala]

A ako je to s NAT 1-1 ?

Ja som bol presvedceny, ze cez NAT to nefunguje standardne. Ak napr. IP 62.168..x.x NAT-ujem na 192.168.x.x a IP 62.168.y.y NAT-ujem na 192.168.y.y tak to funguje, alebo da sa to spojazdnit ? Ak ano, privital by som komentar, pripadne pokec sukromne na pupalaro@pupalova.sk . Ak sa chcu pripojit aj iny nie som proti aj na diskusii tu. A rovno to potom frknut do slabikara )) s POZDRAVOM

Pupala

[Doda]

Nedavno jsem se pokousel rozchodit prave OpenSwan na Debianu s jadrem 2.6.8. Vse se zda v poradku, ale nevytvori se mi zadne rozhrani ipsec0: jako na jadre 2.4. Ani nemuzu najit modul ipsec.o ani nic podobneho. Je mozne rozchodit openswan na kernelu 2.6 stejne jako na 2.4 ? Podle dokumentace co jsem nasel a precetl je to nejak rozdilne.

[Doda]

Jeste upresneni. Modul ipsec.o je docela urcite soucasti baliku (v Debianu) openswan-modules-source, ale nemuzu ho nejak zkompilovat s jadrem 2.6. Mozna by se musela vyhodit ta nativni podpora ipsecu z 2.6. jadra.

[Doda]

Tak me jeste napadlo zkompilovat ipsec.ko modul primo z puvodnich zdrojaku openswan, coz slo, ale pokud ho nahraju do pameti, tak mi jadro sleti.

[Michal Kubeček]

Máte nějaký konkrétní důvod k použití OpenSwan místo nativních nástrojů?

[Doda]

Ano, nekolik, nevim, jestli je ale uznate. Jednam mama udelane rozsahle vpn na openswan, kde se konfiguracni soubory a klice generuji pomoci specialniho software. Jde z velke casti o naprosto totozne routery, ktere se daji v pripadku havarie rychle nahradit. Tady ten debian neni ten pripad. Dalsi vec jsou podobne generovane konfiguraky pro shorewall, v pripade jadra 2.6 a nativniho ipsecu je to zase nejake jine. Shorewall se musi nejak patchovat a konfiguracni soubory jsou rozdilne

Me by zajimalo, jestli se navenek ta nativni podpora ipsec ve 2.6 muze pouzit stejne, tedy stejne konfiguracni soubory a stejne se s tim zachazi. Ja na to nejsem uplne odbornik, ale proste po prostudovani docela dost dokumentu se mi to zda jine.

Je mozne, ze jsem se vydal spatnou cestou, ale prave proto bych potreboval trochu postrcit. Staci jednoduse.

[Michal Kubeček]

Ano, možnost převést s nemalými úpravami existující a relativně odzkoušenou konfiguraci je docela dobrý důvod, proč dát přednost OpenSwan. Sám jsem taky svého času poměrně dlouho zůstával u jádra řady 2.2 a ipchains, než jsem se přesvědčil, že mi jádro 2.4 a netfilter opravdu přinese něco pozitivního, co bude stát za tu práci. Původně jsem předpokládal, že je řeč o nastavení stroje "from scratch".

Nejsem si jistý, co ve své otázce rozumíte slovem stejné. Jestli jde o možnost použít na jednotlivých strojích prakticky stejný konfigurační soubor (pouze s nahrazením např. IP adresy a jména), pak ano. Jestli myslíte možnost použít stejný konfigurační soubor jako ve FreeS/WAN resp. OpenSwan, pak ne, ta konfigurace vypadá úplně jinak (i když vlastně nastavujete totéž).

Na druhou stranu bych řekl, že konfigurace ipsec-tools trochu víc odpovídá tomu, jak IPsec vlastně funguje, zatímco FreeS/WAN (OpenSwan) to trochu "maskuje". Jinak jsou to ale stejné protokoly, takže není problém používat na jedné straně jednu implementaci a na druhé straně druhou. Jen nesmíte uměle vyrobit nekompatibilitu třeba disjunktní sadou podporovaných algoritmů nebo požadovaným formátem identifikátoru (ale to platí i v případě, že bude na obou stranách totéž).

[Doda]

Me slo opravdu o to, pouzit konfiguracni soubory, ktere "zkopiruji" od OpenSwan. Pokusim se prokousat i podporou v 2.6., ale jeste by me zajimala nasledujici vec (reknu to jednoduse, nevim jak to jinak formulovat): Vznikne mi v systemu pri pouziti nativni podpory ipsec ve 2.6 take dalsi interface s nazvem napriklad ipsec0: jako je tomu u openswanu na 2.4 ?

[Michal Kubeček]

Ne, nevznikne, funguje to trochu jinak. Rozhodnutí o tom, které pakety mají být posílány zabezpečeně, není prováděno podle směrovací tabulky, ale na základě nastavení security policy resp. security association.