Hálózat 192.168.X.X C-osztály netmaskjának átírása

Szerverek

A mostani hálózatunk szegmensekre , alhálózatokra van bontva, 10 alhálóra így:

192.168.168.0 , 192.168.167.0 , 192.168.1.0 , ...

A hálózati maszkok a gépeknél a DHCP-által kiosztva : 255.255.255.0 

510 kliensről van szó.

Ezért most van egy gateway gép (Virtuális gép) aminek van annyi , (10 virtuális) hálókártyája , ahány alhálózatunk van, és annyi IP -címe is.

192.168.168.7 , 192.168.167.7 , 192.168.1.7 , ...

 

Szeretnénk ezt a gateway  gépet kiváltani egy FortiGate eszközzel, úgy, hogy a 4  hálókártyája figyelne a belső hálózat felé.

Ezért a kérdésem az lenne, hogy mi történne, ha a hálózati maszkot átírnánk erre : 255.255.0.0  ??

Meglátásom szerint akkor az alhálózatban lévő gépek látnák egymást, anélkül, hogy a gateway 10 virtuális hálókártyát tartalmazna, ami fizikailag egy LAN port, 1 Gigabit  sebességú.

Akkor a  FortiGate lenne a gateway , ezzel a címmel : 192.168.168.250 , és a mostani gateway Linuxos gépet kivehetnénk a hálózatból.

Jól gondolom, vagy nagyot tévedek ??

 

UPDATE :
Minimális külsős (FortiGate szakember) segítséggel meg lesz oldva a VLAN szeparáció egyenlőre egy CORE-SWITCH -csel, így nem kell a szegmenseket sem átalakítani.

  • 1377 megtekintés

( uid_6201 v | 2021. 10. 01., p – 07:08 )

Szerkesztve: 2021. 10. 01., p – 07:09

úgy, hogy csak egy hálókártyája fegyelne a belső hálózat felé.

Előtte a switch VLAN képes?

( gyuri23 | 2021. 10. 01., p – 07:16 )

Alapvetően jól gondolod, pláne, ha nincs VLAN sehol. Arra kell figyelni, hogy az összes kliensen át kell írni a GW-t az újra, vagy a tűzfal belső interfészén az összes eddigi GW címet be kell állítani (ez talán nem annyira szerencsés) Ha vannak static címek a hálózaton, pl. nyomtatók, azokat kézzel kell átállítani. Egyébként működik a dolog.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

A gépek IP címeit, gateway címet, DNS címet  is a DHCP osztja. Tehát ez könnyen átírható.

A FortiGate most csak egy címen (LAN -porton) figyel (192.168.168.250),  de gondolom ennek is a hálózatimaszkját át kell majd írni erre : 255.255.0.0  .

Igaz ?

Ja, és jó lenne , ha a gépek látnák egymás, attól függetlenül, hogy más alhálózatban (nem VLAN) vannak .

Sot, meg akkor is lathatjak egymast, ha egy switchelt halon (egy broadcast domain) lognak kulonbozo subnettel (host-on definialt subnet, a gw rendesen legyen beallitva!).

A gateway kuldhet ICMP redirect-et (emlekeim szerint ez volt az), amivel a host foglalkozhat. Igy nagyreszt beken hagyjak a routert.

Ez konnyen ellenorizheto is. Ha bekerul A MAC tablajaba B cime es viszont, akkor nyert.

A topicnyitobol ez nem derult ki.

Mellesleg ez nem ganyolas, hanem az IPv4 szabvanyos resze. Viszont konnyen annak tunhet. Ha a halozati szakerto nem erti az alapveto mechanizmusokat, erosen csodalkozhat, hogy miert vagy miert nem tortenik valami meg egy ilyen egyszeru konfiguracioban is.

Peldaul az, hogy a netmask-nak kizarolag a hoston belul van jelentosege (dinamikus routing eseten ez nem ilyen egyszeru) sokaknak nem vilagos. Jelen esetben csak azon egyszeru dontesnel jatszik szerepet a hostban, hogy a kimeno forgalmat a router (illetve melyik) fele iranyitsa, azaz a GW MAC cimet irja a fejlecbe, vagy lokalis halon probalkozzon a cel keresesevel. De ehhez a donteshez se csak a netmask-ot veszi figyelembe a host.

