Hier, je me suis expérimenté à installer OpenVPN sur un serveur tout neuf … Ou plus ou moins une récup d’un vieux PC de @Codeur_Fou x)
Et je dois dire que c’était plutôt simple quand on a un bon tuto. Et c’est là que je vous renvoie à l’excellent billet de Nico Largo sur le sujet.
Il y a juste une toute petite chose qui manque sur son tutoriel. Il utilise le port 443, port qui je le rappel est utilisé communément par le HTTPS.
Comment donc faire cohabiter Apache et OpenVPN pour qu’ils délivrent les pages demandés en HTTPS et le VPN tranquilou ni vu ni connu j’t’embrouille wesh ?
EDIT : Comme me l’a signalé Kahas, je me base sur Debian, mais les modifications sont tout à fait applicables sur d’autres systèmes Linux, il vous suffira d’adapter les commandes. De plus, je modifie Apache, mais la configuration d’Nginx et autres serveurs web sera sensiblement la même.
Le bateau n’est pas dans ce port ? Changeons la destination !
L’idée est en fait toute simple, il suffisait juste d’y penser. C’est @KLMP200 sur Twitter qui m’a donné la piste. Cependant, le tutoriel qu’il m’a envoyé est beaucoup beaucoup trop dense et comprends pleins de modifications inutiles (toucher aux interfaces réseaux ? NO WAY !)
Première chose à faire, ajouter UNE ligne dans le fichier /etc/openvpn/server.conf (en violet, le reste venant du tuto de Nico Largo, remplacez les XXX.XXX.XXX.XXX par l’IP de votre serveur) :
# Serveur TCP/443
mode server
proto tcp
port 443
port-share XXX.XXX.XXX.XXX 4443
dev tun
Un petit redémarrage d’OpenVPN et nous en avons fini avec lui :
sudo service openvpn restart
Ce que vous venez d’ajouter va dire à OpenVPN de rediriger tout le flux qui n’est pas un packet VPN vers un autre port, choisi arbitrairement 4443 (vous pouvez mettre celui qui vous chante x) )
La migration des indiens
Il nous reste plus donc qu’à modifier Apache pour qu’il écoute sur ce nouveau port. Et là, il y a pas mal de fichiers à éditer. C’est parti !
Tout d’abord, /etc/apache2/ports.conf :
<IfModule mod_ssl.c>
NameVirtualHost *:4443
Listen 4443
</IfModule>
<IfModule mod_gnutls.c>
Listen 4443
</IfModule>
Ensuite, /etc/apache2/sites-available/default-ssl (une seule ligne à changer) :
<VirtualHost _default_:4443>
Et enfin vos virtual hosts. Changez tout les *:443 que vous aurez mis par *:4443
Un petit redémarrage d’Apache et ce sera fini 😀
sudo service apache2 restart
Voilà, ce fut rapide, mais bon, je suis particulièrement content que ce genre de choses soit possible, je me demande même pourquoi je n’avais pas utilisé cette technique quand j’étais à Supinfo à l’époque ><
Bonjour et merci pour le tuto.
Cependant, impossible pour mes sites en SSL d’être accessible depuis le changement décris plus haut.
OpenVPN n’est aussi pas content, il renvoie :
Sun May 10 12:29:54 2020 us=108213 83.59.223.87:39624 Non-OpenVPN client protocol detected
J’ai l’impression qu’openVPN a changé depuis 2016, voire qu’il faille activer d’autres options…
Au plaisir !
PS: autre tuto avec pb équivalent : https://memo-linux.com/openvpn-sur-le-port-443-partage-avec-un-serveur-web/
En effet, le poste est maintenant un peu désuet et ne répond plus vraiment à ce qu’est devenu OpenVPN.
Dorénavant, il est plus simple de passer par un demultiplexeur comme SSLH qui va faire le boulot de transmettre les bon paquets aux bons services derrière.
Voici un article en français histoire de vous mettre dans le bain 🙂 https://linuxfr.org/news/sslh-110-la-bete-noire-des-censeurs
Xéfir, merci pour l’info j’étais en train d’étudier SSLH, car d’après d’autres tuto qui marient openvpn et apache sans rien d’autre, les stats par client ne sont plus possible, car ip cliente 127.0.0.1….
Pour le reste j’ai testé ta méthode avec le port 80 et c’est OK
Du coups j’ai pu voir que ma configuration sur le site testé en SSL était foireuse.
Donc « re tentative » avec le 443 et je confirme qu’en 2020 ton tuto est tjs d’actualité 😉
Le mariage est donc parfait et pour ma part convient tout à faire un usage privé.
Pour revenir aux problèmes de sécurité sur les port >> 1024, rien de plus facile, choisir un port en dessous :p
pourquoi ne pas proposer localhost à la place de xxx.xxx.xxx.xxx ? Un soucis particulier ?
Bonne remarque, j’avoue ne jamais avoir essayé et à mon avis, il ne devrait pas y avoir de soucis (sauf si OpenVPN gère mal ses propres routes, dans ce cas, une boucle locale se produira, entrainant un timeout).
Je suis passé récemment sur Nginx et SSLH, rendant ce billet « obsolète », mais rien ne t’empêche de tester, tu n’as pas grand-chose à perdre x)
Si « localhost » ne fonctionne pas, essaie 127.0.0.1, la résolution de nom peut faire des siennes.
Promis, je vais gratter un truc sur SSLH un de ces quatre 🙂
A ce stade les machines clientes vont pouvoir se connecter au serveur VPN. Par contre impossible d’aller plus loin que ce dernier car l’adresse 10.8.0.x ne sera par routée en dehors de votre serveur. Il faut donc configurer le serveur pour qu’il joue le rôle de routeur entre l’interface VPN (tun0) et l’interface physique (eth0) et de NATeur entre les adresses en 10.8.0.x et son adresse IP réelle.
Ça c’est le rôle d’iptables 🙂
Réfère-toi au guide proposé dans l’article pour la configuration d’OpenVPN : http://blog.nicolargo.com/2010/10/installation-dun-serveur-openvpn-sous-debianubuntu.html
Le principe ici est juste de pouvoir utiliser un serveur web sur son port https normal tout en accueillant un serveur VPN derrière (impossible d’utiliser deux logiciels sur le même port, l’un doit servir de proxy au second, et OpenVPN gère ça nativement, ce qui est plutôt cool :D)
Ton exemple est en effet valable pour les serveurs mutualisés ou plusieurs personnes ont la possibilité d’exécuter des scripts comme un serveur web python à l’arrache et intercepter les données qui arrivent.
N’ayant installé OpenVPN que sur des machines à usage personnel pour le moment, je ne m’étais jamais vraiment posé la question.
Donc oui, dans le cas d’une machine avec plusieurs utilisateurs, il est envisageable d’utiliser un port ne pouvant être lié qu’avec root (donc en dessous de 1024).
Après, rappelons-le, ton serveur web n’est pas censé tomber normalement hein ?
Il faudra forcément qu’il soit éteint pour qu’une attaque telle que tu l’as présenté intervienne.
Un utilisateur ne pourra jamais se lié au port 4443 si celui-ci est déjà occupé par Apache/Nginx.
En effet, il n’est pas censé tomber, il faut bien que le port soit libéré un instant pour qu’un autre programme l’écoute. Je voulais juste mettre en évidence une possible faiblesse de sécurité
Je ne penses pas que ça soit une bonne idée de changer les ports de services sensibles sur des numéros de ports supérieurs a 1024, tout simplement parce que n’importe quel user peut utiliser ses ports.
Imagine que, pour une raison X ou Y , un de tes services est troué ( on es jamais a l’abris d’un trou de sécu ) et que le apache qui écoute bien le 4443, comme dans ton exemple, crash. N’importe quel user peur alors lancer n’importe quoi sur 4443 et écouter tout ce qui passe .
Certes il faut une série de « coïncidences » pour qu’un vrai problème soi présent. Mais j’voulais juste ton avis la dessu