Open-VPN/Wireguard - Accéder aux ressources du réseau local

Tags: #<Tag:0x00007fc9df853a80> #<Tag:0x00007fc9df853968>

Bonjour à tous,

Je me creuse la tête depuis des jours et je ne trouve pas de solution.
Je vais d’abord vous expliquer le projet et ce que j’ai fait.

L’entreprise pour laquelle je travaille, possède deux drones. Mon directeur souhaite que je renvois au bureau, en temps réel, les flux vidéos de ces derniers pour pouvoir guider les équipes de terrain.
Ceux-ci sont capables de transmettre leurs images via le protocole RTMP uniquement et via wifi.

J’ai donc installé un petit serveur sous Debian derrière la box internet de l’entreprise.
J’y ai installé NGINX que j’ai paramétré pour qu’il reçoive le flux RTMP et le mette à disposition en mode Live.
J’ai ensuite installé MotionEye, qui va lire ce flux et offre une interface web pour les opérateurs.
J’ai enfin ouvert le port 1935 (RTMP) sur la box et pris un smartphone avec 4G pour partager, via wifi, la connexion internet aux drones.

Tout ceci fonctionne très bien mais, pour des raisons de confidentialité, il faut que je crypte les flux.

J’ai donc installé OpenVpn via le script https://raw.githubusercontent.com/Nyr/openvpn-install/master/openvpn-install.sh
J’utilise simplement l’application OpenVPN for Android que je connecte à mon VPN. Un petit partage de connexion par wifi et la télécommande du drone envois son flux vers mon serveur au travers du VPN.

Mais voilà, mon serveur qui possède une IP locale de type 192.168.1.100, est parfaitement accessible en local ou en claire via le port 1135, mais ce port n’est pas disponible depuis le VPN. Seul les ports 433 et 80 le sont.

Voici le résultat de iptables -L :

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  10.8.0.0/24          anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Mon fichier de configuration openvpn :

local 192.168.1.100
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option DNS 192.168.1.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify

Ainsi que celui de /etc/systemd/system/openvpn-iptables.service :
[Unit]
Before=network.target
[Service]
Type=oneshot
ExecStart=/usr/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to 192.168.1.100
ExecStart=/usr/sbin/iptables -I INPUT -p udp --dport 1194 -j ACCEPT
ExecStart=/usr/sbin/iptables -I FORWARD -s 10.8.0.0/24 -j ACCEPT
ExecStart=/usr/sbin/iptables -I FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
ExecStop=/usr/sbin/iptables -t nat -D POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to 192.168.1.100
ExecStop=/usr/sbin/iptables -D INPUT -p udp --dport 1194 -j ACCEPT
ExecStop=/usr/sbin/iptables -D FORWARD -s 10.8.0.0/24 -j ACCEPT
ExecStop=/usr/sbin/iptables -D FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target

En bref, le port 1135 de mon serveur est bien ouvert et accessible en local (comme depuis le net suite à l’ouverture du port sur la box) mais pas lorsque je suis connecté depuis le VPN.
Je précise par contre que les port 433 et 80, tout comme le ping, fonctionnent très bien.
Donc, je suis bien sur le même réseau que mon serveur qui est accessible.

A noter également que c’est une unique machine qui héberge tout (OpenVPN, Nginx, OpenEye).

Merci d’avance, à quiconque pourra m’apporter son aide.

le port 1135 est utilisé depuis l’extérieur, lorsque tu es connecté au vpn les trames envoyés de ton Android sont considérées comme étant à l’intérieur de la machine à la sortie du vpn.

Regarde si tu n’a pas le flux rtmp disponible directement en localhost, lorsque le vpn est monté.

Je ne connais pas RTMP, comment cela fonctionne-t-il ? Le drone et NGINX sont-ils client ou serveur ?

Qu’entends-tu exactement par « ouvert » ?

Qu’entends-tu exactement par

  • accessible
  • en local
  • en clair
  • via le port 1135 ? A quoi correspond ce port ?

Qu’entends-tu exactement par « disponibles » ?

Les règles iptables dans la table filter sont inutiles puisque la politique par défaut est réglée à ACCEPT. Quant à la règle POSTROUTING, elle ne sert que s’il y a du trafic provenant du VPN à travers le serveur à destination d’une autre machine.

C’est-à-dire ?

Bonjour @PascalHambourg,
Je pensais mon message claire mais au vue de tes questions, c’est loin d’être le cas…
Je vais donc te répondre pour éclaircir quelque peu mes propos.

