Hello!
Deoarece in luna februarie urmeaza sa sustin examenele practice de la finalul modulului CCNA3 (Scaling Networks), care urmeaza sa evalueze nu numai in ce masura am asimilat notiuni prezentate in acest modul dar si elemente din CCNA2 (Routing and Switching Essentials), in laboratorul de azi imi propun recapitularea notiunii de Access Control Lists (ACL), prezentata in capitolul 9 din CCNA2.
Pe scurt, un ACL reprezinta un mecanism prin care un router ia decizia de a trimite mai departe sau de a arunca pachete, pe baza informatiei care se regaseste in headerul pachetului. Un ACL este format din unul sau mai multe ACE-uri (Access Control Entry). ACE-urile sunt declaratii de tip permit sau deny, iar pe baza lor se realizeaza identificarea si filtrarea traficului. In mod implicit orice ACL se incheie cu un ACE de tip deny all traffic. Prin urmare daca un ACE de tip permit nu este configurat, iar ACL-ul este aplicat pe interfata, rezultatul va fi blocarea intregului trafic pe interfata respectiva.
Pe langa aplicarea pe interfete pentru a controla traficul, ACL-urile se mai pot aplica pe liniile VTY pentru a filtra accesul remote pe echipamente, mai pot fi utilizate pentru implementarea mecanismelor NAT sau mai pot fi folosite pentru realizarea politicilor QoS de prioritizare a traficului.
Ca mod de functionare, in momentul in care un router primeste un pachet, informatia din header este confruntata cu lista de ACE-uri. Spre deosebire de procesul de routing, unde tabela de rutare poate fi consultata de mai multe ori pana cand routerul ia o decizie de inaintare a pachetului catre una dintre interfete, la ACL-uri decizia se ia imediat ce informatia din header a facut “match” cu un ACE.
Este foarte important de avut in vedere acest lucru cand ierarhizam ACE-urile intr-un ACL.
ACL-urile sunt de doua tipuri, Standard sau Extended. ACL-urile Standard filtreaza traficul avand ca informatie doar IP-ul sursa, utilizeaza putine resurse si sunt definite in intervalele 1 - 99, 1399 - 1999. Plasarea lor se face cat mai aproape de destinatie.
ACL-urile Extended prezinta o sintaxa mai complexa si pot realiza filtrarea traficului pe baza protocolului din headerul IP, a IP-ului sursa sau destinatie, a portului sursa sau destinatie, in functie de flag-uri TCP, etc.. Implementarea lor necesita o utilizare mai ridicata a resurselor hardware si sunt definite in intervalele 100 - 199, 2000 - 2699. Plasarea lor se face cat mai aproape de sursa.
Tip: Cand am intalnit prima data notiunea de ACL, pentru a memora mai usor locul unde trebuie plasat intr-o topologie am folosit urmatorul truc, am memorat propozitia “Elevii sunt somnorosi dimineata.” Este o propozitie care in spate m-a ajutat sa tin minte urmatorul lucru : Extended - Source; Standard - Destination.
Topologie (dati click pe imagine pentru a mari)
In topologia prezentata am folosit routere pentru a simula hosturile. Pe R4, R5, R6, R7 si R8 am folosit comanda no ip routing in modul global config.
Ca obiective, dupa configurarea interfetelor conform schemei de adresare, imi propun sa configurez pe R1 un ACL standard care sa contina doua ACE-uri, prin care sa realizez NAT doar pentru hosturile din reteaua 192.168.34.0/24 si VLAN-ul 11.
In continuare vreau sa blochez traficul dinspre reteaua 192.168.35.0/24 spre VLAN-ul 9 printr-un ACL standard. Fiind vorba despre un ACL standard il voi plasa cat mai aproape de destinatie, adica pe R2, pe sub-interfata g0/0.9 outbound.
Pe R1, doresc configurarea unui ACL Extended care sa ofere posibilitatea hosturilor din reteaua 192.168.34.0/24 sa poata da ping in 10.10.18.2, dar sa blocheze pingul dinspre 10.10.18.2 spre reteaua 192.168.34.0/24. In acelasi timp din 10.10.18.2 trebuie sa avem posibilitatea de a utiliza comanda ping catre celelalte retele. Fiind un ACL extended il plasam cat mai aproape de sursa. In cazul acesta sursa mesajelor de tip echo-reply fiind R8, plasam ACL-ul pe interfata serial 5/1 inbound.
Pe R3 configuram liniile vty pentru accesul remote, apoi configuram un ACL prin care permitem doar accesul remote de pe R8.
Configurare NAT pe R1
R1(config)#access-list 1 permit 192.168.34.0 0.0.0.255
R1(config)#access-list 1 permit 192.168.27.0 0.0.0.255
Stabilim cele doua ACE-uri pe care le vom utiliza pentru a realiza NAT doar pentru hosturile din retelele 192.168.34.0/24 si 192.168.27.0/24.
R1(config)#ip nat inside source list 1 interface f6/0 overload
Configuram NAT, folosind ca sursa ACL-ul standard 1. Folosim argumentul “overload” pentru a realiza PAT.
Configuram R2, apoi utilizam comanda ping din VLAN-ul 9 si din VLAN-ul 11, catre o destinatie din internet (ex. google, 8.8.8.8). Vom observa ca avem conectivitate din VLAN-ul 11 dar nu si din VLAN-ul 9.
R1#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 192.168.255.221:6 192.168.27.1:6 8.8.8.8:6 8.8.8.8:6
Configurare ACL standard pe R2
R2(config)#access-list 1 deny 192.168.35.0 0.0.0.255
R2(config)#access-list 1 permit any
R2(config)#int g0/0.9
R2(config-subif)#ip access-group 1 out
Am subliniat comanda access-list 1 permit any, deoarece daca nu folosim acest ACE, declaratia implicita deny all traffic de la sfarsitul ACL-ului va bloca tot traficul in momentul in care il plasam pe interfata.
Putem verifica acest lucru configurand ACL-ul fara aceasta intrare si incercand sa stabilim conectivitatea din orice retea catre VLAN-ul 9. Vom observa ca acest lucru nu se mai realizeaza dupa ce plasam ACL-ul pe interfata. Abia dupa introducerea ACE-ului care permite tot traficul vom putea realiza conexiuni cu hosturile din VLAN-ul 9. Exceptie vor face hosturile din reteaua 192.168.35.0/24 care vor fi blocate de primul ACE.
Configurare ACL extended pe R1
R1(config)#access-list 100 permit icmp host 10.10.18.2 192.168.34.0 0.0.0.255 echo-reply
R1(config)#access-list 100 deny icmp host 10.10.18.2 192.168.34.0 0.0.0.255 echo
R1(config)#access-list 100 permit ip any any
R1(config)#int s5/3
R1(config-if)#ip access-group 100 in
Verificare ACL
Pornim un ping dinspre R4 spre R8 (trebuie sa primim raspuns)
R4#ping 10.10.18.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.18.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/100/120 ms
Pornim un ping dinspre R8 spre R4 (nu trebuie sa primim raspuns)
R8#ping 192.168.34.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.34.1, timeout is 2 seconds:
UUUUU
Success rate is 0 percent (0/5)
Pornim un ping dinspre R8 spre R5, R6 sau R7 (trebuie sa avem raspuns)
R8#ping 192.168.35.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.35.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/34/44 ms
R8#ping 192.168.26.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.26.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/38/80 ms
R8#ping 192.168.27.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.27.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/38/68 ms
Configuram liniile VTY pe R3
R3(config)#username admin privilege 15 secret cisco
R3(config)#line vty 0 4
R3(config-line)#login local
Dupa configurare verificam posibilitatea de a ne conecta la R3 prin telnet de pe R7 (trebuie sa reuseasca)
R7#telnet 10.10.13.2
Trying 10.10.13.2 ... Open
User Access Verification
Username: admin
Password:
R3#
Configuram un ACL standard pe R3 care sa contina un singur ACE de tip permit, care sa faca filtrarea dupa adresa IP a lui R8. Dupa configurare il plasam pe liniile VTY.
R3(config)#access-list 1 permit 10.10.18.2
R3(config)#line vty 0 4
R3(config-line)#access-class 1 in
Verificam iar posibilitatea de a ne conecta la R3 prin telnet de pe R7 (nu trebuie sa reuseasca)
R7#telnet 10.10.13.2
Trying 10.10.13.2 ...
% Connection refused by remote host
Verificam posibilitatea de a ne conecta la R3 prin telnet de pe R8 (trebuie sa reuseasca)
R8#telnet 10.10.13.2
Trying 10.10.13.2 ... Open
User Access Verification
Username: admin
Password:
R3#
Pentru realizarea rutarii intre R1, R2 si R3 am configurat OSPF single area folosind ca network statement 0.0.0.0 255.255.255.255 pentru a activa protocolul pe toate interfetele. Pentru a scoate traficul catre internet am folosit o ruta default pe R1 pe care am propagat-o catre R2 si R3.
Cam acesta este laboratorul, sper sa fie de folos celor care doresc recapitulrea notiunii de ACL din CCNA2.
Pentru intrebari sau observatii puteti utiliza sectiunea de comentarii. Spor! :)
Niciun comentariu :
Trimiteți un comentariu