Cisco IOS – Routing

A Cisco IOS alapzozás után folytatódjon Szakály Attila ismertetője. A mostani téma a routingokkal kapcsolatban fog folytatódni.

Routing Protokollok

Többféle routing protokoll létezik némelyik nagyon okos (mint mondjuk az OSPF) némelyik kevésbé mint mondjuk a RIP 1). Ezek a routing protokollok a routereink közötti belső metrika és network topológia feltérképezését végzik automatikusan. A belső szó azért fontos mert az internet végpontra való csatlakozáshoz más routing protokollok kellenek mint mondjuk a BGP! Az automatikusan szó pedig azért mert lehet manuális, „kézi” routokat is beállítani, ha úgy tartja kedvünk. Ha pl van egy irodánk Budapesten egy meg Tatabányán és a 2 irodát bérelt volani WAN kapcsolat köti össze akkor a 2 routeren be lehet állítani egy automatikus routing protokollt mondjuk egy jó kis OSPF et, és úgymond ezzel kötjük össze a 2 irodánk hálózatát, ezzel mondjuk meg mi merre van, ezzel irányítjuk 8irányítja a router automatikusan) melyik forgalom merre menjen.

Nézzük meg az OSPF beállítását egy példán keresztül:

2 iroda, 2 router, 1-1 switch, 1-1 PC, és a routereinket bérelt vonalon kötöttük össze jelen esetben soros kapcsolattal mert a szolgáltató ilyen véget adott…

Az 2 router közötti kapcsolat legyen 192.168.10.0/24
A Budapesti irodában legyen 192.168.1.0/24 es hálózat
A tatabányai irodában pedíg legyen 192.168.2.0/24 es hálózat

Szépen felkonfiguráljuk az interfészeinket értelemszerűen. Miután ez megvan, a PC-inknek is adunk 1-1 IP címet és mivel ezek ugye külön alhálózatba lesznek egyenlőre nem fogják tudni elérni egymást… Viszont tudják a saját alapértelmezett GW-üket ami ugye a Router belső lába. Innen a routernek kellene továbblőni a forgalmat, node merre? Ezt deríti fel a routing protokoll (vagy adott esetben ezt adjuk meg kézi routokkal).

Lássuk akkor az OSPF beállítását:

Az első parancsot (config)# konfig módban kell kiadni „router ospf azonosító”

Itt egyből át is dob minket a protokoll konfigurációs módjába. Az „1”-es szám egy azonosító amivel később ugyanerre a beállított protokollra hivatkozhatunk. Most meg kell adni az összes olyan hálózatot amit a router ismer mert ő ezeket a hálózatokat fogja hirdetni. Mik is ezek a hálózatok? Hát amik direktbe kapcsolódva vannak hozzá. Itt mondjuk van egy alhálózat a router belső lábán és egy alhálózat a serial interfészén. A példába nem sokat számolgattam hova mekkora hálózatot tegyek ezért mindenhová /24 es került. A parancs így néz ki:

(Az 1.0 –ás hálózat a router belső lábán lévő hálózat a 10.0-ás pedig a 2 iroda közötti kapcsolat hálózata) Fontos hogy fordított maszkkal kell az OSPF-nél dolgozni tehát 255.255.255.0 helyett nekünk 0.0.0.255 öt kell írni mert miért ne? Ez a routing protokolloknál változó érdemes megnézni a parancsait a neten mielőtt belefogunk egy ilyenbe. A másik routeren tök ugyanezt kell beállítani csak értelemszerűen az ottani hálózatokkal. A 192.168.10.0 az ugye közös és mondjuk oda meg tegyünk 192.168.2.0 –át a belső lábára.
Ezek után miután mind2 router tudja hogy mely hálózatokat ismer ő és miket kell hirdetnie kifelé, lássuk hogy történt e valami. Kérdezzük le a route táblát a „sh ip route paranccsal”

