Bonsoir la liste,

Merci pour toutes vos réponses sur l'IP publique et sur le suivi de l'IP 
dynamique.


J'ai donc installé la partie serveur d'OpenVPN en tant que plateforme de tests 
sur une machine de mon sous-réseau.

J'ai vérifié si l'installation était opérationnelle même si toutes les options 
ne sont pas encore bien définies, ni bien claires dans ma compréhension.

Le service me semble actif avec ps -ef :
# openvpn  18900 18527  0 22:36 pts/3    00:00:00 
openvpn --config /etc/openvpn/server/server.conf

Son interface tun0 a été créée en 10.8.0.1

Il est aussi visible depuis mon sous-réseau :
$ nmap -p 0-65535 -sT -sV -PT 192.168.3.106
80/tcp    open  http    Apache httpd 2.2.9 ((Debian))
111/tcp   open  rpcbind
1194/tcp  open  unknown
4559/tcp  open  hylafax HylaFAX 4.4.4
9527/tcp  open  ssh      (protocol 2.0)
50986/tcp open  rpcbind

Mais pas son interface tun0 :
$ nmap -p 0-65535 -sT -sV -PT 10.8.0.1
80/tcp open  http-proxy Squid webproxy 2.6.STABLE21

Je me demande comment les futurs clients vont réussir à le trouver...


De plus, une route par défaut a été créée vers la passerelle sur le même brin 
du sous-réseau.
J'imagine que c'est normal puisqu'un VPN est destiné à interconnecter des 
sites distants entre eux, mais en l'état actuel, je ne maitrise rien en 
termes d'accès à ce VPN depuis l'extérieur.
Est-ce que je peux éviter cet accès à la passerelle pour la phase de tests?
Est-ce sans conséquence?


Je ne détecte pas d'anomalies dans ses logs.
J'espère donc qu'il est opérationel et que je peux passer aux clients.



Avant de passer au premier client je voudrai aussi éclaicir un point.
Selon les auteurs il serait préférable de lui affecter un port en mode non 
connecté. Je ne comprend pas très bien pourquoi.
Est-ce une mesure de sécurité ou le reflet d'opinions/d'habitudes.
Y a-t-il des raisons?


Merci d'avance.

-- 
Alain Vaugham
Clef GPG : 0xD26D18BC
_________________________________
Linux mailing list
[email protected]
http://lists.parinux.org/mailman/listinfo/linux

Répondre à