VPN Site à Site

[tjacquem]

Une fonctionnalité qui manque mais que l'on peut facilement mettre en place entre 2 synos distants : un "site to site VPN".

Pour les profanes, l'idée est de créer un lien permanent entre les subnets de 2 sites. En règle générale, la réponse à ce genre de question est souvent la même : "Just create a route", et une fois encore c'est vrai. Le problème est d'avoir ces routes actives lorsque l'on en a besoin.

Hypothèses :

• Site A (Master)
  • subnet 192.168.1.0/24
  • Gateway 192.168.1.1
  • Syno en 192.168.1.10 avec VPN Server L2TP/IPSEC sur subnet 192.168.2.0/24, avec le DDNS qui va bien pour que le site B puisse le contacter
• Site B (Slave)
  • subnet 192.168.10.0/24
  • Syno en 192.168.10.10

La conf :

Sur les sites A et B :

• Utiliser le Syno local comme Gateway pour tous les clients (postes, serveurs, etc.)
• Les Synos conservent la vraie Gateway dans leur configuration ethernet
• via ssh on active le routage IPv4 en ajoutant si cela n 'y est pas déjà la ligne "net.ipv4.ip_forward = 1" dans le fichier etc/sysctl.conf

Sur le site A :

• on édite le fichier /etc/ppp/ip-up et on ajoute la route vers le site B tout à la fin du fichier : /sbin/route add -net 192.168.10.0 netmask 255.255.255.0 gw 192.168.2.0

Sur le site B :

• On créé la connexion normalement via l'interface d'admin : Panneau de configuration/Réseau, onglet "Interface réseau", bouton [créer] -> Créer un profil VPN (on oublie pas l'option de connexion automatique dedans svp)
• On édite le fichier /etc/ppp/ip-up et on ajoute la route vers le site A à la fin du bloc check_is_vpnclient_l2tp :  /sbin/route add -net 192.168.1.0 netmask 255.255.255.0 gw 192.168.2.0

Et voilà... on a un magnifique VPN site à site qui fonctionne tout seul.

MAIS, puisqu'il faut un "mais"... les routes ne survivront pas à la mise à jour du VPN server ou du DSM. Ce n'est pas grave puisque vous avez noté vos routes à entrer côté A et côté B et il suffit de modifier les fichiers /etc/ppp/ip-up à nouveau. Les Synos se voyant l'un l'autre, vous pourrez toujours rebondir en ssh d'un Syno à l'autre pour tout remettre d'équerre.

Tada !

C'est si simple qu'on se demande pourquoi ce n'est pas natif ^^

Bisous à tous ;) Mouhahaha

Modifié le 5 janvier 2017 par tjacquem
encore une fraute de fappe ;)

[PiwiLAbruti]

Tu as oublié de préciser que les clients doivent également avoir une route pour que leur trafic à destination du réseau distant soit routé par le NAS et non par la box. Ce qui d'ailleurs ne fonctionne pas avec un smartphone. Il resterait la solution d'ajouter la route au routeur (ou box si elle le permet, ce qui est très rare) pour ne rien avoir à configurer sur les clients, mais du coup le chemin de routage est moins optimisé.

Bref, ça fonctionne mais ce ne sera jamais optimal.

[tjacquem]

j'ai commencé par dire que sur chaque site il faut utiliser le syno comme Gateway ;)

du coup ça fonctionne avec tout y.c, les smartphones. J'utilise cette conf depuis 1 an entre chez moi et chez mes beaux parents.

info :ça fonctionne toujours en 6.1 ;)

[PiwiLAbruti]

Donc l'accès internet se fait par rebond sur le NAS, toujours pas très optimal ;-)

[tjacquem]

Exact. Cela dit, nous avons bien un package "Proxy server" tout à fait officiel, ce que je prends pour une démonstration de sa capacité à tenir la charge.

Cela dit, nous parlons toujours d'une petite infra, de l'ordre du privé fou ou de la PME désargentée, car il est bien évident qu'il sera toujours mieux d'utiliser des Firewalls hardwares prévus à cet effet ;)