RTMP est un protocole de diffusion de flux de données (audio, vidéo). Il est utilisé pour du live stream sur Facebook et Youtube par exemple.
Source : Wikipedia
Le drone émet le flux vidéo en direction du serveur NGINX via le port 1935.
Sur la télécommande du drone, il faut entrer un url du style :
rtmp://<adress_ip_de_la_box_hébergeant_le_serveur>/live/<nom_de_la_diffusion>

NGINX est configuré de cette manière nginx.conf :

rtmp {
    server {
            listen 1935;
            chunk_size 4096;
		notify_method get;
            application flux {
                    live on;
                    record off;
            }
    }
}

Je redirige le port 1935 de ma box vers l’ip locale de mon serveur.

J’ai fait des tests de diffusion RTMP directement en wifi sur le réseau local :

  • rtmp://192.168.1.100/flux/drone1

J’ai également fait un test en 4G avec l’url :

  • rtmp://<adress_ip_de_la_box_hébergeant_le_serveur>/flux/drone1

Tout fonctionne très bien.
Mais RTMP n’est pas un protocole crypté, il n’y a même pas d’authentification, ce qui pose des problèmes de confidentialité.
C’est pourquoi, j’aimerais faire la même chose mais à l’intérieur d’un VPN.
Ce qui, pour l’instant, ne fonctionne pas.

Si je me connecte à mon VPN et que je ping mon serveur (192.168.1.100), ça fonctionne.
J’ai également créé une page index.html dans le dossier web de NGINX et si j’utilise mon navigateur, toujours en étant connecté au VPN, http:// 192.168.1.100 et https:// 192.168.1.100 m’affichent parfaitement cette page. (les espaces sont là uniquement pour empêcher leur détection en tant que lien)
Mai si je tente d’utiliser l’url rtmp://192.168.1.100/flux/drone1, la connexion est refusée par le serveur.

En tout cas, merci à toi de t’intéresser à mon problème.

Le problème est que, je suppose, la route est la suivante :
<ip_de_la_télécommande> => <ip_du_smartphone> => <ip_du_serveur_dhcp_openvpn> => 192.168.1.100 => <ip_publique_de_ma_box>

L’url RTMP est entrée dans le système de la télécommande.
Si j’utilise localhost avec 127.0.0.1, ne vais-je pas boucler sur l’ip de la télécommande ?

Alors, j’ai fait quelques tests.

Vue que les ports 443 et 80 de mon serveur recevant le flux vidéos semblent accessibles depuis le VPN, j’ai modifié NGINX pour qu’il écoute RTMP sur le port 443 plutôt que 1935.

J’ai fait un test en wifi sur mon réseau local et le drone peut envoyer ce flux sur un port différent et cela fonctionne.
Malgré tout, dès que je connecte le drone au VPN, ça ne fonctionne pas. Pourtant, Angry IP Scanner considère les port 80 et 443 disponibles sur mon serveur…

Je pense que je vais changer ma question.

Quelqu’un saurait-il paramétrer OpenVPN pour que je puisse accéder totalement à mon réseau local (même sans accéder à internet) ?

Pour rappel, mon fichier server.conf :

local 192.168.1.100
port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key
dh dh.pem
auth SHA512
tls-crypt tc.key
topology subnet
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1 bypass-dhcp"
ifconfig-pool-persist ipp.txt
push "dhcp-option DNS 192.168.1.1"
push "dhcp-option DNS 192.168.1.1"
keepalive 10 120
cipher AES-256-CBC
user nobody
group nogroup
persist-keyAinsi
persist-tun
status openvpn-status.log
verb 3
crl-verify crl.pem
explicit-exit-notify

Depuis quel appareil ? Le smartphone ou le drone ?

Depuis quel appareil ? Le smartphone ou le drone ?

Avec quel message ?

Pas vraiment, non. Que vient faire la télécommande dans le routage entre le drone et le serveur ? C’est le drone ou la télécommande qui se connecte en wifi ?

Scanner exécuté depuis quel appareil ? Le smartphone, le drone, la télécommande ?

Bonjour @PascalHambourg,

Détail du fonctionnement :

  • Le drone se connecte par radio à la télécommande et transmet son flux vidéo.
  • La télécommande se connecte en wifi sur le smartphone.
  • Le smartphone est connecté en 4G et se connecte au VPN via OpenVPN.
  • Enfin, le serveur héberge le serveur OpenVPN, un serveur NGINX qui reçoit via le port 1935 la vidéo en RTMP et MotionEye qui sert d’interface de visualisation.