Igen, de azért nem árt, ha követünk bizonyos mintákat. Én vagyok annyira maradi, hogy ha LAN hálózatot tervezek, akkor az:

- mikroszegmentált,

- egy vlanhoz egy és csak egy subnet tartozik

- intervlan routing segítségével érik el  egymást a különböző subnetben leledző hosztok

És ezt javaslom a topicnyitónak is.

Akkor egyelőre legalább 1 managelhető switch-et vegyél a Fortigate után, ami tag-elt vlan-okat szétpakolja neked access portokra, amikre mehetnek a régi switch-ek a régi szegmensekkel.

Kezdetnek! Aztán innen lehet majd tovább fejleszteni tervezetten, ésszel.

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Az munkavállalóra is igaz, hogy a feladathoz választjuk a szerszámot, nem a szerszámhoz a feladatot. Most akkor a Windows-os GUI lovag kolléga (tehát nem ért az IT-hoz, csak azt hiszi mindenki, a GUI-t jól kattintgatni könnyű) miatt kabátot kerestek a gombhoz. Egy 500 végpontos hálózat üzemeltetésében. Grat!

Álatlában nem szokták javasolni hogy /24-nél nagyobb hálózat legyen egyben.

Utána kellnézni, de van ilyen lehtőség Fortiban:

        config secondaryip
            edit 1
                set ip 9.1.1.2 255.255.255.0
                set allowaccess ping https ssh snmp http
            next
        end

Vagy veszel egy VLAN képes switchet a Forti elé...

szinte bármilyen mai openwrt képes soho router tudja :))
de pl.: sok 'okos' switch is tud ilyet. de ez utóbbi nem ad dhcp/dns szolgáltatást.
és mivel nagy valószínűséggel - bár erről nem tudunk semmit - a gateway gépnek nevezett szerver adja azt is, ez megszűnne, a hálózat meg működésképtelenné válna. sacc/kb.

na de hát az alhálózatok valamiért létrejöttek, pl. pont azért, hogy funkciók/gépek/szolgáltatások könnyen szeparálhatóak legyenek.

arról nem is beszélve, hogy az alhálózat gépei lássák egymást, az csak a routok beállításának kérdése.
 

( nagyjoco | 2021. 10. 01., p – 08:53 )

A forti tud intervlan routingot, kell egy vlanokat támogató switch és kész vagy. Nem kell , őst nagyon nem is ajánlatos ekkkora broadcast domain-t létrehozni.

( quash | 2021. 10. 01., p – 11:04 )

Inkább kérjetek meg valakit aki ezt VLAN-okkal kivitelezni tudja!
Lehetőség szerint nem egy porton.

Amit kitaláltál, teljesen működő képes, hosszú távon a következő problémákba fogtok beleszaladni:

  • router 1 port = 1Gbit
    A jelenlegi megoldásotok ugyan nem szép, de minden subnetnek saját gigabites kapcsolata van a többi felé.
    /16-os maszkkal ennek nem lesz jelentősége,  de a későbbiek folyamán ha pl. más subnetbe raktok bármit is, akkor maximum 1 gigabit lesz az áteresztő sebesség!
  • Broadcast és minden egy más forgalom a hálózat összes pontján meg fog jelenni.
    Vagyis egy csomó felesleges forgalom megy mindenfelé.
    10 gépes hálózatnál nincsen jelentősége, 50-100-… gép esetén már mérhető sebességcsökkenés lehet!
  • Semmilyen formában nem fogjátok tudni a hálózatok közötti forgalmat szabályozni.
    Ha vannak szerverek, mindenki látni fogja őket, a portás, a vendég WiFi, mindenki …
    Ha vannak kamerák szintén.
    Vannak olyan erőforrások amiket javasolt valamilyen DMZ jellegű hálózatba rakni.
    Ezzel a megoldással ilyen sem lesz
  • VPN – ha bármilyen külső VPN-t akartok használni, lehet átfedés, ami nem kötelező jelleggel, de problémát okozhat.