Mais voilà, ça fait le job, et ça le fait plutôt bien, alors je partage... ;) ça me permet de gérer les PC et le syno de mes beaux parents à 2000km d'ici en Ukraine sans trop désécuriser le tout avec du visualisateur d'équipe (en français dans le texte) ou des ports ouverts de partout sur internet. Je vais d'ailleurs bientôt ajouter un lien vers chez mon père avec un autre DS712+ que j'espère récupérer bientôt.

[PiwiLAbruti]

Je ne critique absolument pas ton travail (mes propos portent parfois à confusion), c'est juste pour soulever les quelques désagréments de ce type de solution par rapport à l'idéal. Mais en attendant ça fonctionne très bien, aucun doute là-dessus.

Pour les routes à ajouter sur les NAS, tu peux les placer dans un fichier dans /usr/local. Cet emplacement survit aux mises à jour de DSM et il suffit simplement de rajouter une ligne pour dans /etc/ppp pour qu'il soit opérationnel suite à une mise à jour (. /usr/local/etc/ppp/ip-up par exemple).

[tjacquem]

Je ne l'avais pas mal pris... je trouve qu'une discussion est toujours constructive ;)

[Fenrir]

Bonne idée de tuto, quelques remarques pour apporter de l'eau à tout moulin :

-----

En DHCP tu as les options 33 (obsolètes) et 121 => https://tools.ietf.org/html/rfc3442

En gros tu peux faire ceci :

1. Box :
   1. dhcp OFF (sauf si elle permet de gérer les options DHCP, ce qui est rarissime)