A felső rész egy jelmagyarázat, az első pedig a routing táblánk. Láthatjuk hogy a Router „C” betűvel jelzi azokat a hálózatokat amik direktbe kapcsolódva vannak hozzá, de mi az a sor az „O” betűvel? Hát az már az OSPF. A mi jó kis OSPF ünk fogta magát és felderítette a másik router által küldött cuccot, így most már ez a router tudja hogy a másik routernek az egyik lábán van egy alhálózat amit 192.168.2.0-ának hívnak… na amit itt most belőttünk kicsiben, az működik nagyban is. Ezzel gyakorlatilag van egy működő hálózatunk.

Statikus (kézi) route-ok

Megnéztük korábban ugye az automatikus routing protokollokat (RIP, EIGRP, OSPF), amik szépen felderítik a hálózatot és teljesen automatikusan routolják a forgalmat a felderített információ alapján, és ha pontosan nem is tudják hova kell küldeni a csomagot, de mindenképp egy jó irányba vagy olyan eszközhöz küldik ami már tudja hogy merre van a cél. Az automatikus routing protokollok mellett használhatunk viszont kézzel beállított statikus routokat is. Ezeket használhatjuk akár együtt is, de kis hálózat esetén akár használhatunk csak statikus routokat is.

Nézzük meg ezt a nagyon egyszerű hálózatot és próbáljuk meg kézzel beállítani azt ami nem megy. Az egyszerűség kedvéért mindenhol /24 es alhálózatok vannak. Nyilván a célunk hogy PC0 és PC1 elérjék egymást (nyilván csak a példában van 2 gép de a cél hogy a 2 hálózat átjárható legyen). Nézzük szét a PC0-ról meddig látunk el? Az alapértelmezett gw-t biztos látjuk hiszen azok egy alhálózaton vannak. Kezdjünk pingelni egy kicsit tovább. Látjuk hogy még a 192.168.5.1 et is elérjük, tehát a router külső lábát (fogalmazzuk így hiszen PC0 szemszögéből nézzük a dolgokat) viszont a 192.168.5.2-t már nem. Miért is van ez így? Hiszen ha már elérjük a routerünk külső lábát, és a routerünk ismeri a 192.168.5.2-t hiszen közvetlen kapcsolatban van vele akkor miért nem érjük el? Hát azért, mert senki nem mondta meg a routernek hogy az abba az irányba menő forgalommal mit csináljon hiszen nincsenek route-ok. Nyilván magából a routerből tudjuk pingelni a következő Routert de a PC-ről nem. Természetesen ennélfogva a PC0-ról nem fogjuk elérni a PC1-et. Próbáljuk meg korrigálni a dolgot.

A parancs struktúrája nagyon egyszerű, egyszerűen azt mondjuk neki hogy az „Ebbe” az irányba menő forgalmat küld el „erre”. A parancs az „ip route”.

Router(config)#ip route 192.168.2.0 255.255.255.0 192.168.5.2

Vagy

Router(config)#ip route 192.168.2.0 255.255.255.0 f0/0

A kettő teljesen ugyan az, az elsőnél a másik router lábát adtuk meg neki (annak a routernek a lábát amerre szeretnénk hogy menjen a forgalom) a másodiknál pedig a router saját interfészét (azt az interfészt amelyiken szeretnénk hogy azon menjen ki a forgalom). Hogy melyiket jobb használni, erre nincs konkrét válaszom, attól függ hogy a jövőben az IP-ket vagy az interfészeinket szeretnénk lecserélni. Lássuk most működik e a dolog és látja e egymást a 2 PC. Sajnos nem. De miért nem? Hát most már route is van elrontottunk valamit? Nem, de ha belegondolunk megírtuk az útvonalat az egyik irányba, de a csomagunknak vissza is kell találnia! A problémát mind2 oldalról kezelni kell, menjünk be a másik routerbe is, vagyis a Router1 be és írjuk meg az útvonalat visszafele is:

Router(config)#ip route 192.168.1.0 255.255.255.0 192.168.5.1

Mit is csináltunk most? Hát megmondtuk a Router1-nek, hogy ha valaki csomagot küld rajtam keresztül a 192.168.1.0/24-es alhálózatba akkor azt el kell irányítanom a 192.168.5.1 felé vagyis a másik router irányába. Aztán hogy onnan hova megy az már nekem nem számít, a lényeg hogy én odaküldök mindent ami arra akar menni.

