Aller à la recherche

Des Logiciels Libres

Pour parler de Logiciels Libres en milieu professionnel... ou pas!

lundi, mars 7 2016 18:58

Métrologie avec Carbon-Graphite - Partie 1 - Les concepts

Présentation conceptuelle de la métrologie avec la pile "Carbon-Graphite".

Lire la suite

lundi, février 1 2016 04:11

Configuration d'une VM avec OpenVswitch avec VLAN

Ce billet aborde la configuration des VLANs pour une VM reliée à un OpenVswitch.

Lire la suite

mercredi, janvier 6 2016 21:38

Configuration d'une VM avec OpenVswitch sans VLAN

Ce billet présente les premières étapes pour configurer une VM avec la libvirt et le support d'un switch virtuel OpenVswitch.

Lire la suite

samedi, novembre 28 2015 09:24

Fin de vie de la Fedora 21

Un bref rappel concernant la Fedora 21, celle-ci ne sera plus maintenue à partir du 1er décembre 2015. Pensez à migrer vers une Fedora plus récente.

jeudi, novembre 12 2015 14:53

Fedora 23 disponible

Je suis en retard mais pour ceux qui auraient loupé ça, la Fedora 23 est disponible (depuis le 3 novembre dernier). Pour la télécharger c'est ici !

Lire la suite

vendredi, septembre 25 2015 08:47

Fedora 23 Beta

Juste un billet rapide pour dire que la Fedora 23 Beta était disponible depuis quelques jours déjà. Vous pouvez la télécharger sur le site officiel comme d'hatidude.

C'est l'occasion de la tester (en général les Beta de chez Fedora sont plutôt stable), et de remonter les bugs !

Bon tests !

mercredi, juin 24 2015 13:55

Fin de vie de la Fedora 20

Un bref message pour annonce que la Fedora 20 est officiellement en fin de vie (EOL) depuis hier (23 juin 2015).

Lire la suite

jeudi, avril 2 2015 16:11

Les nouveautés de la Fedora 22

Voici une petite selection de nouveautés attendues pour la Fedora 22. Cette dernière est prévue pour sortir à la mi-mai, si tout se passe bien.

Lire la suite

jeudi, mars 26 2015 10:20

Configuration basique d'OpenVswitch

Configuration de la partie OpenVswitch sur CentOS 7.

Lire la suite

jeudi, janvier 8 2015 15:07

Interdiction par défaut de se connecter en root via ssh pour Fedora 22

Si vous avez l'habitude de vous connecter en root à vos Fedora via SSH, vous devriez perdre cette mauvaise habitude dès la prochaine Fedora 22.

Lire la suite

mercredi, décembre 17 2014 13:32

Fin de vie de la Fedora 19

Suite à la sortie de la F21, la Fedora 19 n'aura donc plus de mise à jour à partir du 06 janvier 2014. 

Il n'y aura donc plus de support sur cette version, si vous ne mettez pas à jour vers la Fedora 20 ou 21, ce sera à vos risques et périls.

Pour rappel, seules es 2 dernières versions majeures de Fedora sont maintenues (mises à jour de sécurité, corrections de bugs etc).

L'outil pour mettre à jour : fedup

mardi, décembre 9 2014 10:40

Fedora 21 disponible

La Fedora 21 (plus vraiment de petit nom, à part Twenty One), après de nombreux mois de travail, compte tenus des très nombreux changement apportés au projet, vient de sortir.

Lire la suite

lundi, novembre 17 2014 19:41

OpenNebula sur CentOS 7

OpenNebula permet de créer/gérer un datacenter virtualisé. Ce billet traite de l'installation d'OpenNebula 4.10 sur CentOS 7, avec comme espace de stockagé partagé un montage NFS.

Lire la suite

jeudi, avril 3 2014 14:05

Mise en oeuvre de logstash

Logstash est un excellent produit de tri, traitement et collecte des journaux (=>logs).

Lire la suite

lundi, mars 3 2014 09:35

Un cadeau de Broadcom pour l'OpenSource

