VPN L2TP/Racoon/IPSec nyni PPTP + domena Samba

[mytrix]

Dobry den,

Takže po nekonečné době testování a čtení všech možný diskuzí jsme dospěl k
názoru, že použití kombinace L2PT + IPSec je na systémech FreeBSD a
všeobecně *BSD bohužel nepoužitelné a to z důvodu nulové podpory NAT-T. I
samotný racoon již jakousi takovou podporu má, nicméně podpora není v jádru
systému, tudíž se zdá být situace bezvýchodná, alespoň prozatím.

Rozhodl jsem se proto, že přistoupím k použití PPTP, které nečiní žádné
problémy a je přístupní jak z NATovaných sítí tak i sítí mobilních
operátorů. Jako daemona jsem použil mpd. Jak to tak vypadá, vše funguje jak
má. Měl bych však jeden dotaz.

VPN ve Windows XP podporují i zadání domény, do které se daný uživatel
přihlašuje. Na stejném serveru kde běží PPTP je spuštěna i SAMBA, která
zároveň supluje fci domain controlleru. Je nějaká možnost, jak toto vše
nakonfigurovat tak, aby se provádělo ověření klienta oproti této doméně?

S tím související poddotaz. Lze nějak zařídit, aby se po přihlášení
uživatele k VPN mu automaticky namapoval domovský adresář případně další
síťové disky?

Děkuji.

S pozdravem
mytrix

-----Original Message-----
From: users-l-bounces at freebsd.cz [mailto:users-l-bounces at freebsd.cz] On
Behalf Of Dan Lukes
Sent: Thursday, April 28, 2005 5:14 PM
To: FreeBSD mailing list
Subject: Re: VPN L2TP/Racoon/IPSec

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





-- 
FreeBSD mailing list (users-l at freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l