2. nas A :
   1. route statique : 192.168.10.0/24 via 192.168.2.B
   2. dhcp ON
      1. il informe les clients de la passerelle par défaut (qui peut être le nas A, la box, ou autre chose ...)
      2. mais il leur donne aussi la route : 192.168.10.0/24 next-hop 192.168.1.10 (via l'option 121)
3. nas B :
   1. route statique : 192.168.1.0/24 via 192.168.2.A
   2. dhcp ON
      1. il informe les clients de la passerelle par défaut (qui peut être le nas B, la box, ou autre chose ...)
      2. mais il leur donne aussi la route : 192.168.1.0/24 next-hop 192.168.10.10 (via l'option 121)

nb : je n'ai pas testé, mais ça devrait fonctionner nativement

Il y a 4 heures, tjacquem a dit :

via ssh on active le routage IPv4 en ajoutant si cela n 'y est pas déjà la ligne "net.ipv4.ip_forward = 1" dans le fichier etc/sysctl.conf

Normalement c'est inutile, il suffit d'installer le serveur VPN sur les 2 nas (même pas besoin de s'y connecter) pour que le routage soit activé.

Autre manière graphique de faire : une simple tache planifiée en root (au boot et périodiquement au cas où) avec "echo 1 > /proc/sys/net/ipv4/ip_forward"

Il y a 4 heures, tjacquem a dit :

C'est si simple qu'on se demande pourquoi ce n'est pas natif ^^

Pour 3 raisons :

• il s'agit de NAS : des serveurs de fichiers, pas des passerelles VPN
• il s'agit de matériel grand public : rien qu'avec ton titre, tu as perdu 95% des "clients" Synology
• c'est déjà faisable en direct dans DSM

[antdid]

il y a 3 minutes, Fenrir a dit :

rien qu'avec ton titre, tu as perdu 95% des "clients" Synology

Je confirme ! Mais ça a l'air intéressant 

[tjacquem]

Merci @Fenrir pour ces informations. J'utilise déjà le DHCP des synos sur les deux sites, donc j'ai voulu 'essayer l'option 121 du DHCP, mais impossible de renseigner la valeur... je saisi 192.168.10.0/24 192.168.1.10 et lorsque je valide il ne garde rien

[Fenrir]

il y a 2 minutes, tjacquem a dit :

je saisi 192.168.10.0/24 192.168.1.10 et lorsque je valide il ne garde rien

Il y a une syntaxe à respecter, tu as des exemples dans la RFC.

nb : pour les clients windows il faut peut être rajouter l'option 249, mais elle ne semble pas présente dans l'interface syno

Exemple : https://ercpe.de/blog/pushing-static-routes-with-isc-dhcp-server

Mais bon, monter un serveur dhcp dans un coin de machine ça prend 2min et au pire, on peut toujours aller modifier la conf du syno, mais ça fait sauter l'un de mes arguments

Voici un bout de la conf d'un DHCP que j’avais monté au taf il y a quelques années (ne le prends pas tel quel, sinon tu vas avoir des surprises, c'était un hack) :

authoritative;
option msw-classless-static-routes code 249 = array of integer 8;
option rfc3442-classless-static-routes code 121 = array of integer 8;
ddns-update-style none;
log-facility local7;

set vendor-enc = option vendor-encapsulated-options;
set vendor-string = option vendor-class-identifier;
set dhcp-client = option dhcp-client-identifier;
set user = option user-class;

class "winmac" {
	match if (
		(substring (option vendor-class-identifier, 0, 4) = "MSFT")
	);
}

option domain-name-servers xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx;
option ntp-servers xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx;
option time-servers xxx.xxx.xxx.xxx, xxx.xxx.xxx.xxx;
option domain-name "xxx.xxx";

default-lease-time 600;
max-lease-time 7200;

shared-network vlan96 {
	subnet 10.96.0.0 netmask 255.255.0.0 {
		option routers 10.96.0.1;
		option broadcast-address 10.96.0.2;
	}
	pool {
		allow members of "winmac";
		range 10.96.1.1 10.96.29.255;
		option msw-classless-static-routes 10, 10, 192, 10, 96, 0, 2, 0, 10, 96, 0, 1;
		option subnet-mask 255.255.255.255;
	}
	pool {
		deny members of "winmac";
		range 10.96.30.1 10.96.31.254;
		option rfc3442-classless-static-routes 10, 10, 192, 10, 96, 0, 2, 10, 96, 0, 2;
		option subnet-mask 255.255.0.0;
	}
}

 

[JackBristow]

Hello,

J'ai un setup similaire (tunnel VPN L2TP/IPsec entre 2 NAS Synology) en place depuis quelque temps et je cherche à améliorer un peu la configuration car il y a un point qui m'embête un peu: côté serveur impossible de créer une route statique vers le LAN client via l'interface web de DSM. Au début, j'avais ajouté la route manuellement en ligne de commande, mais elle disparaissait à chaque fois que la connexion VPN est coupée/ré-établie. Du coup, pour le moment, la solution que j'ai mis en place, c'est de configurer une tache planifiée sur le serveur, qui s'exécute toutes les 30 min pour (re)créer la route:

ip route replace 192.168.10.0/24 via 192.168.2.1 dev ppp301

Ça marche plutôt bien... mais lorsque la connexion VPN est ré-établie, je dois ré-attendre jusqu'à 30min pour que la route soit remise en place... L'idéal serait que l'ajout de la route se fasse de manière automatique au démarrage du serveur ou à la connexion du client.

C'est pour ça que j'étais plein d'espoir lorsque j'ai trouvé ce post: je me suis empressé de tester la solution proposée dans l'exemple, en passant par le script /etc/ppp/ip-up.
Via les logs, je vois qu'il est bien appelé, mais sur la ligne rajoutée à la fin pour ajouter la route, j'obtiens une erreur "Permission denied".

Suis-je le seul dans ce cas? Est-ce que quelqu'un peut me confirmer que l'ajout de route via le script ip-up marche bien de son côté?
(Et si possible la version de DSM qu'il utilise, car je suis sous DSM7.2.1 : peut-être qu'il y a eu une évolution par rapport à l'époque de ce tuto écrit en 2017?)

 

Merci!

Modifié dimanche à 15:02 par JackBristow