Ce n'est pas la première fois, et ce ne sera surement pas la dernière! Broadcom vient d'annoncer la mise à disposition de la documentation complète sur ses puces graphiques VideoCore IV, ainsi que les sources complètes de la pile logiciel en rapport. Cela, peut être pour remercier le Raspberry Pi, qui fête sa 2e année, et son succès planétaire.

Lire la suite

jeudi, décembre 19 2013 09:32

Fin de vie de la Fedora 18

L'annonce de la date de fin de vie (EOL) pour la Fedora 18 vient de tomber.

Lire la suite

mardi, décembre 17 2013 16:16

La Fedora 20 "Heisenbug" est sortie

Et voilà, la version finale de la Fedora 20 vient de sortir. Elle coïncide avec le 10e anniversaire du projet Fedora, et ce veut aussi un hommage à Seth Vidal, developpeur principale des projets YUM, et grand contributeur de projets libres, qui nous a quitté en juillet dernier. Cette version de Fedora lui est donc dédiée.

Pour voir la liste des changements: ici sur le site officiel, ou quand j'en avais parlé précédemment.

Les notes officielles de sortie sont ici. Pour télécharger la Fedora 20, il faut aller sur la page officielle du projet.

Gnome F20

dimanche, octobre 13 2013 16:41

Les fonctionnalités attendues pour la Fedora 20

Les fonctionnalités attendues pour la Fedora 20 Heisenbug, qui doit sortir en cette fin d'année, sont les suivantes:

Environnements graphiques

GNOME 3.10

La version alpha de la Fedora 20 propose une préversion de Gnome 3.10, la version 3.9.90. Gnome 3.10 proposera de nouvelles applications et fonctionnalités, comme gnome-music, gnome-map, une refonte du menu de status, et le support Zimbra dans Evolution.

Il y aura aussi un support préliminaire de Wayland, même si ce dernier ne sera pas dans les paquets par défaut. La couche Wayland étant un potentiel remplacant du serveur graphique ancestral X11.

KDE Plasma Workspaces 4.11

La Fedora 20 apportera KDE 4.11, qui inclut certaines évolutions, comme un indexage plus rapide avec Nepomuk, l'amélioration de Kontact, l'intégration de KScreen dans KWin, le support des metalinks/HTTP dans KGet et bien d'autres encore.

Architecture ARM

L'architecture ARM devient officiellement supportées. J'en ai déjà parlé ici. Voir aussi ce que ça apporte dans les sujets liés à la virtualisation.

Améliorations sur NetworkManager

Le CLI pour manipuler facilement ces connexions en ligne de commande s'améliore. Il sera possible via nmcli d'ajouter, éditer, supprimer, activer et desactiver des connexions réseaux. Pratique pour ceux qui ne veulent pas user leur souris.

NetworkManager supportera aussi les aggrégats de cartes réseaux (bonding) ainsi que les ponts ethernet (bridge). Des solutions déjà courament utilisées en entreprise, pour la haute disponibilité, ou encore la virtualisation. Vivement cette intégration dans RedHat Entreprise Linux (ou CentOS) du coup.

Plus de sendmail ou syslog par défaut

Certains services que certains pouvaient trouvés inutiles ne seront plus installés par défaut. Ils restent bien sûr possible de les installer à posteriori.

Cela concerne tout d'abord sendmail, car il n'est en effet plus nécessaire sur un poste de travail d'avoir un serveur de messagerie (MTA).

Syslog est aussi touché, vu que systemd peut prendre en charge la journalisation des évènements système (log).

Amélioration de la virtualisation

Fedora toujours à la pointe sur ce sujet:

  • Support du LVM Thin Provisionning dans l'installeur, améliorant aussi les fonctionnalités de snapshots.
  • virt-manager supporte les snapshots/checkpoints des machines virtuelles.
  • Contrôle d'accès basé sur des rôles pour la Libvirt.
  • ARM sur x86 avec la libvirt, virt-install et virt-manager.

Pour les développeurs

A noter:

  • Ruby on Rails 4.0
  • Perl 5.18

samedi, octobre 5 2013 19:50

Réseaux GRE avec routage OSPF

Objectifs

Etablir un réseau maillé (mesh) avec des liaisons GRE. Les tables de routage seront découvertes automatiquement via le protocole OSPF (Open Shortest Path First).

