VPN L2TP/Racoon/IPSec

[Dan Lukes]

mytrix napsal/wrote, On 04/28/05 16:46:
> a) měl jste pravdu s těma IPčkama, jakmile jsem provedl úpravu dle vaši
> rady, log hned vypadal zajímavěji. Až na bod b)
> b) zde dělala neplechu nastaveni lifetime, servery se zřejmě dost dobře
> neshodli na doby vypršení. (ERROR: proposal.c:217:cmpsaprop_alloc(): long
> lifetime proposed: my:30 peer:3600)

	To jsem si sice vsiml, ale spatne vylozil a za problem to nepovazoval.

> záznam. Když jsem adresu vrátil zpět, tak při pokusu o připojení se mi v
> messages objeví hláška "kernel: IPv4 ESP input: no key association found for
> spi 43877483". Jak jsem zjistil na diskuzi, tak prostě musím čekat, dokud
> nevyprší ta session, nebo tak něco. Nicméně jak lze toto ošetřit, aby k

	No, nevim, jestli jsem dostatecne podchytil v cem mate problem.

	Zkusim malinko zabrousit do toho, jak IPSEC funguje.

	Pokud policy (ulozena v SPD) urci, ze paket se ma zasifrovat, provede 
se to nejnovejsim dostupnym klicem. Onen klic ma svoje SPI a to je 
zapsano do zasifrovaneho paketu. Na druhe strane se zasifrovany paket 
identifikuje prave timto SPI a tim se najde prislusny klic.

	Klice samy maji omezenou zivotnost a jejich vymena (obnova) probiha 
asynchronne na samotnem prenosu dat. Proste, kdyz je treba data 
zasifrovat, ale zatim k dane policy zadny klic neexistuje, pak ISAKMP 
dostane za ukol nejaky dohodnout. Totez se stane, pokud klic existuje, 
ale blizi se doba jeho expirace (je ve stavu "dying"). Neni nic divneho, 
pokud v systemu k dane policy existuje klicu vic - jelikoz vymena klicu 
je asynchronni a navic, poradi ani zpozdeni paketu v siti Internet neni 
zaruceno, stava se, ze po dohode na novem klici prijdou jeste pakety 
"stare" - to ale nicemu nevadi, stary klic, se svym SPI je v systemu 
stale pritomen a lze ho pouzit na desifrovani. Na odesilani uz se 
pouziva ale klic novy (vzdy nejnovejsi dostupny).

	Komplikace nastane ve chvili, pokud jedna strana "ztrati" klic k platne 
session. A zda se, ze presne k tomu doslo u vas (proc presne, to nevim). 
Velky problem je to zejmena v pripade, ze se prenasi komunikace typu 
"klient-server" a klic ztratil server.

	Klient v teto chvili posila pozadavek chraneny klicem urciteho SPI, 
ktere ale server nezna. Neni schopen pakety zpracovat, nevi k jake 
policy patri - a v zasade - jsou to pro nej stejne neduveryhodne pakety, 
jako pakety nejakeho utocnika. Prichod pakety s neznamym SPI vyvola 
prave tu hlasku, kterou jste videl. Klient ale nevi, ze jeho pakety jsou 
zahazovany - IPSEC "utocnika" o takovem rozhodnuti neinformuje. Klient 
nema zadny duvod zahajit hanshaking o novem klici - on preci platny ma.

	Server, naproti tomu, s klientem nema duvod komunikovat - nema zrovna 
zadny pozadavek na vyrizovani, a sam od sebe on nemluvi. Nejsou-li zadna 
data k odeslani, neprijde se na to, ze prislusna policy nema zadny 
platny klic - a handshaking se tedy take nezahaji.

	Vysledkem je "mrtva session" az do okamziku, kdy vyprsi platnost klicu 
klienta. Pak je to, obvykle, on, kdo iniciuje vymenu klicu.

	Neexistuje mnoho uspokojivych reseni. Zaprve lze zkratit zivotnost 
klicu a tim zkratit "mrtvou" dobu. Nedoporucuju ji ale zkracovat 
presprilis - omezenim je nejmene to, ze samotny hanshaking neco trva, a 
stav "dying" nastava typicky v 80% vycerpane zivotnosti - domluva noveho 
klice se tedy musi stihnout v onech dvaceti procentech - a je treba si 
uvedomit, ze pod zatizenim se tu a tam muze nejaky paket ztratit, takze 
by bylo dobre pocitat s tim, ze ne vzdy se to podari hned a tak by tento 
cas mel vystacit i nejmene na jedno, lepe vsak dve, opakovani.

	Zadruhe, lze oboustranne pravidelne "pingat" - to pripadne vyprovokuje 
hanshaking "mrtve strany". To uz ale IPSEC ani ISAKMP nezajisti.

> předpokládám, že se budu muset poprat s NAT-T, abych protlačil IPSec spojení
> v případě, že by se klient přihlašoval z NATované sítě, což je v dnešní době
> celkem běžný problém. Jen doufám, že to nebude zásadní problém.. ? :o)

	Nevim. Az dosud jsem mel dojem, ze tohle ani FreeBSD ani Windows 
nepodporuji. Ale tolik to nesleduju. Dejte vedet, jak jste dopadl. TO me 
docela zajima ...

					Dan Lukes