GRE : Generic Routing Encapsulation

Avantages de GRE par rapport aux VPN conventionnels (extrait de https://supportforums.adtran.com/thread/1408) :
	"VPNs do not create routable interfaces, which means certain actions that could be taken on other interfaces cannot be taken on VPN tunnels. Also, VPNs do not allow multicast traffic to pass, therefore dynamic routing protocols, such as RIP and OSPF, are no longer options to use across VPN."

Explications similaires sur https://learningnetwork.cisco.com/thread/81746

Linux multipoint GRE tunneling : http://blog.asiantuntijakaveri.fi/2012/01/linux-multipoint-gre-tunneling.html

SUR PREMIER ORDINATEUR ("physique", dont l'IP "publique" est 192.168.6.123) :
	ip tunnel add name tigre mode gre local 192.168.6.123 remote 192.168.6.126
	lsmod |head -5		# ajout de 3 modules
	ip t
	ip link set tigre up	# le "state" reste à UNKNOWN !
	ip link show tigre
	ip r
	ip addr add 10.0.168.123/24 dev tigre
	ip addr show tigre
	ip a			# 2 autres interfaces, gretap et gre0, ont été automatiquement créées qui n'ont pas besoin d'être UP pour que le tunnel soit opérationnel ; constater également les MTU défini automatiquement pour les différentes interfaces créées
    # Attendre la mise en place de l'extrémité du tunnel (sur "SECOND ORDINATEUR" ci-dessous)
	ping 10.0.168.126
SUR SECOND ORDINATEUR ("physique" également, dont l'IP "publique" est 192.168.6.126) :
	ip tunnel add name tigre mode gre local 192.168.6.126 remote 192.168.6.123
	ip link set tigre up
	ip addr add 10.0.168.126/24 dev tigre
	ping 10.0.168.123

_____


En reprenant le trio de machines virtuelles (Ubuntu sous VirtualBox) employées auparavant pour les travaux sur les routages statique et dynamique, 

...


Installation et mise en œuvre du programme UFTP (http://uftp-multicast.sourceforge.net).
 - mise en évidence du bon fonctionnement entre 2 postes reliés directement.
 - Constat d'échec dans une tentative d'utilisation via un tunnel GRE (alors que des communications avec nc - NetCat - ne pose aucun problème).
	=> ip -d link show up	# comparer les "attributs" d'interface(s) conventionnelle(s) (comme par exemple enp0sN) et ceux de l'interface tigre pour dénoter chez cette dernière l'absence de "MULTICAST" !

Soupçonnant une omission dans les quelques documents expliquant comment mettre pratiquement en œuvre GRE, j'ai recherché "linux gre multicast issue" et la première réponse fut la bonne :
	http://bjornruud.net/2011/02/gre-tunnel-with-multicast-support.html

ATTENTION ! Bien penser à relancer le (démon "récepteur") client UFTP APRÈS que tous les réglages aient été opérés.

                                                     Internet
          CentOS                             Ubuntu     |                               Debian 
	+-----------------------+          +-------------------------------+          +-----------------------+
	|                       |  gauche  |       192.168.X.Y             |  droite  |                       |
	| Client_1  10.0.1.2/24 |<-------->| 10.0.1.1/24  Box  10.0.2.1/24 |<-------->| 10.0.2.2/24  Client_2 |
	+-----------------------+          +-------------------------------+          +-----------------------+
	Y arrêter et désactiver NetworkManager...     idem                                      idem
	ET AUSSI firewalld SUR CentOS (systemctl stop firewalld ; systemctl disable firewalld)

				... REGARDER LE RESTE DANS LE SOUS-DOSSIER gre



ACCESSOIREMENT :
	https://serverfault.com/questions/457984/how-to-force-certain-traffic-through-gre-tunnel
	https://serverfault.com/questions/359100/multiple-gre-tunnels-on-the-same-host-only-one-routes-incoming-packets

??? http://backreference.org/2013/07/23/gre-bridging-ipsec-and-nfqueue/