layer 2 routing

Hálózatok egyéb

Udv!

Van egy ilyen halozati terv: https://imgur.com/a/0foUb

A felso firewallnak hivott cucc egy ilyen: minipc, 4db kulon gigas interface-el, vyos/vyatta vagy pfsense fut rajta.

Az also ket gep egy-egy szerver: egyik nativan fog futtatni dolgokat (ubuntu), a masikon proxmox fog futni vm-ekkel (linux+windowsok).
Mindegyik szerverbe 2 halokartya van: 1-1 megy a firewallba, egy masikkal meg ossze vannak kotve.

Azt szeretnem valahogy megoldani, hogy a proxmoxban levo vm-ek az osszekotesen (zold kabel) keresztul erjek el a Server1-et, es vica versa. jo lenne ha minden gep a 192.168.11.0/24 tartomanyi ipt hasznalna.

(ha server1-en csinalok egy bridge-t, meg proxmoxon is berakom vmbr0-be az eth1-et akkor egy szep hurkot csinalok ami nemjo.)

Mivel lehetne ezt megoldani?

  • 2391 megtekintés

( blackluck v | 2018. 02. 07., sze – 17:58 )

Felveszel a 2 szerverben levo eth1-re egy masik ip tartomanyt es amit azt szeretned a 2 gep kozotti kabelen menjen annak azt mondod azt az ip-t hasznalja, vagy mit ertek felre/nem ertek?

( Mcsiv v | 2018. 02. 07., sze – 18:00 )

benne van a címben, routing :D
A bridge nem routing, ott tényleg hurkot fogsz csinálni.

Ha viszont ezt "jo lenne ha minden gep a 192.168.11.0/24 tartomanyi ipt hasznalna." komolyan gondolod, akkor az IP cimekre explicit kell megmondanod hogy ezek a zöld kábelen vannak

// Happy debugging, suckers
#define true (rand() > 10)

( gabrielakos v | 2018. 02. 07., sze – 18:13 )

Layer 2 az nem routing. A routing a Layer 3-ban van.
Viszont szerintem ha bekapcsolod az STP-t akkor nem lesz gond a hurok.
--
Gábriel Ákos

( uid_7086 | 2018. 02. 07., sze – 21:57 )

Lehet, hogy hülyeség, mert nem értek hozzá, de bridge megtámogatva ebtables segítségével beállított szabályokkal nem segít?

szerk: úgy tűnik rosszul emlékeztem, ebben a formában nem működik a dolog (IP cím alapján a megfelelő bridge portra irányítani a forgalmat) - vagy megint rossz helyen keresem a doksiban.

( n.balazs v | 2018. 02. 07., sze – 18:39 )

Ha jól értem, akkor azt szeretnéd megoldani, hogy a Server1 és a Proxmox gépek közötti forgalom ne menjen át a Firewall gépen. Csak akkor menjen forgalom a Firewall gép felé, ha az indokolt. Jól értem?

( alr | 2018. 02. 07., sze – 19:08 )

mivel nincs switched,így ha mind a két oldalon felveszel egy-egy static route-ot a szervereken?

( uid_6201 v | 2018. 02. 07., sze – 22:45 )

L2 esetén nem beszélhetünk routingról. Azonban a bridging esetén is tudsz hurokmentesíteni.

ip link set BRIDGENAME type bridge stp_state 1

( coco | 2018. 02. 07., sze – 22:50 )

L2 esetében is lehet routing, tipikusan fabric jellegű eszközöknél (pl Cisco Nexus). Ha mindenképpen L2n akarod megoldani akkor nézz szét az MLAG (multi chassis link aggregation) környékén

Ne csináljátok már.. csak azért írok, mert én is be akartam kommentelni, hogy VAN routing layer2-n, és fentebb meg is adták, hogy hogyan...

https://tools.ietf.org/html/rfc7176

https://tools.ietf.org/html/rfc6439

HP-tól Huwaei-en át a Cisco-ig mind hasonlóképp működik és enterprise/cloud környezetben nagyrészt ma ilyet épít mindenki.
(Ha elszakadnánk a 8 eres réz ethernettől, subscriber vagy rádiós dolgok felé, akkor még inkább találnánk routingot layer2-n.)

( Elbandi v | 2018. 02. 08., cs – 01:25 )

kozben egy lehetseges megoldas elojott: iptables + forwardmask + ip route elvileg mukodhet. ki kell tesztelnem.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

( freeoli v | 2018. 02. 08., cs – 06:33 )

Aztakurva. Hagyd ott. Szaladj. Ne nézz vissza és tiltsd le a számokat. Ez egy ámokfutás ami sose lesz jó ha kérdezed.

Vegyel 5k alatt egy switchet és nem lesz gondod. Vagy egyből 3 at. Számold ki hogy mennyibe kerül az időd, hogy Megeri e hogy a magán idődet pazarlod és a végeredményben 100ft-os átlag oraber én oldódik meg a gondot.

A direkt linkre használj más cimtartomanyt.

+1

Ha jol ertem, akkor storage-nek akarod hasznalni a Bare-metal gepet, a Hypervisor ala.

ha mas IP tartomanyt hasznalsz es a storage kommunikaciot (pl GlusterFS) arra "tereled" akkor nincs gond.

Az ket szervert az eth0 labakon ugyis elered a C-s IP tartomanybol, akkor meg mi ertelme van abba tenni az eth1-et is?

( coco | 2018. 02. 08., cs – 11:30 )

halleluja, na végre valaki értelmesen hozzászól a témához

