Installer Openvpn Sur Un Ds710+

[CaptainIgloo]

Cot

[PatrickH]

Moi je ne toucherais rien dans iptable (de plus je ne suis pas sur que la version de iptable qui est incluse dans le syno supporte toutes ces commandes !)

Par contre il te faudra rajouter une route statique dans la freebox du type :

• destination IP : 192.168.2.0
• mask : 255.255.255.0
• gateway : 192.168.1.24

cela permettra

[CaptainIgloo]

Moi je ne toucherais rien dans iptable (de plus je ne suis pas sur que la version de iptable qui est incluse dans le syno supporte toutes ces commandes !)

Par contre il te faudra rajouter une route statique dans la freebox du type :

• destination IP : 192.168.2.0
• mask : 255.255.255.0
• gateway : 192.168.1.24

cela permettra à tout équipement du segment 192.168.1.x de savoir router ses paquets vers un équipement du segment 192.168.2.y en passant par le syno qui fait ici office de "gateway"

et sur le PC portable avec lequel tu te connecte faire :

• route ADD 192.168.1.0 MASK 255.255.255.0 192.168.2.5

Et ca comme tu dois t'en douter c'est pour faire l'inverse

Patrick

La route est pushée vers le portable par le serveur (srv ovpn > push "route 192.168.1.0 255.255.255.0").

J'hérite donc déjà de cette route.

Ceci étant, je n'atteinds pas (ping) les IP du 192.168.1.0 et cela me perturbe ...

Sur la freebox je ne peux executer les commandes (à ma connaissance pas d'accès telnet ou SSH).

[PatrickH]

La route est push

[CaptainIgloo]

Pas moyen sur Freebox !

Quelqu'un a-t'il d

[PatrickH]

Pas moyen sur Freebox !

Quelqu'un a-t'il d

[CaptainIgloo]

Je viens de me lire un fil au complet ! Fiou ... : Lien vers le post en question

Comme les commandes iptable de fonctionneraient pas, il suffirait d'ajouter dans /opt/etc/init.d/S24openvpn les lignes en rouge ci-dessous.

# IP forwarding is enabled

echo 1 > /proc/sys/net/ipv4/ip_forward

echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

echo 1 > /proc/sys/net/ipv4/conf/tun0/proxy_arp

[PatrickH]

Humm... jamais essay

[CaptainIgloo]

Il y a eu un retour possitif sur un forum Qnap en appliquant la proc

[CaptainIgloo]

Il y a eu un retour possitif sur un forum Qnap en appliquant la procédure (http://forum.qnapclu...rafic-internet/).

Je testerai de retour at home ...

Je confirme cela fonctionne parfaitement avec :

echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

echo 1 > /proc/sys/net/ipv4/conf/tun0/proxy_arp

[CaptainIgloo]

Il me reste plus qu'a faire le tuto intégral !

Je peux maintenant atteindre http://mafreebox.free.fr depuis l'extérieur de chez moi en montant une session VPN depuis mon boulot par exemple.

Cela fonction même très bien avec la 3G et un petit transcodage de diffusion VLC.

Créer un diffusion depuis un PC avec VLC

Par exemple l'dresse de France 2 (Bas débit)

rtsp://mafreebox.freebox.fr/fbxtv_pub/stream?namespace=1&service=201&flavour=ld

Options

:sout=#transcode{vcodec=h264,vb=800,scale=1,acodec=mp4a,ab=128,channels=2,samplerate=44100}:std{access=http,mux=ts,dst=192.168.1.17:8080}

Cela fonctionne même très bien ....

[CaptainIgloo]

Le tuto avance ! Il sera suffisement complet j'esp

[MS_Totor]

bonjour,

pourquoi refaire un autre tuto pour 710+ ? et pourquoi le limitter uniquement au 710+ ?

l'installation de openvpn est dorénavant accessible à tous les synos depuis nos demandes répétées au support, bref tun.ko est dispo dans le firmware, mais pas bridge.ko l'autre module kernel nécessaire pour utiliser le mode bridge au lieu du mode routé.

ipkg fournit openvpn pou chaque modèle de syno, ensuite le paramétrage est commun pour tous les synos, et dépend uniquement des souhaits de l'utilisateur.

la topologie du réseau virtuel et celle du réseau local, choix du mode udp (plus fluide) ou tcp.

à partir du moment ou tu as pigé que en mode routé, la carte virtuelle (tun0) possède ces propres paramètres réseaux comme une deuxième carte réseau physique rajoutée, il suffit d'appliquer la même logique que pour du réseau/routage classique.

le serveur openvpn agit en serveur DHCP indépendant du réseau local et gère son propre réseau , et comme tout vrais serveur DHCP, (exemple serveur DHCP windows) il peut donner lors d'une demande d'attribution d'ip dynamique, ce que l'on appelle des options supplémentaires.

-ou est la passerelle

-ou est le serveur DNS, et option DNS pointant vers des services, ftp, web etc......pour l'intranet

-plage d'ip dynamique, plage réservée etc.....

-intégration à active directory etc... etc....

En relisant ton propos, je me rends compte que cette partie est un peu confuse, d'où mon complément pour éclairer sur la façon dont est géré la chose.

en faisant complètement abstraction du réseau local existant vu des clients , sur la carte tun0, le reseau doit être diffèrent de celui du réseau local (pas obligatoire, mais sans rentrer dans les détails, utile quand on ne connais pas le réseau) , et doit etre different également des réseaux les plus souvent rencontrés à l'extérieur, ciber café , adressage ip classique via xxbox très souvent en

-192.168.1.0 (255.255.255.0) ou /24

-192.168.0.0 (255.255.255.0) ou /24

pourquoi ?

pour éviter des conflit d'adresses IP en adressage ip dynamique, le client sur internet et dans son réseau local recevrai la même ip sur ses deux cartes réseaux (physique et virtuelle), ou le reseau local du client aurais déjà une ip exemple 192.168.0.10 déjà prise par un serveur , et via sa carte virtuelle, rencontrerai un conflit avec un autre appareil ayant la même ip dans le réseau local "distant/maison ", celui du syno ou d'un pc)

bref: l'adressage ip du serveur vpn pourrais être tout ce que tu veux à partir du moment ou cet adressage n'est pas sur le même sous réseau que les reseau "locaux" distant et local selon que l'on regarde depuis le réseau ou est situé le syno, ou si on regarde depuis le réseau ou est situé le client.

bref 192.168.100.0 ou 192.168.50.0 etc vont très bien et ce sont des adresses faciles à retenir...

de même, pratiquant openvpn depuis 2000, il est judicieux de changer la topographie du réseau local ou est situé un serveur openvpn, et de le passer en 192.168.10.0, et là jamais de conflit et facile de tracer les paquets, et pas de souci comme quoi le routeur n'est pas accessible depuis l'exterieur

à cette étape, ton client via sa carte virtuelle auras donc une ip dynamique (exemple) 192.168.100.5 et via sa carte physique exemple 192.168.1.20

il a déjà via sa carte physique une passerelle et un DNS donnés par une xxxbox , mais la carte virtuelle en 192.168.100.5 ?

bien sur que non, cette carte virtuelle auras ses propres informations via l'autre serveur DHCP ( et les infos de DNS et passerelle) via le fichier client fabriqué à partir de la configuration du serveur openvpn.

d'où l'importance dès le départ de comprendre comment gérer les options qui seront transmises aux clients.

la doc la dessus est dispo sur le forum)

