Re: [Lug-bg] Mind-boggling: dynamic multipoint vpn под Линукс.

[Anton Glinkov <lartc@xxxxxx>]

Danail Petrov wrote:
> Здрасти,
> ти как реши че на човека му трябва layer2 свързаност?
никъде не съм го рещил. Казах, че при този сценарий е плюс и 
_ако_му_е_нужна_, може да я използва.
Как по-просто да обясня, че нещото, което предлагам е да се създаде 
full-mesh система от ethernet тунели, която ще се контролира от STP. Т.е 
има един общ ethernet сегмент, в който се намират всичките му линукс 
машини. Свързъността м/у тях е гарантирана от fullmesh-a и STP-то. Т.е 
по всяко едно време (ако изключим пълно умиране на дадена точка, тогава 
само тя изчезва) те се виждат. Като иска Layer 3, просто ще си добави по 
7 статични routes (не мисля, че има нужда от динамични протоколи освен 
ако няма ) на всяка една от 8те машини и проблемът му с рутирането (ако 
изобщо може да се нарече проблем) е решен.
> Anton Glinkov wrote:
>> Колко товари една openvpn сесия, която е само отворена и не се ползва 
>> според теб?
> Какво значи да е отворена и да не се ползва? Я си представи един вирус в 
> локалната мрежа, който плюе яко към ff:ff:ff:ff:ff:ff или по-лошият 
> вариянт, ако тунелният ти интерфейс работи като Proxy-arp? А сега си 
> представи всичкият този трафик кодиран в ESP пакети (и ако кажем се 
> ползва aes/3des + sha) целия този трафик ще се процесва софтуерно от 
> CPU-то на машината, и ще даде 100% load (и това е само един от няколкото 
> проблеми за които се сещам)
'отворена и да не се ползва' означава, тунелът да е изграден и работещ, 
но по него да минават само bridge-STP-related ethernet фреймове. Ако 
реши да настрои звезда - всяка машина ще има по един работещ и по 6 
'спящи' тунела готови да 'потекат' в момента в който стане нещо с 
работещия, а центърът на звездата - 7 работещи. Другият вариант е да се 
изравни натоварването и всяка точка да има по 2 работещи и 5 'спящи', но 
тогава ще има безсмислено завъртане на трафик. При настройка на bridge 
priority, port priority и path cost, лесно можеш да си играеш и разменяш 
топологиите on-the-fly, и да намериш  най-удачната за случая, без да се 
притесняваш, че системата ще рухне (освен ако не задаваш неразумни 
стойности на горните 2, разбира се :))
За броадкастите и Layer 2 - виж по-горе. А proxy_arp се спира лесно :)
>>  full-mesh и СТП-то се прави, за да се постигне, това което се търси - 
>> ако някой линк и/или точка умре - автоматично да се прерутира
> "рутирането" и STP-то са две съвсем различни неща. Това което говориш за 
> прерутирането се извършва чрез рутиращи протоколи (BGP,OSPF,ISIS,RIP), 
> или иначе казано, когато говорим за routing говорим за layer3. А там, 
> STP _няма_ :)
пропуснал съм кавичките на 'прерутира' - моя грешка :)
>>  
>> Layer 2 свързъността, според настройките (cost priority). Човекът е 
>> писал - иска мултипойнт VPN решение под линукс. 
> Аз пак питам, къде е казал че иска layer2 VPN?
Аз пак казвам - никой не го кара -> виж най-горе. Layer 2 е връзката 
само м/у линуските. После може да се включи Layer 3 рутиране.
>> Ти говориш за маршрутизатори и техните протоколи, а аз говоря за 
>> най-обикновен линукс :). 
> Как стигна до това заключение? :)
Това казвам - идеята ми е проблемът да се реши без маршрутизиращи 
протоколи, което според мен е елегантно и, при добра настройка, почти 
ненатоварващо хардуера. (криптирането няма как да се избегне)
>> А ако се чудиш какво става с arp заявката и изцяло с ethernet 
>> broadcast-ите 
> Изобщо не се чудя дори :)
>> зависи изцяло от това дали иска Layer-2 или Layer-3   
> питам аз ... ;-)
виж по-горе.. :)
>> свързаност м/у точките. Ако си запознат със СТП протокола, ще знаеш, 
>> че всички портове, които не се ползват (т.е имат детектнат loop),
> Сигурно съм наясно малко повече от теб за работата на STP (дано не 
> прозвучи захапливо, наистина нямам намерение да се заяждам)
не можеш да бъдеш сигурен ;-)
>> се блокират изцяло и през тях минават само 802.1d пакети. Не виждам 
>> какво общо имат arp-заявките тук. 
> Сигурно вече си разбрал, описах го по-горе.
даже и да направи Layer 2 VPN, което пак казвам, и _подчертавам_, че не 
е задължително - има си ebtables за контриране на broadcast бури и 
всякакви други 'лоши' фреймове.
>> Ако реши може да си бриджне и вътрешни мрежи в този 'общ бридж' и 
>> всичко пак ще си работи абсолютно без проблеми. Ако човекът има нужда 
>> от помощ - да ми драсне едно писмо - ще помогна с каквото мога. Не ми 
>> се спори повече. Приятна вечер.
>>   
> Приятелю, не ме разбирай погрешно. Аз съм последният човек в тази листа, 
> който иска да породи конфликт. Просто ми е странна твоята идея!!!Аз също 
> съм тук за да помагам с каквото мога!!!
Продължавам да си мисля, че не схващаш напълно, каква ми е идеята и 
затова гледам да бъда минимално остър :) Извинявам се, ако съм те 
засегнал с нещо. От алкохола е :)

-- 
Anton Glinkov
network administrator
_______________________________________________
Lug-bg mailing list
Lug-bg@xxxxxxxxxxxxxxxxxx
http://linux-bulgaria.org/mailman/listinfo/lug-bg