Collecte 4G/Starlink

Un réseau mobile et satellite ?

Malheureusement, petit opérateur oblige, nous n'avons pas de backbone mobile et de satellites (dommage...). Mais avouez que c'est quand même intéressant de proposer aux clients, une formule fibre + mobile/satellite ?

Un client qui prendra cette option ne se verra jamais coupé (à 99,999% 😃).

Mais comment va-t-on faire ?

Tout simplement ! On va payer des SIM d'Orange, Bouygues ou des Starlink de SpaceX.

Deux possibilités :

• Nous sommes des parasites qui ne servent à rien mis à part rajouter des intermédiaires entre le client et la société qui fait vraiment tourner le physique

Le trafic (Data et Voix) du client passent par le réseau SpaceX et sort sur Internet sans jamais passer par le nôtre.

• Nous nous soucions de nos clients et dans ce cas :

On monte un tunnel (j'ai mis un IPsec mais ca peut être aussi un wireguard, L2TP, etc) entre le routeur accueillant la liaison Starlink et notre backbone. On peut ainsi router le trafic (que ce soit VOIP ou DATA).

Bien évidement, je ne souhaite pas arnaquer mes clients et donc j'ai choisi la seconde solution.

DMVPN

Encore un protocole bizarre ?

Mais non, le DMVPN (Dynamic Multipoint Virtual Private Network), défini dans https://datatracker.ietf.org/doc/html/draft-detienne-dmvpn-00 va permettre de monter dynamiquement des VPN multipoint.

Mouais, et c'est quoi l'utilité là ?

Imaginons, nos routeurs mobiles et satellites comme des spokes et notre serveur, hébergé dans notre backbone, notre HUB :

Spoke1 et Spoke2 vont pouvoir monter un tunnel avec Hub1. Mais c'est quoi l'intérêt ?

On va monter un tunnel routé ! Un tunnel GRE protégé par IPsec IKEv2. Les tunnels GRE portent une IP (interco avec HUB1).

Ainsi, on va pouvoir router le trafic que l'on souhaite sur ce tunnel (en l'occurrence, le trafic VOIP).

Et tout ça de façon multipoint ! HUB1 n'aura qu'une seule interface Tunnel pour l'ensemble des spokes ! Trop bien nan ?

On pourrait très bien faire du routage dynamique pour que nos Spokes montent automatiquement un process BGP avec le HUB !

Je compare le DMVPN de Cisco à du SDWAN. Le principe du SDWAN est de faire un IPsec routé (interco IP) et mettre du BGP !

Configuration Hub/Spoke

Le DMVPN est composé de trois protocoles : mGRE / IPsec / NHRP.

Je vous explique le principe du NHRP (Next-Hop Resolution Protocol) :

Comment HUB1 pourrait savoir les IPs publiques des Spokes ?

NHRP fonctionne à peu comme l'ARP sauf que l'ARP map une IP à une adresse MAC. Le NHRP va mapper l'adresse IP du tunnel à l'adresse IP NBMA (IP Publique de la liaison).

Il faut savoir qu'il existe plusieurs phases dans le DMVPN : la 1 et la 2 sont obsolètes. Seule la 3 est, d'après la documentation, viable.

Que va-t-on choisir ? La réponse semble évidente : la phase 1 !

Et non pas de connerie. Je n'ai pas besoin des fonctionnalités des phases 3 (le but est de monter des tunnel dynamiquement entre Spoke, super l'utilité dans mon cas !).

DMVPN n'a pas du tout été prévu dans le cadre que je l'utilise mais honnêtement faut bien essayer des fois 😄

Allez on s'y met ! Et on va protéger le tunnel GRE par de l'IKEv2 !

On a pas beaucoup de routeur étant donné la taille de notre opérateur, on va donner utiliser les LNS (hé bah quoi ? Ce sont des routeurs nan ?)

crypto ikev2 proposal IKEv2_PROPOSAL
 encryption aes-cbc-256
 integrity sha256
 group 20
crypto ikev2 policy IKEv2_POLICY
 proposal IKEv2_PROPOSAL
crypto ikev2 keyring IKEv2_KEYRING
 peer HUB_PEER
  address 0.0.0.0 0.0.0.0
  pre-shared-key local TEST
  pre-shared-key remote TEST
 !
crypto ikev2 profile IKEv2_PROFILE
 match identity remote address 0.0.0.0
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEv2_KEYRING
 lifetime 3600
crypto ipsec transform-set PROFILE-TRANSFORM esp-aes 256 esp-sha256-hmac
  mode tunnel
!
crypto ipsec profile IPSEC_PROFILE
 set transform-set PROFILE-TRANSFORM
 set ikev2-profile IKEv2_PROFILE