Nem írtad mekkora hálózat, mennyi végpont/kliens/etc … de ha több switch-etek van, akkor egy /16-os subnetet inkább felejtsétek el. Sok helyen ebben látják az über tuti megoldást! Ilyet akkor csinálunk ha nincsen kedvünk vele foglalkozni, vagy nem értünk hozzá. Hosszútávon csak a szívás lesz vele.

Az ideális megoldás Router, VLAN-ok (megfelelő switch-ekkel), LACP – hidd el nem olyan bonyolult, és hosszútávon megtérül!

Most 510 kliensünk van, amik DHCP-től kapnak IP-címet. Ezek vannak funkciók szerint széttagolva 10 alhálózatba.

A FortiGate-nek 4 Gigabites Lan portja van, tehát a mostani 10 alhálónkat osztanánk ki a 4 fizikai portra.

Ja, és a mostani Gateway szerver Vbox-ban virtualizált, tehát fizikailag egydarab  Gigabites Lan porton virtualizálunk 10 Vbox Lan portot.

Szerintem ha a FortiGate elé tennénk egy VLAN képes Switchet és abba menne be a 10 kábel és onnan a FortiGate 4 portjába lenne szétosztva (4 x 1 GBit) Akkor már jobb lenne a helyzet a mostaninál is.

Egyetlen dolgot kellene csak reálisan mérlegelnetek!
Egy szakmainak gondolt fórumban megkérdezed, merre induljatok el.
A válaszadók 80% azt mondja, ne csináljátok, mert csak problémátok lesz belőle!
Ebből milyen következtetést kellene levonni? :)

Ha egy cégnek akinek több mint 510 számítógépe (és egyéb eszköze) van, nem tud vásárolni ~10-15 db managelhető switch-et, akkor ott igen komoly problémák vannak!
Ha ezt a managment nem érti meg, akkor vagy a kommunikáció rossz az irányukba, vagy szimplán idióták.

Ekkora rendszert valós szegmentáció nélkül üzemeltetni, nagyon sok szempontból aggályos, a többségét leírták már nektek.
Ha az IT osztály ezt nem érti meg, vagy szimplán a problémát nem éri, akkor erősen javasolt lenne egy ezzel foglalkozó, külső céget bevonni.

Senki nem mondta hogy amit kitaláltál, az nem működő képes! Simán működni fog, akár évekig probléma mentesen is. Láttunk már ilyet több helyen is, megy. Néha, nem is értik miért kellene rajta változtatni, hiszen működik!
Managmentnek általában ez a lényeg, menjen …
De ha probléma lesz! Akkor kit fognak elővenni?

Amúgy ha tényleg ennyire nincsen lové, egy alternatív javaslat:
Vesztek N db Cisco 3750X switch-et, ezeket használtan 100-120€-ért garanciával be lehet szerezni!
Esetleg adott helyen ahol 10-20-30 db gép u.a. subnetben (VLAN)-ban van, ott marad régi switch.
(POE verzió sem sokkal drágább) és kialakítotok egy normális hálózatot.

Jelenleg egy router-től vártok csodát, azért mert az kattingatni lehet …

A félreértések elkerülése miatt, segíteni szeretnék, nem cseszegetni! :)

Tehát akkor most is egyetlen egy fizikai hálózaton megy a teljes forgalom (tehát nincs a buta switch-ek szintján sem szeparláva, hogy egyik IP szegmens egyik switch, amásik IP szekmens másik switch), és a mostani router egyetlen egy fizikai LAN kapcsolattal rendelkezik?

Akkor ez alapján úgy oldjátok meg a címkiosztást, hogy vagy fix IP van a gépeken, vagy a gépek MAC cím alapján kapnak IP-t a megfelelő tartományból. Mind a kettő jó nagy kínlódás.

