VPN entre machine publique et privées

spam wrote:

Bonjour!

Voilà mon problème: Nous utilisons OpenVpn pour relier nos serveurs
hébergés à notre LAN. Le problème est que nous avons placé des serveurs
locaux chez nos clients dont la plupart utilisent des routeurs idiots
qui servent juste de passerelle. De plus ils n'ont pas d'adresse IP
fixe. L'idée serait que ce soit eux qui initialisent une connexion vers
notre tête de réseau VPN qui elle est accessible publiquement.
OpenVpn semble nécessiter que les deux machines se voient...
Inutile de préciser que toutes ces machines sont sous linux.

Quelle solution technique préconisez vous ?
Pour ma part ayant été échaudé très tôt des solutions commerciales du marché

j'ai développé il y a 3 ans un routeur polyvalent (*) qui assure lui-même
les connexions de ce type et assure également l'accès Internet s'il y a
lieu.

Maintenant vous pouvez très bien porter la fonction d'initialisation VPN sur
votre serveur hébergé mais ce n'est pas très élégant. En effet, un serveur
est un serveur et doit se limiter à cette tâche.

Quoi qu'il en soit si vous faites ce dernier choix, il n'y a pas de problème
particulier. Il vous suffira de régler le routeur idiot afin qu'il achemine
les communications selon le protocole UDP sur port 500 ainsi que le
protocole 50 (ESP) vers votre serveur. Cela s'appelle du port forwarding.
Rien ne vous empêche d'y ajouter une fonction de filtrage afin de ne
permettre cet acheminement que depuis votre tête de pont.

Si votre routeur est un routeur bas de gamme il sera incapable d'acheminer
le protocole 50 (ceci est valable en 2004 mais ne le sera sans doute plus
en 2005).
Du coup s'offrent à vous 3 solutions :
travailler en NAT-T (NAT traversal, un procédé conçu pour s'affranchir de
ces routeurs). Le NAT-T consiste à encapsuler l'ESP dans de l'UDP sur un
port à définir. Etant donné qu'il s'agit d'UDP tous les routeurs du marché
savent l'acheminer (mais tous ne savent pas forcément l'acheminer sur un
port non bien-connu [Well-known])

Voir si le routeur idiot n'est pas capable d'établir lui-même un tunnel
IPSEC (de plus en plus sont capables de la faire mais, hélas,
uniquementuavec un secret partagé et non des certificats X509) ;

Remplacer le routeur idiot par un vrai routeur pratiquant le full-NAT.

db


(*) Ce routeur est sous Linux, ne comporte pas de disque ni de ventilateur.
Il est donc silencieux et possède la taille d'un hub huit ports.
Ce routeur est évolutif, il n'est pas que routeur (RIPv1, RIPv2, OSPF ou
BGP4+) mais également pont, pont-routant, firewall, clien ou serveur VPN.
Il est capable d'appliquer une politique de qualité de service définie en
local ou reçue via COPS ou d'autres protocoles, peut être équipé d'un
détecteur d'intusion, d'un relais de mails, d'un antivirus/antispam, selon
le besoin du client. Enfin, il possède 3 interfaces Ethernet et 2 ports USB
1.1. et peut malgré tout contenir un disque dur. Sa consommation est de
l'ordre de 30W (sans disque). Un autre modèle consomme moins de 10W,
peut-être téléalimenté (via 802.3af) mais ne dispose que de 2 interfaces
Ethernet, 2 PCMCIA et 1 miniPCI.

"@(spam)yannos.com" <""yann(no)"@(spam)yannos.com"> wrote in message
news:c4r3fg$10sc$1@biggoron.nerim.net

Voilà mon problème: Nous utilisons OpenVpn pour relier nos serveurs
hébergés à notre LAN. Le problème est que nous avons placé des serveurs
locaux chez nos clients dont la plupart utilisent des routeurs idiots
qui servent juste de passerelle.

C'est quoi un routeur idiot ?
Si les serveurs ont des adresses privées, il doit faire de la NAT.

De plus ils n'ont pas d'adresse IP
fixe. L'idée serait que ce soit eux qui initialisent une connexion vers
notre tête de réseau VPN qui elle est accessible publiquement.
OpenVpn semble nécessiter que les deux machines se voient...

