Re: lug-bg: vtun

[Vesselin Kolev <vlk@xxxxxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

linux@xxxxxxxxxxxxxxxx wrote:

| Имали смисъл да се използва възможностa на vtun
| (http://vtun.sourceforge.net/) да компресира данните.
|
| Говоря за lzo компресия и каква степен на компресия в реални условия
| ще се получи, както и какво натоварване ще създаде на процесора на
| машината и доколко това ще се отрази на скороста на линията.
|
| т.е. кога е целесъобразно да се използва real-time компресия на данни
| ???
|
| Благодаря предварително.

Това е един изключително интересен въпрос.

По принцип LZO алгоритъмът има претенциите да бъде много бърз при работа
с блокове от информация с променлива дължина (сиреч на пръв поглед
идеално се вписва в задачката за компресия при IP транспорта на данни).
Наистина той печели по показателя "време" надпреварата със zlib. От
друга страна бързината му е факт поради неизвършването на дълбока
компресия и това е негов минус.

Въпреки това този алгоритъм наистина постига много добри резултати при
преноса на данни чрез UDP. Визирам конкретно наблюденията си върху NFS.
Преносът на информация там може видимо да се ускори, но е нужно да се
каже, че ускорението ще важи само и единствено за информация, която е
податлива на компресиране. Освен това помни, че винаги имаш капсулация в
тунелния протокол. Тази капсулация намалява действително използваният
параметът MTU на виртуалното туналено устройство и може да се наложи
(насилствена) фрагментация, която да вдигне натоварването на машината
ти. От друга страна всяка фрагментация увеличава фактическия трафик в
рамките на една сесия. По принцип тунелирането в почти всички случаи
увеличава трафика като увеличението е за сметка на фрагментирането,
особено за NFS. Т.е. компресирането тук може да помогне само, ако така
компресира информацията съдържаща се в пакета, че да предотврати
фрагментирането. Във всеки друг случай ти ще печелиш много по-малко от
компресирането. Всъщност нека обясним по-подробно. Ако ти си само шлюз
за дадена NFS сесия, която идва от сървър, който е свързан с теб в
рамките на етернет мрежа, ще ти се наложи да транслираш фрагменти с
големина 1500 (колкото е MTU в етернет мрежата). Ако ти ги препредаваш
през тунел към даден клиент обаче, ще ти се наложи да фрагментираш
заради разликата в стойностите на MTU на етернет и на тунела. Пита се
дали компресията може да предотврати фрагментирането? Еднозначен отговор
няма. Зависи какво транслираш. Същото е положението при препредаване на
сесии по TCP в случаите на изтеглянето на файлове (чрез FTP, HTTP).
Както каза и Васил, HTML документите са най-лесната плячка, както и
сесии по ICQ, IRC, Jabber (стига да не са през SSL). Най-големи ядове ще
ти създават криптираните сесии. Нищо не можеш да правиш пакетите, които
идват през тях.

Друг един важен въпрос е комбинирането на компресиране и криптиране.
Истината е, че те вървят заедно. Но не защото нямаляват обемът на
информацията. Компресията се използва преди криптирането да се затрудни
атаката от тип "познат текст" срещу криптоалгоритъма, който ползваш.
Т.е. при хибридната схема "компресиране-криптиране" ти заздравяваш
криптирането. Препоръчително е преди криптиране винаги да се използва
компресиране, дори върху неподатлива на компресиране информация. Така
сравнението на криптирания блок и на некриптирания е трудно и не носи
полезна информация за атакуващия.

Що се касае до натоварването, честно казано нямам точен количествен
анализ, който да ти дам. Използвал съм vtun на твърде мощна машина,
където ефекта от натоварването поради тунелиране трудно се усеща.
Цитирам по памет една дискусия, която ми изпадна от Google и в която
хората твърдяха, че спокойно използват vtun с ниско ниво на компресия
lzo при скорости от порядъка на 8-10 Mpbs върху машина с процесор AMD
Athlon 750 MHz, която служи само за тунелен шлюз.

От друга страна vtun е един напълно нестандартен тунелен реализатор и
мениджър. При това създава излишно натоварване върху системата (и не
можах да разбера защо) при условие, че използва един доста бърз
симетричен криптоалгоритъм (BlowFish) и лек хеш (MD5). Освен да ползват
лош имплемент на BlowFish, май друго не може да са оплескали. Опитай
нещо, което е RFC съвместимо и използва IPsec. Лично аз съм постигал
невероятно висока производителсност с FreeS/WAN и наследника му.
Мегабитните канали просто вече няма да те плашат.

~  Поздрави
~     Весо


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFAnkvk+48lZPXaa+MRAi6pAJwJHv+4AcZuN0P4c/EwuWgzNbyOAACg/zvZ
I3H8YOblwN0968fPXqiZEtQ=
=YwJF
-----END PGP SIGNATURE-----


============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================