Szerintem forszírozni kellene, hogy az új Fori teljes körű kihasználása nem lehetséges VLAN képes switch-ek nélkül a jelenlegi hálózattal. Hátha így a Fori befektetést nem akarják kukázni, és jut keret a normális megoldásra.

( junior013 | 2021. 10. 01., p – 12:51 )

Elvben működőképes amit írtál, gyakorlatilag szakmai szempontból egy határozott ön-tökönszúrás amire készülsz.

A leírtakból feltételezve nem egy 10 gépes kisirodai hálózatról beszélünk. Márpedig nagyobb hálózatokat adat- és üzembiztonsági okokból is szegmentálni KELL.

Szóval VLAN képes eszközök felé kezdj el gondolkozni!

"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

( Raynes v | 2021. 10. 03., v – 19:08 )

A 192.168.x.y címekre eleve 255.255.0.0 maszk kéne és nem 255.255.255.0, amit most használtok. Nézz utána a neten, hogy hogyan működik a hálózati maszk, vannak rá online kalkulátorok. Ha zavarba ezt ez a 255.255.255.255.255.255.255.255.istentudja.hány0 szisztéma, akkor sok szoftver támogatja a /16-ként is meg lehet adni jelen esetben.

Tekints a netmaszkra úgy, hogy megmutatja, hogy az IPv4 cím melyik oktetjei, és azok milyen részben változhatnak, és mely részük fix. Tudom, bonyás, de vissza fogjuk még ezt a bonyás megoldást is sírni, mikor bejön az IPv6, mert ott annyira megkeverték a fekáliát, hogy fel van hobosodva teljesen fehérre.

Eredetileg ez a maszkozás azt szolgálta, hogy a hálózaton korlátozni lehessen a klienseknek kimenő broadcastet, mert ha túl tág maszk van megengedve, akkor sokféle nem létező IP-re lesz kiküldözgetve mindenféle broadcast csomag, ami a hálózat túlterheléséhez vezethet. Így a netmaszkkal van bekorlátozva, hogy hány IP lehet az adott hálózaton, szükséges mértékűre szorítva a felesleges hálózati forgalmat.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Külön gw ip-i van minden subnetnek most, tehát a közös maszk alapból nem lenne jó önmagában.

"..mert ha túl tág maszk van megengedve, akkor sokféle nem létező IP-re lesz kiküldözgetve mindenféle broadcast csomag.."
Ez így értelmetlen mondat, nem így működik a broadcast.

Miért kellene /16-os maszk a 192.168. tartományra a mostani /24 helyett, mindenképp?

Az, hogy az egyik, privát célra fenntartott tartomány a 192.168.0.0/16, attól még nem kell /16-os tartományként használni, hanem tetszőlegesen tovább bontható a helyi igények szerint. Sőt, nem is igazán praktikus egy, akár 64k címet tartalmazó subnet-et üzemeltetni. Ilyen elven a 10.0.0.0/8 tartományt mindig /8 netmaszkkal kellen használni?

A broadcast üzenet meg nem megy ki a subnet minden egyes címére, ha használja valami ha nem. Nem attól lesz nagy a broadcast forgalom. A brdoadcast üzenet csak a brodcast címre megy ki, és minden egyes gép ami az adott subnet-be tartozik feldogozza. A nagy broadcast forgalmat az okozza, hogy minden gép válaszolni fog ezeknek a broadcast üzeneteknek a túlnyomó részére. Az adott subnet gateway-e pedig nem küldi tovább a broadcast üzenetet a többi subnet-re, Ő a határ, így lesz a broadcast üzenet lokális.

Annyi megjegyzés, hogy "A nagy broadcast forgalmat az okozza,minden gép válaszolni fog ezeknek a broadcast üzeneteknek a túlnyomó részére" ez sem pontos. A broadcastra általában egy gép válaszol pl. egy arp requestre. A nagyobb broadcast forgalom a brodcastot küldő gépek számának növekedéséből adódik.