Tekintsünk vissza egy pillanatra a hálózati topológiánkra és képzeljük el hogy a Router1 nek van egy Internet végpontja is, amit bizony a felhasználóink előszeretettel használni szeretnének. Hogy mondjuk meg a routerünknek hogy mit küldjön erre és mit küldjön arra és hogy egyáltalán mi felé küldje azt amit küld? Vagy gondoljunk egy olyan szituációra hogy Router1 nek van 8 lába és mindegyiken más alhálózat van. Miért ne lehetne? Ezek szerint Router0-ban mindegy egyes alhálózatra külön route-ot kellene írjunk? Szerencsére nem, hiszen olyat is tudunk mondani a routerünknek, hasonlóképpen mint egy PC-nek, hogy azt amit nem tudsz merre menjen azt küld el „erre” vagyis egy bizonyos irányba. Ezzel gyakorlatilag meg is oldottuk a problémát! Vannak konkrét hálózataink, ezekhez konkrétan megírt routok, ha erre akarsz menni akkor ezen az interfészen menj ki, ha arra akkor meg azon, Viszont ha nem tudod merre menj, akkor tessék itt egy úgymond default route ami megmondja hogy merre küld azt amiről fogalmad sincs merre küld.

Router1(config)#ip route 0.0.0.0 0.0.0.0 „és ide a router saját interfészét adjuk meg pl f1/0”

Ezzel közöltük mondjuk a Router1 el hogy ha a konkrétan definiált route-ok megnézése után sem tudod merre irányítsd a forgalmat akkor küld ki a fasthethernet1/0-ás interfészeden. Statikus routoknál jól meg kell gondolni a mit és hová kell tegyünk, itt mondanék is egy példát, jelen esetben a PC1 gépről boldogan internetezhetünk, viszont a PC0-ról nem igazán, hiszen a Router0-ának csak azt mondtuk meg hol a 192.168.2.0 –ás hálózat, ha PC0-ról az internet felé kéne csomagot küldeni a dolog már a Router0-nál elbukna. Természetesen oda is beállíthatjuk hogy menjen minden forgalom a Router1 felé és a problémát át is hidaltuk, de ez egy szemléletes példa a statikus route-ok használatára.

Még két dolgot szeretnék ide leírni, az egyik hogy akár 1 konkrét host felé is megadhatunk route-ot, ez esetben használjunk 255.255.255.255–ös maszkot

Router0(config)#ip route 192.168.2.100 255.255.255.255 192.168.5.2

Illetve a másik dolog, a meglévő route-jaink lekérdezése a „sh ip route” paranccsal. A statikus route-jainkat „S” betűvel fogja jelezni a router.

Ahol nem adtunk meg úgynevezett default route-ot ott azt fogja írni hogy gateway of last resort is not set, de természetesen ez nem hiba és nem kötelező megadni.

ACL ek (Access Listák)

Képzeljük el hogy van egy már beállított hálózati topológiánk, ahogy minden működik és minden elérhető mindenhonnan. Az ACL ek gyakorlatilag szabályok amik megmondják hogy a már beállított hálózaton (lépjünk túl egy kicsit a routokon és téletezzük vel, hogy itt most valóban minden elérhető mindenhonnan) mi az a forgalom ami engedélyezett és mi az ami nem! Függetlenül attól hogy ismerem az utat, átengedhetem e vagy sem! Gondoljunk bele abba hogy ha mindenki elér mindent ez bizonyos szempontból jó, már már álomszerű lenne ha ezt meg is tehetnénk, viszont a gyakorlatban mi legalább annyit tiltogatunk mint engedélyezünk. Nem feltétlenül jó dolog az ha mindenki elér mindent. Na pontosan erre használhatók ezek a szabályok. Csináljunk pl. egy belső webszervert a Budapesti irodánknak ahova a budapestiek a szupertitkos adataikat publikálják. Mivel ez tényleg csak a Budapesti irodára vonatkozik, hát szeretnénk mi hogy Tatabányáról vagy bárhonnan máshonnan ezek az adatok elérhetők legyenek? Kit érdekel – mondhatnánk mi – természetesen a Budapestieket hiszen ők féltik az adataikat. Mit tehetünk? Fogjuk magunkat és létrehozunk egy olyan szabályt a routeren (hogy melyiken az mindíg attól függ hol a praktikusabb) amivel megtiltjuk hogy a webszerver bárhonnan kívülről elérhető legyen. Egyszerűen nem engedjük át a forgalmat a routeren, kész passz. Még azt is eldönthetjük hogy csak a http forgalmat tiltjuk le vagy teljesen minden IP apaló forgalmat afelé a szerver felé. De nézzük ennek az ellenkezőjét. Mert akár azt is megtehetjük hogy sehová semmilyen forgalmat nem engedünk ki, kivéve afelé az egy webszerver felé a http forgalmat. A lehetőségeink korlátlanok a tekintetben hogy mit engedünk és mit tiltunk meg.