C'est quoi des machines qui se voient ?
OpenVPN nécessite qu'une des parties puisse voir l'autre, et pas
obligatoirement vice versa à partir du moment ou la connexion est
établlie.

Inutile de préciser que toutes ces machines sont sous linux.

Que du bonheur.

Quelle solution technique préconisez vous ?

Utilisation d'un DNS dynamique par exemple.
Tout du moins, il faudrait une description plus précise de
l'environnement pour y voir plus clair. Mais OpenVPN me semble être la
bonne solution dans un environnement naté avec serveurs à adressage
privé.



--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

"@(spam)yannos.com" <""yann(no)"@(spam)yannos.com"> wrote in message
news:c4r3fg$10sc$1@biggoron.nerim.net

Voilà mon problème: Nous utilisons OpenVpn pour relier nos serveurs
hébergés à notre LAN. Le problème est que nous avons placé des serveurs
locaux chez nos clients dont la plupart utilisent des routeurs idiots
qui servent juste de passerelle.

C'est quoi un routeur idiot ?
Si les serveurs ont des adresses privées, il doit faire de la NAT.

De plus ils n'ont pas d'adresse IP
fixe. L'idée serait que ce soit eux qui initialisent une connexion vers
notre tête de réseau VPN qui elle est accessible publiquement.
OpenVpn semble nécessiter que les deux machines se voient...

C'est quoi des machines qui se voient ?
OpenVPN nécessite qu'une des parties puisse voir l'autre, et pas
obligatoirement vice versa à partir du moment ou la connexion est
établlie.

Inutile de préciser que toutes ces machines sont sous linux.

Que du bonheur.

Quelle solution technique préconisez vous ?

Utilisation d'un DNS dynamique par exemple.
Tout du moins, il faudrait une description plus précise de
l'environnement pour y voir plus clair. Mais OpenVPN me semble être la
bonne solution dans un environnement naté avec serveurs à adressage
privé.



--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

"@(spam)yannos.com" <""yann(no)"@(spam)yannos.com"> wrote in message
news:c4r3fg$10sc$1@biggoron.nerim.net

Voilà mon problème: Nous utilisons OpenVpn pour relier nos serveur s
hébergés à notre LAN. Le problème est que nous avons placé de s serveurs
locaux chez nos clients dont la plupart utilisent des routeurs idiots
qui servent juste de passerelle.

C'est quoi un routeur idiot ?
Si les serveurs ont des adresses privées, il doit faire de la NAT.

De plus ils n'ont pas d'adresse IP
fixe. L'idée serait que ce soit eux qui initialisent une connexion ve rs
notre tête de réseau VPN qui elle est accessible publiquement.
OpenVpn semble nécessiter que les deux machines se voient...

C'est quoi des machines qui se voient ?
OpenVPN nécessite qu'une des parties puisse voir l'autre, et pas
obligatoirement vice versa à partir du moment ou la connexion est
établlie.

Inutile de préciser que toutes ces machines sont sous linux.

Que du bonheur.

Quelle solution technique préconisez vous ?

Utilisation d'un DNS dynamique par exemple.
Tout du moins, il faudrait une description plus précise de
l'environnement pour y voir plus clair. Mais OpenVPN me semble être l a
bonne solution dans un environnement naté avec serveurs à adressage
privé.



Ok, en gros, j'ai:

Tête VPN --- Firewall --- DMZ --- Firewall ----------- internet


de mon côté et


internet ------------ Routeur passerelle idiot --- serveur à maintenir


Il faut préciser que le client n'est pas en IP fixe... je souhaiterais
donc que ce soit le serveur de son côté qui établisse la connexion.

Comme je le disais, je ne peux intervenir sur le routeur pour l'instant
sinon le pb serait réglé.

Par contre, je dispose de plusieurs machines en ligne chez des
hébergeurs ainsi que d'une adresse ip fixe localement.

De plus, je dispose de 4 DNS sous bind, mais 3 sont des esclaves du 4
eme qui est chez nous.

Voilà, j'espère que c'est plus clair !

Merci pour votre aide !

--
@+ Yann Marigo

spam wrote:

"@(spam)yannos.com" <""yann(no)"@(spam)yannos.com"> wrote in message
news:c4r3fg$10sc$1@biggoron.nerim.net

Voilà mon problème: Nous utilisons OpenVpn pour relier nos serveurs
hébergés à notre LAN. Le problème est que nous avons placé des serveurs
locaux chez nos clients dont la plupart utilisent des routeurs idiots
qui servent juste de passerelle.

