[Megoldva] DHCP - alhalozatok, tervezes

Hálózatok általános

Sziasztok!

Van egy belso halozatom, ami jelenleg igy nez ki: 10.0.0.0/24

Na most az a kerdesem, hogy ha fel akarnam ezt osztani 3 reszre maszkokkal, valahogy igy:
10.0.0.0/26 - ide dinamikus DHCPt szeretnek
10.0.0.96/27 - ide statikus cimeket MAC alapjan
10.0.0.192/27 - ide is statikus cimeket MAC alapjan

akkor:
a) A windows kliensek latnak - e egymast? Mondjuk pl. az egyik alhalozatbol a masikban levo felkinalt mappakat.

b) Felgyorsulna - e a halozat?

c) A serverben egy halozati kartya van a belso halozatra, es egy kifele. Meglehet ezt valositani a dhcpd.conf-ban tobb subnet bevezetesevel? Ha igen, kellenek groupok is?

d) A server(mint gep) tobbi server funkcioira(mint kiszolgalo SW) ez a valtozas nem lenne kihatassal? Vagyis ahol a belso halozat IPjeire szukseg van a konfighoz, ott at kell alitani kulon mindegyikre? Szoval a 10.0.0.0/24 nem letezhet tobbe?

e) Esetleg valamely beallitasokban tudok hivatkozni mind a 3ra alhalozatra egyszerre igy: 10.0.0.0/24 ?

Koszi a segitseget elore is.

  • 2520 megtekintés

( zeller | 2008. 06. 10., k – 20:56 )

Fizikailag is szétszeded, vagy csak logikailag? A logikai szeparáláshoz (tól-ig dinamikusan osztott címek, a további részen meg DHCP-vel hardvercímre osztott címek) elég a dhcp-szerverben megfelelően felvenni a fix címeket. Fizikai (avagy vlan-os logikai) szeparálás esetén meg köll routing az egyes subnetek között... Ja, ha ugyanazon a fizikai infrastruktúrán mennek a gépek, akkor nem lesz gyorsulás.

( Mik v | 2008. 06. 10., k – 21:00 )

a: Igen
b: Nem
c: Igen, nem
d: Nem kell átálni. A /24 mint hálózat nem létezne többé, viszont pl. az Apache a htacces-ben továbbra is használhatná a /24-et. Ebben kicsit bizonytalan vagyok, fixme!
e: Igen, ESETLEG és igen VALAMELY beállításokban, attól függ mire gondolsz. Lásd. d pont.

Csak a dhcp módosítás kevés lesz, routingot is kell konfigurálni. A leírásod alapján felesleges a /24 szétdarabolása, a címek kiosztásának darabolását a dhcp így is megtudja csinálni. (0-63 -ig dinamikus, 96-126 -ig statikus stb)

( stra | 2008. 06. 10., k – 21:08 )

a) A Windowsok látják egymást, ha a hálózatok között lévő router vagy tűzfal átengedi a forgalmat.

Név szerint akkor látják egymást, ha mindegyik lmhost file-jába beírod a többi nevét, vagy valamilyen közös névszolgáltatást használsz (pl.: WINS), azaz a broadcast alapú nem fog menni.

b) Ha ugyanabba a broadcast domainbe tartoznának, akkor nem valószínű. Azaz nagy hálózatot érdemes szétszedni L2 szinten is. Úgy tűnik, hogy te maximum 119 gépet szeretnél külön hálózatokba tenni. A gyorsulás elsősorban a nagy broadcast-forgalom csökkentéséből adódna.

c) Attól függ, mit. Egyelőre nem világos, hogy miért és hogyan szeretnéd a több hálózatot kialakítani.

d) A szerverfunkciókra nem lesz kihatással. De ha subnetelni szeretnél, akkor subnetelni kell, és azt beállítani a hálózati konfigokban.

e) Az a használat helyétől, a kívánt céltól függ.

Megjegyzés: router esetleg több hálózati kártya vagy trönkölés a szerveren, opcionálisan tűzfal a hálózatok közötti forgalomhoz, VLAN-ok kialakítása, switchek.

( NagyZ v | 2008. 06. 10., k – 21:23 )

oo, most vagy te nagyon kavarsz valamit, vagy en ;)

10.0.0.0/24 -et osztod szet, de mivel csak maszkokat irtal, igy csak a dhcpd -t kell konfigolni. a szolgaltasok szempontjabol meg tokmindegy hogy most epp honnan jovok (persze szurheted kulon), csak ettol (gondolom most mindenhol 10.0.0.0/24 van irva) nem fog semmi borulni, max neked segit az, hogy szetosztottad oket.

ergo _semmi_ nem fog valtozni.

a vlanokkal valo felosztas mar mas, ahogy zeller is irta.

( Tincibodal | 2008. 06. 11., sze – 11:07 )

Hat koszonom mindenkinek a hozzaszolast, hogy ennyien probaltok segiteni.

Mivel tobb valaszban voltak kisebb elteresek, jobbnak latom inkabb, ha inkabb egy kicsit konkretizalom ez a szituaciot:

