Bonsoir,
j’ai installé strongSwan 6.0beta Vici Post-Quantum IKEv2 Daemon. Bien sûr vous pouvez utiliser la version officielle d’aujourd’hui, la version 5.9 sans compiler, mais vous ne pourrez pas chiffrer avec les algorithmes OQS.
Je ne connais pas « stroongSwan VICI » c’est à dire une configuration IPSec sans le fichier « ipsec.conf » (j’ai du retard sûrement) :
Avec ces fichiers donc :
/etc/strongswan.conf
/etc/swanctl/swanctl.conf
Je voulais créer un « mémo » - je me suis dis que sur ce forum c’était parfait.
J’ai fais quelques « tests » pour joindre plusieurs réseaux et sous-réseaux IPv6 (ULA et UNICAST GLOBAL) et je souhaitai ouvrir ce sujet pour ce grand plaisir de « sécurité moderne ».
Je ne connais pas, ou plutôt n’ai « jamais utilisé » la commande « ip xfrm » non plus.
xfrm est un framework IP pour transformer les paquets (comme le chiffrement de leurs payloads (charges utiles). Ce cadre est utilisé pour implémenter la suite de protocoles IPsec (avec l’objet state fonctionnant sur la base de données d’association de sécurité et l’objet policy fonctionnant sur la base de données de politique de sécurité). Il est également utilisé pour le protocole de compression de charge utile IP et les fonctionnalités de Mobile IPv6.
| ip xfrm state add | add new state into xfrm |
|---|---|
| ip xfrm state update | update existing state in xfrm |
| ip xfrm state allocspi | allocate an SPI value |
| ip xfrm state delete | delete existing state in xfrm |
| ip xfrm state get | get existing state in xfrm |
| ip xfrm state deleteall | delete all existing state in xfrm |
| ip xfrm state list | print out the list of existing state in xfrm |
| ip xfrm state flush | flush all state in xfrm |
| ip xfrm state count | count all existing state in xfrm |
| ip xfrm policy add | add a new policy |
|---|---|
| ip xfrm policy update | update an existing policy |
| ip xfrm policy delete | delete an existing policy |
| ip xfrm policy get | get an existing policy |
| ip xfrm policy deleteall | delete all existing xfrm policies |
| ip xfrm policy list | print out the list of xfrm policies |
| ip xfrm policy flush | flush policies |
DĂ©jĂ , je voulais remonter cette information.
Après une déconnexion de ma boxe internet par exemple, je reste connecté à la IKEv2_SA - par contre j’ai étais déconnecté de la CHILD_SA.
root@initiator:~ # swanctl --list-sas
gw-gw: #4, ESTABLISHED, IKEv2, 66402962da1dd722_i befb11fc81c37e67_r*
local 'bw.zw3b.eu' @ 192.168.1.254[4500]
remote 'vps.zw3b.eu' @ 135.125.133.51[4500]
AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519/KE1_KYBER_L3/KE2_BIKE_L3/KE3_HQC_L3/KE4_HQC_L5
established 13185s ago, rekeying in 684s
J’aimerai savoir si une commande permettrait de « terminer » la connexion de l’association de sécurité IKEv2.
Bon j’ai trouvé la solution, pour terminer la connexion IKE_SA (enfants ou non) :
$ swanctl --terminate --ike gw-gw
Pour initialiser une connexion IKE_SA seulement :
$ swanctl --initiate --ike gw-gw
Pour initialiser une connexion IKE_SA + CHILD_SA :
$ swanctl --initiate [ --ike gw-gw ] --child gw-gw
Sur une « association de sécurité IKE » en particulier ouvrir sur un autre « Child SA » :
$ swanctl --initiate --ike gw-gw --child test
initiate failed: CHILD_SA config 'test' not found
Pour terminer une connexion CHILD_SA :
$ swanctl --terminate --ike gw-gw --child test
Documentation StrongSwan - Modern vici-based Scenarios IPv6 Configuration Examples et la page Usable Examples configurations.
Dumps de trafic IPsec sous Linux :: strongSwan Documentation
Il s’agit d’un court didacticiel expliquant comment obtenir des dumps de trafic IPsec corrects sous Linux.
De nombreux utilisateurs ne sont pas conscients de l’anomalie de capture de paquets qui se produit lors de la capture avec les paramètres par défaut à l’aide de Wireshark et tcpdump. Cet article expliquera comment effectuer des vidages de trafic corrects de…​#tcpdump #wiresharp #certifs
Sous Linux, « strongSwan » installe les routes dans la table de routage 220 par défaut et nécessite donc que le noyau prenne en charge le routage basé sur des politiques.
ip -6 route show table 220
Documentation strongSwan :: Introduction to strongSwan → Routing
Documentation strongSwan :: Route-based VPN
J'ajoute un script "updown.sh"
Vu que j’essaie de passer directement sur l’interface réseau principale, je n’utilise ce script (en bas de la page Route-based VPN. Je ne sais pas encore si c’est mieux de créer des interfaces « vti_/ipsecX » ou de tout faire passer sur la carte principale. Pour l’instant « je galère avec mes routes » sans dissocier plusieurs interfaces réseaux (pour plusieurs connexions), mais au final cela pourait être mieux que d’avoir 20 ethernet « ipsec », je sais pas trop.
#!/bin/bash
# set charon.install_virtual_ip = no to prevent the daemon from also installing the VIP
set -o nounset
set -o errexit
VTI_IF="vti${PLUTO_UNIQUEID}"
PLUTO_MY_SOURCEIP="172.16.5.1"
#PLUTO_MARK_OUT=42
echo ''
echo 'VTP_IF : '$VTI_IF
echo 'PLUTO_VERB : '$PLUTO_VERB
echo 'PLUTO_ME : '$PLUTO_ME
echo 'PLUTO_PEER : '$PLUTO_PEER
#echo 'PLUTO_MARK_IN : '$PLUTO_MARK_IN
#echo 'PLUTO_MARK_OUT : '$PLUTO_MARK_OUT
echo 'PLUTO_MY_SOURCEIP :'$PLUTO_MY_SOURCEIP
echo 'PLUTO_PEER_SOURCEIP : '$PLUTO_PEER_SOURCEIP
echo 'PLUTO_PEER_CLIENT : '$PLUTO_PEER_CLIENT
echo ''
case "${PLUTO_VERB}" in
up-client)
ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti key "${PLUTO_MARK_OUT%%/*}"
# ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti key "42"
# ip tunnel add "${VTI_IF}" local "${PLUTO_ME}" remote "${PLUTO_PEER}" mode vti
ip link set "${VTI_IF}" up
ip addr add "${PLUTO_MY_SOURCEIP}" dev "${VTI_IF}"
# Ajoutez les itinéraires souhaités sur le tunnel
ip route add "${PLUTO_PEER_SOURCEIP}" dev "${VTI_IF}"
# Désactivez les vérifications de politique pour cette interface, sinon le noyau supprimera le trafic après le déchiffrement.
sysctl -w "net.ipv4.conf.${VTI_IF}.disable_policy=1"
# Disable RP filter for the tunnel interface
sysctl -w "net.ipv4.conf.${VTI_IF}.rp_filter=0"
;;
down-client)
ip tunnel del "${VTI_IF}"
;;
esac
Merci.
IPsec (Internet Protocol Security)
IPSec permet d’assurer des communications privées et protégées sur des réseaux IP, par l’utilisation des services de sécurité cryptographiques. De plus, IPsec opère à la couche réseau (couche 3 du modèle OSI), ce qui le rend indépendant des applications, et veut dire que les utilisateurs n’ont pas besoin de configurer chaque application.
Son objectif est d’authentifier et de chiffrer les données : le flux ne pourra être compréhensible que par le destinataire final (confidentialité) et la modification des données par des intermédiaires ne pourra être possible (Intégrité).Lors de l’établissement d’une connexion IPsec, plusieurs opérations sont effectuées :
- Échange des clés
- un canal d’échange de clés, sur une connexion UDP depuis et vers le port 500 (ISAKMP pour Internet Security Association and Key Management Protocol).
Le protocole IKE (Internet Key Exchange) est chargé de négocier la connexion. Avant qu’une transmission IPsec puisse être possible, IKE est utilisé pour authentifier les deux extrémités d’un tunnel sécurisé en échangeant des clés.
- Transfert des données
Un ou plusieurs canaux de données par lesquels le trafic du réseau privé est véhiculé, deux protocoles sont possibles :
- le protocole no 51, AH, (Authentication Header) fournit l’intégrité et l’authentification. AH authentifie les paquets en les signant, ce qui assure l’intégrité de l’information. Une signature unique est créée pour chaque paquet envoyé et empêche que l’information soit modifiée.
- le protocole no 50, ESP (Encapsulating Security Payload), en plus de l’authentification et l’intégrité, fournit également la confidentialité par l’entremise de la cryptographie.
IPsec peut fonctionner dans un mode transport hôte à hôte ou bien dans un mode tunnel réseau.
Mode transport
Dans le mode transport, ce sont uniquement les données transférées (la partie payload du paquet IP) qui sont chiffrées et/ou authentifiées. Le reste du paquet IP est inchangé et de ce fait le routage des paquets n’est pas modifié. Néanmoins, les adresses IP ne pouvant pas être modifiées par le NAT sans corrompre le hash de l’en-tête AH généré par IPsec, AH ne peut pas être utilisé dans un environnement nécessitant ces modifications d’en-tête. En revanche, il est possible d’avoir recours à l’encapsulation NAT-T pour encapsuler IPSec ESP. Le mode transport est utilisé pour les communications dites hôte à hôte (Host-to-Host).Mode tunnel
En mode tunnel, c’est la totalité du paquet IP qui est chiffré et/ou authentifié. Le paquet est ensuite encapsulé dans un nouveau paquet IP avec un nouvel en-tête IP. Au contraire du mode transport, ce mode supporte donc bien la traversée de NAT quand le protocole ESP est utilisé. Le mode tunnel est utilisé pour créer des réseaux privés virtuels (VPN) permettant la communication de réseau à réseau (c.a.d. entre deux sites distants), d’hôte à réseau (accès à distance d’un utilisateur) ou bien d’hôte à hôte (messagerie privée.)IPsec utilise une association de sécurité (Security association) pour dicter comment les parties vont faire usage de AH (Authentication header), protocole définissant un format d’en-tête spécifique portant les informations d’authentification, et de ESP l’encapsulation de la charge utile d’un paquet.
Source : Wikipédia → IPsec
IKE (Internet Key Exchange)
Le protocole IKE (Internet Key Exchange) est chargé de négocier la connexion. Avant qu’une transmission IPsec puisse être possible, IKE est utilisé pour authentifier les deux extrémités d’un tunnel sécurisé en échangeant des clés partagées ou des certificats. Ce protocole permet deux types d’authentifications, PSK (secret prépartagé ou secret partagé) pour la génération de clefs de sessions RSA ou à l’aide de certificats. IKE utilise l’échange de clés Diffie-Hellman.
Source : Wikipédia → Internet Key Exchange - Échange de clés Diffie-Hellman
AH (Autentification Header)
L’Autentification Header ou AH est un protocole définissant un format d’en-tête spécifique portant les informations d’authentification, et de l’encapsulation de la charge utile d’un paquet. À l’aide de l’AH on obtient l’authentification et l’intégrité. AH authentifie les paquets en les signant, ce qui assure l’intégrité de l’information. Une signature unique est créée pour chaque paquet envoyé et empêche que l’information soit modifiée.
Source : Wikipédia → Authentication Header
ESP (Encapsulating Security Payload)
Encapsulating Security Payload (ou ESP), est un protocole appartenant à la suite IPsec, permettant de combiner plusieurs services de sécurité : confidentialité, authentification et intégrité.
ESP fournit le chiffrement des messages / données utiles et l’authentification d’une donnée utile et de son origine. Le protocole ESP assure la confidentialité des encapsulations des messages, des données utiles. ESP propose également les services AH. ESP propose de l’authentification de la même manière que AH grâce à l’utilisation de données d’en-tête : Le SPI (Security Parameters Index).
ESP ne protège pas l’en-tête du paquet; cependant, dans un mode tunnel si le paquet entier est encapsulé dans un autre paquet en tant que paquet de données utiles / données, il peut crypter le paquet entier résidant à l’intérieur d’un autre paquet.
EAP (Extensible Authentication Protocol)
Extensible Authentication Protocol ou EAP est un protocole de communication réseau embarquant de multiples méthodes d’authentification, pouvant être utilisé sur les liaisons point à point, les réseaux filaires et les réseaux sans fil tels que les réseaux Wi-Fi.
Plusieurs méthodes d’authentification sont prédéfinies (MD5, OTP (One-Time Passwords), Generic Token Card, SIM, etc.) mais il est possible d’en rajouter sans qu’il soit nécessaire de changer ou de créer un nouveau protocole réseau.
Il est conçu pour fournir un mécanisme d’authentification pour les liaisons PPP (couche 2 du modèle OSI) afin d’autoriser ou interdire l’établissement de la couche réseau (couche 3 du modèle OSI). Ce protocole ne s’appuie donc pas sur le protocole IP (couche 3 du modèle OSI).
La liaison PPP est définie entre un peer et un authenticator.
L’authenticator peut envoyer une requête au peer pour connaître son identité ou alors de déterminer son identité par l’interface de communication.
Cette identification est suivie d’une ou plusieurs requêtes envoyées par l’authenticator (obligatoire) avec un paramètre contenant la méthode d’authentification souhaitée (MD5, OTP (One-Time Passwords), Generic Token Card, SIM, etc.)
Cette authentification peut être réalisée par l’authenticator lui-même ou déléguée à un service tiers (authentication server). L’authentification peut être demandée par chaque extrémité.Le protocole EAP ne supporte pas nativement la fragmentation des paquets réseau (MTU (Maximum Transmission Unit)) mais ce comportement peut être modifié avec certaines méthodes :
Les standards WPA et WPA2 ont adopté 5 types d’EAP comme mécanismes officiels d’identification.
- EAP-TLS
- EAP-TTLS/MSCHAPv2
- PEAPv0/EAP-MS-CHAPv2
- PEAPv1/EAP-GTC
- EAP-SIM
EAP-TLS : C’est le seul protocole EAP qui doit obligatoirement être implanté sur un matériel pour que ce dernier puisse porter le logo WPA ou WPA2. Il offre une bonne sécurité. En effet il utilise deux certificats pour la création d’un tunnel sécurisé qui permet ensuite l’identification : un côté serveur et un côté client. Cela signifie que même si le mot de passe est découvert, il ne sera d’aucune utilité sans le certificat client. Bien que EAP-TLS fournisse une excellente sécurité, l’obligation de disposer d’un certificat client est peut-être son talon d’Achille. En effet lorsque l’on dispose d’un grand parc de machines, il peut s’avérer difficile et coûteux de gérer un certificat par machine. C’est pour se passer du certificat client que les protocoles PEAP et EAP-TTLS ont été créés.
Il utilise une Infrastructure à clés publiques (PKI) pour sécuriser les communications d’identification entre les clients et le serveur RADIUS (Remote Authentication Dial-In User Service).EAP-TTLS ou EAP-Tunneled Transport Layer Security utilise des certificats X-509 uniquement sur le serveur d’identification. Le certificat est optionnel du côté client. Il offre un très bon niveau de sécurité. Le défaut de EAP-TTLS par rapport à PEAP est de ne pas être présent nativement sur les systèmes Microsoft et Cisco. En revanche, il est légèrement plus sécurisé que PEAP car il ne diffuse pas le nom de l’utilisateur en clair.
PEAP Protected EAP : PEAP est très similaire à une autre méthode EAP : EAP-TTLS. Protected EAP a été créé pour contrer EAP-TTLS qui était jusque-là la seule méthode EAP à utiliser une Infrastructure à clés publiques (Public Key Infrastructure, PKI) que du côté serveur, pour la création d’un tunnel TLS protégeant l’identification. Dans ces deux standards, l’utilisation d’une clef publique côté client est optionnelle. Il existe deux versions de PEAP certifiées WPA (mise à jour) et WPA2 : PEAPv0/EAP-MS-CHAPv2 et PEAPv1/EAP-GTC.
EAP-SIM est une méthode EAP pour les clients des réseaux Wi-Fi et des réseaux de téléphonie mobile GSM, UMTS et LTE. Il est utilisé pour l’identification et la distribution de clefs au travers des réseaux ; SIM signifie « Subscriber Identity Module ».
Autres méthodes EAP (Extensible Authentication Protocol) :
- LEAP, EAP-MD5, EAP-FAST, EAP-AKA
Source : Wikipédia : Extensible Authentication Protocol - Maximum Transmission Unit (MTU)
SA (Security Association)
Une association de sécurité IPSec est une structure de données servant à stocker l’ensemble des paramètres de sécurité associés à une communication . Une SA étant unidirectionnelle, il faut deux SA pour protéger les deux sens d’une communication.
Source : Wikipedia → Security association
SPI (Security Parameter Index)
L’index des paramètres de sécurité (SPI) est une balise d’identification ajoutée à l’en-tête lors de l’utilisation d’IPsec pour tunneliser le trafic IP. Cette balise aide le noyau à distinguer deux flux de trafic dans lesquels des règles et algorithmes de chiffrement différents peuvent être utilisés.
Le SPI (conformément à la RFC 2401) est un élément obligatoire d’une association de sécurité (SA) IPsec car il permet au système de réception de sélectionner la SA sous laquelle un paquet reçu sera traité. Un SPI n’a qu’une signification locale, puisqu’il est défini par le créateur de la SA ; un SPI est généralement considéré comme une chaîne de bits opaque. Cependant, le créateur d’une SA peut interpréter les bits d’un SPI pour faciliter le traitement local.
Cela fonctionne comme les numéros de port dans les connexions TCP et UDP. Cela signifie qu’il peut y avoir différentes SA utilisées pour assurer la sécurité d’une connexion. Une SA pourrait donc agir comme un ensemble de règles.
Transporté dans l’en-tête Encapsulated Security Payload (ESP) ou dans l’en-tête d’authentification (AH), sa longueur est de 32 bits.
Je finis avec :
PKI (Public Key Infrastructure)
Une « infrastructure à clés publiques » (ICP) ou « infrastructure de gestion de clés » (IGC) ou encore « public key infrastructure » (PKI), est un ensemble de composants physiques ou matériel type Hardware Security Module (HSM), de procédures humaines (vérifications, validation) et de logiciels destiné à gérer les clés publiques des utilisateurs d’un système.
Une infrastructure de gestion de clés permet de lier des clés publiques à des identités (comme des noms d’utilisateurs ou d’organisations). Une infrastructure de gestion de clés fournit des garanties permettant de faire a priori confiance à une clé publique obtenue par son biais.
Une erreur courante est d’assimiler le terme « infrastructure de gestion de clés » à « autorité de certification ». Cette erreur provient probablement du terme PKIX, pour PKI X.509, qui est lui bien associé aux autorités de certification et aux certificats X.509
L’infrastructure à clés publiques (PKI) repose sur un ensemble de processus, de technologies et de politiques qui permettent de chiffrer et de signer des données. Vous pouvez alors émettre des certificats numériques pour l’authentification de vos utilisateurs, de vos appareils et de vos services. Ces certificats établissent des connexions sécurisées pour vos pages web publiques, mais aussi vos systèmes privés (VPN, Wi-Fi interne, et autres services compatibles avec l’authentification multifacteur).
Bonne journée, mesdames, messieurs.
Romain
PS : J’hésite à mettre ici ma configuration strongSwan (ce que je ferais sûrement, ultérieurement ;
→ Mes tests de configuration (j’ai rien de mieux pour le moment)
- La config « 1 » est un exemple des fichiers « /etc/strongSwan.conf » (Serveur / Client)
- La config « 2 » est OK sans sous-réseaux (IPv4 publique to IPv4 publique - le traceroute ne fait pas de saut entre les 2 machines connectées).
- La config « 3 » est OK de « site » à « site » (ping & services) avec sous réseaux IPv6.
- La config « 4 » est OK de « site » à « serveur » à « site » : (ping et services) avec sous-réseaux, j’en suis là au 20240313.
Exemple de création de certificats SSL/TLS avec la commande « pki ».
Il faudrait essayer d’autres méthodes d’autentification – EAP (Extensible Authentication Protocol)
20240313 : Je vous ajoute mon script « firewall-icmpv6 » où j’ai ajouté la fonction « ipv6_strongswan() » qui permet de laisser passer les requêtes UDP/TCP sur le prefix d’adresses « IPv6 SWAN Site-Local scoped » en plus de l’ICMPv6 (du ping)
-
un bout du firewall-ipv6 pour checker les networks range de liens
fe80::/10, des sites-Localsfec0::/10, du multicastff00::/8(mĂŞme longueur de bloc IPv6::/64 et IPv6::/104) et des adresses localesfc00::/7
J’ai écris/copié/collé ces informations sur le sujet « IPsec modern communication IPv6 et IKEv2 security ».
Ce n’est pas trop « lourd » à lire 
Note : pour infos j’ai ouvert un sujet sur LaFibre.info pour celles et ceux qui préféraient ou qui n’ont pas de compte sur Debian-Fr.org.
Greets.
GestiĂłIP : IPv6 subnet calculator
Note personnelle d'un exemple réseau IPv6 (temporaire, todo)
Date : 20240226
Info : 🥳 Network IPv6 - IPSec - strongSwan - Modern Security communication
FR.LAB3W.DC (France/Alpes)
Je configure la machine serveur « domain controller »
Ici c’est chez moi à mon domicile.
J’ai plusieurs machines sur différents réseaux de machines, de tablettes, de smartphones etc.
VMBR0 <-> LAN/WAN
//-----------------------
// VMBR0 <-> LAN/WAN
//---------
// IP Address (addr unique locale magic) :
fc01:0000:0000:0000:0000:0000:0000:0253/16
// network range :
fc01:0000:0000:0000:0000:0000:0000:0000-
fc01:ffff:ffff:ffff:ffff:ffff:ffff:ffff
// IP Address (addr unique locale "fc01::") - gateway generale :
2001:cb1d:02d4:88ff:ffff:ffff:ffff:ffff/56
fc01:cb1d:02d4:88ff:ffff:ffff:ffff:ffff/56
// network range :
fc01:cb1d:02d4:8800:0000:0000:0000:0000-
fc01:cb1d:02d4:88ff:ffff:ffff:ffff:ffff
//-----------------------
VMBR1 <-> VLAN/VSERVERs
//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D2 (a2ff:00ff/96) :
2001:cb1d:02d4:8851:0642:0000:a2ff:00ff/96
fc01:cb1d:02d4:8851:0642:0000:a2ff:00ff/96
// network range :
fc01:cb1d:02d4:8850:0000:0000:0000:0000-
fc01:cb1d:02d4:885f:ffff:ffff:ffff:ffff
//-----------------------
FR.LAB3W.BW (France/Alpes)
Je configure la machine serveur « initiateur »
Ici c’est chez moi à mon domicile.
J’ai plusieurs machines sur différents réseaux de machines, de tablettes, de smartphones etc.
VMBR0 <-> LAN/WAN
//-----------------------
// VMBR0 <-> LAN/WAN
//---------
// IP Address (addr unique locale magic) :
fc00:0000:0000:0000:0000:0000:0000:0254/16
// network range :
fc00:0000:0000:0000:0000:0000:0000:0000-
fc00:ffff:ffff:ffff:ffff:ffff:ffff:ffff
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") :
2001:cb1d:2d4:8850:0642:0000:0000:0254/64
fc01:cb1d:2d4:8850:0642:0000:0000:0254/64
// network range :
fc01:cb1d:02d4:8850:0000:0000:0000:0000-
fc01:cb1d:02d4:8850:ffff:ffff:ffff:ffff
//---------
// IP Address (addr secure wide area) :
fec0:0000:0000:0000:0000:0000:0000:0254/16
// network range :
fec0:0000:0000:0000:0000:0000:0000:0000-
fec0:ffff:ffff:ffff:ffff:ffff:ffff:ffff
//---------
VMBR1 <-> VLAN/VSERVERs
//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D1 (a1ff:00ff/96) :
2001:cb1d:02d4:8851:0642:0000:a1ff:00ff/96
fc01:cb1d:02d4:8851:0642:0000:a1ff:00ff/96
// network range :
fc01:cb1d:02d4:8851:0642:0000:0000:0000-
fc01:cb1d:02d4:8851:0642:0000:ffff:ffff
//-----------------------
DE.LAB3W.VPS (Allemagne/Berllin)
Ici c’est un VPS (1 seule IPv6 UNICAST GLOBAL).
VMBR0 <-> LAN/WAN
//-----------------------
// VMBR0 <-> LAN/WAN
//---------
// IP Address (addr unicast globale "2001::/128" :
2001:41d0:701:1100::6530/128
//---------
// IP Address (addr secure wide area) :
fec0:0000:0000:0000:0000:0000:0000:0001/16
// network range :
fec0:0000:0000:0000:0000:0000:0000:0000-
fec0:ffff:ffff:ffff:ffff:ffff:ffff:ffff
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D1 (a1ff:00ff/96) :
fec0:cb1d:02d4:885e:eeee:0642:0000:0254/61
// network range :
fec0:cb1d:02d4:8858:0000:0000:0000:0000-
fec0:cb1d:02d4:885f:ffff:ffff:ffff:ffff
vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 135.125.133.51 netmask 255.255.255.0 broadcast 135.125.133.255
inet6 fec0::1 prefixlen 16 scopeid 0x40<site>
inet6 fe80::24b2:4ff:fea2:c384 prefixlen 64 scopeid 0x20<link>
inet6 2001:41d0:701:1100::6530 prefixlen 128 scopeid 0x0<global>
ether 26:b2:04:a2:c3:84 txqueuelen 1000 (Ethernet)
RX packets 216146041 bytes 93608898294 (87.1 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 231937862 bytes 48252690945 (44.9 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
VMBR1 <-> VLAN/VSERVERs
//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_00 (0000:0000:0000:0000/64) :
fc00:41d0:701:1100::fffe/64
// network range :
fc00:41d0:701:1100:0000:0000:0000:0000-
fc00:41d0:701:1100:ffff:ffff:ffff:ffff
vmbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.133.0.254 netmask 255.255.255.0 broadcast 10.133.0.255
inet6 fe80::7069:deff:fe53:4683 prefixlen 64 scopeid 0x20<link>
inet6 fc00:41d0:701:1100::fffe prefixlen 64 scopeid 0x0<global>
ether 72:69:de:53:46:83 txqueuelen 1000 (Ethernet)
RX packets 68448644 bytes 15499970989 (14.4 GiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 63449533 bytes 7999980401 (7.4 GiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
UK.LAB3W.VPS (Angleterre/Londres)
Ici c’est un VPS (1 seule IPv6 UNICAST GLOBAL).
VMBR0 <-> LAN/WAN
//-----------------------
// VMBR0 <-> LAN/WAN
//---------
// IP Address (addr unicast globale "2001::/128" :
2001:41d0:801:2000::44f9/128
//---------
// IP Address (addr secure wide area) :
fec0:0000:0000:0000:0000:0000:0000:0243/16
// network range :
fec0:0000:0000:0000:0000:0000:0000:0000-
fec0:ffff:ffff:ffff:ffff:ffff:ffff:ffff
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_D1 (a1ff:00ff/96) :
fec0:cb1d:02d4:885e:eeee:0642:0000:0254/61
// network range :
fec0:cb1d:02d4:8858:0000:0000:0000:0000-
fec0:cb1d:02d4:885f:ffff:ffff:ffff:ffff
vmbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 57.128.171.43 netmask 255.255.255.0 broadcast 57.128.171.255
inet6 fe80::a09c:91ff:fed5:d3d9 prefixlen 64 scopeid 0x20<link>
inet6 fec1::243 prefixlen 128 scopeid 0x40<site>
inet6 2001:41d0:801:2000::44f9 prefixlen 128 scopeid 0x0<global>
ether a2:9c:91:d5:d3:d9 txqueuelen 1000 (Ethernet)
RX packets 778091 bytes 177948788 (169.7 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 684303 bytes 250874892 (239.2 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
VMBR1 <-> VLAN/VSERVERs
//-----------------------
// VMBR1 <-> VLAN/VSERVERs
//---------
// IP Address (addr unicast globale "2001::" / addr unique locale "fc01::") -> VLAN_00 (0000:0000:0000:0000/64) :
fc00:41d0:801:2000::fffe/64
// network range :
fc00:41d0:801:2000:0000:0000:0000:0000-
fc00:41d0:801:2000:ffff:ffff:ffff:ffff
vmbr1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 10.171.43.254 netmask 255.255.255.0 broadcast 10.171.43.255
inet6 fe80::40a9:16ff:fe94:6f1a prefixlen 64 scopeid 0x20<link>
inet6 fc00:41d0:801:2000::fffe prefixlen 64 scopeid 0x0<global>
ether 42:a9:16:94:6f:1a txqueuelen 1000 (Ethernet)
RX packets 24074 bytes 3246205 (3.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 20868 bytes 64167857 (61.1 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
CA.LAB3W.SRV (Canada/Montreal)
Ici c’est un Dédié (1 bloc IPv6::/64 UNICAST GLOBAL).
//-----------------------
[...]
//-----------------------
Pour le plaisir et les nouveaux Êtres comme moi → ScienceEtonnante " L’Algorithme qui Sécurise Internet (entre autres…)"
David Louapre vous parle de l’étonnant algorithme de Diffie-Hellman, une méthode de cryptographie dont il a eu du mal à croire qu’elle puisse exister !
%20A+.png)
.png)
