Démarrer un serveur VPN derrière le NAT d'un fournisseur

Un article sur la façon dont j'ai réussi à exécuter un serveur VPN derrière le NAT d'un fournisseur domestique (sans adresse IP blanche). Je vous le dis tout de suite : les performances de cette implémentation dépendent directement du type de NAT utilisé par votre fournisseur, ainsi que du routeur.
J'avais donc besoin de me connecter depuis mon smartphone Android à mon ordinateur personnel, les deux appareils sont connectés à Internet via les NAT du fournisseur, et l'ordinateur est connecté via un routeur domestique, qui effectue également des connexions NAT.
Le schéma classique utilisant un VPS/VDS loué avec une adresse IP blanche, ainsi que la location d'une adresse IP blanche auprès du fournisseur, n'a pas été envisagé pour plusieurs raisons.
En vue de expérience des articles précédents, après avoir mené plusieurs expériences avec les STUN et les NAT des fournisseurs. J'ai décidé de faire une petite expérience en exécutant la commande sur un routeur domestique exécutant le firmware OpenWRT :

$ stun stun.sipnet.ru

j'ai obtenu le résultat :

Client STUN version 0.97
Primaire : cartographie indépendante, filtre indépendant, port aléatoire, épingle à cheveux
la valeur de retour est Assistance

Traduction littérale:
Cartographie indépendante - affichage indépendant
Filtre indépendant - filtre indépendant
port aléatoire - port aléatoire
sera une épingle à cheveux - il y aura une épingle à cheveux
Après avoir exécuté une commande similaire sur mon PC, j'ai obtenu :

Client STUN version 0.97
Primaire : cartographie indépendante, filtre dépendant du port, port aléatoire, épingle à cheveux
la valeur de retour est Assistance

Filtre dépendant du port - filtre dépendant du port
La différence dans les résultats de sortie des commandes indiquait que le routeur domestique apportait « sa contribution » au processus de diffusion de paquets depuis Internet, cela se manifestait par le fait que lorsque la commande était exécutée sur l'ordinateur :

stun stun.sipnet.ru -p 11111 -v

j'ai eu le résultat :

...
Adresse mappée = XX.1XX.1X4.2XX:4398
...

à ce moment-là, une session UDP était ouverte pendant un moment, si à ce moment-là une requête UDP était envoyée (par exemple : netcat XX.1XX.1X4.2XX 4398 -u), alors la requête parvenait au routeur domestique, qui était confirmé par TCPDump exécuté dessus, mais la demande n'a pas atteint l'ordinateur - IPtables en tant que traducteur NAT sur le routeur l'a abandonnée.

Mais le fait même de faire passer une requête UDP via le NAT du fournisseur laissait espérer un succès. Le routeur étant dans ma juridiction, j'ai résolu le problème en redirigeant le port UDP/11111 vers l'ordinateur :

iptables -t nat -A PREROUTING -i eth1 -p udp -d 10.1XX.2XX.XXX --dport 11111 -j DNAT --to-destination 192.168.X.XXX

Ainsi, j'ai eu l'opportunité d'initier une session UDP et de recevoir des requêtes Internet depuis n'importe quelle adresse IP. À ce moment, j'ai lancé le serveur OpenVPN (après l'avoir configuré) en écoutant le port UDP/11111, j'ai indiqué l'adresse IP externe et le port (XX.1XX.1X4.2XX:4398) sur le smartphone et je me suis connecté avec succès du smartphone au ordinateur. Mais dans cette implémentation, un problème est survenu, il fallait en quelque sorte maintenir la session UDP jusqu'à ce que le client OpenVPN se connecte au serveur, je n'aimais pas l'option de lancer périodiquement le client STUN - je ne voulais pas charger les serveurs STUN en vain.
A également attiré l'attention sur l'entrée "sera une épingle à cheveux - il y aura une épingle à cheveux", ce mode

Hairpinning permet à une machine sur un réseau local derrière NAT d'accéder à une autre machine sur le même réseau à l'adresse externe du routeur.

En conséquence, j'ai résolu simplement le problème du maintien d'une session UDP - j'ai lancé le client sur le même ordinateur que le serveur.
Cela a fonctionné comme ceci :

• lancé le client STUN avec le port local 11111
• réponse reçue avec l'adresse IP externe et le port XX.1XX.1X4.2XX:4398
• données envoyées avec une adresse IP externe et un port vers la messagerie (tout autre service est possible) configuré sur le smartphone
• lancé un serveur OpenVPN sur un ordinateur écoutant sur le port UDP/11111
• lancé un client OpenVPN sur un ordinateur spécifiant XX.1XX.1X4.2XX:4398 pour se connecter
• à tout moment lancé le client OpenVPN sur le smartphone en précisant l'adresse IP et le port (dans mon cas, l'adresse IP n'a pas changé) pour se connecter

Ainsi, j'ai eu la possibilité de me connecter à mon ordinateur depuis un smartphone. Cette implémentation vous permet de connecter n'importe quel client OpenVPN.

Pratique

Vous aurez besoin de:

# apt install openvpn stun-client sendemail

