IP cim switchporthoz rendelve

Hálózatok egyéb

Elegge egyszeru dolgot szeretnenk megvalositani, de valamiert megis bonyolultnak tunik.
Van egy publikus cimtartomanyunk. Ezekbol szeretnenk kiosztani gepekre IP cimeket, de korlatozni szeretnenk, hogy egy adott porton milyne IP-k fodulhatnak elo.
PL:
Gi0/0/1 -en a 101-esvegu IP lehessen.
Gi0/0/2 -en a 102-esvegu IP lehessen.
stb

Bonyolitja a dolgot, hogy nem lehet MAC cimhez kotni az IP-t. Mert ha mondjuk a 3-as porton van 5 IP es az 5 cimbol 4 virtualis gepe amit veletlenul cserelgetnek es mindug uj MAC cimet csinalnak nekik akkor azt kezelni nem kivitelezheto.
DHCP-t sem osztunk a tartomanyban, ezert minden cim-et kezzel kell beallitani a gepen.

Van valami javaslat, vagy megoldas, hogy hogyan lehet felvenni port-hoz adott IP-t?

Koszi

  • 1874 megtekintés

( _ventura_ v | 2019. 08. 19., h – 20:53 )

Ez switch fuggo. Egyáltalán tudja amit akarsz ? mármint adott porton csak adott IP kommunikálhat ?

Fedora 30, Thinkpad x220

+1 a switch függőségre.

Mivel a probléma - amire a megoldást keresed - még hosting környezetben sem fordul elő sűrűn, szerintem az is megoldás lehet, ha
tetszőleges -managelhető- switchre irsz programot, ami lekérdezni az aktuális mac/port összerendeléseket és ezt ellenőrzöd, adott esetben riasztás generálva.

Vérmérséklettől függően lekapcsolod a portot a script segitségével 1-24 órára.

ps: a fenti problémára akár (korlátokkal) megoldást nyújthat a port isolated funkció is, amivel mindenki csak az uplink porttal tud kommunikálni.

( renard | 2019. 08. 19., h – 21:07 )

Cisco switchek esetében port ACL-nek hívják azt, amivel a feladatot megoldható, ott lehet szűrni IP-re is.

( lcsaszar v | 2019. 08. 19., h – 21:35 )

Ha a DHCP szerver Cisco IOS, akkor lehet Port Based Address Allocation-t konfigurálni. Talán megoldható más DHCP szervernél is, mert a port nevét használja ASCII client-id gyanánt.

( zeller | 2019. 08. 19., h – 22:35 )

Mi a valódi feladat? Mert ez elsőre egy eléggé átgondolatlan ötletnek tűnik...

Ott nincs, de az mar nem a mi gondunk.
Vagyis annyiban megis, hogy a MAC-hez nem lehet kotni mert a fizikai gepen krealhatjak a VM-eket, de azok is csak azt az IP-t kaphatjak amit engedtunk a port-on... vagy atnyomjak a gep IP-jen, belso cimekkel es NAT olnak a gepen a publikusra, de ez mar megint nem a mi dolgunk lesz.
Csak annyi hogy adott switchporton adott ip(k) es semmi mas.

Mindenképpen certificate alapú hitelesítésre gondoltam (ISE mondjuk, ha Cisco), ezt viszont a guest-eknek is támogatniuk kell.

Enélkül, vagy a virtuális layer (vmware?) támogatása nélkül szerintem csak úgy fogod tudni megoldani, ha minden VM dedikált fizikai nic-et kap.
Live migration nem fog gondot okozni?

Linuxon van rá megoldás, hogy adott virtuális interface adott source IP-vel tud csak komminikálni kifelé. Valamelyik hypervisor alapból létre is hozza ezeket a szabályokat, az adott VM hozzárendelt IP-je szerint.
Ezt akár egy minimal php + bash vagy csak bash mókával meg lehet oldani linux oldalról.