A debian linux serverben 2 halokartya van: egy kifele, es egy amire az egesz belso halo kapcsolodik. Ebben a belso haloban a kliens gepek mar csak sima switchekkel vannak osszekotve. Ugyhogy en azt gondolom, hogy fizikailag is, meg per pillanat meg logikailag is egy halozatban vannak(10.0.0.0/24). Most ugynez ki a dhcpd.conf beallitasom, hogy dinamikusan es statikusan kiosztom amit kell, tehat mukdodik alhalozatok nekul is.

Az alhalozatokra azert gondoltam, hogy konnyebben kezelhetove valjanak ezek a "blokkok". Valojaban szuksegem volna 3 csoportra (IP tartomany blokkra), de kulon akarom oket kezelni. Pl. meggyult a bajom az iptablessal, mert nem akar mukodni az "iprange", es innen jott az otlet, hogy ha lennenek alhalozatok akkor az egesz alhalozatra tudnek szabalyokat adni, es egymastol fuggetenul a 3 alhalozatot kezelni (engedelyezni vagy blokkolni). Mivel hasznalok proxyt is, igy kulon tudom akkor allitani itt is a 3 alhalozatot (bar azzal jelenleg nincs gondom, ott tudok szurni ugy is, ha IP intervallumot adok meg).

Szoval ez az alhalozatokra valo bontas, ilyen modon nem konnyitene meg a munkat, ha tudok hivatkozni az alhalozatra?

Csak azt sem tudom sajnos, hogy az ilyen logikai felosztas mennyire bontja meg a serverfunkciokat, esetleg a routingot ... vagy valami mast ?

Vagy latnak-e egymast a logikai alhalozatok problema nelkul? Ettol is tartok.

Az alhálózatok arra jók, hogy szétszedd a hálózatod kisebb darabokra. De ha csak azért szednéd szét, hogy ezzel szabályozd a hozzáféréseket, akkor azt _esetedben_ egyszerűbben is megteheted. Majd ha tisztában leszel a routing, hálózat-alhálózat fogalmakkal, akkor használhatod az alhálózatokat...

( Kiskübi v | 2008. 06. 11., sze – 15:34 )

Látom, zavar esete forog fenn.

A-osztályú címek: 8 bites hálózati cím, a maradék 24 a gépek címe. A 10-essel kezdődő címek olyanok, amelyek NAT mögött használatosak, mert internetre esetleg kijutva a routerek úgyis eldobják. Ezek jók tehát lokális hálóra. A maszk (bitmaszk) mondja meg, hogy mely bitek képezik a hálózati címet.
Leírási módok: cím/maszk (pl. 10.0.0.0/255.0.0.0); cím/bit (pl. 10.0.0.0/8).
A-osztályú címtartomány: 10.0.0.1 - 10.255.255.254.

Hálózat fölosztása pl.: 10.0.0.0/255.128.0.0, azaz 10.0.0.0/9, ekkor két hálózat lesz, a 10.0.0.0 és a 10.128.0.0, de 24 helyett csak 23 bit marad a gépekre.

B-osztályú címek: 16 bites hálózati címet szoktak beállítani, de utánaolvastam, nehogy hülyeséget írjak, 12 bites az osztatlan B-osztályú hálózati cím. (A 16 bites hálózati cím nem rossz attól még, csak osztott).
Lokális címtartomány 172.16.0.1 - 172.31.255.254;
Hálózat: 172.16.0.0/255.240.0.0, azaz 172.16.0.0/12.

C-osztályú címek: 24 bites hálózati címet szoktak beállítani a maszkkal, valójában 16.
Előbbi esetben (24 bites háló):
Lokális címtartomány 192.168.x.1 - 192.168.x.254;
Hálózat: 192.168.x.0/255.255.255.0, azaz 192.168.x.0/24.
Utóbbi (16 bites háló):
Lokális címtartomány 192.168.0.1 - 192.168.255.254;
Hálózat: 192.168.0.0/255.255.0.0, azaz 192.168.0.0/16.

Broadcast-címek azok, amelyeknél a gépcímben végig 1-es bitek vannak, pl. egy /8-as hálózatban: y.255.255.255. Ezeket ne oszd ki. :)

A Windows úgy tudom, az alhálókon nem lát keresztül (illetve a saját smb/cifs protokolljával nem). TCP/IP átmegy, ha van route-olás közöttük.

Mivel a Win elég sokat broadcast-ol, egy erősen terhelt hálón lehet, hogy valamelyest javít egy felosztás, de szerintem a gyakorlatban ez nem lesz megoldás semmilyen teljesítményproblémára.

A többi szerver jó kérdés.

Ha pl. egy /8-as tartományt leosztasz (/9-re, /24-re, mindegy), akkor nem működik többé a /8-as tartomány.

Arra vigyázz, ha DHCP-szervert indítasz, hogy ne kapkodja el az esetleges egyéb DHCP-szerverek elől a klienseket, mert akkor lehet, hogy valaki morcos lesz. :) pl. csak a saját switch-ed felé menő interfészre (ethX) menjen.