( lcsaszar v | 2018. 02. 08., cs – 12:41 )

Nem kell semmit csinálni, mert a metrika miatt a feltételed automatikusan teljesül.

( zrubi v | 2018. 02. 08., cs – 13:13 )

Ez így "broken by design".

Innetől csak csúf tákolás, bármit is csinálsz.
Véleméynem szerint nem valós problémára keresel megoldást.

pl
- miért kell egy hálózatban lenni a VM-eknek a hypervisorral???
- minek van összebrigdelve a két interface a "tűzfalon"??

Mit is akarsz elérni pontosan? :)

--
zrubi.hu

Szerveren futnak az atalanos dolgok: web, apache, ssh, email, stb. van a masik gep amin a proxmox fut, azon meg majd a jatszos/tesztelo/feligeles dolgok. elotte a cucc meg csinalna a tuzfalat, forwardolna a portokat a megfelelo helyere (korlatos ip cim all rendelkezesre)
hw cuccok adottak, nincs se plusz switch, se semmi (egyreszt meg sajat hw, masreszt ez nem ibm hogy csettintesre ramesik barmilyen hw).

Ebben a felallasban kene megoldani hogy a proxmoxon futo barmi, ne a tuzfalon keresztul erje pl a serveren a mysql-t.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Ertem. Mondjuk azt nem, hogy miert nem erheti el a tuzfalon keresztul (ami ebben az esetben lenyegeben egy switch-kent funkcional) egymast a proxmox es a vas, miert kell a direkt kabel... Az az 1000 megabit (max) nem fogja osszeomlasztani a tuzfalat :)

ha ugy allitod be pl a pfsense-t akkor WAN iranyba (nalad eth0) tuzfalaz, a firewall ket masik laba (eth1,2 ) lenyegeben egy mezei switchkent funkcional. Szoval nem ertem a direkt kabel koncepciojat.

a firewallban 4 fuggetlen interface van, nem pedig switch modul. igy a bitlapatolas az OS-en kereszul megy. ez mar az egyeni perverziom, hogy nem szeretnem ha packetok ott maszkalnak ahol "nem kene" :)

meg persze egy kis self-challenge. :D

kozben talaltam egy megoldast: ebtables-ben brouting tablaben a DROP specialis jelentessel bir: a link layerbol "atdobja" a packetet network layerbe, ott meg mar a standard routinggal at lehet iranyitani masik interfacere (ip route, ip rule)

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Én a helyedben úgy csinálnám, hogy:

- veszek egy switchet, amibe bekötöm a következőket:
* FW.eth1, Server.eth0, Proxmox.eth1 (bridgelve a VM-ek kárytáival)

- FW.eth2 - hypervisor.eth0 összeköt, külön hálózati tartománnyal.
Ide amúgy is csak limitált access kellhet, amit a tüzfalon jól korlátozhatsz is.

Igy a server1-be nem kell másik hálókártya, amivel további szívásoktól kíméled meg magad. A hypervisor hálozata nem lesz a produktívval összekeverve, ami security szempontból alapvető. A tűzfal tűzfal marad(hat), és nem degradálod le switch-re azzal a bridge megoldással.

És igen tudom, mondtad hogy nincs pulsz switch, de egy 5 portos Gbites switch az játékpénz. Ha nekem egy ilyen projekthez nem adnának erre pénzt, akkor inkább vennék egyet zsebből, csak hogy ne gányolt végeretményt kelljen majd átadnom/üzemeltetnem. Ezeken felül, ha majd holnap kitalálják, hogy kellene mégegy server2-is a rendszerbe, akkor nem kell újratervezned...

(Vagy szimplán nem vállalnám a tákolást)

Szerintem.

--
zrubi.hu

Tehát ezt a baromságot az éles céges környezetedben akarod megcsinálni.

Ne tedd.

Ha nincs pénz egy 3k-s tp link 5 portos switchre akkor írd azt és én beszállok 1 usd-vel, komolyan. Írd meg hogy miért ilyen szegény az intezmenyetek és én beszállok. Írd privátban akár, mert ha ezt így csinálod akkor a szegényekkel szursz ki és olyat tanulsz aminek nem fogod hasznát venni.

Te a switchet akarod kiváltani. Kiáltottad, van egy tuzfalad ami még arp proxy is és működik is.

( gyu v | 2018. 02. 08., cs – 15:02 )

lehet ebtables-el is hákolni, ahogy fentebb írták...

Az erős hákolás, és "dinamukos" ott se lesz a megoldás. (Nem fog magától átbillenni)

de magát a "specifikus" route-okat rá lehet attól még kényszeríteni a rendszerre:

a proxmox eth1-ére felveszed ugyanazt az ip-t, ami az eth0-n van, de /32 netmask-kal, és azt az 1-2 specifikus IP-t, amit a Server1 kiszolgál kézzel host-route-oknak felveszed erre az interfészre.

Meg ugyanezt vica versa a Server1-en.

Egy probléma van csak vele: ha megszakad a link a server1 és a proxmox között, akkor a kommunikáció is megáll a kettő közt, nem fog automatikusan átbillenni a route a másik irányba. ahhoz routing kell.

Abból kiindulva, mekkora gányolás mehet ott, kétlem, hogy a Trill-alapú megoldás értelmesen kivitelezhető lenne abban a környezetben. Pedig amúgy, a probléma felvetése után, mint szép megoldás, nekem is az volt az első gondolatom. Csak gyanítom, nem greenfield R&D projektről van szó, ahnem arról, hogy már adott egy rakás ló, amibe aztán vissza kéne lapátolni a...