Nem akarok most már túl sokat írni erről, lényeg hogy mielőtt ACL-eket konfigurálnánk gondosan tervezzük meg az egészet! Mindenképpen!!! Ha csak úgy ukk mukk fukk nekiállunk na az biztos nem fog működni. A tervezés azért is fontos, mert ACL-eket utólag módosítani külön tortúra. Ennyi magyarázat épp elég most már nézzük meg inkább egy példán keresztül.

Hogy maradjunk a webes példánál, alul 1-1 külön alhálózatba bepakoltunk 1-1 webszervert és majd a 2 fölső gépről próbáljuk meg engedélyezni illetve tiltani a 2 szerver webes elérését. Természetesen a webes példa alapján elkészíthetitek a saját ACL jeiteket is az igényeknek megfelelően, én most azért maradok ennél a példánál mert ezt nagyon jól lehet Packet Tracerbe szimulálni (a kliensen böngészőt lehet nyitni, a szerveren meg van HTML weboldal)

Feladat 1; próbáljuk meg a 192.168.3.2 es gépről letiltani azt hogy mind2 webszerveren lévő weboldalakat meg tudjuk nézni mert az a felhasználó aki azon a gépen van egy hülye és ki szeretnénk tolni vele. Ha ez megvan próbáljunk meg még jobban kitolni vele és mondjuk arról a gépről mindenféle forgalmat letiltani a 2 webszerver irányába (de mind2 esetben csak és kizárólag a 2 webszerver irányába).
Első lépés a tervezés! Mint Mindig. Próbáljunk logikusan gondolkodni, első kérdés fel is tehetjük hová érdemes tennünk a szabályunkat? Az aranyszabály az, hogy próbáljuk megfogni a forgalmat amilyen hamar csak lehet, hiszen minek kóboroljanak a bitek ha úgyis letiltjuk őket… Ráadásul mivel a 2 webszerver külön alhálózaton van ezért a Debr1 és a Debr2 routeren is létre kéne hozni 1-1 ACL-t a siker érdekében de ha belegondolunk miért ne csinálhatnánk ezt meg a Debr3 nevű routeren? Ott kapásból megfogjuk a forgalmat ráadásul 1 helyre tudjuk tenni az összes ACL-t. Szuper, megvan a hely akkor essünk neki. Lássuk először a parancsot, és utána következik egy kis magyarázat:

Debr3(config)#access-list 105 deny tcp host 192.168.3.2 host 192.168.1.200 eq www
Debr3(config)#access-list 105 deny tcp host 192.168.3.2 host 192.168.2.200 eq www
Debr3(config)#access-list 105 permit ip any any

Majd pedíg:

Debr3(config)#interface fastEthernet 0/0
Debr3(config-if)#ip access-group 105 in