Szerintem jobb, ha 10.0.0.0/8 a háló, nincs osztás, de attól még rendszerezheted a címeidet. Nálam pl. 10.1.x.x a szerverek, 10.2.x.x a beállított fix címek, 10.3.x.x-re ad a szerver ethernet-cím alapján, a DHCP-ben előre konfigurált IP-címeket, 10.4.x.x-re meg DHCP megy a nem ismert ethernet-című gépek számára.

Az elgépelésre és egyéb hibákra vonatkozó jogot fenntartom.

En azert nagyon koszonom neked es mindenkinek a segitseget, nameg foleg ezt a reszletes leirast.

A vegeredmenyben akkor nem osztok, meggyoztetek. :))

A tartomany cimeknek, maszkoknak mar en is utananeztem (A,B,C osztaly, halozat cime vs. gep cime, ... stb.), de gyakorlatilag sajnos meg mindig nem ertem, hogy mikor, azaz mi indokolja, hogy "csak" logikailag oszzak fel egy halozatot.

Tehat milyen esetben dont ugy a rendszergazda, hogy logikailag kell/erdemes felosztani egy halozatot?

Vannak esetek, amikor elég csak "logikailag" (IP-szinten), de az az általánosabb, amikor ez együtt jár a "fizikai" (Layer2-szinten, pl.: Ethernet; külön kábelezés, VLAN-ok) történő szeparálással is.

Az első esetben azért logikai, mivel egy adott IP-tartományban lévő gépek csak egymást tudják megszólítani, de bizonyos (pl.: broadcast) jellegű forgalom mégis látható és lehallgatható marad a másik IP-tartományban lévők számára is, valamint nem ad védelmet az ellen, ha valaki a másik subnetbe tartozó IP-címet állít be magának, és így próbál többletjogokat szerezni.

Az előbbi általában szükségmegoldás. Erőltetett példaként: esetleg alkalmazható akkor, ha nem túl sok a gép, és az egyiket csak bizonyos gépek érhetik el, de a céleszköz nem képes ezt önmaga szabályozni, és nincs pénz menedzselhető (vagy további) switchre, esetleg plusz hálózati kártyákra, és a biztonsági kockázat kicsi.

Az utóbbira példa egy belül LAN-t kiszolgáló internetkapcsolattal rendelkező gateway (router, tűzfal), vagy egy több osztályból álló cég, ahol a különböző osztályok különböző erőforrásokat érhetnek el. Valamint a broadcast forgalom csökkentése érdekében bizonyos host felett már akkor is célszerű, ha esetleg egyéb ok miatt nem lenne rá szükség.

Felettem stra korrektül leírta, de lehet még variálni. Milyen esetben dönt úgy? Éppen olyan hangulatban kelt fel aznap reggel :)
Nálunk pl. 200-egynéhány gép van 2 épületcsoportban, összesen 5 épületben, 8 rendezővel. Vannak épületek amelyek csak pár méterre, de a 2 épületcsoport kb. 300m-re van egymástól. (meg még a többi épület, de most maradjuk ezeknél) Címkiosztás rendező szekrényenként történik, így van ahol egy C hálózatban csak 10 gép van és van olyan C hálózat ahol 80-90. Így IP cím alapján tudom, hogy melyik gép melyik rack-be van bekötve, melyik switch-hez kell nyúlni, vagy rosszabb esetben melyik rack-hez kell odamenni. Szóval megkönnyíti a munkám és kezelhetőbbé teszi a hálózatot...

( ricsip v | 2008. 06. 11., sze – 21:51 )

Csak halványan idekapcsolódó kérdés: van vmi értelme egy közepes 200-300 gépet tartalmazó hálózatban csak a broadcast forgalom csökkentése miatt szeparálni a gépeket? Ennyi gépnél van számottevő lassulás a hálózatban a broadcast miatt? Engem ami miatt zavarni szokott, az max. annyi h. network trace-nél wireshark-ban még be kell rakni plussz 1-2 filtert, meg a sok ARP-ot szűrni.

A broadcast forgalom nagysága sok mindentől függhet. Például gépek ki-be kapcsolásainak gyakoriságától, a használt operációs rendszerek ARP cache timeoutjától, a hálózati protokollok beállításaitól (pl. hálózati hirdetések, NetBIOS node-type, stb.). Az ARP (és általában a broadcast) kéréseket minden eszköznek fel kell dolgoznia, akkor is, ha neki semmi dolga nem lenne vele. Az unicast/broadcast arányt kell megnézni (ez az információ általában kinyerhető a switchportok statisztikáiból), és azután lehet dönteni, de valószínűleg érdemes _lehet_.

( Tincibodal | 2008. 06. 12., cs – 08:47 )

Nem pontosan idevago kerdes, de megtudna valaki mondani nekem, hogy a debian tuzfal "default" beallitasai - melyek rogton bootolas utan alkalmazasba lepnek - melyik fajlban vannak?

Koszi(es bocsi a tul amator kerdesert).