A sávszélesség még alkutárgya, de valószínűleg egy full 100MByte-os vonal lesz szét osztva. A végpontok száma jelenleg kb. 38. De egyes végpontokon wifi router figyel, így a felhasználók száma egyenlőre nem ismert (de a kollégiumban kb. 120-an laknak - kis kolesz.)
<k...@mayten.sch.bme.hu> írta (2014. december 9. 17:55): > > Szia, > > mint egykor kollegiumi netadmin, nem azt mondanam meg, hogy mit csinalj, > hanem azt, hogy mi hogy csinaltuk. > > On 2014-12-09 16:14, Zoltán Takács wrote: >> >> - loggoljam, hogy melyik végpont mikor-mit csinált, hogy ha >> szankcionálni kell, akkor legyen hol utána néznem... > > > ez minket kevesbe erdekelt, az erdekelt inkabb, hogy az IP amivel problema > volt, az kie volt. nem tudom nalad mekkora savszelesseg van, nalunk > akkoriban 1 giga es kb 1200 forgalmazo gep. Nincs az a hely ahova > rogzithetnenk ki mit csinalt. Az IP cimet mindenki felevente ujra kellett, > hogy reigsztralja, azaz nevere vennie, a kovetkezo regisztracioig o felelt > erte. > > Akkoriban elegendo volt az IP - MAC cimparokat figyelni. Ez olcso > megoldaskent egy arpwatch is megoldja. Nalunk amikor meg nem volt DHCP > bevezetve (sot, tiltva volt) akkor minden esetben, amikor egy nem parositott > ip - mac jelent meg a halozaton, azt kitiltottuk. Modern kori megoldasok: > VMPS, 802.1x, NAC, ezek mindegyike szofisztikaltabb megoldas ma mar, mint > egy sima MAC figyeles (de a MAC figyeles a legolcsobb). > > Amennyiben van DHCP nalatok (vagy lesz) es olyan a halozat is, force-old a > DHCP hasznalatat dhcp snooping, ip source guard es DAI beallitasaval. > > A MAC-re szures elonye, hogy nem kovetel a felhasznalotol extra > autentikaciot, konnyebb es gyorsabb implementalni, hibakeresni, ugyanakkor > kevesse biztonsagos, mint a felhasznalo azonositasa. > >> - legyen lehetőségem sávszélesség állításra - lehetőleg >> felhasználónként vagy végpontonként... (a m0n0wall még mindig jó...) > > > IP cimenkent csinaltunk savkorlatot, egy masik VLAN-ba leptettuk az adott > vegpontot (itt mar VMPS-t hasznaltunk, azaz mindegy hova volt bedugva a PC, > az a port ahova kotottek mindenkepp a savkorlatozott VLANba kerult). De > volt olyan atmeneti idoszak is, amikor maradt az IP cime, maradt a VLANja > is, ellenben a routeren egy policy map-et illesztettunk a kerdeses IP-kre es > leszabalyoztuk onnan. Ennek hatranya, hogy szoftveres megoldas, azaz > mindenkepp CPU novelo a routeren. itt megint csak az a lenyeges kerdes, > hogy mekkora savszelessegre tervezel. akkoriban nalunk hat-hetszaz mbit/s > volt a plafon, azaz amit tenyleg forgalmaztak a kollegistak. > >> - legyen lehetőségem pl. a torrentezés tiltására vagy legalábbis >> visszabb szorítására (itt valami csomagszűrésre vagy mit tudom én, > > > Hat, mi is akartuk tiltani, de akkor mi honnan szereztunk volna filmeket, ha > senki nem tolti le? :) Elso korben anno bevezettem az NBAR-t, amivel > lehetett protokoll analizist csinalni egy egyszeru supervisor modulon is. > Hatranya, hogy idonkent annyi CPU-t hasznalt, hogy az egesz router > belefagyott. De amikor mukodott, egesz jo volt, a torrentet, legyen > barmilyen porton, szepen lekorlatozta. > > Mai megoldaskent en nem is gondolnek masra, mint alkalmazasi reteg-beli > tuzfalra, peldaul egy megfelelo palo alto elbir barmilyen savszelesseggel. > ismet ugye a kerdes, mekkora sav, hany vegpont. > >> beállítható, hogy a sávszélesség mondjuk 80%-át a 80-as porton >> forgalmazza és a maradék 20%-ot a többin.... Na, ilyet a m0n0wall-ban >> nem találtam... >> > > ezt sima iptables + tc megoldja neked, egy script az egesz. de megint csak: > ez full szoftveres megoldas, van az a savszelesseg amivel egy PC mar nem bir > el es szuk keresztmetszet lesz. a redundans megoldasrol nem is beszelve, ha > van egy linuxos PC ami tuzfal, akkor az egyben single point of failure. ha > nincs sok felhasznalo, nem gond, de mondjuk nalunk ezer kollegista dorombolt > az ajton egyszerre, ha nem volt net, plusz aki nem kollegista volt de > kollegista eroforrast hasznalt volna kintrol, pl email, levlistak. > > de amugy is, a torrentezes tok fuggetlen a portszamoktol, ugye az sehol > nincs eloirva, hogy torrentezni ne lehetne a 80-as porton, raadasul ez a > megkozelites megoli a standard ftp (20/21), scp (22), voip (5060 + rtp > portok) es altalaban a stream hallgatast (gyakran jonnek a streamek pl 8080, > 8000 portokon). Ha ezeknek mind 20%-on kell osztozni, mindenki hamar fog > http tunnelezni. > > nem tudom hany vegpontra tervezel, mekkora savszelesseged van, lehet, hogy > valami linux-alapu megoldas is tokeletes lesz es nem kell tulgondolni. > > udv > adam > > _______________________________________________ > Techinfo mailing list > Techinfo@lista.sulinet.hu > Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo > Illemtan: http://www.szag.hu/illemtan.html > Ügyfélszolgálat FAQ: http://sulinet.niif.hu/ _______________________________________________ Techinfo mailing list Techinfo@lista.sulinet.hu Fel- és leiratkozás: http://lista.sulinet.hu/mailman/listinfo/techinfo Illemtan: http://www.szag.hu/illemtan.html Ügyfélszolgálat FAQ: http://sulinet.niif.hu/
