A legtöbb helyi hálózat egyetlen címtartománnyal indul: a router gyári beállítása kiosztja a 192.168.1.0/24 címeit, és minden eszköz ebből kap címet. Amíg egy irodában húsz számítógép és két nyomtató van, ez működik. Amikor megjelenik a második telephely, a vendég-Wi-Fi, a kamerarendszer vagy egy VPN, a véletlenszerűen kiosztott címek sok fölösleges munkát okoznak.
A címterv azt rögzíti, melyik címtartomány mire való, a VLAN-struktúra pedig azt, hogyan válik szét a hálózat logikai részekre a kapcsolókon. A kettőt érdemes együtt megtervezni, hogy a hálózat évek múlva is átlátható maradjon.
Miért kell címterv egy kisebb hálózatnak is
Egy kis hálózatban a címek összevisszasága eleinte nem fáj, a gondok később, egy-egy változásnál jönnek elő:
- Szegmentálásnál. Ha a nyomtatók, a kamerák és a munkaállomások ugyanabban a tartományban, egymás mellett kapnak címet, a tűzfalszabályok csak egyedi címekre írhatók. Minden új eszköz új szabályt kér, és a szabálykészlet gyorsan átláthatatlanná válik.
- VPN-nél. Az otthoni routerek nagy része gyárilag a 192.168.0.0/24 vagy a 192.168.1.0/24 tartományt használja. Ha a cég belső hálózata is ilyen, egy otthonról kapcsolódó munkatárs gépe az ebbe a tartományba eső címekre a helyi hálózat felé küldi a csomagot, így ezek a céges címek a VPN-en át nem érhetők el. Ha a VPN minden forgalmat a cég felé terel, fordítva történik: az otthoni hálózat eszközei válnak elérhetetlenné.
- Új telephelynél vagy összekötésnél. Két iroda, amely külön-külön ugyanazt a tartományt kapta, csak címfordítással vagy újraszámozással köthető össze. Ugyanez a helyzet egy felhős hálózat bekötésekor, ha annak címtartományát senki nem egyeztette a helyiekkel.
- Hibakeresésnél. Ha egy címből nem derül ki, hol és milyen eszközről van szó, minden riasztásnál és naplóbejegyzésnél utána kell járni.
A címterv ezeket előre eldönti. Egy egyszerű, logikus séma egy kis irodában gyorsan elkészül, egy működő hálózat utólagos újraszámozása viszont minden fix címet, tűzfalszabályt és nyomtatóbeállítást érint.
Privát címtartományok és felosztásuk
A belső hálózatokra az IETF RFC 1918 (1996) három IPv4-tartományt jelöl ki, amelyek az interneten nem irányíthatók, így bármely szervezet szabadon használhatja őket:
| Tartomány | Előtag | Címek száma | Jellemző használat |
|---|---|---|---|
| 10.0.0.0–10.255.255.255 | 10.0.0.0/8 | 16 777 216 | Több telephely, nagyobb hálózat, hierarchikus felosztás |
| 172.16.0.0–172.31.255.255 | 172.16.0.0/12 | 1 048 576 | Közepes hálózat, külön blokk felhőnek vagy laborhálózatnak |
| 192.168.0.0–192.168.255.255 | 192.168.0.0/16 | 65 536 | Kis iroda, otthoni hálózatok gyári beállítása |
A tartományokat CIDR-jelöléssel (IETF RFC 4632) adjuk meg: a perjel utáni szám azt mutatja, hány bit azonosítja a hálózatot. Egy /24 alhálózatban 256 cím van, ebből 254 osztható ki eszközöknek, mert az első a hálózat címe, az utolsó a szórási cím. Egy /23 kétszer ennyit, egy /25 feleennyit ad. A pont-pont kapcsolatokon, például két router között, elég egy /31, amelyben az IETF RFC 3021 (2000) szerint mindkét cím kiosztható.
Hogyan érdemes választani
Telephelyekkel és VPN-nel számoló hálózatnál a 10.0.0.0/8 a legkényelmesebb, mert bőven van benne hely a hierarchiára. Érdemes elkerülni a tartományok leggyakrabban használt elejét: a 10.0.0.0/24, a 10.0.1.0/24, a 192.168.0.0/24 és a 192.168.1.0/24 sok otthoni routeren, szolgáltatói eszközön és szoftver gyári beállításaként előfordul, ezért VPN-en át könnyen ütközik. A 100.64.0.0/10 tartomány nem privát: az IETF RFC 6598 (2012) az internetszolgáltatók címfordítására tartja fenn, belső hálózatra nem célszerű használni.
A tervbe a felhőt is bele kell számolni. A felhős virtuális hálózatoknak is privát címtartomány kell, és ha ezek a helyi hálózattal VPN-en vagy közvetlen kapcsolaton érintkeznek, nem fedhetik egymást. Ugyanez igaz a vendéghálózatra és egy esetleges laborhálózatra is: ha a címtervben előre kapnak egy-egy blokkot, később nem kell átszámozni őket.
IPv6
Ahol IPv6 is fut, ott a felosztás logikája hasonló, csak a méretek mások: egy /48-as előtag és a szokásos /64-es szegmensek között 16 bit, vagyis négy hexadecimális számjegy marad, amelyekbe a telephely és a funkció kódolható, például az első kettő a telephely, az utolsó kettő a funkció. Az IPv6-címek felépítéséről és a /64-es szegmensméret okáról az IPv6-alapokról szóló cikk ír.
Telephely, épület, funkció: a címek logikája
Egy jó címterv hierarchikus. Minden telephely egy saját, összefüggő blokkot kap, azon belül az épületek vagy emeletek, legbelül a funkciók osztoznak a címeken. Így a címből ránézésre kiderül, hol és mire használt eszközről van szó, és egy telephely minden alhálózata egyetlen előtaggal leírható, ezért a telephelyek közötti útválasztásban és a tűzfalszabályokban egy-egy sor elég telephelyenként.
Egy lehetséges séma
Szemléltetésként egy egyszerű séma a 10.0.0.0/8 tartományban, ahol a második oktett a telephely, a harmadik a funkció:
| Rész | Jelentés | Példa |
|---|---|---|
| 10.X.0.0/16 | Telephely (X = 1 a központ, 2, 3… a további helyszínek) | 10.2.0.0/16: második telephely |
| 10.X.10.0/24 | Munkaállomások | 10.2.10.0/24 |
| 10.X.20.0/24 | IP-telefonok | 10.2.20.0/24 |
| 10.X.30.0/24 | Nyomtatók és multifunkciós eszközök | 10.2.30.0/24 |
| 10.X.40.0/24 | Kamerák, beléptetés, épületfelügyelet | 10.2.40.0/24 |
| 10.X.50.0/24 | Szerverek | 10.2.50.0/24 |
| 10.X.90.0/24 | Vendéghálózat | 10.2.90.0/24 |
| 10.X.99.0/24 | Hálózati eszközök menedzsmentje | 10.2.99.0/24 |
| 10.250.0.0/16 | Telephelyek közötti kapcsolatok, loopback címek | 10.250.0.0/31 |
Ha egy telephelyen több épület vagy emelet van, a harmadik oktett két részre osztható: például a 10.1.110.0/24 az első épület munkaállomásai, a 10.1.210.0/24 a második épületé, a funkciót pedig a harmadik oktett utolsó két számjegye adja. Mivel egy oktett értéke legfeljebb 255 lehet, ez a változat legfeljebb két épületig működik, és a második épületben csak az 55-ig terjedő funkciókódok férnek el: a 90-es vendég- és a 99-es menedzsmenthálózat ott már nem. Ahol több épület van, vagy minden funkciónak minden épületben helyet kell hagyni, ott más kódolás kell, például épületenként külön /16-os blokk.
Méretezés és tartalék
A /24 sok funkcióra kényelmes méret, de nem mindenhova jó. Érdemes a mai igényt nagyjából megduplázva méretezni: egy 400 munkaállomásos épületnek így egy /22 (1022 kiosztható cím) kell, a menedzsmenthálózatnak viszont egy /26 (62 cím) is elég. A blokkok között érdemes szabad helyet hagyni, hogy egy alhálózat később a szomszédos tartománnyal bővíthető legyen. A telephelyi blokkoknál ugyanez a helyzet: ha a tervben a 2-es telephely után azonnal a 3-as jön, a 2-es nem tud egy második /16-tal bővülni anélkül, hogy a hierarchia megtörne.
Az OT-környezet hálózatai külön blokkot érdemelnek, mert ott a címek évekig, sokszor évtizedekig nem változnak, és a vezérlők konfigurációjába vannak beírva. Ezeket a tervben az irodai részektől jól elválasztva, saját blokkban célszerű elhelyezni.
VLAN-azonosítók és nevek
A VLAN (virtual LAN) egy fizikai kapcsolóhálózatot oszt több logikai hálózatra. Az IEEE 802.1Q szabvány a kapcsolók között továbbított keretbe egy címkét illeszt, amelynek 12 bites mezője a VLAN-azonosító. A 0 és a 4095 fenntartott érték, így 1 és 4094 közötti azonosítók használhatók. Egyes kapcsolók ennél kevesebb VLAN-t kezelnek, és egyes gyártók bizonyos tartományokat belső célra fenntartanak, ezért a tervezés előtt érdemes megnézni a használt eszközök korlátait.
A gyakorlatban egy VLAN egy IP-alhálózatnak felel meg: a VLAN-on belüli eszközök közvetlenül, második rétegben beszélnek egymással, a VLAN-ok közötti forgalom pedig egy útválasztón vagy tűzfalon megy át. A VLAN-ok közötti forgalmon érvényesíthetők a szegmentációs szabályok. A zónák közötti engedélyek megtervezéséről a forgalmi mátrixról szóló cikk ír részletesen.
A számozás logikája
A legkönnyebben kezelhető, ha a VLAN-azonosító és a címterv egymásra utal. A fenti sémában a munkaállomások VLAN-ja a 10-es, a hozzá tartozó alhálózat harmadik oktettje is 10, a telefonoké 20 és 20, és így tovább. Aki a kapcsolón a 30-as VLAN-t látja, tudja, hogy nyomtatókról és a 10.X.30.0/24 tartományról van szó.
A VLAN-azonosító egy kapcsolási tartományon belül érvényes. Ha a telephelyeket útválasztott kapcsolat köti össze, és a második réteg nem nyúlik át egyik helyszínről a másikra, minden telephely ugyanazokat az azonosítókat használhatja ugyanarra a funkcióra. Ez a dokumentációt és a sablonokat is egyszerűbbé teszi: a 20-as VLAN mindenhol a telefonoké, csak az IP-tartomány második oktettje tér el.
Natív VLAN és VLAN 1
A legtöbb kapcsolón minden port gyárilag az 1-es VLAN-ban van, és a trönkportokon a címkézetlen forgalom is ide kerül (natív VLAN). Érdemes az 1-es VLAN-t semmilyen felhasználói vagy menedzsmentforgalomra nem használni, és a számozás tervezésekor a natív VLAN-nak is egy külön, máshol nem használt azonosítót fenntartani. Így egy rosszul bekötött vagy gyári állapotú eszköz nem kerül automatikusan egy élő hálózatba. A trönkök beállításáról és a kapcsolók további második rétegbeli védelmeiről a kapcsolók biztonsági funkcióiról szóló cikk szól.
Nevek
A VLAN-név a kapcsoló konfigurációjában és a felügyeleti felületeken jelenik meg, ezért legyen rövid, egységes és ékezet nélküli, például BP-KOZPONT-NYOMTATO vagy egyszerűen NYOMTATO, ha a telephely a kapcsoló nevéből amúgy is kiderül. A név a funkciót írja le, ne egy személyt vagy egy osztály ideiglenes nevét, mert azok gyorsabban változnak, mint a hálózat.
DHCP-tartományok, fix címek és foglalások
Egy alhálózaton belül is érdemes rendet tartani: melyik cím az átjáróé, melyiket osztja ki a DHCP, és melyeket kapnak a fix címes eszközök.
Belső felosztás
Egy szokásos konvenció egy /24-es alhálózatra:
- .1: az alapértelmezett átjáró (vagy .254, ha a hálózatban ez a szokás; a lényeg, hogy mindenhol ugyanaz legyen);
- .2–.9: csak a redundáns átjárók saját címei (a hálózati eszközök menedzsmentcíme a 99-es alhálózatba kerül);
- .10–.49: fix címes eszközök, például szerverek, nyomtatók, vezérlők;
- .50–.250: a DHCP által kiosztott tartomány.
A fix címek és a DHCP-tartomány ne fedjék egymást. Ha egy kézzel beállított cím a DHCP-tartományba esik, a DHCP-szerver könnyen kiadhatja egy másik eszköznek is, és címütközés lép fel. Sok DHCP-szerver és kliens kiosztás előtt ellenőrzi, foglalt-e a cím, de erre nem érdemes építeni.
Fix cím vagy foglalás
Két módon kaphat egy eszköz állandó címet. A fix címet az eszközön magán állítják be, ez a helyes választás a hálózati eszközöknél, az átjáróknál és mindennél, aminek akkor is működnie kell, ha a DHCP-szerver nem érhető el. A foglalásnál a DHCP-szerver a MAC-cím alapján mindig ugyanazt a címet adja ugyanannak az eszköznek. Ez nyomtatóknál és sok irodai eszköznél kényelmesebb, mert a cím, az átjáró és a DNS-beállítás egy helyen, a szerveren módosítható. Ha egy foglalt eszköz hálózati kártyáját cserélik, a foglalást is át kell írni.
Bérleti idő és relay
A DHCP (IETF RFC 2131) bérletre adja a címet. Munkaállomásoknál néhány napos, vendéghálózatnál, ahol sok eszköz rövid ideig van jelen, néhány órás bérleti idő a szokásos, különben a tartomány a régóta távozott eszközök bérleteivel telik meg. Ha a DHCP-szerver egy központi helyen fut, a VLAN-ok átjárói relay agentként továbbítják hozzá a kéréseket, és a szerver a relay által a kérésbe írt átjárócím (giaddr) alapján választja ki a megfelelő tartományt. Ez is a címterven múlik: a szerveren minden alhálózathoz külön tartomány kell, pontosan a terv szerinti határokkal.
A terv dokumentálása és karbantartása
A címterv akkor ér valamit, ha le van írva, és a leírás megegyezik azzal, ami a kapcsolókon fut. Egy táblázat vagy egy erre szolgáló IP-címkezelő (IPAM) eszköz is megfelel, ha mindenki ugyanazt használja, és csak egy példány létezik belőle.
Mit tartalmazzon
Alhálózatonként legalább a következőket:
- telephely és épület, a VLAN-azonosító és a VLAN neve;
- az alhálózat előtaggal, az átjáró címe;
- a DHCP-tartomány határai és a fix címes tartomány;
- a funkció és a tűzfalzóna, amelybe az alhálózat tartozik;
- ki felel érte, és mikor módosult utoljára.
A fix címeket és a foglalásokat eszközönként is érdemes vezetni: cím, eszköznév, típus, hely, MAC-cím. Ha a belső DNS-ben a fordított feloldáshoz szükséges bejegyzések is megvannak, a naplóelemző eszközök a címek mellé nevet is meg tudnak jeleníteni.
Változáskezelés
Új VLAN vagy alhálózat előbb a tervbe kerül, csak utána a kapcsolókra és a DHCP-szerverre. Egy megszűnt funkció azonosítóját és tartományát nem érdemes azonnal más célra kiosztani, mert régi tűzfalszabályok, nyomtatóbeállítások vagy dokumentumok még hivatkozhatnak rá.
Időnként a tervet egyeztetni kell a valósággal: a kapcsolók VLAN-listáját, a DHCP-szerver bérleteit és foglalásait, valamint az útválasztó alhálózatait. Az eltérések, például egy tervben nem szereplő VLAN vagy egy fix címes tartományban megjelenő ismeretlen eszköz, gyakran olyan változásra utalnak, amely a terven kívül történt. A hálózati eszközök rendszeres karbantartásáról a karbantartásról szóló cikk ír.
Kapcsolódó szolgáltatás: Switching és routing →