Après avoir écrit quelques scripts, quelques fichiers de configuration, généré les certificats nécessaires (puisque le client sur le smartphone ne fonctionne qu'avec des certificats), nous avons obtenu l'implémentation habituelle du serveur OpenVPN.

Script principal sur ordinateur

# cat vpn11.sh

#!/bin/bash
until [[ -n "$iftosrv" ]]; do echo "$(date) Определяю сетевой интерфейс"; iftosrv=`ip route get 8.8.8.8 | head -n 1 | sed 's|.*dev ||' | awk '{print $1}'`; sleep 5; done
ABSOLUTE_FILENAME=`readlink -f "$0"`
DIR=`dirname "$ABSOLUTE_FILENAME"`
localport=11111
until [[ $a ]]; do
	address=`stun stun.sipnet.ru -v -p $localport 2>&1 | grep "MappedAddress" | sort | uniq | head -n 1 | sed 's/:/ /g' | awk '{print $3" "$4}'`
        ip=`echo "$address" | awk {'print $1'}`
        port=`echo "$address" | awk {'print $2'}`
	srv="openvpn --config $DIR/server.conf --port $localport --daemon"
	$srv
	echo "$(date) Сервер запущен с внешним адресом $ip:$port"
	$DIR/sendemail.sh "OpenVPN-Server" "$ip:$port"
	sleep 1
	openvpn --config $DIR/client.conf --remote $ip --port $port
	echo "$(date) Cоединение клиента с сервером разорвано"
	for i in `ps xa | grep "$srv" | grep -v grep | awk '{print $1}'`; do
		kill $i && echo "$(date) Завершен процесс сервера $i ($srv)"
		done
	echo "Жду 15 сек"
	sleep 15
	done

Script d'envoi d'e-mail :

# cat sendemail.sh 

#!/bin/bash
from="От кого"
pass="Пароль"
to="Кому"
theme="$1"
message="$2"
server="smtp.yandex.ru:587"
sendEmail -o tls=yes -f "$from" -t "$to" -s "$server" -xu "$from" -xp "$pass" -u "$theme" -m "$message"

Fichier de configuration du serveur :

# cat server.conf

proto udp
dev tun
ca      /home/vpn11-srv/ca.crt
cert    /home/vpn11-srv/server.crt
key     /home/vpn11-srv/server.key
dh      /home/vpn11-srv/dh2048.pem
server 10.2.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
tls-server
tls-auth /home/vpn11-srv/ta.key 0
tls-timeout 60
auth    SHA256
cipher  AES-256-CBC
client-to-client
keepalive 10 30
comp-lzo
max-clients 10
user nobody
group nogroup
persist-key
persist-tun
log /var/log/vpn11-server.log
verb 3
mute 20

Fichier de configuration client :

# cat client.conf

client
dev tun
proto udp
ca      "/home/vpn11-srv/ca.crt"
cert    "/home/vpn11-srv/client1.crt"
key     "/home/vpn11-srv/client1.key"
tls-client
tls-auth "/home/vpn11-srv/ta.key" 1
auth SHA256
cipher AES-256-CBC
auth-nocache
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
log /var/log/vpn11-clent.log
verb 3
mute 20
ping 10
ping-exit 30

Les certificats ont été générés selon cet article.
Exécution du script :

# ./vpn11.sh

Le rendre d'abord exécutable

# chmod +x vpn11.sh

Du côté des smartphones

En installant l'application Ouvrir un VPN pour Android, en copiant le fichier de configuration, les certificats et en le configurant, cela s'est passé comme ceci :
Consulter mes e-mails sur mon smartphone
Je modifie le numéro de port dans les paramètres
Je démarre le client et me connecte

En train de rédiger l’article, j’ai transféré la configuration de l’ordinateur vers le Raspberry Pi 3 et j’ai essayé de faire tourner le tout sur un modem LTE, mais cela n’a pas fonctionné ! résultat de la commande

# stun stun.ekiga.net -p 11111

Client STUN version 0.97
Primaire : cartographie indépendante, filtre dépendant du port, port aléatoire, épingle à cheveux
la valeur de retour est Assistance

значение Filtre dépendant du port a empêché le démarrage du système.
Mais le fournisseur d'origine a laissé le système fonctionner sur le Raspberry Pi 3 sans aucun problème.
En conjonction avec une webcam, avec VLC pour
créer un flux RTSP à partir d'une webcam

$ cvlc v4l2:///dev/video0:chroma=h264 :input-slave=alsa://hw:1,0 --sout '#transcode{vcodec=x264,venc=x264{preset=ultrafast,profile=baseline,level=31},vb=2048,fps=12,scale=1,acodec=mpga,ab=128,channels=2,samplerate=44100,scodec=none}:rtp{sdp=rtsp://10.2.0.1:8554/}' --no-sout-all --sout-keep

et VLC sur un smartphone pour le visionnage (stream rtsp://10.2.0.1:8554/), il s'est avéré un bon système de vidéosurveillance à distance, vous pouvez également configurer Samba, acheminer le trafic via VPN, contrôler à distance un ordinateur et beaucoup plus ...

conclusion

Comme l'a montré la pratique, pour organiser un serveur VPN, vous pouvez vous passer d'une adresse IP externe pour laquelle vous devez payer, ainsi que d'un VPS/VDS loué. Mais tout dépend du fournisseur. Bien sûr, je souhaitais avoir plus d'informations sur les différents fournisseurs et types de NAT utilisés, mais ce n'est qu'un début...
Je vous remercie!

Source: habr.com