Ha MAC-alapon nem szűrsz, akkor az adott, pl. gw MAC forrással tolt arp-reply is elég, hogy felé menjenek a csomagok. Ha nem te osztod az IP-t, nem te "osztod"/kötöd adott interfészhez a MAC-et, akkor nehéz lesz...
Én egyébként olyat csinálnék, hogy a fizikai kártya hardvercíme _és_ portonként kiosztva tartományok a virtuális gépekhez (AA:BB:xx:##.##.## az xx. porthoz pl.), ha tud ilyen szűrést a motyó, és mindenkinek kiadni, hogy milyen cicababatrikót, akarom mondani macadressz-t használhat a vm-ekben.
Ha mást használ, az nem fog kommunikálni, ha a gépén mást állít be, az sem fog kommunikálni - ha a gw ip-jét húzza magára, akkor meg fejét letépni.

( Vamp | 2019. 08. 19., h – 23:03 )

Nalunk hamarosan tervben van egy szoftver bevezetese, ami pont az altalad felvetett problemara (is) megoldas lenne. Sajnos most nem ujrik be a program neve (nem halozatos vagyok), de ha megyek legkozelebb melozni, ranezek.

( debtamas88 | 2019. 08. 20., k – 18:37 )

Szia!

PL:
Gi0/0/1 -en a 101-esvegu IP lehessen.
Gi0/0/2 -en a 102-esvegu IP lehessen.
stb

Bonyolitja a dolgot, hogy nem lehet MAC cimhez kotni az IP-t. Mert ha mondjuk a 3-as porton van 5 IP es az 5 cimbol 4 virtualis gepe amit veletlenul cserelgetnek es mindug uj MAC cimet csinalnak nekik akkor azt kezelni nem kivitelezheto.

....

Pontosan ez lenne a cel. Valaki elkattan es hirtelen felhuzza magara mondjuk a gateway ip cimet es maris megvan a “nyertes”. Mac et meg az klonoz manapsag aki akar.

A legegyszerűbb megoldás (szerintem), hogy a publikus ip-ket felosztod csoportok-ra, és minden csoporthoz csinálsz egy vlan-t és vlan-ip-t.
Mindegyik gateway-re (vlan-ip) pedig menne az ACL milyen ip-ket fogad el, valamint ip-source-guard a vlan-ip-re.
(Másik megoldás - VRF/PBR - ugyan így):
(HOST-1)----(gateway: vlan-1 ip)-----(fő-router ip)-----(WAN)
(HOST-2)----(gateway: vlan-2 ip)-----(fő-router ip)-----(WAN)
...

Publikus subnetet a fő-router ip/ipk-re küldi az ISP - ott pedig fel kell venni a route -t.
(Itt még kicsit dinamikusabb is a dolog, ha át kell irányítani máshová a forgalmat valami miatt.)
route public-ip-1 via vlan-1-ip
route public-ip-2 via vlan-1-ip
route public-ip-3 via vlan-2-ip
...

Problémák:
-Adott vlan-csoporton belül HOST-ip ütközés van:
> Erre nincs megoldás, monitorozni kell, annak megfelelően elhárítani.
-Adott vlan-csoporton belül HOST felveszi a vlan-ip (gateway) címet:
> Erre nincs megoldás, monitorozni kell, annak megfelelően elhárítani.
> Kimenő forgalma nem lesz, csak az adott vlan csoportban lévő HOST-al/HOST-kal lesz probléma.

Amennyiben a switch tudja (L3 switchek tudják), akkor fog menni. Nekünk lassan tizenéves dlink DGS34xx is tudja, és azzal oldjuk meg, hogy ki melyik porton milyen IP-vel forgalmazhat. Nem kell semmiféle külső script/vlan stb. Megfelelő eszköz kell és pofon egyszerű lesz az egész.

Fedora 30, Thinkpad x220

A switch egy D-Link DGS-3420-as sorozat, Firmware Version : Build 3.03.B002.

Itt egy konfig részlet:


hosting_sw:admin#show access_profile
Command: show access_profile

Access Profile Table

Total User Set Rule Entries : 51
Total Used HW Entries : 51
Total Available HW Entries : 1485

================================================================================
Profile ID: 1 Profile name: IPv4 Type: IPv4

Mask on
Source IP : 255.255.255.255

Available HW Entries : 205
--------------------------------------------------------------------------------
Rule ID : 1 Ports: 1

Match on
Source IP : 1.2.3.4 Mask : 255.255.255.248

Action:
Permit

--------------------------------------------------------------------------------
Rule ID : 21 Ports: 3

Match on
Source IP : 5.6.7.8

Action:
Permit

--------------------------------------------------------------------------------
....
....
....
--------------------------------------------------------------------------------
Rule ID : 252 Ports: 1-24

Match on
Source IP : 0.0.0.0 Mask : 0.0.0.0

Action:
Deny

================================================================================

Fedora 30, Thinkpad x220

Szia!

Ha a statikus MAC/IP megoldást választjátok (Port Security), azt kérdezzétek meg 1 switch-porton max. hány db MAC címet enged így felvenni - mert ha jól rémlik az max. 16 lehet.

interface GigabitEthernet1/0/3
switchport access vlan 100
switchport port-security
switchport port-security violation restrict
switchport port-security mac-address MAC-1
switchport port-security mac-address MAC-2
..
switchport port-security mac-address MAC-16

Ebbe a limitációba futottam bele egyszer C2960X - switchen, de elnézve a ezt C9300 szériát, ennél se lesz több ez, ezt a limitációt sehol nem írják le :)

FYI én nem olvastam ki a kérdező postjából, hogy MAC címre akar limitálni. Márpedig Te ezzel azt teszed.

Az a lényeg, hogy Hosting Józsi kap a /27-ből 5db IPcímet, amit olyan fizikai v virtuális géppel használ, amivel akar.
A lényeg "mindössze" az, másik - már működő - gép címet ne tudja "ellopni", de főleg a gateway címét nem tudja magára húzni, ezzel kieéses okozva az egész blokkban.

Hát ez jó akkor, ha a példában említett scenario van. De ha /24 ből kapott 10db -ipt akkor már nem.
A legtöbb hosting cégnél pedig így van, hogy van egy nagy tartomány és abból osztogatnak.

Viszont jó pár switch tudja hogy adott porton adott IP kommunikálhat csak, nem kell semmilyen vlan, mac kötés arp kötés semmi. IP-Port és kész. A kérdezőnek is pont ez kell. Csak a jó eszközt kell kiválasztani.

Valamint ez arra is jó, hogy ne tudjon hamis címekkel másokat támadni, amennyiben megtörik az egyik gépet.

Fedora 30, Thinkpad x220

Meg azt sem tudjuk, milyen előírásai, ip címkiosztási logikája van. Dolgoztam olyan helyen, ahol VRRP-t röfögtettek, a subnet első három címe el is ment a vritual gateway címre meg két fizikai router interface címre, így egy /29 esetében 3, azaz 3 kiosztható host ip cím maradt.

( feri__ | 2019. 08. 26., h – 08:40 )

Sokféle megoldást lehet kitalálni, nyilván, az alapértelmezetten csak L2 switch valamilyen extra szolgáltatását lehet kihasználni.
Az is a probléma, hogy a tényleg rosszindulatú felhasználó a switch portot is ellophatja (akár rárak egy buta switchet), MAC és IP címet hamisít.
Az ipar a problémára a port alapú authentikációt találta ki, kaphatók is ezt tudó switchek.
Lásd: https://en.wikipedia.org/wiki/IEEE_802.1X