[Techinfo] iphone dhcp

[ka at mayten.sch.bme.hu]

Szia,

On 2017-10-19 12:47, Molnar Peter wrote:
> A kovetkezok miatt hasznalom:
> 1. Uj gepek eseten a MAC-cimrol kapok email-t, s tudom regisztralni a 
> gepet
> Ugyanis errol is kapok ertesitest:
>           ip address: 169.254.173.48
>     ethernet address: 30:75:12:fb:b1:7f
> 
> 2. Ha valamenyik eszkoznek az ip cimet elallitjak, akkor ertesitest 
> kapok rola.
> 3. Ha egy uj eszkozt helyeznek a halozatba fix cimmel, akkor tudni 
> fogok rola.
> mondtam, nem tokeletes de sokat segit.

nalunk a regisztracio azt jelentette, hogy a MAC cim a halozaton addig 
nem is birt forgalmazni, IP cimet sem tudott kerni, amig nem volt 
regisztralva.  A regisztracio soran egy emberhez rendeltuk azt, ami utan 
jutott egyatalan hozza a halozathoz es kapott ip cimet.

Az altalad fentebb bemasolt reszletbol nekem ugy tunik, nalad ez a 
regisztracio igazabol masodlagos, amolyan informativ dolog csak: tud 
kerni IP cimet, tud forgalmazni, legfeljebb nem a halozaton kivulre.  De 
peldaul zavart kelteni lokalisan tud (ld. arpwatch uzenetek).  Ebben a 
formaban a gep regisztralasa csak egy kozmetikai lepesnek tunik, de 
javits ki batran ha rosszul latom, mivel igaz, hogy internetre nem jut 
ki (169.254) de 1) beallithat maganak kezzel ervenyes, nem utkozo cimet, 
tovabba 2) mint irtam zavart kelteni igy is tud, hogy nem lat ki.

De tegyuk fel nincs eszkozon ezen valtoztatni, ahogy irtad korabban, 
rendben.  A problema igazabol nem is letezett addig, amig a szifonok nem 
kezdtek el mac cimet valtogatni, igy a tovabbiakban en fokuszalnek erre 
a reszproblemara.  Ha nem lehet oket lebeszelni rola, valamint az 
arpwatch szukseges szamodra, akkor mi a teendo.

Az elso nyilvanvalo dolog, ami latszik, hogy az arpwatch szukseges a 
vezetekes halozaton, de inkabb csak zavaro a vezetek nelkuli halozaton.  
Ebbol az is kovetkezik, hogy ezek ossze vannak bridge-elve - kulonben 
ket arpwatch futna amibol az egyiket siman leallithatnad (a vezetek 
nelkuli oldalon).

Felmerul tehat a kerdes, hogy ha valoban nincs szegmentalva a vezetekes 
es a vezetek nelkuli resz, akkor mi lenne, ha szegmentalnal.  A 
vezetekes reszt ne batsd, hagyd ahogy van, arpwatchostul.  A vezetek 
nelkuli halozat lehetne szeparalt.  Ha nincsenek is vlan-kepes switcheid 
(nem tudjuk, hogy vannak), az AP-kat kikabeleznem dedikalt halozaton, 
teljesen szeparalva a tobbi resztol (nem tudjuk, ez kivitelezheto-e 
fizikailag).  Route-olt atjaropontot letesitenek a ketto kozott, igy 
szamukra irrelevans lenne, hogy egy broadcast domainben vannak-e vagy 
sem, ellenben az atjaro ponton tudnek okossagokat csinalni.

Az alapotlet az, hogy elfelejtenem a vegpontok regisztraciojat - semmi 
haszon nem szarmazik belole, hiszen valojaban nem a vegponton hasznalt 
hardverre vagy kivancsi, hanem a vegfelhasznalora.  Be tudnek vezetni 
captive portalt, akkor, ha nincs 802.1x kepes AP-m amivel ezt normalisan 
meg lehetne csinalni.  Nyilvan 802.1x lenne az optimalis, raadasul 
tplinkes szappantartok is tudjak ezt.  De tegyuk fel valamiert nem tudod 
vagy nem akarod bevezetni.  Ekkor az atjaroponton captive portalt 
inditanek, ahol akar mar letezo accounttal (AD, vagy LDAP, ha van nalad) 
akar dedikalt accounttal lehet atjutni.  Nyilvan innentol az IP cimeket 
barki kerhetne, hiszen az accountot kell engedelyezni wifi hasznalatra, 
nem pedig a MAC cimet.

Funkcionalisan nem lenne rosszabb 'regisztracio' mint ami most velhetoen 
van nalad, ugyanakkor megszabadulnal az arpwatch (szerintem haszontalan) 
leveleitol a vezetek nelkuli oldalon, mikozben a vezetekesen tovabbra is 
megtarthatnad.  Utobbinak jelentosege azret van, mert el tudom kepzelni, 
hogy vezetekes vegpontokon a vegfelhasznaloi kenyelem es rugalmassag 
kizarja a captive portal es/vagy 802.1x hasznalatat, ugyanakkor ott 
nincs is senki aki rendszeresen valtoztatgatja a mac cimet.

Mint irtam nem ismerem az infrastrukturad, lehet a fentieket mar regen 
vegiggondoltad es valamilyen ismeretlen ok miatt ellene dontotttel, ez 
esetben a rovid valasz az eredeti kerdesedre, hogy az arpwatch mar nem 
tamogatott, sajat magad bele tudsz fejleszteni feature-t, hogy bizonyos 
mac vagy ip cimeket ignoraljon, de szerintem ez tuneti kezeles, nem a 
problemat oldod meg vele, a mac cim randomizaciot pedig nem fogod tudni 
kikapcsolni.  Raadasul egyre tobb gyarto implementalja helyesen.

-- 
Regards
Adam