És ezzel meg is volnánk. Láthatjuk pingelni tudjuk a webszervereket, ám a weboldalak már nem fognak bejönni. Lássuk mit is csináltunk. Maga a parancs az „access-list”. A „105”-ös szám egy csoport azonosító mellyel hivatkozni tudunk majd erre az Access lista groupra. Értelemszerűen sok szabályt létre lehet itt hozni, és csoportosítani lehet őket, itt jön képbe ez az azonosító szám. Jó tudni hogy 1 től 99 ig számozzuk az úgynevezett standard ACL-eket és 100-tól 199-ig az úgynevezett Extended ACLeket. Hát a miénk most egy extended ACL lett és végig a 105ös számmal fogunk rá hivatkozni. A következő a deny/permit. Tiltjuk vagy engedélyezzük… a következő a „tcp” Itt leggyakrabban vagy a „tcp” vagy az „ip” szerepel, amikor „ip”-t írunk akkor az minden IP-s forgalomra vonatkozik majd amikor „tcp”-t írunk akkor itt később lehet majd definiálni részletesebben, hogy pontosan mit is akarunk letiltani (mondjuk 1 konkrét portot). A következő 2 rész az ,hogy HONNAN induló és HOVÁ menő forgalomra vonatkozzon ez a szabály. Jelen esetben nem alhálózat szinten (olyan példát is csinálunk majd) hanem gépenként tehát host szinten korlátozunk tehát a 192.168.3.2-es hosttól a 192.168.1.200as host felé. Mivel nem mindent szeretnénk letiltani csak a webes elérést (éppen ezért „tcp”-t választottunk) itt kell megmondani hogy mit is tiltunk le „eq www” minden „www”-vel egyenlő (eq) forgalmat ha szó szerint akarom írni, tehát gyakorlatilag a webes elérést. (ezt a www álca ez itt most csak a 80 as port lesz de később csinálunk port szerinti tiltást is) A második sor ugyanez csak az a másik webszerverre vonatkozik.

De mi is az a 3. sor (access-list 105 permit ip any any)??? Miért van az ott? Mi lehet az? Itt szeretnék elmondani néhány alapvető dolgot az ACL-ekről: Az ACL-eket sorokban képzeljük el. A szabályok föntről lefelé kerülnek vizsgálatra. Ha egy szabály érvényesül akkor a többi szabály már nem lesz figyelembe véve. Értsük ezalatt azt, hogy ha egyszer valamit letiltottunk vagy átengedtünk akkor az le van tiltva vagy át van engedve Függetlenül a lentebb található szabályoktól. Tehát olyan nincs hogy az első sorban valamit átengedünk, majd később letiltjuk! Akkor az már átment. Itt jön szóba a tervezés mivel új ACL sort mindig csak a lista végéhez tudunk hozzáadni!!!!!!! Tehát ha valamit átengedtünk és utólag jut eszünkbe hogy jajj azt mégis le akarjuk tiltani, akkor az a hajó már elment… És a legfontosabb dolog hogy az ACL lista végén mindig van egy képzeletbeli MINDENT letiltok MINDENFELÉ ACL szabály ha odatesszük ha nem. Ez úgy nézne ki leírva hogy „deny ip any any” vagyis –tiltani – minden IP forgalmat – bárhonnan jön-bárhová megy. Ennek értelmében próbáljuk értelmezni a 3adik sorunkat (access-list 105 permit ip any any). Mit szeretnénk elérni? Tiltsuk le egy hostról a 2 webszerver irányába a webes elérést de minden más menjen! Na, most ha a mi listánk végére a routerünk odateszi ezt a mindent tiltok mindenhová akkor nekem jól semmi nem fog menni, hiszen először letiltjuk a webes elérést a 2 szerver irányába, majd a router letilt minden minden irányba. Hát éppen ezért kell a 3adik sor a lista végére, „permit” – engedélyezz „ ip” – minden ip forgalmat „any” – bárhonnan jön „any” – bárhová megy. Ami a legérdekesebb hogy ettől nem tűnik el a „deny ip any any” sor az ACL végéről az mindig ott van, viszont mivel azt mondjuk hogy a szabályok felülről lefelé kerülnek vizsgálatra, és ha az egyik érvényre jut a többit már nem veszi figyelembe, akkor ezzel az engedélyező szabállyal gyakorlatilag kiütöttük a tiltást.

A legutolsó lépésként a szabályt hozzá kell rendeljük egy interfészhez, jelen esetben a fasthethernet 0/0 a fönti gépek alapértelmezett átjárója, tehát tegyük ide. Lépjünk be interfész konfig módba és a parancs mint fent láthatjuk „ip access-group” azonosító és „in” vagy „out”. Mivel itt a forgalom befelé jön vagy jönne ezért „in”. Ezzel az első példát ki is végeztük. Még egy nagyon fontos információ, ha mégis elrontanánk az ACL-jeinket, mondjuk a sorrendet, a legjobb ha megírjuk a helyes sorrendet egy notepadba, a meglévő ACL jeinket kitöröljük „no”-val és megcsináljuk előről az egészet (notepadból copy paste, csak pillanatok műve), de legyünk tisztába vele hogy meglévő listához új ACL szabályt mindig csak a lista legvégére tudunk hozzáadni!!!!!