option push , ce sont des options que l'on transmet au client en même temps que l'adresse ip.

concernent en général

-l'ip de la passerelle

-l'ip du DNS..

à ce stade une fois la connexion effectuée, le client a comme dans l'exemple du dessus une ip 192.168.100.5 sur sa carte virtuelle, et ne peut voir ou pinguer que ce qu'il y a sur ce réseau, seul le syno est sur ce réseau (exemple 192.168.100.1 ) !! son firewall doit être réglé en conséquence, sinon pas de ping.

pour accéder au réseau local "maison" voir le reste des pc etc... on doit donc rajouter une route, pour que les paquets transitant sur la boucle 192.168.100.0 puissent aller vers le réseau local " maison" exemple 192.168.10.0

push "route 192.168.10.0 255.255.255.0"

pour que les paquets soit re dirigés il faut soit forwarder ces paquets soit passer par un proxy,

activer le forward

echo 1 > /proc/sys/net/ipv4/ip_forward

et via iptables on redirige les flux venant de 192.168.100.0 vers le réseau local "maison"

iptables -A FORWARD -i tun0 -s 192.168.100.0/24 -d 192.168.10.0/24 -j ACCEPT

ou tu peux restreindre un accès unique si le client à une ip réservée et donc statique

iptables -A FORWARD -i tun0 -s 192.168.100.5 -d 192.168.10.0/24 -j ACCEPT

dernier truc, dans la conf du serveur, la chose très souvent oubliée !!

ajoutez cette directive

client-config-dir ccd

puis créer dans l'arborescence de openvpn si il n'existe pas le repertoire ccd, puis créer le fichier client2 (exemple)

