[GNS3] Topologie "Hub-and-Spoke" + routage inter-VPN
Suite à une question dans ce forum
http://www.developpez.net/forums/d12...s-n-sites-vpn/
j'avais monté un petit lab sous GNS3 que je trouve intéressant de partager.
Voici la topologie.
Un routeur Central connecte 2 sites distants Site 1 et Site 2 en encryptant les flux dans des VPN. Le routeur Interco est destiné à simuler un "nuage de transit IP", comme si c'était un opérateur qui connectait tous les sites.
La question était de savoir s'il est possible de router les flux entre les sites distants sans avoir à créer un nouveau VPN entre Site 1 et Site 2.
Dans ce lab, la réponse est oui...
Voici la config du routeur Central. J'ai attaché les fichiers de config de tous les routeurs pour ceux qui voudraient rejouer le scenario (en revanche, il vous faut une image crypto à intégrer dans GNS3).
Le point-clé de la configuration du routeur Central, c'est la façon dont le "crypto-engine" permet de définir le traffic éligible pour l'encryption.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
L'access-list 110 associé au crypto-peer 2.2.2.1 encrypte les flux
192.168.200.0/24 -> 192.168.3.0/24 (Central vers Site 2)
192.168.254.0/24 -> 192.168.3.0/24 (Site 1 vers Site 2)
et l'access-list associé au crypto-peer 3.3.3.1 encrypte les flux
192.168.200.0/24 -> 192.168.254.0/24 (Central vers Site 1)
192.168.3.0/24 -> 192.168.254.0/24 (Site 2 vers Site 1).
Quelques displays depuis le ThinkPad (ifconfig tap0, table de routage et ping sur l'adresse de Site 2) :
Donc effectivement, le routage inter-VPN fonctionne plutôt bien ici.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30root@steph-ThinkPad-T400:/# ifconfig tap0 tap0 Link encap:Ethernet HWaddr 9e:d4:c1:f6:b6:75 inet addr:192.168.254.10 Bcast:192.168.254.255 Mask:255.255.255.0 inet6 addr: fe80::9cd4:c1ff:fef6:b675/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:998 errors:0 dropped:182 overruns:0 frame:0 TX packets:641 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:500 RX bytes:165918 (165.9 KB) TX bytes:75242 (75.2 KB) root@steph-ThinkPad-T400:/# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.254.254 0.0.0.0 UG 0 0 0 tap0 192.168.254.0 * 255.255.255.0 U 0 0 0 tap0 root@steph-ThinkPad-T400:/# ping 192.168.3.254 PING 192.168.3.254 (192.168.3.254) 56(84) bytes of data. 64 bytes from 192.168.3.254: icmp_req=1 ttl=253 time=49.8 ms 64 bytes from 192.168.3.254: icmp_req=2 ttl=253 time=52.2 ms 64 bytes from 192.168.3.254: icmp_req=3 ttl=253 time=243 ms 64 bytes from 192.168.3.254: icmp_req=4 ttl=253 time=55.7 ms 64 bytes from 192.168.3.254: icmp_req=5 ttl=253 time=58.5 ms 64 bytes from 192.168.3.254: icmp_req=6 ttl=253 time=53.0 ms ^C --- 192.168.3.254 ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5005ms rtt min/avg/max/mdev = 49.822/85.554/243.917/70.875 ms
En revanche, je pense que beaucoup d'équipements vendus comme étant des routeurs centraux de topologies "Hub-and-Spoke" ne permettront pas de faire parler des "Spokes" entre eux parce que les VPNs définis au niveau du routeur central devront impérativement avoir un réseau/subnet local (directement connecté) comme extrémité du VPN. Je doute qu'il soit possible de contourner cette limitation par une "galipette" d'adressage et de mask.
D'autre part, il est à noter le routage inter-VPN est forcément intensif pour la CPU. En effet, avant d'être routé vers un autre VPN, le paquet IP encrypté doit être décrypté, puis routé, puis enfin passé au crypto-engine pour être de nouveau encrypté sur le "VPN destination". D'ailleurs, les commandes "no ip route-cache" configurées sur les interfaces qui cryptent sont destinées à désactiver le fast-switching (pour forcer les paquets à être "process-switchés"). Sans cette commande, l'encryption ne peut pas s'opérer. A noter que les très gros routeurs du marché (pas Cisco uniquement) proposent des cartes d'encryption dédiées pour le traitement de ces paquets, ce qui permet de décharger la CPU principale et d'offrir un chemin de switching hardware entre les différentes interfaces.
Il est facile de mettre en évidence le routage inter-VPN sur le routeur Central :
On voit bien que chaque ICMP passe au travers de la FIB (Forwarding Information Base), qui est une "lookup table" purement IP et n'a rien à voir avec le crypto-engine. En d'autre termes, la fonction de routage ne voit que de "simples" paquets IP, ce qui est fait avant et après est du ressort des crypto-maps.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Concernant notre topologie, si le routeur Central ne peut pas faire de routage inter-VPN, la seule solution consiste à créer un VPN entre Site 1 et Site 2.
Steph
Répondre avec citation
Partager