luni, 7 noiembrie 2016

DMVPN si Acces Internet

Va amintiti discutia despre DMVPN de aici ?
Totul a pornit de la faptul ca dupa ce am parcurs portiunea rezervata acestui subiect din Certification Guide-ul oficial pentru CCNA, am fost dezamagit sa constat ca nu se intra in detalii despre modul de configurare. Prin urmare, din curiozitate am facut putina munca de cercetare, iar rezultatul a fost acel laborator.

Azi, condus de aceeasi dorinta de a vedea lucrurile duse pana la capat, voi adauga partea de IPSec si voi presupune ca utilizatorii din LAN-uri vor sa iasa si catre Internet, asa ca va trebui sa gasesc o solutie pentru ca ei sa poata accesa backbone-ul ISP-ului. Reteaua catre care vom dori sa ajungem cand iesim din VPN, este un loopback configurat pe ISP, care are adresa 9.9.9.9/32.

Locul de joaca este cel din laboratorul precedent.

Inainte de a configura IPSec, va recomand sa porniti o captura pe unul dintre linkuri si sa faceti trafic pe tunel care sa treaca prin acel link. Veti putea observa toate mesajele "hello" trimise de EIGRP si orice alt trafic mai trece prin tunel.



Partea 1: Configuram IPsec

Configuram un ISAKMP Policy pentru Faza 1 de negociere

crypto isakmp policy 10
hash md5
authentication pre-share

Adaugam pre-shared keys dinamice pentru toate routerele din VPN.

crypto isakmp key 1337bits address 0.0.0.0 0.0.0.0

Cream politica din Faza 2, pentru criptarea datelor.

crypto ipsec transform-set 53cr37 esp-3des esp-md5-hmac
Cream un profil IPSec care sa fie aplicat dinamic pe Tunel.

crypto ipsec profile DMVPN_Lab
set security-association lifetime seconds 300
set transform-set 53cr37

Pe interfetele Tunnel este nevoie sa mai adaugam comanda:

tunnel protection ipsec profile DMVPN_Lab

Dupa ce terminam de configurat IPSec, putem arunca o noua privire in WireShark pentru a observa ca traficul care trece acum prin tunel este criptat (ESP).


Partea 2: Configurare NAT

Si acum, urmeaza partea frumoasa in care clientul doreste si acces din LAN catre backbone-ul ISP-ului.
Pentru a realiza acest lucru, in topologia de fata m-am gandit la urmatoarea solutie. Pe fiecare router voi configura un ACL extended in care voi face doua declaratii de tip deny de la sursa clasa din LAN cu destinatie subnetul in care se afla interfetele tunel si un supernet care sa cuprinda toate celelalte LAN-uri. Apoi voi permite clasa din LAN catre orice alta destinatie pentru orice protocol.

Acest ACL il voi utiliza pentru a face NAT pe interfata fizica ce leaga routerele de ISP.
Daca solutia e corecta, cand dam un ping de pe oricare dintre cele 4 routere din VPN catre interfata loopback de pe ISP cu sursa interfata loopback configurata pe ele, ar trebui sa mearga. Fara aceasta configurare, un astfel de ping nu reuseste deoarece ISP-ul nu stie sa ajunga la LAN-uri.


Configuratia de pe routere arata in felul urmator:

ACL Denver

ip access-list extended INTERNET
deny   ip host 172.16.10.1 192.168.1.0 0.0.0.7
deny   ip host 172.16.10.1 172.16.0.0 0.0.255.255
permit ip host 172.16.10.1 any


ACL Los Angeles

ip access-list extended INTERNET
deny   ip host 172.16.40.1 192.168.1.0 0.0.0.7
deny   ip host 172.16.40.1 172.16.0.0 0.0.255.255
permit ip host 172.16.40.1 any


ACL Texas

ip access-list extended INTERNET
deny   ip host 172.16.30.1 192.168.1.0 0.0.0.7
deny   ip host 172.16.30.1 172.16.0.0 0.0.255.255
permit ip host 172.16.30.1 any


ACL New York

ip access-list extended INTERNET
deny   ip host 172.16.20.1 192.168.1.0 0.0.0.7
deny   ip host 172.16.20.1 172.16.0.0 0.0.255.255
permit ip host 172.16.20.1 any


Apoi pe fiecare vom configura interfetele ip nat inside / outside si vom face NAT folosind comanda:

ip nat inside source list INTERNET interface FastEthernet0/0 overload

Oare a mers ? Configurand veti afla. :)
Cam aceasta este completarea adusa laboratorului precedent.
Sper ca ati gasit acest articol util si interesant, iar pana data viitoare va urez toate cele bune.
Spor!






Niciun comentariu :

Trimiteți un comentariu