Première étape : l'IKEv2 ! On crée une phase 1 avec les algo voulu (aes256 et sha256 et diffie helman 20 ). On met cette proposition dans une policy et on monte le peer IPsec.

Pourquoi avoir mis 0.0.0.0 0.0.0.0 ? Car c'est un serveur IPsec ! On ne connait pas les IPs des 4G/Starlink donc on met 0.0.0.0. Toutes les IPs pourront essayer de monter un peer IPsec avec notre LNS. La PSK est TEST (super mot de passe Nathan ! Je ne te félicite pas).

Allez bientôt fini ! On lie ce "keyring" à notre profile et on indique le keepalive (1h dans notre cas). Ensuite, les algo de la phase 2 (sha256 et aes256). Et on lie ça à un profil ipsec !

Bordel que c'est long l'IPsec sur un cisco en CLI. Au moins sur forti, c'est du clic clic 😄

Plus qu'à créer notre interface tunnel :

LNS1#sh run int tu1
interface Tunnel1
 vrf forwarding VOIP
 ip address 169.254.0.1 255.255.0.0
 no ip redirects
 ip nhrp authentication NATHAN
 ip nhrp network-id 1
 tunnel source Loopback55
 tunnel mode gre multipoint
 tunnel key 510
 tunnel protection ipsec profile IPSEC_PROFILE
end

La VRF c'est pour plus tard ! Mis à part ça, rien de compliqué à notre niveau !

Les commandes NHRP permettent de mettre un mot de passe NATHAN et on un network-id (pas nécessaire les deux). On met le tunnel en mode multipoint et on y associe une clé (pas nécessaire non plus) et la protection IPsec. Et c'est tout !

Pour les plus attentifs, on fonctionne en mode un HUB donc sur LNS1. Si LNS1 tombe, alors on perd le tunnel ! C'est pas normal mais c'est voulu. Il y aura un épisode sur des tests de bascule et on corrigera les SPOF (single point of failure). La plupart du temps, on ne fait jamais tout bien au début et c'est intéressant de repasser sur de la configuration et essayer d'améliorer le truc !

Côté spoke :

crypto ikev2 proposal IKEv2_PROPOSAL
 encryption aes-cbc-256
 integrity sha256
 group 20
crypto ikev2 policy IKEv2_POLICY
 proposal IKEv2_PROPOSAL
crypto ikev2 keyring IKEv2_KEYRING
 peer SPOKE_PEER
  address 109.205.66.127
  pre-shared-key local TEST
  pre-shared-key remote TEST
 !
crypto ikev2 profile IKEv2_PROFILE
 match identity remote address 109.205.66.127 255.255.255.255
 authentication remote pre-share
 authentication local pre-share
 keyring local IKEv2_KEYRING
 lifetime 3600
crypto ipsec transform-set PROFILE-TRANSFORM esp-aes 256 esp-sha256-hmac
  mode tunnel
crypto ipsec profile IPSEC_PROFILE
 set transform-set PROFILE-TRANSFORM
 set ikev2-profile IKEv2_PROFILE

Aucun changement sauf pour le keyring ! En effet, on renseigne l'IP du serveur en l'occurrence 109.205.66.127.

Et sur l'interface tunnel :

4G_3#sh run int tu1
interface Tunnel1
 vrf forwarding VOIP
 ip address 169.254.0.3 255.255.0.0
 ip nhrp authentication NATHAN
 ip nhrp map 169.254.0.1 109.205.66.127
 ip nhrp map multicast 109.205.66.127
 ip nhrp network-id 1
 ip nhrp nhs 169.254.0.1
 tunnel source GigabitEthernet1
 tunnel destination 109.205.66.127
 tunnel key 510
 tunnel protection ipsec profile IPSEC_PROFILE
end

Plutôt simple n'est ce pas ? On map l'IP privée du HUB sur son IP Publique.

4G_3#ping vrf VOIP 169.254.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 169.254.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/29 ms

Nickel ! Ca à l'air de bien fonctionner ?

VRF VOIP

Un gros projet celui là !

Sans rentrer dans les détails (bon sang ce que je suis nul en téléphonie !), je vais essayer de monter un Centrex pour que les téléphones s'enregistrent et se provisionnent dessus.

Comme d'habitude, il faut penser au début avant de faire des dingueries !

Je veux qu'un client ait un subnet dédié à sa téléphonie dans son LAN et que ce subnet soit routé dans mon backbone. Par contre, pas envie que ces subnets soient dans le routage global (routage Internet) !

On va donc utiliser le principe des VRF (virtual router forwarding). Une VRF va permettre de virtualiser un niveau 3 donc un routeur.

