On 11/18/12 22:41, David Pasek:
Takze predpokladejme, ze je to opravdu potreba technicky vyresit a pojdme
do vetsiho detailu ...
Moc se mi do toho nechtelo, ale dobra tedy.
O tom, ze by VirtualBox mel interne implementovano neco podobneho
private vlan mi neni niceho znamo.
V tu chvili se problem rozpada podle toho, zda je cilem ochranit pouze
vne-virtualni svet pred virtualnima masinama, nebo jestli jest zadano
ochranit virtualni masiny i pred sebou navzajem.
V prvnim pripade se to blizi uloze z bezne klasicke LAN, nejspis bych se
vydal pri reseni zhruba smerem - umistit do toho VBoxu i router. Ten mit
s ostatnimi virtualizovanymi masinami v host-only siti, on sam by mel
druhou virtualizovanou kartu, ktera jedina by mohla ven. Ma to
samozrejem nevyhodu - obdobne jako v klasicke LAN bude moct utocnik
narusit provoz ve stejne lokalni siti.
Pokud maji byt v-PC chranene i mezi sebou nastane teprve ten vazny
problem. Nutne je pro kazdou masinu nutne vytvorit vlastni LAN - a tedy
i IP blok (a to chce mit ctyrikrat tolik IP adres nez je potreba u flat
reseni). A router, na kterem se vsechny tyhle LAN budou sbihat. S prilis
mnoha vlastnimi LAN bude ale asi problem. VBox ma nejaky, pomerne nizky,
limit na pocet sitovych karet, mam dojem, takze interni router s
nekolika desitkama karet nepostavis. Soucasne nemam dojem, ze by interni
softwarova implementace switche umela pakety z nekolika internich LAN
tagovat 802.1q a "vlanizovane" je routeru predavat pres jeden interface.
Takze tudy to na snadnou cestu nevidim.
Problem postu LAN a interface lze obejit napriklad tunelem (problem s
vysokym potrebnym poctem IP se tim ale pravdepodobne nezmensi), pribude
ale jeden typicky "tunelovy" problem a to je problem se snizenou vnitrni
MTU.
Takze zbyva VDE. To zas tak detailne neznam, al enemel jsem nikdy dojem,
ze se nejak zvlast zabyva probiranym problemem a nabizi nejake vhodne
nastroje an reseni. Ale k definitivnimu zamitnuti by to chtelo hlubsi
zkoumani.
Jeste je potreba neprehlednou nektere mene prime cesty k reseni - ja
vlastne nevim jestli je v ramci emulovanych sitovych karet emulovana i
funkce zmeny MAC. Pokud neni, odpada problem mozneho "kradeni" MAC. A i
pokud je, nemel by to byt zas tak slozity zasah do zdrojaku emulatoru
tuhle schopnost odstranit. To samozrejme neresi zdaleka vsechno - stale
je mozne podvrhovat ARP, a pokud soucasne nezablokuju moznost prepnuti
do promiskuitniho modu, nezabranil jsem ani prijmu cizich paketu. A
problemy s kradenou IP to samozrejem neresi vubec.
V nevirtualizovanych "normalnich" modernich CISCO L3 LAN se to podle me da
resit pomoci port-security arp spoofing
viz.
http://www.cisco.com/en/US/products/hw/switches/ps5023/products_configuration_example09186a00807c4101.shtml
K probiranemu tematu to moc neni, takze jen velmi kratce - nezda se, ze
by arp spoofing nebo IP source guard mohl fungovat i staticky - ty jsou
navazany na udaje DHCP. A neni zaruceno, ze konkretni server DHCP
muze/bude/chce pouzivat. Ja treba nemam DHCP na serverech moc rad.
a jestlize se na portu objevi nepatricna MAC ci IP, tak se port prepne do
err-disabled stavu. Takze tim napatricna sitova konfigurace na koncovem
zarizeni zadisabluje port na switchi a je vystarano.
Jo, ale tohle Mirkovi uvnitr VBoxu nepomuze. Nemluve o tom, ze
implementovany je to na "fakt velkejch boxech". I kdyz, za precteni to i
tak stoji, protoze to mimo jine popisuje zakladni metody, ktere pripadny
utocnik, ktereho si do site sam nasadil do pozice superuzivatele
nektereho z virtualizovanych pocitacu muze pouzit (a k nekterym muze
dojit i neumyslne, chybou).
Zde bych dodal, ze jde o relativne novou vec, a to i na IPv4, a uvedene
moznosti maji jen dost nove switche, obvykle jeste navic jen s nejakym
dostatecne soucasnym firmwarem. Pokud by totez clovek chtel i pro IPv6 tak
to uz aby clovek vhodne zarizeni opravdu spendlickem pohledal.
Toto je urcite velka pravda. Je to opravdu hodne nova vec a vendori a cele
odvetvi teprve hledaji svoje "nejlepsi" reseni.
IPv6 neni (v tomto ohledu) nova vec, a predevsim, v dobe, kdy se
navrhovala, uz byly se stejnymi problemy zkusenosti z IPv4. Temhle
problemu se mohlo a melo alespon castecne predejit uz v navrhu IPv6.
Nemuseli dneska vsichni prekvapene zirat, ze problemy, ktere se kdysi
musely slozite resit na IPv4 se musi, uplne stejne, zase slozite a velmi
neustrojne resit znovu. Kdyby IPv6 navrh vzniknul v akademickem, od
reality odtrzenem prostredi, tak bych to jeste pochopil. Ale navrh
pochazi z komercni sfery, takze se nemuzu zbavit podezreni, ze uz tehda
premysleli o tom, jak vedle masivni vyroby levnejch switchu se budou
pekne prodavat ty "featured" drahy, kterymi se slavnostner vyresi
problemy, ktery tam vubec bejt nemusely. Ale to sem nepatri a darmo bych
se rozcilil.
Dan
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