Jöjjön a feladat „b” része amikor még jobban kitolunk a csákóvámmal és mindenféle forgalmat letiltunk afelé a 2 szerver felé, mert mondjuk ott egy ftp szerver is üzemel és mi jól letiltjuk neki azt is:

Debr3(config)#access-list 105 deny ip host 192.168.3.2 host 192.168.1.200
Debr3(config)#access-list 105 deny ip host 192.168.3.2 host 192.168.2.200
Debr3(config)#access-list 105 permit ip any any

Mivel itt gyakorlatilag minden ip-s forgaltmat tiltunk a listánk egy picit egyszerűbbnek néz ki, próbáljuk is ki hogy a 2 webszerver nem pingik, viszont mondjuk a PC0 az igen. Természetesen az interfészhez való hozzárendelést itt sem szabad elfelejteni.

Feladat 2; próbáljuk meg most letiltani az összes 192.168.3.0/24 es alhálózatban található gépről minden kimenő webes forgalmat. Ugye ez hasonló az előzőhöz, hova is lenne a legjobb lepakolni az ACL jeinket? Hát ismét csak a Debr3-ra.

Debr3(config)#access-list 105 deny tcp 192.168.3.0 0.0.0.255 any range 80 80
Debr3(config)#access-list 105 deny tcp 192.168.3.0 0.0.0.255 any range 443 443
Debr3(config)#access-list 105 permit ip any any
Debr3(config)#interface fastethernet 0/0
Debr3(config-if)#ip access-group 105 in

Használjuk ismét a 105 ös számot jó lesz az nekünk (mondanom sem kell ez pucér routerről indul tehát az előző feladatban lévő ACL eknek semmi köze ezekhez). Tiltsuk meg a „deny”- al ismét válasszuk a „tcp”-t a 192.168.3.0 ás alhálózatból fordított maszkal(!!) „any” tehát bármerre menő forgalmat ami a 80 as és a 443 as porton szeretne kimenni. Mivel minden másnak mennie kell ne felejtsük ez a lista végéről az engedélyező ACL ünket valamint az interfészhez való hozzárendelést.

Feladat 3; Hogy jobban megértsük a lista végén láthatatlanul szellemként kísértő automatikusan letiltok mindent szabályt nézzünk meg egy olyan példát hogy a „Debr3” routeren tiltsunk le minden kimenő forgalmat a 192.168.3.0/24 es alhálózatban lévő gépek szemszövégől nézve, egyetlen kivétellel mondjuk a 192.168.1.200 as szerveren lévő weboldalakat meg tudják nézni. Ez pl teljesen életszerű példa, úgy gondoljuk hogy az ott dolgozó embereknek nem szabad kijutni az ő kis hálózatukból nehogy túl sokat tudjanak, ámde mégis van egy webszerver amit el kellene érniük.

Debr3(config)#access-list 105 permit tcp any host 192.168.1.200 range 80 80
Debr3(config)#access-list 105 permit tcp any host 192.168.1.200 range 443 443

És ennyi. A történet megfordult, itt most tiltás helyett csináltunk 2 engedélyezést a 80 as és a 443 as porton minden mást pedig a router szépen letilt by default. Próbáljuk ki még csak pingelni sem tudunk sehová, a webszervert sem, viszont a rajta lévő weboldalt mégis elérjük.

Feladat 4; Próbáljuk meg most a 192.168.1.0/24 es alhálózatot (bal alul) teljesen eltüntetni a külvilág elől, tehát tiltsunk le mindent ami efelé az alhálózat felé jönne, egyetlen dolgot engedjünk meg hogy a 192.168.1.200 as webszerveren lévő oldalakat kívülről is elérjék. Hát úgy néz ki a leghamarabbi hely ahol el tudunk csípni minden forgalmat egy helyen az a Debr1 router belső lába (ez a f0/0ás interfész) hiszen ez az a láb amihez ha majd hozzárendeljük az ACL szabályainkat akkor bármilyen kívülről jövő forgalomra érvényesülni tud.

