Étiquette : Réseau

Pas de commentaire

Configuration d’OpenVPN pour accéder aux autres machines du réseau

  de

Pour des raisons de sécurité, j’applique des filtres IP sur les principaux points d’entrée de mon cloud, avec un serveur ouvert vers l’extérieur qui sert de passerelle vers le réseau interne. Ayant installé OpenVPN pour d’autres usages, je me suis dit qu’il ne serait pas idiot de se servir d’OpenVPN pour accéder au réseau local et donc accéder aux machines de mon réseau cloud sur ma station personnelle, ce qui fait que peu importe mon emplacement, je suis toujours sur une IP acceptée par les différents services et accès de ma plateforme.

Pour ce faire, il suffit tout simplement d’aller dans les propriétés d’un utilisateur OpenVPN, et d’autoriser cet utilisateur à accéder à d’autres sous-réseaux :
Il reste donc à saisir par exemple 172.21.1.0/24 si les machines auxquelles on souhaite accéder sont sur ce sous-réseau.
Une fois la configuration appliquée, un simple ping permet de vérifier les machines du réseau local répondent, et on peut même s’y connecter directement, car étant sur le réseau local, nous ne sommes plus concernés par d’éventuelles règles NAT appliquées sur l’interface physique du serveur.
Ainsi, sur chacun de mes serveurs GNU/Linux, mon fichier /etc/hosts.allow est comme ceci :

sshd : 12.34.56.78 : allow
sshd : 12.34.56.79 : allow
sshd : ALL : deny

La machine est donc accessible uniquement via SSH par le serveur qui fait office de passerelle, soit par le VPN.

Dans le cadre d’un usage du bureau à distance sur une VM Windows, on peut filtrer grâce aux règles de pare-feu et aux étendues :

Je peux donc laisser plus sereinement ma VM Windows ouverte en TSE car elle rejettera systématiquement ce qui ne provient pas de mon réseau local.

6 Commentaires

Création d’un réseau interne grâce au NAT sur Proxmox VE 5

  de

Il y a quelques semaines maintenant, j’ai repensé mon cloud personnel. Auparavant basé sur ESXi, j’ai changé de technologie pour revenir sur quelque chose de plus « léger » que je connaissais déjà : Proxmox. Cet hyperviseur basé sur Debian m’avait causé dans sa version 4 pas mal de maux de tête pour réussir à monter un réseau et donner accès à internet à mes VM sans qu’elles n’utilisent d’IP globales ; la version 5 ne fait pas vraiment mieux, c’est pourquoi je vais partager dans cet article les opérations nécessaires via l’interface de Proxmox et via la modification du fichier /etc/network/interfaces.

Sur l’hôte, dans les paramètres réseau, doivent apparaître juste après l’installation la carte physique de la machine et un bridge. Il est très important de ne pas y toucher sous peine de rendre la machine injoignable après le redémarrage ou la recharge de la configuration des cartes. L’interface web ne semblant pas traduire correctement les valeurs saisies en un fichier de configuration propre, on va donc passer par la modification en direct du fichier /etc/network/interfaces pour y créer un deuxième bridge qui sera notre réseau local.

En l’ouvrant avec nano en utilisateur root, il doit ressembler à ceci (je vais appeler dans cet exemple ma carte réseau eth0 et mon IP 26.10.19.91), en gras les paramètres qu’il faut absolument vérifier afin qu’ils soient sur cette valeur :

auto lo
iface lo inet loopback


iface eth0 inet manual


auto vmbr0
iface vmbr0 inet static
  address 26.10.19.91
  netmask 255.255.255.0
  gateway 26.10.19.1
  bridge_ports eth0
  bridge_stp off
  bridge_fd 0 


auto vmbr1
iface vmbr1 inet static
  address 192.168.2.1
  netmask 255.255.255.0
  bridge_ports none
  bridge_stp off
  bridge_fd 0

Le vmbr1 est le nouveau bridge sur lequel nous allons raccorder nos VM pour leur donner accès à internet et pouvoir faire du NAT afin de les joindre depuis l’extérieur sur la même IP que l’hôte et qu’elles puissent éventuellement communiquer entre elles.

Un redémarrage plus tard (relancer les interfaces réseaux n’est pas suffisant), le nouveau pont doit apparaître dans la section réseau de l’interface web :

Par la suite, en configurant le réseau sur les VM, on indiquera une adresse IP comprise entre 192.168.2.2 et 192.168.2.254 (si vous avez laissé le sous-réseau par défaut) et 192.168.2.1 en gateway. Concernant les serveurs DNS, il est possible d’utiliser des serveurs DNS externes ou internes ; parmi les DNS publics, on peut renseigner par exemple 1.1.1.1 qui est le DNS public CloudFlare, ou le réputé 8.8.8.8 de Google.

Maintenant que les machines peuvent avoir une IP définie, afin de les joindre via certaines applications, il ne reste plus qu’à faire le NAT dans iptables. Toujours en root, on autorise le routage des paquets venant sur l’interface vmbr0 (qui est liée à eth0, la carte physique liée à internet) vers notre sous-réseau fraîchement créé :

iptables -t nat -A POSTROUTING -s ‘192.168.2.0/24’ -o vmbr0 -j MASQUERADE

Et enfin, si l’on souhaite ouvrir le port 80 sur 192.168.2.2 :

iptables -t nat -A PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