Donc dans un premier temps, configurer les liaisons GRE. Dans un second temps, configurer les démons ospfd pour la partie routage.

Topologie de la maquette

Il s'agit d'une version étendue de celle utilisée pour l'article sur la configuration d'un tunnel GRE simple. Au lieu d'avoir 2 réseaux distincts, nous en avons cette fois 4.

Les 4 réseaux A, B, C, D possède un identifiant qui leur a été attribué de manière arbitraire, pour simplifier les plans d'adressage:

  • Le réseau A => 16
  • Le réseau B => 22
  • Le réseau C => 227
  • Le réseau D => 13

Pour faire simple là aussi, ces différents réseaux sont reliés entre eux par un accès WAN sur une plage d'adresse unique en 192.168.122.X. X est remplacé par l'identifiant du réseau.

Chaque réseau possède des clients utilisant une plage d'adresse privée du style 192.168.X.0/24 où X est là aussi remplacé par l'idéntifiant du réseau.

Ce qui nous donne au final:

  • Réseau A Adresse WAN 192.168.122.16 avec réseau clients 192.168.16.0/24
  • Réseau B Adresse WAN 192.168.122.22 avec réseau clients 192.168.22.0/24
  • Réseau C Adresse WAN 192.168.122.227 avec réseau clients 192.168.227.0/24
  • Réseau D Adresse WAN 192.168.122.13 avec réseau clients 192.168.13.0/24

Toujours pour simplifier, l'adresse IP du serveur OpenBSD gérant le tunnel, et faisant office de passerelle, est sous la forme 192.168.X.254.

Bref voir le schéma suivant:

Gre 4 reseaux

En fonction de la fiabilité des liens entre les différents réseaux, il est possible de ne faire que seulement 2 liens entre chaque site, pour assurer la tolérance de panne. Pour que ce soit un vrai réseau maillé, pour N noeuds, chaque N doit avoir N-1 connexions. Donc dans notre cas, 3 connexions. Celles-ci seront numérotées arbitrairement pour faciliter encore une fois la configuration, voir le schéma suivant:

Gre 4 MESH

Il n'y a pas non plus de logique dans l'attribution des adresses IP des extrémités des tunnels, j'aurais pu opter pour un adressage du style 172.16.numero_tunnel.identifiant_réseau... Peut être la prochaine fois ;)

Ce numéro de tunnel est aussi repris dans la numérotation des interfaces GRE.

Pré-requis

Il s'agit des mêmes pré-requis que pour la configuration d'un tunnel GRE simple.

Pare-feu

Dans un premier temps, pour faciliter la mise en oeuvre, n'appliquons aucun filtrage sur les interfaces GRE.

Sur tun.a

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre0
set skip on gre1
set skip on gre2

OSPF

Sur tun.b

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre0
set skip on gre3
set skip on gre4
Sur tun.c

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre1
set skip on gre3
set skip on gre5
Sur tun.d

Ajouter les lignes suivantes dans le début du fichier /etc/pf.conf:

set skip on gre2
set skip on gre4
set skip on gre5

Autorisation des tunnels GRE

Pour autoriser au niveau du noyau les tunnels de type GRE, il faut ajouter sur l'ensemble des serveurs, la ligne suivante dans /etc/sysctl.conf:

net.inet.gre.allow=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.gre.allow=1

Autorisation du routage

Pour activer le routage IP, il faut ajouter sur l'ensemble des serveurs la ligne suivante dans /etc/sysctl.conf:

net.inet.ip.forwarding=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.ip.forwarding=1

Configuration des tunnels GRE

La configuration des 3 liaisons est effectuées sur chaque serveur. Il n'y a aucune information sur le routage à ce niveau.

Sur tun.a

Configuration de la liaison gre0

Contenu du fichier de configuration /etc/hostname.gre0:

172.16.0.2 172.16.0.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.22
Configuration de la liaison gre1

Contenu du fichier de configuration /etc/hostname.gre1:

172.16.1.2 172.16.1.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.227
Configuration de la liaison gre2

Contenu du fichier de configuration /etc/hostname.gre2:

172.16.2.2 172.16.2.1 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.13