Ha csak 192.168.1-168.1-255 tartományban akarja használni (42 ezer alcímmel), akkor kell a /16-os maszk. A /24-es maszk a pl. 192.168.fix.1-255-re elég lenne, de nagyobb tartományra nem, mert csak 8 bitnyi, azaz 256 alcímet enged, a másik 24 bitet kimaszkolja.

Persze megoldás lehet, ha nem ragaszkodnak a 192.168.1-168.x-hez, hanem megfelelne nekik a 192.168.0-8.x is, akkor mehetne a /21 maszk (255.255.248.0) is. A /16 ekkora is elég (65 ezer alcím), csak kicsit pazarolja az alcímeket. A gyakorlatban azért szoktak /8 többszörösénél maradni, azaz /16 és /24, mert fejben ezekkel a legkönnyebb számolni, ezekben van elég tartalék, és annyira azért nem pazarlók.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Ezen válaszod alapján elnézésedet kérem a sajáűt válaszom miatt. Én úgy értettem, azt írod, hogy a 192.168. tartományhoz csakis /16 maszkot szabadna használni minden esetben, mindenhol, mindenkinek.
De most leesett, hogy jelen problémára írtad, hogy ha /16-ot használnának a /24 helyett, az megoldaná a konkrét felvétést.

Nem. Ti a mostani funkciók szerint szeparált hálózatból egy nagy, egybeborított trutymót szeretnétek, mert kellő hozzáértés nélkül ezt tartjátok egyszerűbbnek. Egy DGS-1100-08V2/E 8 portos managelhető switch 12E Ft körül van, a 16 portos "tesóját" is megkapod 40e Ft alatt - ami egy Fortigate után nem hinném, hogy földhöz verné az IT-s budget-et.

Az meg, hogy a 192.168... az /16-tal ad privát címtartományt, az nagyon nem azt jelenti, hogy /16-os maszkkal, egybeborítva kell használni (Ilyen alapon aki 10.x.x.x-es címeket használ, annak /8-as maszk kéne?) A 192.168.x.x/16 annyit jelent, hogy 65535 darab /24-es (régi elnevezés szerint C-osztályú) tartományt ad.

Én úgy tudom, hogy:

A osztály, például 10.x.x.x/8 (CIDR Notation: 10.0.0.0/8) esetén 16777216 (2^24) az összes IP cím, ebből gépeknek kiosztani 16777214-et lehet 1 subnet esetén, mert a 10.0.0.0 a subnet id lesz és a broadcast cím pedig a 10.255.255.255. Az megint más kérdés, hogy a .255 vagy a .0 végűt bizonyos okokból nem lesz kiosztva várhatóan a gyakorlatban.

B osztály, például 172.16.x.x/16 (CIDR Notation: 172.16.0.0/16) esetén 65536 (2^16) az összes IP cím, ebből gépeknek kiosztani 65534-et lehet 1 subnet esetén, mert a 172.16.0.0 a subnet id lesz és a broadcast cím pedig a 172.16.255.255. Az megint más kérdés, hogy a .255 vagy a .0 végűt bizonyos okokból nem lesz kiosztva várhatóan a gyakorlatban.

C osztály, például 192.168.0.x/24 (CIDR Notation: 192.168.0.0/24) esetén 256 (2^8) az összes IP cím, ebből gépeknek kiosztani 254-et lehet 1 subnet esetén, mert a 192.168.0.0 a subnet id lesz és a broadcast cím pedig a 192.168.0.255.

Kérlek pontosítsatok, ha valamit nem jól tudok.

Sakk-matt,
KaTT :)

Visszatértem! A hozzászólásom alatt lévő szavazat gomb nem nyomódik meg magától!

Persze, hogy bármekkora tartomány lehet, /8 - /30 között, ahogy írtad. Bocs, ha félreérthető voltam.

Én úgy értelmeztem, hogy zeller a /8 -ba max 65536 gépet ért bele, nem 16,7 milliót, ezért írtam ezt. Mivel hozzászóltál, már nem tudom javítani, hogy arra írtam :)

Sakk-matt,
KaTT :)

