IP cim switchporthoz rendelve

 ( tibby | 2019. augusztus 19., hétfő - 20:42 )

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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

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

Fedora 30, Thinkpad x220

+1 Ez switch függő. ACL-eknél kell keresni. Milyen switched van?

Meg csak most nezelodunk, de attol fugg h mit veszunk, hogy mivel lehet megoldani a problemankat. Cisco C9300-48T-E vagy 9200-48T-E ami kozott varialunk, illetve Dell N3148 is felmerult.

+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.

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

Valaki az IP Source Guard ot ajanlotta, de mint kiderult az MAC alapjan mukodik es az nem jo sajnos.
ACL jo otlet. Koszi :-)

statikus arp?

En is ebbe az iranyba mennek!

Lecsapnam az interface-en az auto arp-t es az API-n keresztul, amit ad az eszkoz, felvennem/torolnem ha valtozas van. Ez egyszeruen scriptelheto.

Minden mas szerintem bonyolultabb :(

Ez alapvetoen ugy mukodik, hogy minden forgalmat blokkol kikveve a DHCP requesteket. Igy csak azok az IP-k hasznalhatoak amiket a DHCP szerver oszt ki. De ez valoban nem lesz neked jo :)

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.

Írta, hogy ehhez nem használnak DHCP-t.

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

Gondolom azt akarják elkerülni, hogy fel tudják kézzel venni a szomszédos gép publikus IP-jét.

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.

Hostingoltok, tehát fizikai gépen / VM-en belül már nincs kontrollotok?

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?

Nem, mi nem kezeljuk a vm-eket. Nekunk csak annyi a feladat h adott porthoz adott ip-t engedjunk. Vm meg a tobbit majd megoldjak.

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.

Inkább a statikus arp és port security vonalon indulnék el. Az sem mind1, hogy a switch L2 vagy L3 szinten managelhető.

Főleg azért nem, mert IP-vizsgálatot L2 eszközzel nem fogsz ebben az életben csinálni. Port security a hiányos CCIE előképzettségem szerint csak MAC címekre vonatkozik, ergo L2, tehát a kérdezőnek nem viszi előrébb a helyzetét.
--

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.

Koszi!
Nem szeretnenk 3rd party megoldast, meg kulso software-t venni/uzemeltetni ezert.

Esetleg ez: https://packetfence.org/ ?

Vagy valami hasonlo NAC megoldas?

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.

+1, ez tetszetős.

Ez borzasztó overhead.

Ennel szvsz a statikus ARP megoldas egyszerubb es jobb. Nekem ugy tunik, hogy at lett helyezve a problema VLAN ala. Annyi hozadeka van, hogy egymast nem tudjak bantani a "csoportok".

En erre a megoldasra gondoltam:

ip access-list standard 10
permit host 1.1.1.101

interface GigabitEthernet1/0/1
ip access-group 10 in

De nem tudom, hogy ez igy mennyire mukodhet.

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

Ez L2 funkcio ha jol tudom. C9300 elmeletileg tudja. De jo tudni h a d-link is :)

Nem jól tudod, az IP már L3.

Nallatok ez hogy nez ki egy D-link en egy portra beconfiguralva. A config reszere lennek kivancsi. Koszi!

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

Csak azt nem tudjuk, hogy milyen eszköze van a kérdezőnek... Aki a /24-et tizesével osztja, a /28 vagy /29 helyett, az más barbárságra is képes :-)

Vagy csak a mai ipv4 ínséges időkben kevés ip címe van ;>

Fedora 30, Thinkpad x220

vagy baszik sem L3ban kirouteolni a switchportra... aztan ott azt csinal vele a masik PtP amit akar

/29 esetén 10-nél kevesebb IP-cím használható...

Ha tizesével osztja, akkor meg mindenféle más szívásokkal néz szembe.

Nyilván, viszont én a "kevés IP-címre" reagáltam.

Nem ad mindenkinek egyedi gw-t.
A felosztás csak logikai. Egy subnetben van általában mindenki.

C9300-48T-E

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.

Privat vlan?

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