Quand je ping mon serveur en 192.168.1.100 que ce soit depuis la télécommande ou depuis le smartphone, cela fonctionne.

Quand je tente,depuis la télécommande, de transmettre la vidéo au serveur.
Si OpenVPN est éteint, cela fonctionne (en local wifi ou en 4G à travers le smartphone - le port 1935 de la box ayant été routé vers le 1935 du serveur).
Si OpenVPN connecté, j’ai le message : « Connexion au serveur impossible » (en 4G connecté au smartphone).

Si je scan depuis la télécommande ou le smartphone l’adresse locale du serveur 192.168.1.100 en étant connecté à OpenVPN, AngryIP Scanner considère uniquement les ports 80 et 443 comme disponible.

Voilà; j’espère que ces éléments aideront.

Encore merci à tout ceux qui se creusent la tête pour moi et à @PascalHambourg qui est particulièrement actif.

Bon,
Je galère toujours avec ce truc et je me rends compte que je n’avais pas tout compris.

J’ai tenté de remplacer OpenVPN par WireGuard, mais j’ai toujours le même soucis.
Je suppose donc que mon problème est ailleurs…

Je viens donc de faire un petit test avec un traceroute sur le DNS de Google et le résultat m’a surpris.

Quand je le fait depuis mon serveur qui possède l’adresse IP 192.168.1.100 :

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  0.532 ms  0.324 ms  0.221 ms
 2  80.10.126.15 (80.10.126.15)  15.027 ms  16.215 ms  17.460 ms
 3  10.125.7.74 (10.125.7.74)  18.839 ms  18.759 ms 10.125.7.10 (10.125.7.10)  21.257 ms
 4  ae41-0.nistr201.schiltigheim.francetelecom.net (193.252.160.82)  27.483 ms ae41-0.nistr202.strasbourg.francetelecom.net (193.252.160.118)  26.380 ms  28.563 ms
 5  81.253.180.117 (81.253.180.117)  30.079 ms  31.363 ms 193.252.137.82 (193.252.137.82)  33.934 ms
 6  193.252.137.82 (193.252.137.82)  36.077 ms 72.14.214.52 (72.14.214.52)  34.035 ms  34.554 ms
 7  * * *
 8  dns.google (8.8.8.8)  27.281 ms  26.684 ms *

On voit bien ma box en 192.168.1.1 puis les routeurs opérateurs.

Mais si je le fait depuis mon smartphone qui est connecté au VPN, je m’attends à trouver quelques éléments supplémentaires au début puis approximativement le même chemin. Mais je n’ai pas du tout la même chose…

traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  * * *
 2  10.216.3.64 (10.216.3.64)  74.207 ms  74.302 ms  75.038 ms
 3  10.216.2.62 (10.216.2.62)  76.540 ms  76.973 ms  76.311 ms
 4  10.216.2.65 (10.216.2.65)  78.258 ms  80.694 ms  80.837 ms
 5  81.253.184.201 (81.253.184.201)  77.401 ms  75.906 ms  77.082 ms
 6  ae22-0.ncstr101.Schiltigheim.francetelecom.net (193.252.162.6)  78.036 ms  38.628 ms  41.544 ms
 7  ae43-0.nistr201.Schiltigheim.francetelecom.net (193.252.160.109)  40.953 ms  41.016 ms  40.515 ms
 8  193.252.137.82 (193.252.137.82)  44.249 ms  43.536 ms  43.204 ms
 9  google-14.gw.opentransit.net (193.251.252.246)  43.791 ms  43.007 ms 72.14.214.52 (72.14.214.52)  43.116 ms
10  * * *
11  dns.google (8.8.8.8)  33.290 ms  33.006 ms  32.481 ms

Ma box n’apparaît nulle part… Pourtant j’y passe bien une première fois à travers le VPN et normalement, je devrait y repasser mais non crypté pour atteindre internet. Hors, elle n’apparait nulle part.

Quelqu’un y comprends quelque chose ?

On dirait que ça ne passe pas par le VPN. Est-ce qu’il y a une différence avec le smartphone non connecté au VPN ?

1 J'aime

BINGO !
Le traceroute est identique que le VPN soit ou non connecté.
Le problème vient effectivement de là…
Mais comment vais-je bien pouvoir faire pour que la connexion partagée du smartphone passe par mon vpn ?

Est-ce que tu peux afficher la table de routage du smartphone avec le VPN connecté ?

Je t’avouerais que je ne sais pas comment faire pour afficher la table de routage d’un smartphone…
Du peu que j’ai lu, il semble qu’il soit nécessaire d’avoir les droits root, ce que je n’ai pas.