Visszatértem! A hozzászólásom alatt lévő szavazat gomb nem nyomódik meg magától!

Jogos, minden oké. Újra elolvasva, nagyon félre értettem, amit írtál. Többet kellett volna olvasni, kevesebbet írni! :D Akkor nem írtam volna, csak bólogattam volna.

Sakk-matt,
KaTT :)

Visszatértem! A hozzászólásom alatt lévő szavazat gomb nem nyomódik meg magától!

( Friczy v | 2021. 10. 06., sze – 17:26 )

Ennyi kliensre is feleslegesnek érzem a /16 maszkot. /22 elég, ha nagyon óvatos vagy, és azt mondod, hogy a nagyon távoli jövőben sem látod értelmét a külön vlanoknak (pedig annyi kliensnél már volna), akkor /21.

A /16-tal az a fő baj, hogy nagyon sokan használják ezt a privát címteret, és ha bármikor kapcsolódni kell egy olyan hálóhoz, ahol 192.168.x.x címek vannak, akkor nehéz dolgod lesz.

"nagyon sokan használják ezt a privát címteret" - Na ja... Itthon anno egy 192.168.1.0/24-es "túloldal" miatt kellett címtartományt cserélnem... De láttam olyat is, ahol két cég hálózatát kellett öszeboronálni, viszont mindkettőben volt 192.168.x.0/24, és egyiket sem lehetett egyszerűen átcímezni - ott maradt a dupla nat a céges hálók közötti tűzfalakon...

( KaTT v | 2021. 10. 07., cs – 00:19 )

Előttem nagyon sokan leírták, konkrét érvekkel, miért NEM jó a /16 500+ gépnek.

Írok +1 érvet: beszabadul valami vírus, trójai, vagy hasonló... esetleg egy hacker... amint meglátja, hány host-ot lát egy gyors körbenézés után, pezsgőt fog bontani...

Értelmezhetnéd úgy is, hogy a külön subnetek egy külön várak, külön várfallal, védelmi zónával. Most le akarod bontani a sok várfalat, hogy csak 1 várfal legyen mindegyik körül. Értem az érveket, miért lenne /16.

Egy ideális világban: Windows, vírusok, hozzá nem értő felhasználók nélkül, akár még ... de inkább akkor sem! :)

Az is lehet, hogy mind irigykedünk, hogy de jó neked, hogy egy /16 subnetben van 500 géped, nekünk bezzeg max 250, de inkább jóval kevesebb van a /24-en, mert nyuszik vagyunk.

 

LEVIDEO: Váltsd valóra az álmaid, tedd, amit tenned kell! Hallgass a belső hangodra! Valami biztosan lesz!

Sakk-matt,
KaTT :)

Visszatértem! A hozzászólásom alatt lévő szavazat gomb nem nyomódik meg magától!

( Robika88 | 2021. 10. 07., cs – 08:36 )

Szia!

Nekem is ez volt a problémám. Mivel egyes részegységeknek látni kellett egymást így félmegoldással megy jelenleg.

(pl. 200 méterre egy másik gép ami szintén igényli az adatfeltöltést, vagy log-olást egy közös helyről)

A megoldásunk vlan és 255.255.252.0ás maszk lett. Pl. kamerák, vagy ipari gépek, nyomtatók, dolgozok, wifi ... egy egy tartomány, egy egy vlan.

A legjobb ezekben, hogy mindent dhcpvel megoldani nem lehet...

Tervezője úgy találta ki 15 éve a gépet, hogy csak statikus ip stb... Valahol meg is értem ezeket a rendszereket, mert ha folyton össze vagy vele csatlakozva akkor fix a jó (dns név stb nélkül). Én is tettem rá olyan site-ot amit távolról teloról nézel, de a server még is adatokat vesz lokál helyekről amit ajax frissít másodpercenként telon (itthonról mehetnék a levesbe 1-1 ősi géppel, vagy dns névvel backend végen).

Egy tuti: jól meg kell tervezni, de mindenre nem lehet felkészülni. Ahány ház annyi szokás.