Configuration avancée
On met ici en œuvre la configuration avancée. Cette configuration réunit les trois configurations simples et comporte en plus une liaison iBGP établie en parallèle de la liaison OSPF.
Le réseau du client comprend le routeur R2, R3 et le firewall Stormshield Network. Le routeur R1 est un voisin BGP externe. Ce réseau représente un cas réaliste d’architecture, à l’exception du fait que tous les routeurs sont connectés physiquement par le biais d’un LAN unique.
On met en œuvre une politique standard de filtrage pour :
- N’annoncer que les réseaux publics en BGP vers l’extérieur,
- Ne pas propager de réseaux internes ou martians dans BGP interne,
- Tagguer une des routes apprises en eBGP avec une local-preference de 250 ; cette mesure est généralement mise en œuvre pour contrôler le partage de charge entre plusieurs voisins eBGP,
- N’annoncer dans OSPF qu’une route par défaut,
- N’annoncer dans RIP qu’une route par défaut.
Les réseaux annoncés par R2 et R3 le sont respectivement via BGP et RIP. L’utilisation d’OSPF pour annoncer la route par défaut n’a qu’une utilité pédagogique.
Configuration BIRD
Ci-dessous le fichier de configuration équivalent en BIRD :
router id 192.168.97.219; function is_locormartians() prefix set martians; { martians = [ 169.254.0.0/16+, 172.16.0.0/12+, 192.168.0.0/16+,10.0.0.0/8+, 224.0.0.0/4+, 240.0.0.0/4+ ]; # default if net.ip = 0.0.0.0 then return true; # LIR not authorized if (net.len < 8) || (net.len > 24) then return true; # martians if net ~ martians then return true; # local if net = 100.100.100.100/32 then return true; return false; } filter out_eBGP { if net ~ [ 172.16.0.0/24, 3.3.3.3/32, 1.1.1.0/24 ] then accept; else reject; } filter out_iBGP { if ( is_locormartians() ) then reject; else accept; } filter lp_tag_in { if net = 2.2.4.0/24 then { bgp_local_pref = 250; accept; } else accept; } filter default_ok { if net = 0.0.0.0/0 then { accept; } else reject; } sns_log all; # default is "no extra log" # This pseudo-protocol watches all interface up/down events. protocol device { scan time 10; # Scan interfaces every 10 seconds } # The direct protocol automatically generates device routes to # all network interfaces. protocol direct { interface "em3"; ipv4; } # This pseudo-protocol performs synchronization between BIRD's routing # tables and the kernel. protocol kernel { learn; # Learn all alien routes from the kernel persist; # Don't remove routes on bird shutdown scan time 20; # Scan kernel routing table every 20 seconds ipv4 { export all; preference 254; # Protect existing routes }; } protocol rip MyRIP { # You can also use an explicit name debug all; interface "em4" { mode multicast; authentication none; }; ipv4 { import all; export filter default_ok; }; } protocol ospf MyOSPF { area 0.0.0.0 { stub no; interface "em4" { type broadcast; }; }; ipv4 { export filter default_ok; import all; }; } protocol bgp router1 { debug all; description "My 1st BGP uplink"; local as 65065; neighbor 100.100.100.100 as 65001; source address 200.200.200.200; multihop 5; hold time 180; keepalive time 60; ipv4{ export filter out_eBGP; import filter lp_tag_in; }; } protocol bgp router2 { description "My local BGP neighbor"; local as 65065; neighbor 192.168.97.102 as 65065; keepalive time 60; ipv4 { next hop self; export filter out_iBGP; import all; }; }
NOTE
Il est conseillé de positionner le paramètre "priority 0" dans la section interface de la configuration du noeud OSPF afin de désactiver la participation du firewall aux élections pour les rôles de Designated Router / Backup Designated Router.
Autoriser les protocoles RIP, BGP et OSPF dans la politique de filtrage
En vous référant aux exemples de politique de filtrage présentés dans les configuration simples RIP, BGP et OSPF, ajoutez des règles de filtrage pour autoriser les flux de routage RIP, BGP et OSPF vers et depuis le firewall.
Vérifier le bon fonctionnement du routage dynamique
Table de routage du firewall Stormshield Network
bird> show route 0.0.0.0/0 via 192.168.97.1 on em4 [kernel1 14:37:15] * (254) 100.100.100.100/32 via 192.168.97.101 on em4 [kernel1 14:37:15] * (254) 3.3.3.3/32 via 192.168.97.103 on em4 [MyRIP 14:37:06] * (120/2) 192.168.97.0/24 dev em4 [MyOSPF 14:01:33] * I (150/10) [192.168.97.102] via 192.168.97.102 on em4 [router2 14:01:17] (100/10) [i] 1.1.1.0/24 via 192.168.97.102 on em4 [MyOSPF 14:01:36] * E2 (150/10/10000) [192.168.97.102] via 192.168.97.102 on em4 [router2 14:01:17] (100/10) [i] 1.1.3.0/24 via 192.168.97.102 on em4 [MyOSPF 14:01:36] * E2 (150/10/10000) [192.168.97.102] via 192.168.97.102 on em4 [router2 14:01:17] (100/10) [i] 2.2.2.0/24 via 192.168.97.101 on em4 [router1 13:54:12 from 100.100.100.100] * (100/?) [AS65001i] 2.2.4.0/24 via 192.168.97.101 on em4 [router1 14:01:17 from 100.100.100.100] * (100/?) [AS65001i] 172.16.0.254/32 dev lo0 [kernel1 14:37:15] * (254) 192.168.97.219/32 dev lo0 [kernel1 14:37:15] * (254) 172.16.0.0/24 dev em3 [direct1 13:54:11] * (240) 10.200.45.254/32 dev lo0 [kernel1 14:37:15] * (254)
Afin de pouvoir vérifier la local-preference sur la route 2.2.4.0/24 on affiche le détail des routes de l’instance du protocole router1 :
bird> show route protocol router1 all
2.2.2.0/24 via 192.168.97.101 on em4 [router1 13:54:12 from 100.100.100.100] * (100/?) [AS65001i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 65001
BGP.next_hop: 100.100.100.100
BGP.local_pref: 100
2.2.4.0/24 via 192.168.97.101 on em4 [router1 14:01:17 from 100.100.100.100] * (100/?) [AS65001i]
Type: BGP unicast univ
BGP.origin: IGP
BGP.as_path: 65001
BGP.next_hop: 100.100.100.100
BGP.local_pref: 250
Router R3 – show IP route
On constate ici que la route par défaut est également bien annoncée :
@router3:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF, I - ISIS, B - BGP, > - selected route, * - FIB route
R>* 0.0.0.0/0 [120/2] via 192.168.97.1, eth0, 00:06:15
C>* 1.1.8.0/24 is directly connected, lo
C>* 1.1.9.0/24 is directly connected, lo
S>* 3.3.3.3/32 [1/0] is directly connected, Null0, bh
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.97.0/24 is directly connected, eth0
@router3:~$
Dans le cas où ce trafic doit être routé symétriquement - par exemple en cas de NAT - il est nécessaire d'adapter la configuration de BIRD afin d'annoncer le firewall en tant que next-hop. La modification peut se faire dans le filtre « default_ok » qui sert à annoncer la route par défaut à R3 via RIP ainsi qu'à R2 via OSPF :
filter default_ok { if net = 0.0.0.0/0 then { dest = RTD_UNREACHABLE; # annonce le firewall comme next-hop pour cette route accept; } }
Pour imposer une autre passerelle que le firewall lui-même, il faut utiliser la directive :
gw = <ip>;
Router R2 – show IP route
@router2:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
O>* 0.0.0.0/0 [110/10000] via 192.168.97.1, eth0, 22:26:17
C>* 1.1.1.0/24 is directly connected, lo
C>* 1.1.3.0/24 is directly connected, lo
B>* 2.2.2.0/24 [200/1] via 100.100.100.100 (recursive via 192.168.97.1), 00:02:04
B>* 2.2.4.0/24 [200/1] via 100.100.100.100 (recursive via 192.168.97.1), 00:02:04
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.97.0/24 is directly connected, eth0
@router2:~$
Router R1 – show IP route
@router1:~$ show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
S>* 0.0.0.0/0 [1/0] via 192.168.97.1, eth0
B>* 1.1.1.0/24 [20/0] via 200.200.200.200 (recursive via 192.168.97.219), 00:00:29
C>* 2.2.2.0/24 is directly connected, lo
C>* 2.2.4.0/24 is directly connected, lo
B>* 3.3.3.3/32 [20/0] via 200.200.200.200 (recursive via 192.168.97.219), 00:00:08
C>* 100.100.100.100/32 is directly connected, lo
C>* 127.0.0.0/8 is directly connected, lo
B>* 172.16.0.0/24 [20/0] via 200.200.200.200 (recursive via 192.168.97.219), 00:00:29
C>* 192.168.97.0/24 is directly connected, eth0
S>* 200.200.200.200/32 [1/0] via 192.168.97.219, eth0
@router1:~$
Cas d'une configuration en haute disponibilité (cluster)
En cas d'utilisation du protocole de routage dynamique BGP sur un cluster de firewalls SNS, et pour permettre au voisin BGP de fermer proprement une session BGP en cas de bascule au sein du cluster, il est utile de définir une instance BFD dans la configuration BIRD :
protocol bfd mybfdsession {
neighbor myneighborip;
}
Dans cet exemple :
protocol bfd mybfdsession {
neighbor 100.100.100.100;
}
Et d'appeler cette instance dans la configuration BGP de la manière suivante :
protocol bgp MyBGP {
…
bfd graceful;
connect retry time 5;
…
}