C'est ce qui se passe lors de la création d'un L3VPN MPLS pour un client. En jargon opérateur c'est quoi ? Une simple VRF 😄

Je vais donc isoler le trafic VOIP des autres trafics style Internet, hosting. Cette VRF sera relié à mon Centrex et ce dernier aura une patte dans le routage globale.

Allez configurons tout ça de façon dynamique bien sûr !

Côté HUB :

vrf definition VOIP
 rd 64555:64555
 route-target import 64555:64555
 !
 address-family ipv4
  route-target export 64555:64555
  route-target import 64555:64555
 exit-address-family
 !
 address-family ipv6
 exit-address-family
!
ip prefix-list PL_VOIP_CUSTOMER seq 5 permit 172.16.0.0/16 ge 24 le 24
!
route-map RM_VOIP_CUSTOMER permit 10
 match ip address prefix-list PL_VOIP_CUSTOMER
!
router bgp 64555
 bgp listen range 169.254.0.0/16 peer-group 4G_STARLINK
 address-family ipv4 vrf VOIP
  neighbor 4G_STARLINK peer-group
  neighbor 4G_STARLINK remote-as 64666
  neighbor 4G_STARLINK route-map RM_VOIP_CUSTOMER in
 exit-address-family

Normalement, la seule chose que je doit expliquer c'est l'histoire du RD et du route-target dans la VRF VOIP. Si vous ne comprenez pas la prefix liste et la route map, je vous invite à vous référer à l'épisode de la création de l'underlay de la fabric !

Le principe d'une VRF c'est d'avoir une table de routage propre sur les routeurs. Et comment ces derniers vont savoir quelles routes vont dans quelles VRF ?

Avec le principe du RD et du RT. Ils sont propres à une VRF. Le routeur va avoir une route avec 64555:64555:172.16.1.0/24 par exemple.

Grâce à 64555:64555, il va savoir que la route doit être inscrite dans la table de routage de la VRF VOIP !

Le RD et le RT peut être différent mais généralement, on met le même ! (Sauf moi pour la propagation des VLANs dans la fabric VXLAN car je voulais en un coup d'oeil savoir la VNI, le VLAN et l'AS).

Et côté spoke ?

vrf definition VOIP
 rd 64666:64666
 route-target import 64666:64666
 !
 address-family ipv4
  route-target export 64666:64666
  route-target import 64666:64666
 exit-address-family
!
!
interface GigabitEthernet2
 vrf forwarding VOIP
 ip address 172.16.1.254 255.255.255.0
!
router bgp 64666
 !
 address-family ipv4 vrf VOIP
  redistribute connected
  neighbor 169.254.0.1 remote-as 64555
  neighbor 169.254.0.1 activate
 exit-address-family
!

Rien de bien compliqué !

Allez on regarde côté HUB si le subnet des téléphones est remonté (172.16.1.0/24 pour ce client) :

LNS1#sh ip route vrf VOIP

      169.254.0.0/16 is variably subnetted, 2 subnets, 2 masks
C        169.254.0.0/16 is directly connected, Tunnel1
L        169.254.0.1/32 is directly connected, Tunnel1
      172.16.0.0/24 is subnetted, 1 subnets
B        172.16.1.0 [20/0] via 169.254.0.3, 00:06:51

Easy ?

On a donc réussi à router le trafic VOIP dans notre backbone ! Trop la classe nan ?

Un petit ping ?

LNS1#ping vrf VOIP 172.16.1.254
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 19/20/23 ms

Bah là, on voit clairement que c'est chiffré !

Axes d'améliorations

Je suis bien loin d'être un génie (quoique 😏😏) donc forcément il y a des points à améliorer. Par contre, je sais pas vous, mais je trouve ça trop stylé d'avoir trouvé une utilité au subnet 169.254.x.x/16 ! Normalement, quand on en croise, on sait qu'on a merdé dans la configuration de notre DHCP...

Je ne souhaite pas router le trafic DATA, autant qu'il passe par l'opérateur tiers !

La partie VOIP est opérationnel mais il y a un gros SPOF. Le HUB !

Y'en a qu'un ! C'est pas dingue. On a trouvé un sujet pour un autre épisode mais pas maintenant !

Aussi, le fait de devoir mettre une IP sur les tunnels GRE des Spokes. En IKEv2, on peut faire comme un DHCP ! A voir pour le futur.

Allez place au prochain épisode, le début de l'automatisation de la Fabric VXLAN. J'en ai déjà eu marre de propager des VLANs x)

Je termine sur un petit mot de fin : Boruto pré elipse est 10x plus fort que Naruto Rikudo