C'est quoi un routeur idiot ?
Si les serveurs ont des adresses privées, il doit faire de la NAT.

De plus ils n'ont pas d'adresse IP
fixe. L'idée serait que ce soit eux qui initialisent une connexion vers
notre tête de réseau VPN qui elle est accessible publiquement.
OpenVpn semble nécessiter que les deux machines se voient...

C'est quoi des machines qui se voient ?
OpenVPN nécessite qu'une des parties puisse voir l'autre, et pas
obligatoirement vice versa à partir du moment ou la connexion est
établlie.

Inutile de préciser que toutes ces machines sont sous linux.

Que du bonheur.

Quelle solution technique préconisez vous ?

Utilisation d'un DNS dynamique par exemple.
Tout du moins, il faudrait une description plus précise de
l'environnement pour y voir plus clair. Mais OpenVPN me semble être la
bonne solution dans un environnement naté avec serveurs à adressage
privé.



Ok, en gros, j'ai:

Tête VPN --- Firewall --- DMZ --- Firewall ----------- internet


de mon côté et


internet ------------ Routeur passerelle idiot --- serveur à maintenir



Il faut préciser que le client n'est pas en IP fixe... je souhaiterais
donc que ce soit le serveur de son côté qui établisse la connexion.

Oui, oui c'est bien ainsi que je l'avais compris.

Comme je le disais, je ne peux intervenir sur le routeur pour l'instant
sinon le pb serait réglé.
Effectivement et nous ne serions pas là à causer à des heures indues.

Par contre, je dispose de plusieurs machines en ligne chez des
hébergeurs ainsi que d'une adresse ip fixe localement.
Le souci n'est PAS l'adresse dynamique. Cela fait un bail que l'on fait du

VPN avec des nomades.
Le souci est le routeur idiot. Pas tellement qu'il soit idiot (c'est à dire
non full NAT) mais le fait que vous ne puissiez intervenir dessus ou faire
intervenir qqun.
Car pour faire ce que vous voulez faire inutile d'avoir un routeur dernier
cri seulement un routeur routant et capable d'acheminer les ports (port
forwarding).

En effet, sans aucune intervention et en utilisant NAT-T (vu qu'il s'agit
d'un routeur idiot) vous parviendrez à établir le tunnel AU DEPART de votre
serveur hébergé sans problème.
Mais ce tunnel sera alors amputé de la moitié de sa capacité d'acheminement.
C'est à dire que les paquets partant de votre serveur hébergé arriveront
bien à destination (sur votre réseau principal) une fois que vous aurez
paramétré vos différents firewall afin de laisser passer les bons
protocoles (voir mon mail précédent).
Mais le retour sera plus ... hasardeux et dépendra directement des capacités
stateful de votre routeur idiot. Pas de stateful : inutile d'y songer sans
possibilité de régler le port forwarding. Stateful : alors la plupart des
flux TCP feront l'aller et retour sans problème et ce sera plus délicat
pour UDP (les routeurs stateful expirent très vite les entrées UDP de la
table de connexion). Mais surtout même stateful, il vous sera impossible de
communiquer avec vos serveurs hébergés à l'initiative de votre réseau
principal ceci MEME si votre tunnel est parfaitement établi !

De plus, je dispose de 4 DNS sous bind, mais 3 sont des esclaves du 4
eme qui est chez nous.
Pourquoi parlez-vous de BIND ? BIND n'a RIEN à voir là-dedans !

db

spam wrote:

"@(spam)yannos.com" <""yann(no)"@(spam)yannos.com"> wrote in message
news:c4r3fg$10sc$1@biggoron.nerim.net

Voilà mon problème: Nous utilisons OpenVpn pour relier nos serveu rs
hébergés à notre LAN. Le problème est que nous avons placé des serveurs
locaux chez nos clients dont la plupart utilisent des routeurs idiots
qui servent juste de passerelle.

C'est quoi un routeur idiot ?
Si les serveurs ont des adresses privées, il doit faire de la NAT.

De plus ils n'ont pas d'adresse IP
fixe. L'idée serait que ce soit eux qui initialisent une connexion vers
notre tête de réseau VPN qui elle est accessible publiquement.
OpenVpn semble nécessiter que les deux machines se voient...

C'est quoi des machines qui se voient ?
OpenVPN nécessite qu'une des parties puisse voir l'autre, et pas
obligatoirement vice versa à partir du moment ou la connexion est
établlie.

Inutile de préciser que toutes ces machines sont sous linux.

Que du bonheur.

Quelle solution technique préconisez vous ?

Utilisation d'un DNS dynamique par exemple.
Tout du moins, il faudrait une description plus précise de
l'environnement pour y voir plus clair. Mais OpenVPN me semble être la
bonne solution dans un environnement naté avec serveurs à adressag e
privé.

Ok, en gros, j'ai:


Tête VPN --- Firewall --- DMZ --- Firewall ----------- internet


de mon côté et


internet ------------ Routeur passerelle idiot --- serveur à mainteni r

Il faut préciser que le client n'est pas en IP fixe... je souhaiterai s
donc que ce soit le serveur de son côté qui établisse la connexio n.

Oui, oui c'est bien ainsi que je l'avais compris.

Comme je le disais, je ne peux intervenir sur le routeur pour l'instant
sinon le pb serait réglé.

Effectivement et nous ne serions pas là à causer à des heures ind ues.

Par contre, je dispose de plusieurs machines en ligne chez des
hébergeurs ainsi que d'une adresse ip fixe localement.

Le souci n'est PAS l'adresse dynamique. Cela fait un bail que l'on fait du
VPN avec des nomades.

Ben là, c'est un peu le cas, son ip est nomade :)

Le souci est le routeur idiot. Pas tellement qu'il soit idiot (c'est à dire
non full NAT) mais le fait que vous ne puissiez intervenir dessus ou fa ire
intervenir qqun.
Car pour faire ce que vous voulez faire inutile d'avoir un routeur dern ier
cri seulement un routeur routant et capable d'acheminer les ports (port
forwarding).