Sur tun.b

Configuration de la liaison gre0

Contenu du fichier de configuration /etc/hostname.gre0:

172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.16
Configuration de la liaison gre3

Contenu du fichier de configuration /etc/hostname.gre3:

172.16.3.1 172.16.3.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.227
Configuration de la liaison gre4

Contenu du fichier de configuration /etc/hostname.gre4:

172.16.4.1 172.16.4.2 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.13

Sur tun.c

Configuration de la liaison gre1

Contenu du fichier de configuration /etc/hostname.gre1:

172.16.1.1 172.16.1.2 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.16
Configuration de la liaison gre3

Contenu du fichier de configuration /etc/hostname.gre3:

172.16.3.2 172.16.3.1 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.22
Configuration de la liaison gre5

Contenu du fichier de configuration /etc/hostname.gre5:

172.16.5.1 172.16.5.2 netmask 0xffffffff link0 up
tunnel 192.168.122.227 192.168.122.13

Sur tun.d

Configuration de la liaison gre2

Contenu du fichier de configuration /etc/hostname.gre2:

172.16.2.1 172.16.2.2 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.16
Configuration de la liaison gre4

Contenu du fichier de configuration /etc/hostname.gre4:

172.16.4.2 172.16.4.1 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.22
Configuration de la liaison gre5

Contenu du fichier de configuration /etc/hostname.gre5:

172.16.5.2 172.16.5.1 netmask 0xffffffff link0 up
tunnel 192.168.122.13 192.168.122.227

Sur l'ensemble des serveurs

Pour activer les connexions GRE:

# sh /etc/netstart

Elles sont de toute façon activées par défaut au démarrage.

Configuration du démon OSPF

Il s'agit ici d'une configuration très simple permettant d'indiquer sur quelles interfaces le protocole OSPF doit opérer. L'interface indiquée comme passive permet à OSPFd de connaitre le reseau de cette dernière, sans faire d'annonce sur celle-ci. Les démons OSPFd dans notre cas ne peuvent en effet communiquer que via les tunnels GRE.

Sur notre maquette, l'interface reliée au réseau privé est em0.

Sur tun.a

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre0 {}
       interface gre1 {}
       interface gre2 {}
       interface em0 { passive }
}

Sur tun.b

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre0 {}
       interface gre3 {}
       interface gre4 {}
       interface em0 { passive }
}

Sur tun.c

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre1 {}
       interface gre3 {}
       interface gre5 {}
       interface em0 { passive }
}

Sur tun.d

Contenu du fichier /etc/ospfd.conf:

auth-md 1 "secret"
auth-type crypt
auth-md-keyid 1
area 0.0.0.0 {
       interface gre2 {}
       interface gre4 {}
       interface gre5 {}
       interface em0 { passive }
}

Sur l'ensemble des serveurs

Pour activer le démon ospfd par défaut au démarrage, il faut modifer le fichier /etc/rc.conf.local (le créer s'il n 'existe pas) pour avoir la ligne suivante:

ospfd_flags=""

Validation

Une fois tous les tunnels montés, et les services ospfd démarrés, ceux-ci devraient commencer à faire leurs découvertes sur les réseaux. Les routes seront échangées entre les différents démons via les annonces OSPF, constituant une base d'information de routage (ou RIB pour Routing Information Base). Pour consulter la RIB sur un serveur:

$ ospfctl show rib

Exemple sur la machine tun.a:

$ ospfctl show rib                                                                                                   
Destination          Nexthop           Path Type    Type      Cost    Uptime  
172.16.0.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36
172.16.1.2/32        172.16.1.1        Intra-Area   Network   20      01:19:58
172.16.2.2/32        172.16.2.1        Intra-Area   Network   20      01:19:39
172.16.3.1/32        172.16.1.1        Intra-Area   Network   20      00:57:57
172.16.3.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36
172.16.4.1/32        172.16.2.1        Intra-Area   Network   20      01:19:39
172.16.4.2/32        172.16.0.1        Intra-Area   Network   20      00:57:36 
172.16.5.1/32        172.16.2.1        Intra-Area   Network   20      01:19:27
172.16.5.2/32        172.16.1.1        Intra-Area   Network   20      01:19:33
192.168.13.0/24      172.16.2.1        Intra-Area   Network   20      01:19:39
192.168.22.0/24      172.16.0.1        Intra-Area   Network   20      00:57:36
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:19:58

