Topologie format visio 2007:
Informations introductives
A noter que dans la topologie dynagen, j’utilise 4 hyperviseurs locaux pour tirer partie de mon quadcore, à vous de voir si vous voulez le modifier, mais en tous les cas il n’est pas gênant d’avoir plusieurs process dynamips même avec 1 ou deux coeurs (et sur le billet précédent, j’étais sur le laptop, donc dualcore ). pour lancer les hyperviseurs, j’utilise la commande (en root – sudo su)
dynamips -H 7200 & dynamips -H 7201 & dynamips -H 7202 & dynamips -H 7203
Note: pour importer les configs dans les routeurs, tapez, dans la console dynagen, import /all ./configs (il faut bien entendu que les fichiers de configs soient dans le dossier configs du fichier de topo). Le fichier .net est ici:topo.net Les configurations initiales ici: configs_initial.tar
Je fournirais les configs des différents équipements aux diverses étapes de l’article, les configurations finales étant disponible dans la conclusion.
Configuration du backbone MPLS
cette partie (ainsi que certaines des parties suivantes) ne change pas vraiment de ce que j’ai déjà abordé dans mon article sur les MPLS VPNs sauf qu’on mets du ISIS pour l’IGP (ça me permets de réviser pour BSCI ). Bon pour faire très simple (surtout que j’ai pas encore taffé à fond IS-IS, pas bien!, mais ça viendra…):
- IS-IS = Intermediate System to Intermediate System (router to router quoi)
- Séparation des networks en level (comparable aux aires OSPF), en gros, un routeur level 1 communique avec les routeur level 1, et un routeur level 2 avec un routeur level 2, et il y a des level 1 + 2 pour le routage entre aires. Les aires Level 1 sont destinées au routage interne, et les Level 2 au routage externe (à l’aire)
- Les areas sont définies dans l’adresse NSAP, ce qui est l’adresse du protocole CLNS, qui est en fait le protocole de niveau 3 du modèle OSI (à ce propos, j’ai appris récément qu’en fait si OSI avait été implémenté, mais que TCP/IP l’ayant devancé et étant rapidement devenu populaire, OSI à été mis un peu de coté). Pour revenir à NSAP, c’est définit à un niveau global sur le routeur, pas interfaces par interfaces comme c’est le cas avec une adresse IP.
- Voici la structure d’une adresse NSAP area.system_id.NSEL
-area, de 1 à 13 octets (il est courrant d’en utiliser 3), représente l’area. On l’écriras 49.XXXX (49 signifiant l’adressage privé).
-System ID, 6 octets: l’identifiant du système dans son aire, on utilise souvent la mac ou une IP de loopback précédée de 0. Ici, pour faire simple, je vais utiliser 0000.0000.00XX ou XX est l’ID définit dans le schéma).
-NSEL, 1 octet = NSAP Selector : Identifie le processus avec lequel on veux communiquer, pour le routage, c’est toujours 00.
Exemple de NSSAP pour LSR1: 49.0001.0000.0000.0010.00
- la configuration se fait de la sorte:
router isis
net NSAP !replacer par le NSAP du router, net != network
!net = Network Entity Title = NSAP du router pour le routage (NSEL = 00)
is-type level-1|level-1-2 | level-2-only
puis
interface X/X
ip router isis
Voilà les configs sur les routeurs LSR1 et PEx : NE PAS OUBLIER DE ROUTER LES LOOPBACK, sans quoi LDP ne pourrait creer d’adjacence avec ses voisins (si il ne connait pas ses loopbacks)
LSR1:
LSR1(config)#router ISIS
LSR1(config-router)#net 49.0001.0000.0000.0010.00
LSR1(config-router)#is-type level-1
LSR1(config-router)#interface F0/0
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int F0/1
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int F1/0
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int F1/1
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int loop0
LSR1(config-if)#ip router isis
LSR1(config-if)#exit
et pour les PE (on ne mets pas dans le routage le réseau qui sera dans la VRF, à noter que je l’ai fait sans faire gaffe, et que cela permets d’apprendre les routes des VRFs dans la table globale du routeur !!!!) Pour PE4, mettre le réseau qui relie vers BBR1, sans quoi, vu que son IP sera en nexthop pour les réseaux de l’AS 1001 appris via BGP, les routeurs de l’AS 1000 ne pourraient communiquer.
LSR1(config)#router ISIS
LSR1(config-router)#net 49.0001.0000.0000.00XX.00
LSR1(config-router)#is-type level-1
LSR1(config-router)#interface F0/0
LSR1(config-if)#ip router ISIS
LSR1(config-if)#int loop0
LSR1(config-if)#ip router isis
Ce qui à la fin nous donne (SNPA = Adresse L2 OSI (MAC, DLCI, …), et show clns car clns transporte ISIS, mais ça on l’a déjà dit…):
LSR1#show clns neighbors
System Id Interface SNPA State Holdtime Type Protocol
PE3 Fa1/0 cc03.0bf4.0000 Up 8 L1 IS-IS
PE4 Fa1/1 cc04.0bf4.0000 Up 9 L1 IS-IS
PE2 Fa0/1 cc02.0be6.0000 Up 7 L1 IS-IS
PE1 Fa0/0 cc01.0be6.0000 Up 9 L1 IS-IS
Et (à ce moment j’avais oublié les loopbacks dans ISIS)
PE1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks
C 10.1.0.11/32 is directly connected, Loopback0
i L1 10.0.2.0/30 [115/20] via 10.0.0.1, FastEthernet0/0
i L1 10.0.3.0/30 [115/20] via 10.0.0.1, FastEthernet0/0
C 10.0.0.0/30 is directly connected, FastEthernet0/0
i L1 10.0.1.0/30 [115/20] via 10.0.0.1, FastEthernet0/0
i L1 10.254.0.0/30 [115/30] via 10.0.0.1, FastEthernet0/0
C 192.168.0.0 is directly connected, FastEthernet0/1
Et c’est tout ! la commande ip router isis sur les interfaces à permis d’indiquer que l’on voulait inclure les routes IP de l’interface en question dans ISIS. On aurait pu rajouter du redistribute xxx dans le mode router isis global, mais on s’écarte un peu du sujet. Une petite vérif pour la route et tout roule:
PE1#ping 10.0.0.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
PE1#ping 10.0.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/24/48 ms
PE1#ping 10.0.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.2.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/32/76 ms
PE1#ping 10.0.3.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/32 ms
PE1#
Voilà, mon routage Interne dans le backbone MPLS est OKAY, mais, une petite minute, est-ce un backbone MPLS ? Bah non, on a pas encore mis le MPLS Je vous renvoi à mon article sur les MPLS VPNs pour le détail de la config MPLS, mais voici comment ça fonctionne: LSR1:
LSR1(config)#mpls ldp advertise-labels
LSR1(config)#mpls ldp router-id loop 0
LSR1(config)#int f0/0
LSR1(config-if)#mpls ip
LSR1(config-if)#int f0/1
LSR1(config-if)#mpls ip
LSR1(config-if)#int f1/0
LSR1(config-if)#mpls ip
LSR1(config-if)#int f1/1
LSR1(config-if)#mpls ip
LSR1(config-if)#exit
puis même chose sur les PE … Uniquement sur les F0/0 (reliées au LSR1), on va pas envoyer du MPLS sur le client.
LSR1#sh mpls ldp neighbor | i IP
FastEthernet0/1, Src IP addr: 10.0.1.2
FastEthernet1/0, Src IP addr: 10.0.2.2
FastEthernet0/0, Src IP addr: 10.0.0.2
FastEthernet1/1, Src IP addr: 10.0.3.2
LSR1#sh mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop
tag tag or VC or Tunnel Id switched interface
16 Pop tag 10.254.0.0/30 0 Fa1/1 10.0.3.2
17 Pop tag 192.168.0.8/30 0 Fa1/0 10.0.2.2
18 Pop tag 192.168.0.0/30 0 Fa0/0 10.0.0.2
19 Pop tag 192.168.0.4/30 0 Fa0/1 10.0.1.2
20 Pop tag 10.1.0.12/32 0 Fa0/1 10.0.1.2
21 Pop tag 10.1.0.11/32 0 Fa0/0 10.0.0.2
22 Pop tag 10.1.0.13/32 0 Fa1/0 10.0.2.2
23 Pop tag 10.1.0.14/32 0 Fa1/1 10.0.3.2
Voilà tout est Ok, on fera un petit ping tout de même entre deux PE pour s’en assurer, mais le backbone est OK.
Création de la VRF et routage BGP
bon, vous vous rappelez des VRFs ? pour ceux qui n’ont pas lu mon article précédent, ça permets de faire une table de routage virtuelle pour un client, qui est donc indépendante de la table globale du routeur, et qui ce qui est génial c’est que l’on peux définir une route distinguisher pour identifier cette VRFs et transformer ses routes IPv4 en routes VPNv4 via l’utilisation de BGP en mode multi protocoles (MP-BGP) que l’ont peut transporter au sein du backbone et redistribuer ces routes dans la VRF d’un router distant, ce qui permets de faire un VPN en utilisant MPLS (chaque VRF est en fait double labélisée, et un label correspond à la VRF). Note: On peux faire des VRFs lite qui utilisent, au lieu des labels MPLS, un tag VLAN, l’avantage c’est qu’on peux le faire du des 3550 et pas besoin de MPLS. La VRF sera à créer sur les PE 1, 2 et 3, le PE 4 étant relié à un FAI (on avait pas vu le routage eBGP dans mon précédent article, on va corriger cela, et on va même mettre des route reflector ) Pour créer la VRF on utilisera ces commandes:
ip vrf VRF1
rd 1000:1
route-target both 1000:1
interface F0/1
ip vrf forwarding VRF1 ! et la ça fait sauter l'IP
ip address 192.168.0.X 255.255.255.252
exit
Ensuite, on active BGP. Ici, on vas utiliser la fonction de route reflector, en gros, au lieux que tous les routeurs soient voisins iBGP entre eux, ils seront voisins avec PE4 (qui fera aussi de l’eBGP), qui centralisera les routes et les « réfléchira », ce qui veux dire les renverra à ses autres voisins. On notera que LSR1 n’utilisera pas BGP (il faut simplement transiter le trafic au sein de l’AS). pour activer BGP (avec le support des VRFs, soient des adresses VPNv4), dans un premier temps au sein de l’AS (on verra eBGP après): Sur PE 1,2,3:
router bgp 1000
neighbor 10.1.0.14 remote-as 1000
neighbor 10.1.0.14 update-source loop0
address-family vpnv4
neighbor 10.1.0.14 activate
neighbor 10.1.0.14 send-community both
sur PE4
router bgp 1000
neighbor 10.1.0.11 remote-as 1000
neighbor 10.1.0.11 update-source loop0
neighbor 10.1.0.11 route-reflector-client
address-family vpnv4
neighbor 10.1.0.11 activate
neighbor 10.1.0.11 send-community both
neighbor 10.1.0.11 route-reflector-client
exit
neighbor 10.1.0.12 remote-as 1000
neighbor 10.1.0.12 update-source loop0
neighbor 10.1.0.12 route-reflector-client
address-family vpnv4
neighbor 10.1.0.12 activate
neighbor 10.1.0.12 send-community both
neighbor 10.1.0.12 route-reflector-client
exit
neighbor 10.1.0.13 remote-as 1000
neighbor 10.1.0.13 update-source loop0
neighbor 10.1.0.13 route-reflector-client
address-family vpnv4
neighbor 10.1.0.13 activate
neighbor 10.1.0.13 send-community both
neighbor 10.1.0.13 route-reflector-client
exit
Il faut maintenant activer ospf sur les PE 1,2 et 3 pour la VRF VRF1. Ceci se fait de la sorte:
PE1(config)#router ospf 1 vrf VRF1
PE1(config-router)#network 192.168.0.0 0.0.0.255 area 0 ! j'ai mis le subnet /24 pour pouvoir faire copier/coller entre PE
et sur les routeurs RMO1, 2, ainsi que sur RTRDT, config classique:
RMO2(config)#router ospf 1
RMO2(config-router)#network 192.168.0.0 0.0.0.255 area 0 !idem pour les masques
RMO2(config-router)#network 10.0.0.0 0.255.255.255 area 0 !idem pour les masques
RMO2(config-router)#exit
petite vérif pour la route:
PE2#sh ip route vrf VRF1
Routing Table: VRF1
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 1 subnets
O 10.1.0.1 [110/2] via 192.168.0.6, 00:04:32, FastEthernet0/1
192.168.0.0/30 is subnetted, 1 subnets
C 192.168.0.4 is directly connected, FastEthernet0/1
Et maintenant on redistribue OSPF dans BGP, et BGP dans ospf Config sur les PE 1,2 et 3:
PE2(config)#router ospf 1 vrf VRF1
PE2(config-router)#redistribute BGP 1000 subnets
PE2(config-router)#exit
PE2(config)#router bgp 1000
PE2(config-router)#address-family ipv4 vrf VRF1
PE2(config-router-af)#redistribute ospf 1
PE2(config-router-af)#exit
PE2(config-router)#exit
vérifications:
PE4#sh bgp vpnv4 unicast all
BGP table version is 6, local router ID is 10.1.0.14
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 1000:1
*>i10.1.0.1/32 10.1.0.12 2 100 0 ?
*>i10.2.0.1/32 10.1.0.13 2 100 0 ?
*>i192.168.0.0/30 10.1.0.11 0 100 0 ?
*>i192.168.0.4/30 10.1.0.12 0 100 0 ?
*>i192.168.0.8/30 10.1.0.13 0 100 0 ?
PE4#
PE2#sh ip route vrf VRF1
Routing Table: VRF1
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 2 subnets
B 10.2.0.1 [200/2] via 10.1.0.13, 00:01:45
O 10.1.0.1 [110/2] via 192.168.0.6, 00:03:11, FastEthernet0/1
192.168.0.0/30 is subnetted, 3 subnets
B 192.168.0.8 [200/0] via 10.1.0.13, 00:01:45
B 192.168.0.0 [200/0] via 10.1.0.11, 00:01:45
C 192.168.0.4 is directly connected, FastEthernet0/1
RMO1#ping 10.2.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 36/48/68 ms
Voilà le le backbone MPLS et le VPN MPLS sont OK, on va attaquer la partie eBGP et la redistribution de route statique pour l’accès internet dans une VRF une petite archive avec les configs jusqu’a présent:configs_backbone.tar
Routage internet eBGP
Tout d’abord, en regardant la topologie, on voit que le routeur du datacenter a déjà une connexion internet, le FAI fournissant le service de VPN MPLS ne s’occupera pas d’internet pour ce routeur. Pour les autres (RMO1 et RMO2), le FAI va fournir internet, internet étant ici représenté comme l’AS 1001, bref, ce qui est important c’est de voir les options dont l’ont dispose pour amener une connectivité internet dans une VRF:
- Copier la table de routage internet globale dans une VRF : Idiot, qui va s’ammuser à recopier plusieurs fois les quelques 150 000 Routes internet dans ses VRFs ?
- Avoir deux interfaces vers le FAI : Une dans une VRF, une dans la table de routage : Implique d’avoir 2 liens (possibilité d’utiliser des liens virtuels), et que le FAI à dans sa table de routage globale les routes vers internet, ce qui n’est pas toujours souhaité pour des raisons de sécurités
- Route statique vers la table globale: cela implique aussi que le FAI à mis sa table de routage internet dans sa table de routage globale. Cela est possible via la commande ip route vrf {vrf} {net} {mask} global (voir ici: Internet Access from an MPLS VPN Using a Global Routing Table
- Utiliser la connexion internet du datacenter : On aurait pu, mais si elle tombe, plus personne n’a le net…
- chaque site distant à une connexion internet séparée : pourquoi pas…
- Utiliser une VRF dédiée pour internet, et redistribuer ses routes dans la VRF du client: Bonne pratique d’un point de vue sécurité, car le routage internet est séparé du routage interne du FAI, cependant, si la VRF internet contient toutes les routes internet, cela peut poser des problèmes… Cependant, la table de routage internet peux inclure une route par défaut, et l’on peut filtrer les routes redistribuée d’une VRF à une autre. Par contre, il faut prendre en compte que les routes d’une VRFs utilisent beaucoup plus de mémoire qu’une route dans la table globale… A noter aussi dans ce cas le routeur du FAI est vu comme le routeur d’un client (customer edge), mais qu’il est possible d’établir un peering BGP avec un router dans une VRF.
- … il y a pas mal d’autres scénarios possibles, viennent ensuite les problématique du NAT, qui le fait ? Le client ? dans ce cas il faut une IP publique par site client… Le FAI ? dans ce cas il doit gérer les translations de port du client etc, cela peut être un peut lourd…
un peu de lecture:
http://fengnet.com/book/MPLS%20VPN%20Security/ch04lev1sec1.html
http://www.cisco.com/en/US/tech/tk436/tk428/technologies_white_paper09186a00801281f1.shtml
Vous l’aurez compris, tout cela sont des notions de design MPLS, et il y a des bouquins de plusieurs centaines de pages la dessus, et bien que cela soit très intéressant, nous allons ici faire, dans la mesure du possible, ce qui est le plus simple. Ce que l’on va donc faire ici, c’est nater au niveau du client, en utilisant une route statique vers la table globale au niveau du PE. Cela est un peu subtile, car il faut redistribuer les routes des PE via BGP (sur PE4, qui va faire un peering avec le router de l’AS 1001), puis faire des routes statiques que l’on va inclure dans l’IGP qui auront 2 fonctions: Permettre aux routeurs du backbone comment joindre ces IPs, car ils ne sont pas dans la bonne VRF vous noterez qu’il faut spécifier manuellement l’interface et le next-hop pour forcer à passer dans une VRF. Je vais affecter des IP publiques. Sur PE1, cela donnerai ceci (192.0.0.2 serait l’IP publique affectée au routeur, on pourrais aussi faire la même chose avec ses IPs privées, mais on ne va pas envoyer d’ip privées via BGP à un autre FAI…):
ip route 192.0.0.2 255.255.255.255 F0/1 192.168.0.2
router ISIS
redistribute static ip level-1
Le principe est de router ces IPs publiques dans le backbone via ISIS et de les réinjecter dans BGP via la redistribution depuis ISIS avec une route map. Première étape, configuration eBGP: même chose qu’iBGP, mais avec un remote-as différent (par contre on échangeras pas de routes vpnv4) sur PE4 (on fait une route map pour ne réinjecter que les IPs publiques, pas les IPs du subnet backbone):
PE4(config)#ip access-list sta PUBIPs
PE4(config-std-nacl)#permit host 192.0.0.2
PE4(config-std-nacl)#permit host 192.0.0.6
PE4(config-std-nacl)#permit host 192.0.0.10
PE4(config-std-nacl)#exit
PE4(config)#route-map RMPUBIPs permit 10
PE4(config-route-map)#match ip address PUBIPs
PE4(config-route-map)#set metric 100
PE4(config-route-map)#exit
PE4(config)#router bgp 1000
PE4(config-router)#neighbor 10.254.0.2 remote-as 1001
PE4(config-router)#redistribute isis level-1 route-map RMPUBIPs
et sur BBR (ici juste un redistribute connected)
BBR1(config)#router bgp 1001
BBR1(config-router)#neighbor 10.254.0.1 remote-as 1000
BBR1(config-router)#redistribute connected metric 100
vérifications
PE1#sh ip route 100.0.0.0
Routing entry for 100.0.0.0/30, 3 known subnets
B 100.0.0.4 [200/100] via 10.254.0.2, 00:06:20
B 100.0.0.0 [200/100] via 10.254.0.2, 00:06:20
B 100.0.0.12 [200/100] via 10.254.0.2, 00:06:20
BBR1#sh ip route 192.0.0.0
Routing entry for 192.0.0.0/32, 3 known subnets
B 192.0.0.2 [20/100] via 10.254.0.1, 00:07:46
B 192.0.0.6 [20/100] via 10.254.0.1, 00:07:47
B 192.0.0.10 [20/100] via 10.254.0.1, 00:07:47
BBR1#deb ip icmp
PE1#ping ip 100.0.0.1
ICMP packet debugging is on
BBR1#
*Dec 17 00:01:24.083: ICMP: echo reply sent, src 100.0.0.1, dst 10.0.0.2
sur l’exemple de ping au dessus, la réponse ne pourra arriver à PE1, car celui-ci utilise son IP privée que l’on a délibérément pas routée dans BGP Maintenant, on va créer une route statique par défaut dans la vrf VRF1 que l’on va faire pointer sur la passerelle internet (on va utiliser l’IP de BBR1), en indiquant que cette passerelle se trouve dans la table globale. Cela ce fait via l’utilisation du mot clé « global » dans la commande ip route. Ensuite, on va redistribuer cette route par défaut via OSPF. Note: On ne va faire cette manip que sur PE 2 et 3, car le router RTRDT dispose d’une connexion internet externe.
PE2(config)#ip route vrf VRF1 0.0.0.0 0.0.0.0 10.254.0.2 global
PE2(config)#router OSPF 1 vrf VRF1
PE2(config-router)#default-information originate
PE2(config-router)#exit
PE2(config)#
petite vérification:
RMO1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 192.168.0.5 to network 0.0.0.0
10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
O IA 10.2.0.1/32 [110/3] via 192.168.0.5, 00:02:42, FastEthernet0/0
C 10.1.0.0/16 is directly connected, Loopback0
O IA 10.0.0.1/32 [110/3] via 192.168.0.5, 00:02:42, FastEthernet0/0
192.168.0.0/30 is subnetted, 3 subnets
O IA 192.168.0.8 [110/2] via 192.168.0.5, 00:02:42, FastEthernet0/0
O IA 192.168.0.0 [110/2] via 192.168.0.5, 00:02:42, FastEthernet0/0
C 192.168.0.4 is directly connected, FastEthernet0/0
O*E2 0.0.0.0/0 [110/1] via 192.168.0.5, 00:01:40, FastEthernet0/0
Dummy1#deb ip icmp
ICMP packet debugging is on
RMO1#ping 100.0.0.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.14, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Dummy1#
*Mar 1 00:06:07.207: ICMP: echo reply sent, src 100.0.0.14, dst 192.168.0.6
Evidemment le ping est reçu mais la réponse ne peut aboutir, puisque au niveau de RMO1 on a pas fait le NAT, donc le routeur distant voit son IP privée.
On va donc mettre le NAT en place. Ici, il y a une petite subtilité, car il faut bien sur pas nater ce qui est à destination des IP privées, ni le traffic OSPF, j’ai donc utilisé une route map.
Avant toute chose, ne pas oublié de faire une route sur DUMMY1 (on pourrait mettre de l’OSPF entre BBR1 et DUMMY1 et redistribuer BGP dans OSPF, mais on l’a déjà fait au dessus, on va faire au plus simple donc)
Dummy1(config)#ip route 0.0.0.0 0.0.0.0 100.0.0.13
Et au niveau du nat, voici ce que j’ai fait:
- Le but est de ne pas natter le trafic OSPF ni le trafic à destination des sites des VPN MPLS, et j’ai testé avec des deny sur une access-list, et ip nat inside source list, mais ça ne marche pas (ou j’ai loupé quelque chose)
- j’ai donc défini 2 ACLs, une qui correspond au trafic à natter, l’autre à exclure (les noms sont explicites je penses), petite subtilité pour ceux qui n’ont pas l’habitude de matcher via des ACLs, l’ACL NONAT, bien que son but est d’empêcher du trafic d’être natter, va faire des permit sur le trafic à exclure, cela va permettre d’identifier ce trafic, et la route-map va l’interdire.
- défini une route map avec 2 entrée qui font un match sur les ACL précédemment définie pour indiquer ce qui doit être natter ou non
- appliquer la route map dans la commande IP NAT SOURCE
- ne pas oublier les ip nat inside/outside
RMO2(config)#ip access-list extended NONAT
RMO2(config-ext-nacl)#permit ospf ANY ANY
RMO2(config-ext-nacl)#permit ip any 10.0.0.0 0.255.255.255
RMO2(config-ext-nacl)#permit ip any 192.168.0.0 0.0.255.255
RMO2(config-ext-nacl)#exit
RMO2(config)#ip access-list standard NAT
RMO2(config-std-nacl)#permit 10.0.0.0 0.255.255.255
RMO2(config-std-nacl)#exit
RMO2(config)#route-map NATMAP deny 10
RMO2(config-route-map)#match ip address NONAT
RMO2(config-route-map)#route-map NATMAP permit 20
RMO2(config-route-map)#match ip address NAT
RMO2(config-route-map)#exit
RMO2(config)#ip nat pool MyIP 192.0.0.10 192.0.0.10 netmask 255.255.255.252
RMO2(config)#ip nat inside source route-map NATMAP pool MyIP overload
On fait la même config sur RMO1 (en changeant les IPs)
Vérifications
RMO1#ping 100.0.0.14 source loop0
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.14, timeout is 2 seconds:
Packet sent with a source address of 10.1.0.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 248/272/304 ms
Dummy1#
*Mar 1 00:09:03.859: ICMP: echo reply sent, src 100.0.0.14, dst 192.0.0.6
RMO1#ping 10.2.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 144/192/256 ms
Et voilà nos routeurs ont un VPN MPLS ET un accès internet, c’est pas beau ça ?
Sur RTRDT, une simple route statique suffit pour internet. A noter qu’on aurait pu redistribuer cette route statique dans OSPF avec une métrique forte pour qu’au cas où la connexion internet des sites distants tombe, ces derniers pourraient utiliser celle du datacenter, mais tout de manière dans notre cas ici, vu que le net et le vpn passe par le même FAI, si le net est HS, le VPN le sera aussi probablement.
Note: Je ne vais pas mettre de NAT sur le routeur du datacenter vu qu’il n’est pas censé y avoir d’utilisateurs.
RTRDT(config)#ip route 0.0.0.0 0.0.0.0 100.0.0.1
RTRDT#ping 100.0.0.14
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.14, timeout is 2 seconds:
!!!!!
Configuration PPPoE + Site To Site VPN
Pour la partie PPPoE, je me suis inspiré de l’article http://packetlife.net/blog/2009/apr/20/configuring-pppoe/(très bon blog au passage, en anglais) Pour la partie FAI (ce n’est pas au programme ISCW mais bon toujours utile de savoir comment ça marche non ?), il faut, en gros, créer un group « broad band access aggregation », auquel on rattache une interface virtual-template qui va contenir les paramètres PPP (pool d’adresse notement), puis activer ce group BBA sur l’interface qui reçoit les connexions PPPoE. Il est possible de configurer pas mal de chose dans le groupe BBA, comme le nombre de sessions par adresses mac …
BBR1(config)#bba-group pppoe clients_pppoe
BBR1(config-bba-group)#virtual-template 1
BBR1(config-bba-group)#sessions per-mac limit 2
BBR1(config-bba-group)#exit
BBR1(config)#interface virtual-template 1
BBR1(config-if)#ip add 100.0.1.1 255.255.255.0
BBR1(config-if)#peer default ip address pool pool_pppoe
BBR1(config-if)#exit
BBR1(config)#ip local pool pool_pppoe 100.0.1.2 100.0.1.100
BBR1(config)#int F0/1
BBR1(config-if)#pppoe enable group clients_pppoe
BBR1(config-if)#no ip address
BBR1(config-if)#exit
Sur le client, il faut créer une interface Dialer qui contient les paramètres PPP et associer un dialer pool à cette interface dialer, que l’on va appliquer sur l’interface physique.
RBO1(config)#interface dialer1
RBO1(config-if)#dialer pool 1
RBO1(config-if)#encapsulation ppp
RBO1(config-if)#ip address negotiated !negociée via IPCP
RBO1(config-if)#mtu 1492 !1500 - 8 header ppp
RBO1(config-if)#int f0/0
RBO1(config-if)#no ip address
RBO1(config-if)#pppoe enable
RBO1(config-if)#pppoe-client dial-pool-number 1
RBO1(config-if)#exit
RBO1(config)#
vérifications:
RBO1#sh ip route | i 100
100.0.0.0/32 is subnetted, 2 subnets
C 100.0.1.1 is directly connected, Dialer1
C 100.0.1.3 is directly connected, Dialer1
RBO1#sh ip int br dialer 1
Interface IP-Address OK? Method Status Protocol
Dialer1 100.0.1.3 YES IPCP up up
RBO1#ping 100.0.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/84/160 ms
BBR1#sh pppoe session
1 session in LOCALLY_TERMINATED (PTA) State
1 session total
Uniq ID PPPoE RemMAC Port VT VA State
SID LocMAC VA-st
2 2 cc09.0ba0.0000 Fa0/1 1 Vi1.1 PTA
ca0b.0ba1.0006 UP
BBR1#sh ip route | i 100.0.1
C 100.0.1.0/24 is directly connected, Virtual-Access1.1
C 100.0.1.6/32 is directly connected, Virtual-Access1.1
Voilà pour du PPPoE simple, mais on va rajouter un peut d’authentification, sinon c’est pas marrant… Sur le routeur FAI:
BBR1(config)#int virtual-template 1
BBR1(config-if)#ppp authentication chap
BBR1(config)#username pppoeuser password p4$$w0rd
et sur le client (noter le callin qui indique que l’on ne va pas authentifier le pair distant sur le client, en général les FAI utilisent l’authentification unidirectionnelle, le client s’authentifie, mais le FAI ne s’authentifie pas sur le client. Pour être pointilleux, le paramètre callin indique que l’on vas authentifier le pair distant que s’il initie la session, et vu qu’en l’occurence cela n’arrivera pas, quand le client initie la session il n’essaie pas d’authentifier le FAI)
RBO1(config)#int dialer1
RBO1(config-if)#ppp chap hostname pppoeuser
RBO1(config-if)#ppp chap password p4$$w0rd
RBO1(config-if)#ppp authentication chap callin
et on relance la machine
BBR1#clear pppoe all
!attendre que l'interface du client redevienne "up"
BBR1#sh user | b Interface
Interface User Mode Idle Peer Address
Vi1.1 pppoeuser PPPoE - 100.0.1.6 !l'ip a changée
Voilà, un petit coup de NAT (on utilisera pas le NAT) et route par défaut sur le routeur RBO1, et on attaque le Site-to-site, et pour le FUN, je vais mettre une crypto map sur le RBO et une interface VTI sur le router RTRDT, et le tout en GREoIPSEC
RBO1(config)#int loop 0
RBO1(config-if)#ip nat inside
RBO1(config-if)#int dialer 1
RBO1(config-if)#ip nat outside
RBO1(config-if)#exit
RBO1(config)#ip access-list standard NAT
RBO1(config-std-nacl)#permit 10.2.0.0 0.0.255.255
RBO1(config-std-nacl)#exit
RBO1(config)#ip nat inside source list NAT interface dialer1 overload
RBO1(config)#ip route 0.0.0.0 0.0.0.0 100.0.1.1
RBO1#ping 100.0.0.2 !on ping le datacenter sinon pas la peine de faire du VPN :p
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 84/94/124 ms
Donc pour le site to site, ici on va considérer que l’IP du routeur RBO1 est statique, sinon il aurait fallu faire de l’easy-vpn, ce qui aurait été possible, mais je n’avais pas envie. Pour le site-to-site je vais vous passer les détails de la conf, je penses qu’il y a assez d’exemples sur mon blog. Coté client:
RBO1(config)#int tunnel0 !creation tunnel
RBO1(config-if)#tunnel source dialer1 !prends l'ip de Dialer1 en source
RBO1(config-if)#tunnel destination 100.0.0.2
RBO1(config-if)#tunnel mode gre ip
RBO1(config-if)#ip add 10.10.0.2 255.255.255.0 !'lip du tunnel
RBO1(config)#crypto isakmp policy 10 !isakmp policy
RBO1(config-isakmp)#auth pre
RBO1(config-isakmp)#hash sha
RBO1(config-isakmp)#group 5
RBO1(config-isakmp)#encr aes
RBO1(config)#crypto isakmp key ipsecp4$$ address 100.0.0.2 !password isakmp
RBO1(config)#ip access-list extended CRYPTOACL
RBO1(config-ext-nacl)#permit gre host 100.0.1.6 host 100.0.0.2
RBO1(config-ext-nacl)#remark Voir note
RBO1(config-ext-nacl)#exit
RBO1(config)#crypto ipsec transform-set TSET esp-aes esp-sha-hmac
RBO1(cfg-crypto-trans)#mode transport !transport car tunneling par GRE
RBO1(cfg-crypto-trans)#exit
RBO1(config)#crypto map TUNNELDT 10 ipsec-isakmp !la crypto map
% NOTE: This new crypto map will remain disabled until a peer
and a valid access list have been configured.
RBO1(config-crypto-map)#set peer 100.0.0.2
RBO1(config-crypto-map)#match address CRYPTOACL
RBO1(config-crypto-map)#set transform-set TSET
RBO1(config-crypto-map)#exit
RBO1(config)#interface dialer1
RBO1(config-if)#crypto map TUNNELDT
RBO1(config-if)#exit
RBO1(config)#
Note: Bien mettre les IP des hosts sur la crypto ACL, sans quoi vous aurez cette erreur:
*Mar 1 01:39:26.391: ISAKMP:(0:1:SW:1): IPSec policy invalidated proposal
*Mar 1 01:39:26.395: ISAKMP:(0:1:SW:1): phase 2 SA policy not acceptable! (local 100.0.0.2 remote 100.0.1.6)
Pour le coup j’avais mis permit gre any any.
Coté datacenter:
RTRDT(config)#crypto isakmp policy 10
RTRDT(config-isakmp)#auth pre
RTRDT(config-isakmp)#hash sha
RTRDT(config-isakmp)#group 5
RTRDT(config-isakmp)#encr aes
RTRDT(config)#crypto isakmp key ipsecp4$$ address 100.0.1.6
RTRDT(config)#crypto ipsec transform-set TSET esp-aes esp-sha-hmac
RTRDT(cfg-crypto-trans)#mode transport
RTRDT(cfg-crypto-trans)#exit
RTRDT(config)#crypto ipsec profile RBO1
RTRDT(ipsec-profile)#set transform-set TSET
RTRDT(ipsec-profile)#exit
RTRDT(config)#int tunnel0
RTRDT(config-if)#tunnel mode gre ip
RTRDT(config-if)#tunnel source F0/1
RTRDT(config-if)#tunnel dest 100.0.1.6
RTRDT(config-if)#ip address 10.10.0.1 255.255.255.0
RTRDT(config-if)#tunnel protection ipsec profile RBO1
RTRDT(config-if)#exit
Vérifs et Routage OSPF
RBO1#ping 10.10.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.10.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 48/106/164 ms
RBO1#sh crypto isakmp sa
dst src state conn-id slot status
100.0.0.2 100.0.1.6 QM_IDLE 1 0 ACTIVE
RBO1#sh crypto session
Crypto session current status
Interface: Dialer1
Session status: UP-ACTIVE
Peer: 100.0.0.2 port 500
IKE SA: local 100.0.1.6/500 remote 100.0.0.2/500 Active
IPSEC FLOW: permit 47 host 100.0.1.6 host 100.0.0.2
Active SAs: 2, origin: crypto map
IPSEC FLOW: permit 47 host 100.0.1.6 host 100.0.0.2
Active SAs: 2, origin: crypto map
Je rappelle que QM_IDLE signifie que la phase 1 IKE est terminée, donc plus de négociation, du coup la SA de la phase 1 est « IDLE » et « ACTIVE » Pour OSPF, il est déjà configuré sur RTRDT, on va donc configurer sur RBO1
RBO1(config)#router ospf 1
RBO1(config-router)#network 10.3.0.0 0.0.255.255 area 0
RBO1(config-router)#network 10.10.0.0 0.0.255.255 area 0
RBO1(config-router)#exit
et la ça marche pas. J’aurai pu faire la modif discretos pour mla jouer roxor, mais c’est un point il me semble important. Je n’ai pas pour habitude dans mes exemples de modifier le MTU sur les tunnels IPSEC, car je fait essentiellement du PING donc pas besoin, mais du coup ce sont autant de bons reflexes qu’on ne prend pas. Dans le cas présent, voici les erreurs que j’ai eues:
*Mar 1 02:05:14.023: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on Tunnel0 from EXSTART to DOWN, Neighbor Down: Too many retransmissions
RBO1#
*Mar 1 02:05:17.851: OSPF: Rcv hello from 10.0.0.1 area 0 from Tunnel0 10.10.0.1
*Mar 1 02:05:17.851: OSPF:
OSPF: Nbr 10.0.0.1 10.10.0.1 Tunnel0 is currently ignored
*Mar 1 02:06:14.187: OSPF: Rcv DBD from 10.0.0.1 on Tunnel0 seq 0x1014 opt 0x52 flag 0x7 len 32 mtu 1476 state EXSTART
*Mar 1 02:06:14.191: OSPF: Nbr 10.0.0.1 has larger interface MTU
Donc en gros les mises à jour OSPF ne passaient pas dans le tunnel, et le voisin finissait par banir temporairement le neighbor.
Un petit ip mtu 1460 sur les interfaces tunnels des deux cotés et tout roulait.
Je vous mets en prime 2 petits liens sur le MTU et la commande tcp adjust-mss (importante pour s’assurer que les hosts n’outrepassent pas la limite MTU du routeu, en gros, il fait proxy et modifie le MSS lors des négocations TCP, donc si le MSS baisse, le MTU aussi, logique):
http://www.iphelp.ru/doc/3/Cisco.Press.Comparing.Designing.and.Deploying.VPNs.Apr.2006/1587051796/ch07lev1sec4.html
http://www.cisco.com/en/US/tech/tk827/tk369/technologies_white_paper09186a00800d6979.shtml
petite vérif:
RBO1#un all
All possible debugging has been turned off
RBO1#sh ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is 100.0.1.1 to network 0.0.0.0
100.0.0.0/32 is subnetted, 2 subnets
C 100.0.1.6 is directly connected, Dialer1
C 100.0.1.1 is directly connected, Dialer1
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.10.0.0/24 is directly connected, Tunnel0
C 10.3.0.0/24 is directly connected, Loopback0
O IA 10.2.0.1/32 [110/11114] via 10.10.0.1, 00:09:10, Tunnel0
O IA 10.1.0.1/32 [110/11114] via 10.10.0.1, 00:09:10, Tunnel0
O 10.0.0.1/32 [110/11112] via 10.10.0.1, 00:09:10, Tunnel0
192.168.0.0/30 is subnetted, 3 subnets
O IA 192.168.0.8 [110/11113] via 10.10.0.1, 00:09:10, Tunnel0
O 192.168.0.0 [110/11112] via 10.10.0.1, 00:09:10, Tunnel0
O IA 192.168.0.4 [110/11113] via 10.10.0.1, 00:09:10, Tunnel0
S* 0.0.0.0/0 [1/0] via 100.0.1.1
RBO1#ping 10.1.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 248/313/404 ms
Voilà, j’ai ma table de routage, je peux pinger un autre site via mon VPN, tout est OK. Je vous mets les configs, et je vais reposer un peu mon pauvre PC portable qui commence à chauffer à être à 100% de CPU pendant des heures :p
Configuration PPPoA + Remote VPN
Aller, on arrive à la fin !
Au niveau de PPPoA, la conf est quasi identique coté FAI et client (on aurait pu utilisé la même interface virtual template pour les deux d’ailleurs). Juste quelques notions d’ATM, en gros, les VPI (virtual path identifier) identifient un chemin, et les VCI (Virtual Circuit Identifier) identifient un Circuit au sein d’un VPI. Les switchs ATM commutent un couple VPI/VCI vers un autre VPI/VCI. Puisqu’on va l’utiliser, très rapidement, l’encapsulation AAL5 (ATM Adaptation Layer), ajoute des infos à la trame (longueur et CRC), puis du padding pour obtenir un multiple de 48 (rappelez vous qu’ATM utilise des cellules de 53 octets, 5 pour l’entête et 48 pour les données). Cela permets donc, lorsque la trame est reconsituée, de vérifier son intégrité.
Bref, attaquons la config coté FAI:
BBR1(config)#interface virtual-template 2 !la 1 est pour pppoe
BBR1(config-if)#ip address 100.0.2.1 255.255.255.0
BBR1(config-if)#peer default ip address pool pool_pppoa !le pool d'ip clients
BBR1(config-if)#ppp authentication chap
BBR1(config-if)#exit
BBR1(config)#ip local pool pool_pppoa 100.0.2.2 100.0.2.254
BBR1(config)#interface atm2/0
BBR1(config-if)#no sh
BBR1(config-if)#pvc 10/100 !pvc choisi arbitrairement, voir switch atm topo.net
BBR1(config-if-atm-vc)#encapsulation aal5snap
BBR1(config-if-atm-vc)#protocol ppp virtual-Template 2 !on associe la template pour ppp
BBR1(config-if-atm-vc)#exit
BBR1(config-if)#exit
BBR1(config)#username pppoauser password p4$$w0rd !création d'un autre utilisateur, pour la forme
Au niveau du client:
!RTL1
interface ATM1/0
no ip address
no atm ilmi-keepalive
!
interface ATM1/0.1 point-to-point
no snmp trap link-status
pvc 20/200
encapsulation aal5snap
protocol ppp dialer
dialer pool-member 1
!
!
interface Dialer1
ip address negotiated
encapsulation ppp
dialer pool 1
dialer-group 1
ppp authentication chap
ppp chap hostname pppoauser
ppp chap password 0 p4$$w0rd
!
Par contre la configuration ci dessus, malgré qu’elle me semble bonne, ne fonctionne pas, et après plusieurs tests, je n’ai pas réeussi à faire fonctionner pppoa sur dynamips, peux être un problème de version d’IOS, je me renseigne sur ça, et sinon tanpis pour la partie pppoa…
Pour continuer l’article, je vais utiliser ces configs :
!RTL1
interface ATM1/0
ip address 100.0.2.2 255.255.255.0
pvc 20/200
encapsulation aal5snap
!
!BBR1
interface ATM2/0
ip address 100.0.2.1 255.255.255.0
pvc 10/100
encapsulation aal5snap
!
Un petit mot rapidement, j’ai mis la configuration du PVC directement sur l’interface ATM, vous verrez souvent que la config des PVC est appliquée sur une sous interface ATM, cela permets d’avoir plusieurs IP et plusieurs circuits, moi je n’ai qu’une IP et qu’un circuit, donc pas besoin de sous interfaces. A noter aussi que l’on doit obligatoirement spécifier les VPI/VCI pour que cela fonctionne.
Au niveau de la config du routeur RTL1, il manque le default-router dans le pool DHCP (un petit oubli). Pensez à le rajouter:
!
ip dhcp pool private_lan
default-router 192.168.0.254
!
Ne pas oublier le nat et la route par défaut non plus:
RTL1(config-if)#int atm1/0
RTL1(config-if)#ip nat outside
RTL1(config-if)#int f0/0
RTL1(config-if)#ip nat inside
RTL1(config-if)#exit
RTL1(config)#access-list 1 permit 192.168.0.0 0.0.0.255
RTL1(config)#ip nat inside source list 1 int atm1/0 overload
Aller, on passe au Remote VPN. Pour ce faire, on vas utiliser des interfaces Virtual Template et des profiles ISAKMP/IPSEC, d’une part parce que la gestion des clients en est facilitée, et d’autre part, il semble qu’il ne soit pas possible d’avoir une même crypto map pour du remote VPN et du site to site (même si on peut avoir plusieurs entrées via les séquences pour une même crypto map), et vu qu’on ne peux avoir qu’une crypto map par interface, on aurait pas pu avoir les 2 sur BBR1, mais je n’ai pas testé cela.
Première chose, ne pas oublier la liste AAA avec les profiles VPN (c’était l’objet du dernier contest).
Donc dans l’ordre, au niveau du routeur qui va recevoir les connexions VPN
- Configurer la liste pour l’authorization isakmp (password group, pool,…)
- Configurer la liste pour l’authentication (optionnel, mais on va mettre du XAUTH, penser à créer un user local)
- Créer le groupe VPN (on choisira le nom remote_users, on crééra ausis le pool pool_remote_vpn), et un utilisateur
- Créer l’ACL pour le split tunneling (on veux que le VPN serve uniquement pour accéder au réseau 10.0.0.0/8 – réseau de l’entreprise).
- Créer transform set et profile IPSEC
- Créer profile ISAKMP pour le groupe VPN
- Créer une policy ISAKMP en accord avec celle disponible sur le client VPN (on avait pas créé de policy pour le site to site, les paramètres par défaut entre les routeurs étant compatibles).
- Créer une interface tunnel et y appliquer le profile IPSEC
!aaa
RTRDT(config)#aaa new-model
RTRDT(config)#aaa authorization network remote_vpn local
RTRDT(config)#aaa authentication login remote_vpn local
!IPSEC transform set et profile
RTRDT(config)#crypto ipsec transform-set rvpn_tset esp-aes esp-sha-hmac
RTRDT(cfg-crypto-trans)#exit
RTRDT(config)#crypto ipsec profile rvpn_ipsec_profile
RTRDT(ipsec-profile)#set transform-set rvpn_tset
RTRDT(ipsec-profile)#set isakmp-profile rvpn_profile ! optionnel
!group VPN
RTRDT(config)#crypto isakmp client configuration group remote_users
RTRDT(config-isakmp-group)#key vpnp4$$
RTRDT(config-isakmp-group)#pool remote_vpn_pool
RTRDT(config-isakmp-group)#domain corp.lan
RTRDT(config-isakmp-group)#acl splitacl
RTRDT(config-isakmp-group)#netmask 255.255.255.0 !masque associé au pool
RTRDT(config-isakmp-group)#exit
!ACL
RTRDT(config)#ip access-list extended splitacl !utiliser ACL étendue, standard ne marche pas
RTRDT(config-std-nacl)#permit ip 10.0.0.0 0.255.255.255 any
RTRDT(config-std-nacl)#exit
!user
RTRDT(config)#username remote_user password cisco
!pool
RTRDT(config)#ip local pool remote_vpn_pool 10.11.0.1 10.11.0.254
!Profile ISAKMP
RTRDT(config)#crypto isakmp profile rvpn_profile
% A profile is deemed incomplete until it has match identity statements
RTRDT(conf-isa-prof)#match identity group remote_users
RTRDT(conf-isa-prof)#client configuration address respond
RTRDT(conf-isa-prof)#virtual-template 1
RTRDT(conf-isa-prof)#client authentication list remote_vpn
RTRDT(conf-isa-prof)#isakmp authorization list remote_vpn
RTRDT(conf-isa-prof)#exit
!policy isakmp, correspond à une policy du client VPN
RTRDT(config)#crypto isakmp policy 1
RTRDT(config-isakmp)#auth pre-share
RTRDT(config-isakmp)#hash sha
RTRDT(config-isakmp)#encr aes
RTRDT(config-isakmp)#group 2
RTRDT(config-isakmp)#exit
!création du template de tunnel
RTRDT(config)#interface virtual-template 1 type tunnel
RTRDT(config-if)#tunnel mode ipsec ipv4
RTRDT(config-if)#tunnel protection ipsec profile rvpn_ipsec_profile
RTRDT(config-if)#ip mtu 1460
RTRDT(config-if)#ip unnumbered F0/1 !l'oubli de cette commande m'a valu 2h de deboggage...
RTRDT(config-if)#tunnel source F0/1 !mettre l'interface qui reçoit les connexions
Configuration du client:
configuration client
Un ping vers la loopback du routeur RTRDT (10.0.0.1) doit aboutir. Pour l’instant on a pas redistribuer les routes des clients VPNs dans le backbone, donc ça ne va pas marcher vers les autres routeurs.
Un petit avant après de la table de routage du PC:
C:\Documents and Settings\bastien>route print
===========================================================================
===========================================================================
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.0.254 192.168.0.1 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 20
192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.255 255.255.255.255 192.168.0.1 192.168.0.1 20
224.0.0.0 240.0.0.0 192.168.0.1 192.168.0.1 20
255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1 1
255.255.255.255 255.255.255.255 192.168.0.1 3 1
Passerelle par défaut : 192.168.0.254
===========================================================================
#après
C:\Documents and Settings\bastien>route print
===========================================================================
===========================================================================
===========================================================================
Itinéraires actifs :
Destination réseau Masque réseau Adr. passerelle Adr. interface Métrique
0.0.0.0 0.0.0.0 192.168.0.254 192.168.0.1 20 Passerelle par défaut pas par le VPN
10.0.0.0 255.0.0.0 10.11.0.4 10.11.0.4 1 Uniqument 10.0.0.0 (ACL Split tunneling)
10.11.0.0 255.255.255.0 10.11.0.4 10.11.0.4 20 Commande netmask dans le groupe isakmp
10.11.0.4 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.11.0.4 10.11.0.4 20
100.0.0.2 255.255.255.255 192.168.0.254 192.168.0.1 1
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.0.0 255.255.255.0 192.168.0.1 192.168.0.1 20
192.168.0.1 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.0.254 255.255.255.255 192.168.0.1 192.168.0.1 1
192.168.0.255 255.255.255.255 192.168.0.1 192.168.0.1 20
224.0.0.0 240.0.0.0 10.11.0.4 10.11.0.4 20
224.0.0.0 240.0.0.0 192.168.0.1 192.168.0.1 20
255.255.255.255 255.255.255.255 10.11.0.4 3 1
255.255.255.255 255.255.255.255 10.11.0.4 10.11.0.4 1
255.255.255.255 255.255.255.255 192.168.0.1 192.168.0.1 1
Passerelle par défaut : 192.168.0.254
===========================================================================
Vérifications:
RTRDT#sh ip route | i 10.11.0
S 10.11.0.4/32 [1/0] via 0.0.0.0, Virtual-Access2 !Route statique vers le client
RTRDT#sh crypto ipsec sa | i peer
current_peer 100.0.1.6 port 500 !site to site
current_peer 100.0.2.2 port 3550 !mon client remote vpn
RTRDT#sh crypto isakmp sa
dst src state conn-id slot status
100.0.1.6 100.0.0.2 QM_IDLE 1 0 ACTIVE
100.0.0.2 100.0.2.2 QM_IDLE 2 0 ACTIVE
RTRDT#sh crypto ipsec sa interface virtual-access 2 | i settings
in use settings ={Tunnel UDP-Encaps, } !utilisation du nat transparency
Bon on y est presque, il faut redistribuer ces routes statiques au sein du backbone.
Ici, un redistribute static subnets dans OSPF fait que les routes sont de types external E2, et ne seraient donc pas redistribuées dans BGP (voir configuration BGP). De plus, cela redistriburait toutes les routes statiques.
On va donc modifier la configuration sur PE1 (et accessoirement sur les PE2 et 3 pour être logique), de la sorte:
PE1#sh ip route vrf VRF1 | i 10.11.0
O E2 10.11.0.2/32 [110/20] via 192.168.0.2, 00:02:00, FastEthernet0/1
PE1(config)#router bgp 1000
PE1(config-router)# address-family ipv4 vrf VRF1
PE1(config-router-af)#redistribute OSPF 1 vrf VRF1 match internal external
PE1(config-router-af)#exit
PE1(config-router)#exit
petite vérification
RMO1#sh ip route | i 10.11.0
O E2 10.11.0.3/32 [110/20] via 192.168.0.5, 00:00:34, FastEthernet0/0
Et du PC connecté en VPN, je peux pinger les réseaux distants (exemple la loopback RMO1 – 10.1.0.1)
Conclusion
Voilà, bravo à ceux qui ont suivi l’article en entier, il y a sans doute des points qui pourraient être améliorés, mais ici le but était plus de manipuler le plus de technologies possibles, et bien que cela s’intitule ISCW Lab, beaucoup de notions ne sont pas à savoir pour ISCW, comme les routes-map, le routage BGP, la configuration PPPoE coté FAI, …
Configuration finales: configs_finales.tar
Je crois que c’est sans conteste l’article le plus long que j’ai fait à ce jour, aussi n’hésitez pas à laisser vos commentaires.
Si certains ont réussi à faire du PPPoA sur dynamips, je suis preneur
