Dotaz: IPsec VPN

[Zdeněk Zámečník]

Potřeboval bych radu někoho zkušenějšího ohledně IPsec. Snažím se propojit vlastní síť s jednou vzdálenou, kde jako firewall slouží Checkpoint. Bohužel nejsem o moc chytřejší než druhá strana, která mi není schopna pomoci s nastavením.

Abych vše uvedl na pravou mírou - mě běží na serveru Debian, mám zde nějakou veřejnou IP adresu x.x.x.x a privátní síť 192.168.12.0/24. Druhá strana má veřejnou IP adresu y.y.y.y a privátní síť 10.0.0.0/8.

Dále mám k dispozici tyto údaje a zmíněný klíč:

Authentication pre-shared key
ISAKMP encryption 3DES
ISAKMP hash SHA1
ISAKMP SA lifetime 86400 seconds
Diffie-Hellman group 2
IPsec encryption 3DES
IPsec hash SHA1
IPSEC SA lifetime 3600 seconds

Dokázal by mi někdo poradit, jak nastavit, aby mezi sebou tyto dvě privátní sítě mohly plně komunikovat? Chybí mi nějaké informace (jko např. privátní IP vzdálené GW)? Pokoušel jsem se nakonfigurovat racoon a setkey, ale nějak se nemohu dostat k cíli. Pravděpodobně mi uniká nějaká podstatná informace, řekl bych, že musím ještě nějak vytvořit virtuální interface/tunel přes který bude komunikace probíhat. Našel jsem velice pěkné howto (http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ipsec.html), nicméně se týká FreeBSD a nedokáži jej aplikovat v Linuxu.

Má současná konfigurace vypadá následovně:

/etc/racoon/racoon.conf

log debug;
path pre_shared_key "/etc/racoon/psk.txt";
path certificate "/etc/racoon/certs";

remote y.y.y.y {
  exchange_mode main,aggressive;
  proposal {
    encryption_algorithm 3des;
    hash_algorithm sha1;
    authentication_method pre_shared_key;
    lifetime time 86400 seconds;
    dh_group 2;
  }
  generate_policy off;
}

sainfo anonymous {
  pfs_group 2;
  encryption_algorithm 3des;
  authentication_algorithm hmac_sha1;
  compression_algorithm deflate;
  lifetime time 3600 seconds;
}

/etc/ipsec-tools.conf

flush;
spdflush;
spdadd 10.0.0.0/8 y.y.y.y any -P out ipsec esp/tunnel/y.y.y.y-x.x.x.x/require ;
spdadd y.y.y.y 10.0.0.0/8 any -P in ipsec esp/tunnel/x.x.x.x-y.y.y.y/require ;

---

---

Odpovědi

[Zdeněk Zámečník]

Problém vidím tady:

spdadd 10.0.0.0/8 y.y.y.y any -P out ipsec esp/tunnel/y.y.y.y-x.x.x.x/require ;
spdadd y.y.y.y 10.0.0.0/8 any -P in ipsec esp/tunnel/x.x.x.x-y.y.y.y/require ;

Tohle by znamenalo, že chcete definovat politiky pro komunikaci mezi y.y.y.y a 10.0.0.0/8, což podle vašeho popisu není pravda. Spíš by tam mělo být něco jako

spdadd x.x.x.x y.y.y.y any -P out ipsec esp/transport//require;
spdadd y.y.y.y x.x.x.x any -P in ipsec esp/transport//require;
spdadd 192.168.12.0/24 10.0.0.0/8 any -P out ipsec esp/tunnel/x.x.x.x-y.y.y.y/require;
spdadd 10.0.0.0/8 192.168.12.0/24 any -P in ipsec esp/tunnel/y.y.y.y-x.x.x.x/require;

[Zdeněk Zámečník]

Díky za radu, vypadá to srozumitelně. Nejvíce mě mátlo to, že se v systému neobjevil žádný zvláštní interface ani záznam v routovací tabulce, ale už začínám chápat, že to funguje plně transparentně. Teď už se to celé tváří i funkčně, to si ale budu moci ověřit až zítra.

Sep 17 20:53:47 router-alp racoon: INFO: initiate new phase 1 negotiation: x.x.x.x[500]<=>y.y.y.y[500]
Sep 17 20:53:47 router-alp racoon: INFO: begin Identity Protection mode.
Sep 17 20:53:47 router-alp racoon: INFO: ISAKMP-SA established x.x.x.x[500]-y.y.y.y[500] spi:c66aba607ee7b5df:b5f7804879b067b6
Sep 17 20:53:48 router-alp racoon: INFO: initiate new phase 2 negotiation: x.x.x.x[500]<=>y.y.y.y[500]
Sep 17 20:53:48 router-alp racoon: INFO: IPsec-SA established: ESP/Tunnel y.y.y.y[0]->x.x.x.x[0] spi=249667546(0xee19fda)
Sep 17 20:53:48 router-alp racoon: INFO: IPsec-SA established: ESP/Tunnel x.x.x.x[500]->y.y.y.y[500] spi=105754079(0x64daddf)

[Michal Kubeček]

Nejvíce mě mátlo to, že se v systému neobjevil žádný zvláštní interface ani záznam v routovací tabulce, ale už začínám chápat, že to funguje plně transparentně.

Takhle (virtuální interface a routing) fungovala starší implementace používaná na jádrech řady 2.4. Implementace v jádrech od řady 2.6 používá samostatný mechanismus security policies - to je to, co nastavujete těmi příkazy spdadd a co si můžete zobrazit pomocí "setkey -DP".

[Zdeněk Zámečník]

Tak se stále nedaří. Při pokusu o traceroute do vzdálené sítě to projde defaultní GW do internetu a po pár skocích to skončí. Pokud to porovnám s vypnutým IPsec, tak paket dojde stejnou cestou mnohem dál.

Spousta těchto záznamů také asi také nevěští nic dobrého:

router-alp:~# setkey -DP
(per-socket policy) 
	Policy:[Invalid direciton]
	created: Sep 18 14:27:39 2012  lastused:                     
	lifetime: 0(s) validtime: 0(s)
	spid=10564 seq=1 pid=12195
	refcnt=1
(per-socket policy) 
	Policy:[Invalid direciton]
	created: Sep 18 14:27:39 2012  lastused:                     
	lifetime: 0(s) validtime: 0(s)
	spid=10555 seq=2 pid=12195
	refcnt=1
(per-socket policy) 
	Policy:[Invalid direciton]
	created: Sep 18 14:27:39 2012  lastused:                     
	lifetime: 0(s) validtime: 0(s)
	spid=10548 seq=3 pid=12195
	refcnt=1
...

Poradí někdo?

[Michal Kubeček]

Když zkracujete výstup příkazu, tak smažte ty nezajímavé části a ponechte ty zajímavé, ne naopak. Nebo tam máte jen samé per-socket politiky?

[Zdeněk Zámečník]

Pardon, pro mne byly právě ty nezajímavé podezřelé. Před chvilkou jsem ale narazil na jádro problému a tím byl source NAT v iptables, který mi překládal vnitřní IP adresy na veřejnou i pro tento tunel.

[Michal Kubeček]

A každýmu jsem to tady na tý točně říkal: nedělej pravidla pro maškarádu příliš obecná, nedělej pravidla pro maškarádu příliš obecná, nebo se z toho zblázníš. Ale je to marný, je to marný… je to marný.

:-)