A noté que le réseau 192.168.16.0/24 (réseau A) n'apparait pas vu qu'il s'agit du réseau local de la machine tun.a. Cette RIB nous informe que les démons ospfd a trouvé des routes pour les réseaux distants qui nous interessent, à savoir:

  • 192.168.13.0/24 (réseau D)
  • 192.168.22.0/24 (réseau B)
  • 192.168.227.0/24 (réseau C)

Un poids ou coût de 20 leur a été attribué.

Coupons maintenant la liaison GRE (numéro 0) entre tun.a et tun.b, en executant sur tun.b la commande suivante:

# ifconfig gre0 down

Regardons toujours sur tun.a, la RIB (les lignes inutiles sont masquées):

192.168.13.0/24      172.16.2.1        Intra-Area   Network   20      01:26:07
192.168.22.0/24      172.16.2.1        Intra-Area   Network   30      00:00:13
192.168.22.0/24      172.16.1.1        Intra-Area   Network   30      00:00:13
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:26:26

Le réseau B 192.168.22.0/24 n'est plus annoncé comme accessible via 172.16.0.1 (tun.a) mais par 2 nouvelles routes 172.16.2.1 (tun.d) et 172.16.1.1 (tun.c). Cela montre bien que la route défectueuse est contournée. Ce qui est confirmé par l'augmentation du coût de ces routes (30 au lieu de 20).

Coupons maintenant la liaison GRE (numero 2) entre tun.a et tun.d, voici la RIB:

192.168.13.0/24      172.16.1.1        Intra-Area   Network   30      00:00:09
192.168.22.0/24      172.16.1.1        Intra-Area   Network   30      00:04:56
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:31:09

Une route vers 192.168.22.0/24 a bien disparue.

Coupons maintenant la liaison GRE (numero 3) entre tun.c et tun.d, voici la RIB:

192.168.13.0/24      172.16.1.1        Intra-Area   Network   30      00:00:41
192.168.22.0/24      172.16.1.1        Intra-Area   Network   40      00:05:28
192.168.227.0/24     172.16.1.1        Intra-Area   Network   20      01:31:41

La route vers 192.168.22.0/24 est toujours disponible, mais a un coût elevée (40), vu que de tun.a, nous passons par tun.c puis tun.d pour joindre tun.b. Donc malgré 3 coupures notre réseau est toujours fonctionnel, du moment qu'un site possède toujours au moins 1 connexion GRE.

vendredi, octobre 4 2013 21:25

Tunnel GRE sous OpenBSD

Objectifs

Permettre de relier 2 réseaux distincts via un tunnel GRE.

Le protocole GRE permet de relier des réseaux IP différents en masquant le ou les réseaux routés intermédiaires. Pour cela un paquet IP d'un reseau A, à destination du réseau B, à l'entrée du tunnel, est encapsulé dans un autre paquet IP pour être transmis via les réseaux intermédaires (ex: internet, réseau WAN etc). Arrivé sur le réseau B, à l'autre bout du tunnel, le paquet IP est désencapsulé et peut reprendre son trajet sur le réseau B. Ainsi sur le réseau B, ce paquet ne porte plus aucune trace d'un transport sur d'autres réseaux intermédiaires.

Attention, par contre, vu qu'il s'agit d'une encapsulation d'IP sur IP, sans autre traitement, les données sont donc transmises en claire. Pour chiffrer les données, et ainsi sécuriser leur transport sur les réseaux intermédiaires, il est possible par exemple d'utiliser IPSec par dessus le tunnel GRE. Cependant, s'il s'agit de faire transiter que des flux déjà chiffrés (ssh, https, etc), GRE garde tout son intérêt, grâce à sa simplicité de mise en oeuvre, et à sa légèreté.

Topologie de la maquette

Plages d'adresses des 2 reseaux à relier:

  • 192.168.16.x pour le réseau A
  • 192.168.22.x pour le réseau B

