Uzivatel by se asocioval, dostal by pomoci DHCP nejakou adresu, ze ktere by se dostal (u opatrnejsich nodu *pouze* na) na tunelovaci servery vsech cloudu. Jednotlivi clody by pak na tunelovacim serveru mohli svym uzivatelum nabizet ruzne tunelovaci protokoly.
Tohle reseni je jednak jednoduche na implementaci (je mozne ho realizovat prakticky na jakemkoliv node), ma minimalni pozadavky na tranzitni node a na kooperaci. Opatrni provozovatele nodu by sice museli nechat asociovat kohokoliv, ale jeho komunikaci by dorucovali jen na tunelovaci servery, takze by z toho nemuseli mit zadne obavy. Pokud by dany uzivatel udelal nejake problemy, tak by to delal pod IP adresou sveho cloudu a tedy stiznosti a pripadne vysetrovani by bylo zamereno tam a ne na tranzitni node/cloud.
Nevyhoda je, ze kdyby takto pripojeny chtel komunikovat s nekym pripojenym blizko jeho fyzickeho umisteni, tak by pakety sly nejdriv od nej na igw, pres tunel do jeho primarniho cloudu, tam do tunelovaciho serveru a odtamtud zpatky do puvodniho cloudu a tam na cil.
The action you have attempted could not be performed as your session appears to be invalid. Click the below link to attempt this action again with a new session.
...neni to ponekud divne ? (zalogovat znovu jsem se zkousel, prispivat jak vidite muzu...)
cookies fakt vypnuté nemám. všechno mi funguje, na CZF i jinde, vč. trvalého přihlášení.
no, každopádně, k tématu: u nás na APčkách s otevřenou MAC policy (což ale nejsou zdaleka všechny, a bohužel, protože stále ještě všechny platící klienty nemáme na 5 Ghz, a je třeba zajistit stabilní připojení všem, tak se postupně sektory uzavírají...) lidi dostanou od DHCP adresu s docela slušnou rychlostí do internetu (menší než jsou placené rychlosti, a sdílenou s ostantími AP).... akorát je tam jednou za hodiny prudí takový primitivní dashboard, který je potřeba odkliknout ve webovém browseru na jakékoliv cílové IP na portu 80. (no, např. pro přístup z PDA to příliš použitelné není, ale bohužel... to je život... realita a nutnost zaplatit z něčeho přiznanou daňovou povinost zvítězila nad původními utopickými vizemi...)
zatím není DHCP moc na domácích ethernetech, protože naši admini to nějak podmiňují shromažďováním MAC adres od klientů (proti kterému jsem od začátku vystupoval), ale v zásadě, mělo by to takhle fungovat i v domovních rozvodech: že strčíte kabel do ethernetu, odklepnete náš dashboard, a budete online.
__________________
03.02.2008 v 13:51
Alex
Formerly known as Frogale zastupce cloudu 10.38
My mame vsechna AP otevrena a po registraci lidicky z ulice poustime na inet a samozrejme do czfree. Do inetu 64kbit a do czfree neomezene. Registrace vydrzi 14 dnu, pokud nekdo bude chtit vyuzivat czfree nebo inetu zdarma dele, tak musi napsat a my mu to v drtive vetsine (jeden apckar na svem ap prizivniky nechce) povolime naporad.
Edit: Ma to par nevyhod, ale je to lepsi, nez aby se nam do site nabouravali blbci co si meni MAC a IP adresy (to potom nefunguje nikomu).
problém je, že u nás se objevili lidi, co kradou IP adresy, a už u toho i mění MAC adresy. tzn. dokud to nepořešíme, budeme bohužel muset MAC policy asi uzavřít.
stejně pouliční přístup asi potrvá až do prvního dopisu s červeným pruhem od Policie, který dostane někdo, kdo na to nebude mít nervy... u mě osobně tahle situace asi zvolna už nastává, uvidíme jak to bude v s.r.o.
Samotne uzavreni MAC policy imho moc nikam nepovede, predpokladam, ze ten kdo umi menit MAC zvladne i odchytit seznam tech povolenych a proste si nejakou povolenou take ukradne... jiste, uplny lamy to odradi, ale ultimatni reseni to neni
hostap snad umí selektivní WEP klíč pro každou MAC adresu jiný. ale nikdy jsem to nerozchodil a nemáme už zdaleka jenom hostap, spíš naopak - už ho skoro nikde nemáme... všude madwifi.
selektivní WPA podle MAC adresy by nebylo ? o Radiusu u nás všichni žvaní, ale nikdo to nerozběhne, protože se všichni štítí toho komunikovat s klienty.
21.01.2008 v 13:38