avec comme contenu la ligne

iroute 192.168.10.0 255.255.255.0

relancer le serveur.

pourquoi route et iroute ?

route contrôle le routage au niveau noyau du kernel vers openvpn via l'interface tun

iroute gère le routage entre openvpn et le client, ici client2

on pourrait créer plusieurs clients globaux, dont seul certains peuvent voir tout l'ensemble du réseau distant "maison",

y compris le routeur de la maison, les autres n'ont accès qu'au syno et ces ressources.

fin de mon blabla, c'est un petit extrait du tuto général sur openvpn dédié aux synos sur mon site, avec quelques commentaires , mais le site est en travaux actuellement donc pas disponible.

bonne journée

@++

[CaptainIgloo]

Oui merci pour tes pr

[CaptainIgloo]

Ma technique (sans iptable):

Je dispose d'un adressage sur le réseau local du serveur sur le plan d'adressage 192.168.1.0.

Je vais limiter l'etendue DCHP jusqu'a l'adresse 192.168.1.126 afin d'utiliser en subneting la deuxième partie pour le réseau VPN.

(Voir comment limiter l'adressage sur vos matériels respectif)

- Sur un Subnet de Class C

Je disvise en 2 subnets mon réseau local pour obtenir 126 IP dans mon sous-réseau VPN (en réalité PTP j'aurai 63 connexion possibles).

Mon subnet ID VPN sera 192.168.1.128 avec un masque 255.255.255.128 (192.168.1.128/26)

L'étendue VPN ira de 192.168.1.129 - 192.168.1.254.

Si vous voulez opérer autrement : http://www.subnet-calculator.com/

J'ajoute les lignes en gras dans le script de démarrage S24openvpn :

# enable IP forwarding

echo 1 > /proc/sys/net/ipv4/ip_forward

echo 1 > /proc/sys/net/ipv4/conf/eth0/proxy_arp

echo 1 > /proc/sys/net/ipv4/conf/tun0/proxy_arp

Dans le fichier de configuration du serveur :

server 192.168.1.128 255.255.255.128

Je désactive le push de routes

;push "route ..."

Je pousse la passerelle

push "redirect-gateway def1"

Je pousse le DNS Free

push "dhcp-option DNS 212.27.40.240"

Je permets aux stations de ce voir

client-to-client

Tu trouves ma config inadaptée ?

Par contre, je réfléchis à une solution adaptée pour la résolution de noms locale. Bind, Host, natif dans Openvpn ?

[CaptainIgloo]

choix du mode udp (plus fluide) ou tcp.

Est-ce une certitude que le mode UDP est plus fluide ?

En th

[MS_Totor]

bonsoir

je ne dis pas que la config est mauvaise..... !

c'est une approche différente

par contre n'oublie pas le trafic généré sur une simple box, le volume par client est plus élevé qu'un simple ftp, d'où ma question, quel intérêt de fournir autant d'ip dispo ?

combien de client simultané est ce que tu compte avoir en fait

l'encapsulation vpn selon le cryptage choisit peut poser soucis en terme de MTU, car selon le cryptage , tu peux avoir des pertes de paquets et pas mal de fragmentations et le temps de latence en traitement ralentiras le trafic..évites un truc paranoïde...

je n'ai plus le tableaux MTU vs cryptage pour t'apporter des éléments sur le meilleur compromis, mais cela doit encore ce trouver sur le net, openvpn le gère très bien automatiquement normalement mais parfois pas du tout, et c'est la principale source à problème que j'ai du dépanner ....

pour la question de la résolution de nom, tu peux déclarer chaque ressource à pousser au client, via dhcp option ( comme un service ) ou jouer sur les hosts

perso j'ai installé bind, car j'en avais besoin également en virtualisation de serveurs, et ensuite faire un push du serveur dns syno au client, c'est lui qui gèrera ensuite la redirection vers d'autres noms de domaines externes au réseau local, soit vers ton provider free, soit vers un dns externe privé, le choix dns à pousser dépends des droits accordés aux client en fait, et via le bind tu peux accorder également qui peut faire des requêtes sur le serveur....

vaste choix de filtrage, sans parler de proxy

dans toutes les installations que j'ai fait, systématiquement je jouais avec plusieurs clients, et une config directement dédié à l'admin, une aux synchros/sauvegardes, une à l'intranet.

mais depuis quelques années je suis revenu petit à petit à l'encapsulation ssh par choix, et quasi presque plus rien en vpn, donc un peu rouillé

[CaptainIgloo]

bonsoir

je ne dis pas que la config est mauvaise..... !

c'est une approche différente

par contre n'oublie pas le trafic généré sur une simple box, le volume par client est plus élevé qu'un simple ftp, d'où ma question, quel intérêt de fournir autant d'ip dispo ?

combien de client simultané est ce que tu compte avoir en fait

Probablement moins de 5 (max), mais pour la démo, j'ai simplifié le sunbeting /26.

Un masque 255.255.255.248 (/29) doit me suffir.

Mon Syno est 100% à l'usage perso.

[CaptainIgloo]

bonsoir

pour la question de la r

[MS_Totor]

je n'ai pas mes archives dispo pour pusher des resolv, je regarde cela demain, time to miam

pour ssh, de simples sockets sur les principaux services te permettent de faire du ftp over ssh, http over ssh https over ssh ou l'inverse, tout le trafic est encapsulé

avec une gestion des bi clé avec un agent ssh, de type pagent sous windows, tu ne rentre qu'une fois le mot de passe pour un serveur, ou pour plusieurs serveurs à la fois, si les clé sont identiques.

je m'en sert tous les jours pour de la gestion serveur distant, le serveur distant est fermé à tout via iptables sauf un port ssh et , le socket lie mon appel depuis mon réseau local https au serveur openssh du serveur distant puis le forwarde https/site d'administration comme un appel en boucle interne, bref vu de l'extérieur tout est blindé, alors qu'en fait il y a bien sur plusieurs sites en phase de tests sur le port 81, plusieurs ports accessibles, ftp etc...

shorewall est génial pour ca, car il crée deux interfaces dans le process iptables, ce qui permet malgré une simple carte réseau, de gérer le trafic entrant/sortant comme un routeur à deux interfaces, je bosse quand j'ai le temps pour l'intégrer au syno, avec bind cela sera parfait en administration.

si je veux me servir de mon serveur depuis l'extérieur pour aller ailleurs, rien de plus simple, via cette méthode, puisque c'est le syno qui transmet le paquet vers le site désiré, la requête initiale https vient bien de mon portable mais à transité en ssh jusqu'au syno, et ressort du syno en https vers le site désiré, proxy quoi...

[CaptainIgloo]

je n'ai pas mes archives dispo pour pusher des resolv, je regarde cela demain, time to miam

pour ssh, de simples sockets sur les principaux services te permettent de faire du ftp over ssh, http over ssh https over ssh ou l'inverse, tout le trafic est encapsul

[MS_Totor]

bonjour,

loin de moi l'idée de te disperser, je viens de me relire et je suis largement hs du thème abordé initialement, puisque je t'oriente petit à petit vers la solution ssh.

j'arrête donc cette partie là que nous pourrons débattre section modifications logicielles, section plus dédiée à ce genre de causette.

juste un petit mot pour en terminer sur le sujet, ssh c'est la solution standard justement, vu du côté client n'importe quel OS, intègre facilement l'équivalent de putty.

pour le vpn, comme nous le répétons souvent, un simple petit routeur de type wrt54gl, et dd-wrt, intègre openvpn et un iptables complet, ceci pour parer aux manques de paquets integrés aux synos, ou souvent bridés pour satisfaire la lois de la performance vs le nombre de programme qui tournent, du moins c'est la politique d'intégration synology.

je ne vois plus comment pusher de la résolution de noms mis à part déclarer un serveur DNS gérant le domaine local au bout du tunel..

je crois que si bind est trop lourd pour ton utilisation, le fichier host sera la seule solution vu le faible nombre de client.

comme les paquets venant de la boucle vpn sont re routé par le server vpn en bout de chaine vers le segment réseau que tu as décrit plus haut , une ressource commenté dans le host et hop

"le site ou les ressources situés à l'autre bout du tunel, seront accessible sans soucis"

MAIS ....vérifie bien également les paramètres des services sur le syno, par defaut, les services comme web, ftp ssh etc, écoutent sur toutes les interfaces réseaux disponibles, donc aussi bien sur eth0 que sur tun0, ce qui ne convient peut être pas à tes règles de filtrages...

pour ssh tu peux déclarer par exemple dans sshd_config l'ip sur la quelle tu veux écouter, par defaut si rien n'est changé c'est 0.0.0.0 donc tout quoi.

perso sur le syno je gère openvpn via un module dédié sous webmin, c'est bien plus visuel et pratique ..

le temps de mettre à jour une partie du site et je te filerai un lien sous peu, pour une vue d'ensemble

bon je file

@ ++

[CaptainIgloo]

perso sur le syno je g

[MS_Totor]

bien utilis

[CaptainIgloo]

bien utilis