Le réseau WAN utilisé pour le tunnel possède une plage d'ip en 192.168.122.x.

Le serveur OpenBSD sur le réseau A, appellé tun.a, possède les adresses IP suivantes:

  • 192.168.122.16 sur le réseau WAN
  • 192.168.16.254 sur le réseau A

Le serveur OpenBSD sur le réseau B, appellé tun.b, possède les adresses IP suivantes:

  • 192.168.122.22 sur le réseau WAN
  • 192.168.22.254 sur le réseau B

Voir le schéma suivant:

Tunnel GRE

Pré-requis

Pare-feu

Dans un premier temps, pour faciliter la mise en oeuvre, n'appliquons aucun filtrage sur les interfaces GRE.

Ajouter la ligne suivante, sur les 2 serveurs, dans le début du fichier /etc/pf.conf:

set skip on gre0

Autorisation des tunnels GRE

Pour autoriser au niveau du noyau les tunnels de type GRE, il faut ajouter sur les 2 serveurs, la ligne suivante dans /etc/sysctl.conf:

net.inet.gre.allow=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.gre.allow=1

Autorisation du routage

Pour activer le routage IP, il faut ajouter la ligne suivante dans /etc/sysctl.conf:

net.inet.ip.forwarding=1

Et pour l'appliquer immédiatement, taper la commande suivante:

# sysctl -w net.inet.ip.forwarding=1

Configuration

Il s'agit de configurer un tunnel utilisant les adresses suivantes à ses extrémités:

  • 172.16.0.1 sur tun.a
  • 172.16.0.2 sur tun.b

L'interface utilisée pour le tunnel sera nommée gre0 en rapport avec le protocole utilisé GRE.

Sur le serveur tun.a

Contenu du fichier /etc/hostname.gre0

172.16.0.1 172.16.0.2 netmask 0xffffffff link0 up
tunnel 192.168.122.16 192.168.122.22
!route add -net 192.168.22 -netmask 255.255.255.0 172.16.0.2

Sur le serveur tun.b

Contenu du fichier /etc/hostname.gre0

172.16.0.2 172.16.0.1 netmask 0xffffffff link0 up
tunnel 192.168.122.22 192.168.122.16
!route add -net 192.168.16 -netmask 255.255.255.0 172.16.0.1

Validation

Il faut s'assurer que le traffic est bien routé vers l'entrée du tunnel, soit le serveur OpenBSD fait office de passerelle par défaut pour les clients de son réseau, soit il faut ajouter sur ces derniers, une route pour indiquer que les flux vers réseau distant doit passer par le serveur OpenBSD.

Exemple de route à ajouter sur un client Linux du réseau A en 192.168.16.0/24:

# ip route add 192.168.22.0/24 via 192.168.16.254

La même chose pour un client Linux du réseau B en 192.168.22.0/24:

# ip route add 192.168.16.0/24 via 192.168.22.254

Ensuite un simple ping d'un client A vers un client B devrait fonctionner:

[client01.a] $ ping 192.168.22.1
host 192.168.22.1 is alive!

voila!

Exemple de trames interceptées par un tcpdump sur un des serveurs OpenBSD:

12:20:43.026311 FF:FF:00:e8:e7:aa 52:54:00:3f:44:e6 0800 122: gre 192.168.122.16 > 192.168.122.22:  192.168.16.1 > 192.168.22.1: icmp: echo request (id:7e77 seq:243) (ttl 254, id 22932, len 84) (ttl 64, id 30293, len 108)
12:20:43.027113 FF:FF:00:3f:44:e6 52:54:00:e8:e7:aa 0800 122: gre 192.168.122.22 > 192.168.122.16:  192.168.22.1 > 192.168.16.1: icmp: echo reply (id:7e77 seq:243) (ttl 254, id 7409, len 84) (ttl 64, id 33582, len 108)

Ce qui confirme que le ping est bien transmis, et que les trames GRE passent bien en claires, car on voit des paquets GRE entre nos serveurs OpenBSD avec leurs adresses IP du réseau WAN, et à l'intérieur du paquet, les requetes ICMP sur les réseaux A et B.

- page 1 de 6