A noter que si l’on souhaite simplement retirer une règle, on remplace -A par -D. iptables ne sauvegardant pas de manière permanente les règles, elles sont perdues au redémarrage. Il est possible d’installer des applications permettant de faire des backup/restore des règles ou bien d’ajouter les règles au fichier /etc/network/interfaces en utilisant post-up pour les règles à exécuter une fois que l’interface est montée, et post-down pour celles a exécuter quand l’interface est désactivée. Par exemple :

post-up iptables -t nat -A PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp –dport 80 -j DNAT –to 192.168.2.2:80

Pour plus d’informations concernant iptables et ses possibilités, je vous renvoie à ce lien.

Pas de commentaire

Montage d’un NAS sur une machine virtuelle Debian distante

  de

J’ai franchi le pas récemment en achetant un NAS pour sauvegarder à la maison mes documents personnels et du contenu multimédia en tout genre. En plus d’utiliser Google Drive avec Plex (voir cet article), j’ai décidé de monter un troisième serveur Plex sous Debian Stretch pour y décoder le multimédia qui provient de mon NAS directement. Afin que le NAS à la maison soit accessible sur mon Plex qui est une machine virtuelle située en dehors de mon réseau local, je vais utiliser Samba – intégré à mon NAS – et faire un peu de routage sur ma Livebox.

Tout d’abord, satisfaire les prérequis en termes de paquets sur la machine :

adduser <sambaplex>
apt-get install cifs-utils

Je me servirai du dossier home de l’utilisateur sambaplex pour y monter mon NAS afin de le séparer du répertoire de l’utilisateur courant. Etant donné que sur le serveur nous n’allons pas héberger un partage mais seulement en monter un, il n’y a pas besoin d’installer tous les paquets de samba.

Ensuite, il faut paramétrer la box qui fait office de routeur à la maison. Dans mon cas, ayant une IP dynamique, j’ai dû faire appel à un service externe nommé No-IP qui permet de souscrire gratuitement (avec une offre payante) à un nom de domaine que je prolongerai tous les mois ; ce service est géré par ma box grâce à l’API, ce qui signifie que dès que mon IP change, l’adresse que renvoie mon nom de domaine change aussi. Cela évite d’avoir à remonter le partage sur le serveur dès que l’IP change et de pouvoir communiquer avec un nom, ce qui est plus pratique.

Je configure ici mon service de DNS dynamique ; sur la Livebox plusieurs prestataires sont disponibles

Ensuite, il est nécessaire de procéder à l’ouverture des ports dans le pare-feu, et également de NATer ceux-ci afin que le trafic puisse rentrer et sortir proprement. 5 ports sont nécessaires pour que toutes les fonctionnalités soient accessibles :

Je route les ports 135, 137 et 445 en TCP/UDP, 138 en UDP et 139 en TCP vers le NAS

Par précaution, j’ai également procédé à la création d’un bail DHCP permanent pour le NAS afin qu’il ne change pas d’adresse IP locale en cas de redémarrage ou de perte de connexion. Une fois que tout est prêt côté « maison », il ne reste plus qu’à monter le partage samba du NAS sur le serveur distant grâce à cette commande exécutée en root :

mount -t cifs //<nas.domain>/<share> /home/sambaplex -o username=<nasuser>

Il sera alors demandé le mot de passe du compte nasuser qui devra avoir les droits en lecture sur le share que l’on souhaite monter.

Si l’on souhaite démonter le share, rien de plus simple :

umount /home/sambaplex

Désormais je peux ajouter mon contenu sur ce serveur Plex comme si il était localement sur la machine virtuelle, chaque appel aux fichiers passant par Samba – et nécessitant de ce fait, une bonne bande passante étant donné que tout transite du NAS à la maison vers la machine virtuelle.

Pas de commentaire

Accéder à un serveur FTP situé derrière un routeur

  de

Un ami qui partait en vacances et qui souhaitait sauvegarder les vidéos de son drone afin de pouvoir libérer la mémoire interne avait besoin d’un espace en ligne pour déposer les fichiers car sa tablette Android n’avait pas une capacité suffisante. J’ai donc ouvert sur le web mon serveur FTP personnel situé sur mon Cloud personnel. Je vais donc détailler les quelques pas nécessaires à la bonne configuration du serveur FTP afin qu’on puisse y accéder depuis le web même si il est situé derrière un routeur.

J’ai réalisé cette opération en me servant d’un routeur virtuel pfSense car mon serveur FTP est hébergé sur un serveur vSphere ESXi, ainsi que de FileZilla Server pour Windows, sur un 2012 R2. Pour des raisons de simplicité, j’ai utilisé le port 21 afin d’éviter des incompatibilités avec les clients FTP disponibles sur Android.

Etant donné qu’il est placé derrière un routeur, le serveur ne doit pas agir en mode actif, mais en mode passif. Le mode passif nécessite d’être configuré dans FileZilla, car afin de fonctionner correctement, il faut lui spécifier l’IP externe de la machine physique, c’est à dire, par exemple, 87.32.38.143, et non l’IP du serveur FTP sur le réseau local, qui pourrait être 192.168.1.2. Ensuite, un range de ports pour que le mode passif fonctionne, et le tour est joué.

A titre d’exemple, j’ai utilisé le range de ports 30000-30100 car il n’était utilisé par aucune autre application sur l’hyperviseur.

Il faut maintenant ouvrir et router correctement les ports, ce qui n’a rien de difficile. Sur pfSense, il m’a suffit de rediriger vers le serveur FTP les requêtes TCP sur le port 21 sur le range 30000 à 30100. Le test montre bien que tout communique sans problème :