Debr1(config)#access-list 105 permit tcp any host 192.168.1.200 range 80 80
Debr1(config)#access-list 105 permit tcp any host 192.168.1.200 range 443 443
Debr1(config)#interface fastEthernet 0/0
Debr1(config-if)#ip access-group 105 out

Ugye itt most megengedjük, hogy a bárhonnan jövő forgalom a 192.168.1.200 as host irányába a 80 as és a 443 as porton bejöjjön egyébként meg hagyjuk hogy a router minden mást letiltson, és az acces listánkat hozzá pakoljuk a fastethernet 0/0-ához az irány pedig ebben az esetben kifelé mutat tehát „out”.

All in all egy komoly cégnél a 100 soros ACL lista szabályokat mindennaposnak vehetjük, ezért mindenképp tervezzük meg mielőtt belevágunk, fontoljuk meg mit hová tegyünk, és még egyszer kiemelve a szabályoknál a sorrend nagyon fontos. Elég felületesen érintettük csak az ACL-eket mert erről egy egész könyv is kevés annyit lehetne írni, ha valaki komolyan bele akar menni, rengeteg példa van a neten, utána lehet járni a lehetőségek tényleg korlátlanok.

DHCP

Természetesen ezeket a típusú routereket is rá lehet venni automatikus címkiosztásra. Persze ahol rettenetes nagy a security mondjuk egy nagyvállalati környezetben ott valószínűleg úgyis valami AD által ismert és hitelesített windowsos DHCP szerver fogja a címeket osztogatni. De ahol nincs ilyen követelmény ott ezek a routerek tökéletesek annál is inkább mivel egy ilyen routert bekapcsolsz beállítasz és gyakorlatilag 15 évig nincs vele baj még újraindítani sem kell.

Ennélfogva mivel az hogy egy kliens IP címet kapjon elég fontos és alapvető dolog ezért ezek az eszközök tökéletesek erre a feladatra. A DHCP beállítást a (config)# módban kell megkezdenünk és a parancs a következőképpen néz ki:

Router(config)#ip dhcp pool „és egy név”

Ezután egyből átkerülünk a DHCP konfigurációs módba.

A név azért fontos mert később a név alapján hivatkozhatunk majd egy adott DHCP pool-ra. Egy valódi routeren szinte minden DHCP-re vonatkozó tulajdonságot be tudunk állítani itt a Packet Tracer egy kicsit hiányos (pl nem tudunk címfoglalást vagy lease time-ot állÍtani benne, természetesen ezt egy normál routeren megtehetjük).

Adjuk meg most azt a hálózatot amiből a routerünk a címeket fogja osztogatni, emellett beállíthatjuk még a DNS szervereket valamint az alapértelmezett átjárót.

Ha azt szeretnénk hogy bizonyos címeket ne osszon ki a routerünk ebből az alhálózatból, mert mondjuk azt már odaadtuk statikusan egy szervernek, ezt is megtehetjük. Kintebb kell lépjünk a DHCP konfig módból és itt kiadni az „IP DHCP excluded-address” parancsot. Megadhatunk neki 1-1 IP címet is, de akár egy tartományt is. Ilyenkor a 2 címet és a 2 cím közötti IP-k közül semelyiket nem osztja ki.

Csinálhatunk címfoglalást is, bár ezt egy kicsit nehezebb megszülni, a packet tracer sajnos nem is tudja. Az elmélete az hogy egy új DHCP pool-t kell csinálni és nem a „network” paranccsal adunk meg egy alhálózatot hogy abból osztunk ki egy címet hanem a „host” paranccsal adunk meg egyetlen címet. Tudunk adni a kliensünknek egy nevet is, illetve megadni vagy a Hardware address-t (ez a MAC cím) vagy a client identifiert ami szintén a MAC cím csak máshogy kell elválasztani meg „01” el kezdődik de ha már ott tartunk a router ad segítséget a formátumhoz.