Configuration Proxmox / EVE-NG
Mon serveur chez OVH commence à devenir limité. J'ai donc opté pour un mini pc MinisForum que j'ai posé chez moi. L'interconnexion se fait entre une VM debian (virtualisé dans un proxmox), qui me sert de routeur, et mon serveur, le tout avec un wireguard. Je route ensuite le trafic que j'ai envie dans le tunnel.
Derrière le routeur, j'ai mon VLAN où je vais mettre mes VMs qui vont me servir dans le cadre de ce blog.
EVE-NG fonctionne avec des interfaces PNET. De base, y'en a 10. Une est utilisée pour l'IP publique et une autre pour l'interco entre le serveur physique et le lab. J'ai utilisé l'interface PNET9.
Ensuite, il faut raccorder le réseau sur un leaf et propager le VLAN dans la fabric !
LNS1#sh run int Po10.3999
interface Port-channel10.3999
description *** INTERCO PROXMOX ***
encapsulation dot1Q 3999
ip address 100.100.100.10 255.255.255.0
end
LNS1#sh run | i 100.100.101
ip route 100.100.101.0 255.255.255.0 Port-channel10.3999 100.100.100.1
Subnet de management du backbone : 100.100.100.0/24.
Subnet des serveurs derrière le routeur debian : 100.100.101.0/24
Configuration LNS
On efface tous ce qu'on a fait dans l'épisode collecte L2 en PPP sur les LNS !
Pour commencer, on définit l'IP du radius et le mot de passe :
LNS1#sh run | s radius
radius server radius
address ipv4 100.100.101.1 auth-port 1812 acct-port 1813
key naruto
Je vous avez aussi parlé du triple AAA. Hé bah le voici :
LNS1#sh run | s aaa
aaa group server radius radius-naruto
server name radius
aaa authentication ppp default group radius-naruto
aaa authorization network default group radius-naruto local
aaa accounting network default start-stop group radius-naruto
Il faut aussi configurer les IP des loopback pour le unnumbered sur l'interface Virtual-Template. Bien sûr, les IPs doivent être différentes sur les deux différents LNS 😄. Je suis parti avec les IPs des Looback me servant au MPLS. Je ne pense pas qu'il s'agisse de la "best pratice" donc à voir !
LNS1#sh run int virtual-template 1
interface Virtual-Template1
mtu 1492
ip unnumbered Loopback1
no peer default ip address
ppp authentication chap callin
end
Au final, c'est même plus simple de configurer avec un radius plutôt qu'en local.
Installation de Freeradius
Il existe plusieurs outils pour un radius. J'ai décidé de partir sur le plus connu : Feeradius. Il peut gérer aussi bien le PPP que le DHCP.
Allez, on l'installe sur une petite debian :
root@radius:~# cat /etc/debian_version
12.6
root@radius:~# cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"
NAME="Debian GNU/Linux"
VERSION_ID="12"
VERSION="12 (bookworm)"
VERSION_CODENAME=bookworm
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
Le paquet s'appelle...... freeradius !
root@radius:~# apt install freeradius
root@radius:~# systemctl status freeradius
● freeradius.service - FreeRADIUS multi-protocol policy server
Loaded: loaded (/lib/systemd/system/freeradius.service; enabled; preset: enabled)
Active: active (running) since Fri 2024-07-26 22:25:31 CEST; 1 week 0 days ago
Les fichiers de configurations sont présents dans /etc/freeradius :
root@radius:/etc/freeradius# tree
.
└── 3.0
├── certs
├── clients.conf
├── dictionary
├── experimental.conf
├── hints -> mods-config/preprocess/hints
├── huntgroups -> mods-config/preprocess/huntgroups
├── mods-available
├── mods-config
│ ├── attr_filter
│ │ ├── access_challenge
│ │ ├── access_reject
│ │ ├── accounting_response
│ │ ├── coa
│ │ ├── post-proxy
│ │ └── pre-proxy
│ ├── files
│ │ ├── accounting
│ │ ├── authorize
│ │ ├── dhcp
│ │ └── pre-proxy
│ ├── perl
│ │ └── example.pl
│ ├── preprocess
│ │ ├── hints
│ │ └── huntgroups
│ ├── python3
│ │ ├── example.py
│ │ └── radiusd.py
│ ├── README.rst
│ ├── realm
│ │ └── freeradius-naptr-to-home-server.sh
│ ├── sql
│ │ ├── counter
│ │ │ ├── mysql
│ │ │ ├── postgresql
│ │ │ └── sqlite
├── mods-enabled
│ ├── always -> ../mods-available/always
│ ├── attr_filter -> ../mods-available/attr_filter
│ ├── chap -> ../mods-available/chap
│ ├── detail -> ../mods-available/detail
│ ├── detail.log -> ../mods-available/detail.log
│ ├── digest -> ../mods-available/digest
│ ├── dynamic_clients -> ../mods-available/dynamic_clients
│ ├── eap -> ../mods-available/eap
│ ├── echo -> ../mods-available/echo
│ ├── exec -> ../mods-available/exec
│ ├── expiration -> ../mods-available/expiration
│ ├── expr -> ../mods-available/expr
│ ├── files -> ../mods-available/files
│ ├── linelog -> ../mods-available/linelog
│ ├── logintime -> ../mods-available/logintime
│ ├── mschap -> ../mods-available/mschap
│ ├── ntlm_auth -> ../mods-available/ntlm_auth
│ ├── pap -> ../mods-available/pap
│ ├── passwd -> ../mods-available/passwd
│ ├── preprocess -> ../mods-available/preprocess
│ ├── radutmp -> ../mods-available/radutmp
│ ├── realm -> ../mods-available/realm
│ ├── replicate -> ../mods-available/replicate
│ ├── soh -> ../mods-available/soh
│ ├── sradutmp -> ../mods-available/sradutmp
│ ├── unix -> ../mods-available/unix
│ ├── unpack -> ../mods-available/unpack
│ └── utf8 -> ../mods-available/utf8
├── panic.gdb
├── policy.d
├── proxy.conf
├── radiusd.conf
├── README.rst
├── sites-available
├── sites-enabled
│ ├── default -> ../sites-available/default
│ └── inner-tunnel -> ../sites-available/inner-tunnel
├── templates.conf
├── trigger.conf
└── users -> mods-config/files/authorize
59 directories, 281 files
Je ne sais pas si vous avez vu mais il existe un module SQL ! En effet, on peut installer une base de données et gérer nos clients avec. Pour l'instant, je suis parti sur une autre méthode : le fichier user ! Peut être que je ferai la migration après.
Bon et maintenant ? Il faut bien "lier" le radius aux LNS !
Et ca se trouve dans le fichier clients.conf
root@radius:/etc/freeradius/3.0# cat clients.conf
client localhost {
ipaddr = 127.0.0.1
proto = *
secret = testing123
nas_type = other # localhost isn't usually a NAS...
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
client LNS1 {
ipaddr = 100.100.100.10
secret = naruto
shortname = LNS1
nastype = cisco
}
client LNS2 {
ipaddr = 100.100.100.11
secret = naruto
shortname = LNS2
nastype = cisco
}
On renseigne les deux LNS avec leur IP et le mot de passe qu'on avait défini dans la configuration du radius sur les cisco.
Et comme je vous l'avait dit, je configure les utilisateurs dans le fichier users :
root@radius:/etc/freeradius/3.0# cat users
nathan@naruto.ninja Cleartext-Password := "nathan"
Service-Type := Framed-User,
Framed-Protocol := PPP,
Framed-MTU := 1492,
Framed-IP-Address := 109.205.64.50,
Framed-IP-Netmask := 255.255.255.255
sasuke@naruto.ninja Cleartext-Password := "sasuke"
Service-Type := Framed-User,
Framed-Protocol := PPP,
Framed-MTU := 1492,
Framed-IP-Address := 109.205.64.51,
Framed-IP-Netmask := 255.255.255.255
Les différents attributs sont définis dans la RFC 3580 (https://www.freeradius.org/rfc/rfc3580.html). Pour l'instant, je ne souhaite que donner une IP à un client donc j'utilise uniquement le Framed-IP-Address, Framed-IP-Netmask, Framed-MTU et Framed-Protocol. Ils seront toujours utilisés !
Je sais pas si vous vous en souvenez mais dans l'épisode de la configuration de la collecte L2 en PPP, les users n'avaient pas de @XXX.XXX. Alors pourquoi en avoir mis ?
Tout ce qui se trouve après le @ est défini comme un REALM. Ce realm va varier en fonction des opérateurs et SURTOUT, si c'est une collecte L2TP.
Dans une collecte L2TP, le BAS de l'opérateur tiers va s'appuyer sur ce realm pour monter le tunnel.
Dans notre cas, pourquoi en avoir mis un vu que c'est une collecte L2 ? Car on va s'amuser après ! On peut faire un proxy radius basé sur le realm 😄 Ca peut être marrant à tester.
Dans un prochain épisode, on verra comment configurer un lien dans un L3VPN MPLS ! Et aussi le principe de secours avec les Framed-Route !
CPE Mikrotik
Rien ne change mis à part le login dans la configuration du PPP. Le CPE récupère bien une IP, sa route par défaut et arrive à taper Internet. D'ailleurs dans le traceroute, le premier saut est 100.127.0.1, soit l'IP de notre LNS. Vu que l'IP du ppp est un /32, on ne peut pas définir de next-hop ! Donc dans la requête PPP, le LNS va donner l'IP de son interface Virtual-template, ici 100.127.0.1 ! Le premier saut se fera donc avec cette IP.
[admin@Sasuke] /interface/pppoe-client> export
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=test \
service-name=Internet user=sasuke@naruto.ninja
[admin@Sasuke] /ip/address> print
Flags: D - DYNAMIC
Columns: ADDRESS, NETWORK, INTERFACE
# ADDRESS NETWORK INTERFACE
1 D 109.205.64.51/32 109.205.66.127 test
[admin@Sasuke] /ip/route> print
Flags: D - DYNAMIC; A - ACTIVE; c, v, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAv 0.0.0.0/0 test 1
DAc 100.127.0.1/32 test 0
[admin@Sasuke] > /tool/traceroute 1.1.1.1
Columns: ADDRESS, LOSS, SENT, LAST, AVG, BEST, WORST, STD-DEV
# ADDRESS LOSS SENT LAST AVG BEST WORST STD-DEV
1 100.127.0.1 0% 1 6.4ms 6.4 6.4 6.4 0
2 100.65.0.6 0% 1 23ms 23 23 23 0
3 1.1.1.1 0% 1 23.3ms 23.3 23.3 23.3 0
On fait la même chose pour le deuxième client :
[admin@Naruto] /interface/pppoe-client> export
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=test \
service-name=internet user=nathan@naruto.ninja
[admin@Naruto] /ip/address> print
Flags: D - DYNAMIC
Columns: ADDRESS, NETWORK, INTERFACE
# ADDRESS NETWORK INTERFACE
1 D 109.205.64.50/32 109.205.66.127 test
[admin@Naruto] /ip/route> print
Flags: D - DYNAMIC; A - ACTIVE; c, v, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
DST-ADDRESS GATEWAY DISTANCE
DAv 0.0.0.0/0 test 1
DAc 100.127.0.1/32 test 0
LNS
Et côté LNS, ca donne quoi ?
LNS1#sh ip route
B* 0.0.0.0/0 [20/0] via 100.65.0.6, 00:15:19
100.0.0.0/8 is variably subnetted, 9 subnets, 3 masks
C 100.64.0.0/29 is directly connected, Port-channel10.10
L 100.64.0.1/32 is directly connected, Port-channel10.10
C 100.65.0.0/29 is directly connected, Port-channel10.11
L 100.65.0.1/32 is directly connected, Port-channel10.11
C 100.100.100.0/24 is directly connected, Port-channel10.3999
L 100.100.100.10/32 is directly connected, Port-channel10.3999
S 100.100.101.0/24 [1/0] via 100.100.100.1, Port-channel10.3999
C 100.127.0.1/32 is directly connected, Loopback1
i L2 100.127.0.2/32 [115/20] via 100.64.0.2, 00:02:28, Port-channel10.10
109.0.0.0/32 is subnetted, 5 subnets
C 109.205.64.50 is directly connected, Virtual-Access2.2
C 109.205.64.51 is directly connected, Virtual-Access2.1
C 109.205.66.127 is directly connected, Loopback55
B 109.205.66.128 [200/0] via 100.127.0.2, 00:15:07
LNS1#ping 109.205.64.50
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 109.205.64.50, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 5/6/8 ms
LNS1#ping 109.205.64.51
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 109.205.64.51, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
On arrive bien à ping les CPE. Et si vous remarquez, les routes sont apprises en connected ! Et si, c'était la même chose pour les framed-routes ca serait pas mal, vous ne pensez pas ? 😏😏
Wireshark
Les premiers échanges se font toujours (PADI, etc). Cependant, ce n'est plus le LNS qui donne la configuration du client mais le Radius. Deux types d'échanges : Access et Accouting !
Le premier un Acces-Request :
On y retrouve le nom d'utilisateur et le mot de passe CHAP. D'autres attributs peuvent s'y trouver mais pour l'instant, on s'en fiche un peu ! On va pas se compliquer la vie 😄
Le deuxième est un Acces-Accept :
Deux trucs importants ! Tout d'abord, il valide l'authentification ! Bah oui, ca peut paraître bête, mais si l'user et le mot de passe ne matche pas, alors il ne renvoie pas ce message 😋. Ensuite, il délivre les attributs pour le client (autorisation). On retrouve tous les attributs qu'on avait renseigné dans le fichier users, à savoir la MTU, le protocole, l'IP et le masque !
Mais du coup, le Accouting il est où ?
Le AAA ! Authentication Authorization Accounting
On a authentifié (couple login/mot de passe), on a autorisé (IP délivrée par le radius). Il faut donc bien faire l'accouting !
Dans les échanges accouting, le Radius va pouvoir voir si le client est toujours en vie, combien de données il consomme.
Imaginez avec un beau SI, en un clic, voir la consommation d'un client, s'il est en vie (Je comprends que maintenant ton taf Jean-Eudes 😋)
Conclusion
On vient de mettre en place la première vraie collecte dans le backbone ! On peut résumer ce qu'on vient de faire avec le schéma juste en dessous :
Le couple PPP/Radius est très simple à mettre en oeuvre mais se pose une grande question qui divise beaucoup de monde...
Qui s'en occupe ? Le réseau ou le système ?
Hé bah, c'est le réseau ! De toute façon, dans un monde où réseau, système, virtualisation tend à fusionner, je ne vois pas de problème.
Je termine sur un petit mot de fin : Recherche tome 71 naruto collector edition fnac SVPPPP