Oui, je suis bien conscient que si j'acheminais le port nécessaire en
frontal, je me retrouverais dans un cas d'école, mais ce serait trop
simple :)

En effet, sans aucune intervention et en utilisant NAT-T (vu qu'il s'ag it
d'un routeur idiot) vous parviendrez à établir le tunnel AU DEPART de votre
serveur hébergé sans problème.
Mais ce tunnel sera alors amputé de la moitié de sa capacité d'ac heminement.
C'est à dire que les paquets partant de votre serveur hébergé arr iveront
bien à destination (sur votre réseau principal) une fois que vous a urez
paramétré vos différents firewall afin de laisser passer les bons
protocoles (voir mon mail précédent).

C'est déjà le cas.

Mais le retour sera plus ... hasardeux et dépendra directement des ca pacités
stateful de votre routeur idiot. Pas de stateful : inutile d'y songer s ans
possibilité de régler le port forwarding. Stateful : alors la plupa rt des
flux TCP feront l'aller et retour sans problème et ce sera plus dél icat
pour UDP (les routeurs stateful expirent très vite les entrées UDP de la
table de connexion). Mais surtout même stateful, il vous sera impossi ble de
communiquer avec vos serveurs hébergés à l'initiative de votre ré seau
principal ceci MEME si votre tunnel est parfaitement établi !

Il em semble que votre résonnement a une faille (sans être agressif) :
J'arrive parfaitement à initialiser des dialogues en utilisant un
reverse SSH initialisé lui par le serveur côté client. Celà parai t
logique. A partir du moment où une machine est visible et que l'autre,
même derrière plusieurs firewall en cascade et sans NAT, initialise l a
connexion (sur le port 22, 80,...ce que vous voulez), la communication
ne pose aucun problème. Du moment que la connexion point à point est
établie par la machine derrière le routeur, il n'y a plus de soucis e t
plus besoin de NAT ou de port-forwarding ! L'exemple du SSH est flagrant!

Notre tête VPN nous sert en fait de passerelle vers notre sous-réseau
VPN. En gros, on la désigne comme passerelle pour accèder au 192.168. 2.0.
De son côté, elle utilise des TUN/TAP drivers pour créer des interf ace
réseau virtuelles que nous filtrons. Vu de nos postes du LAN, les
machines de notre VPN nous semblent tout aussi accessibles que celles de
la DMZ. Avec ce système de fonctionnement, nous n'établissons jamais de
tunneldepuis notre réseau interne, ce sont toujours les machines
distantes qui le font. Une fois le tunnel établi et maintenu par une
machine distante, il n'y aucun problème pour initialiser une connexion
qui sera expédiée via ce tunnel.

De plus, je dispose de 4 DNS sous bind, mais 3 sont des esclaves du 4
eme qui est chez nous.

Pourquoi parlez-vous de BIND ? BIND n'a RIEN à voir là-dedans !

On parlais d'adresse ip non fixes non ?
Une des solutions proposée était de mettre en place un système à la
dynip... d'où les infos sur bind :)


En gros, nous savons que c'est possible, mais nous cherchons les modes à
utiliser...

Merci pour tout.

--
@+ Yann Marigo

"@(spam)yannos.com" <""yann(no)"@(spam)yannos.com"> wrote in message
news:c4v8sr$67l$1@biggoron.nerim.net

Tête VPN --- Firewall --- DMZ --- Firewall ----------- internet
de mon côté et
internet ------------ Routeur passerelle idiot --- serveur à maintenir

Et les adresses ??? ce sont des adresses publiques ou privées ?
Ca a son importance pour savoir si vous devez faire du port
forwarding d'un coté ou non (voir la faq sur la NAT
<http://www.lalitte.com/nat>)

Il faut préciser que le client n'est pas en IP fixe... je souhaiterais
donc que ce soit le serveur de son côté qui établisse la connexion.

Oui, mais un DNS dynamique public devrait vous affranchir de ce
problème. Du moins, si on sait quelles sont les adresses exactement.

Comme je le disais, je ne peux intervenir sur le routeur pour l'instant
sinon le pb serait réglé.

Si les connexions peuvent être initialisés depuis derrière ce routeur,
ce n'est pas gênant.

Par contre, je dispose de plusieurs machines en ligne chez des
hébergeurs ainsi que d'une adresse ip fixe localement.

Le fait d'avoir des adresses IP fixes ou non n'est pas gênant à
partir du moment ou vous pouvez faire une résolution dynamique qui
vous donne la bonne adresse IP à un instant t.

De plus, je dispose de 4 DNS sous bind, mais 3 sont des esclaves du 4
eme qui est chez nous.

A priori, vous feriez mieux d'utiliser un service externe gratuit
comme dyndns qui fera le boulot sans trop se casser la binette ;-)