Aucune idée, je n’y connais strictement rien en matière de smartphones.
Par contre tu as écrit que l’adresse privée du serveur répondait au ping, en HTTP et en HTTPS lorsque le VPN est monté donc a priori le routage de cette adresse se fait bien via le VPN. Que donne un traceroute vers cette adresse avec et sans VPN ?

Il y a bien un 192.168.1.100 qui répond mais ce n’est en fait pas mon serveur.
J’ai testé VPN éteint et la réponse au ping est toujours positive.
Je me suis fait piéger.

Pourtant tu avais écrit précédemment :

Comment l’autre serveur peut-il afficher ta page ?

Note : si le serveur n’est pas joignable avec 192.168.1.100, il devrait l’être avec son adresse VPN (10.8.0.x), à condition que Nginx écoute sur cette adresse ou l’adresse indéfinie 0.0.0.0 mais pas seulement sur 192.168.1.100.

Bonjour,

Je te te poste mon guide Wireguard, sa pourrait t’aider .

Purge de la configuration

apt autoremove --purge -y wireguard ;
rm -r /etc/wireguard ;

Ajout du dépôt backport

echo « deb http://deb.debian.org/debian buster-backports main » > /etc/apt/sources.list.d/buster-backports.list ;
apt update ;
apt install -y wireguard ;

Autoriser le trafic inter-interface

sed -i ‹ s/#net.ipv4.ip_forward=1/net.ipv4.ip_forward=1/g › /etc/sysctl.conf
/sbin/sysctl -w net.ipv4.ip_forward=1

Pour les systèmes Linux: A exécuter une fois sur le serveur et client. (Configuration permanente)

Arrêt de l’interface wg-quick@wg0

systemctl disable wg-quick@wg0
systemctl stop wg-quick@wg0
systemctl status wg-quick@wg0

Purge de la configuration:
rm /etc/wireguard/wg0.conf
rm /etc/wireguard/privatekey
rm /etc/wireguard/publickey


**Pour la configuration du serveur, j’ai utiliser le site: **

https://www.wireguardconfig.com/
/!\ L’interface par défaut est eth0 pour les règles de pare-feu, la mienne se nommait ens18, j’ai modifier la config en conséquence.

Insertion des clés du serveur
echo « CONTENUDEMACLEPRIVEESERVEUR » > /etc/wireguard/privatekey
echo « CONTENUDEMACLEPUBLICSERVEUR » > /etc/wireguard/publickey

Configuration du serveur (Wire
echo « MACONFIG » > /etc/wireguard/wg0.conf

Activation et démarrage du service

systemctl enable wg-quick@wg0 ;
systemctl start wg-quick@wg0 ;
systemctl status wg-quick@wg0

Permissions: (A confirmer pour la sécurité)

sudo chmod 600 /etc/wireguard/ -R

Vérification :

sudo wg


A partir de là mon VPN est démarrer mais l’internet ne marche pas encore car le flux est par rediriger.


Autoriser le port 51820 en UDP dans IPTABLES (Wireguard)

iptables -t filter -A INPUT -p udp --dport 51820 -j ACCEPT

On accepte les paquets en provenance du VPN

iptables -A FORWARD -i wg0 -j ACCEPT

On autorise également les paquets à destination du VPN

iptables -A FORWARD -o wg0 -j ACCEPT

On effectue la traduction d’adresse entre l’IP publique du serveur et les clients

iptables -t nat -A POSTROUTING -s 192.168.30.0/24 -o ens18 -j MASQUERADE


Client :

[Interface]
Address = 192.168.30.2/24
ListenPort = 51820
PrivateKey = ************
DNS = 192.168.1.4
[Peer]
PublicKey =
AllowedIPs = 192.168.1.0/24, 192.168.10.0/24, 192.168.30.0/24 0.0.0.0/0, ::/0
Endpoint = ***********:51820


Il existe quelque subtilité dans la configuration côté client :

AllowedIPs :

0.0.0.0/0 : Le client aura l’IP WAN du réseau VPN.
::/0 : Bloque le trafic sauf les IP autorisés. (C’est le commutateur sur l’interface de Wireguard.
192.168.1.0/24 : Le client aura droit à accéder au réseau physique
192.168.10.0/24 : Idem mais pour mon autre réseau (virtuel)
192.168.30.0/24 : Les clients VPN pourront communiquer

Vu que les clients peuvent communiquer sur le réseau physique , j’ai mis mon serveur DNS :

DNS = 192.168.1.4