Voilà, j'espère que c'est plus clair !

Pas encore, il faut les adressages !!!

Pour info, j'ai déjà mis en place une telle solution avec des adresses
privées des deux cotés et des IP publiques dynamiques, ca marchait
nickel (OpenVPN passe la NAT sans problème contrairement à IPsec)


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG

Tête VPN (192.168.1.2)--- Firewall (192.168.1.1) --- DMZ (192.168.0.*)
--- Firewall (192.168.0.1)/(ip fixe) ----------- internet

de mon côté et

internet ------------ (ip dynamique)/(192.168.1.1) Routeur passerelle
idiot --- (192.168.1.232) serveur à maintenir

côté client.


J'espère que c'est limpide là :-)

Merci encore

--
@+ Yann Marigo

"@(spam)yannos.com" <""yann(no)"@(spam)yannos.com"> wrote in message
news:c517e6$133a$1@biggoron.nerim.net

Tête VPN (192.168.1.2)--- Firewall (192.168.1.1) --- DMZ (192.168.0.*)
--- Firewall (192.168.0.1)/(ip fixe) ----------- internet
de mon côté et
internet ------------ (ip dynamique)/(192.168.1.1) Routeur passerelle
idiot --- (192.168.1.232) serveur à maintenir
côté client.
J'espère que c'est limpide là :-)

Yep ;-)

Alors, le plus simple à mon avis.
1- Dans la config OpenVPN coté idiot :-), mettre l'IP fixe à joindre
de l'autre coté.
2- Faire du port forwarding sur le firewall relié au net de ton coté
pour rediriger les connexion OpenVPN vers ta bécane 192.168.1.2.
(port utilisé, surement 500 UDP, vers 192.168.1.2)
3- Mettre en place un nom dyndns pour pointer l'adresse IP dynamique
(Voir dyndns.org)
4- Dans la config OpenVPN de ton coté, mettre le nom dyndns
correspondant à l'IP dynamique de l'autre coté
(5)- A priori, utiliser un script auto qui relance le tunnel en cas
de changement d'IP

Et ca devrait rouler !


--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG