Inici d'un servidor VPN darrere del NAT d'un proveïdor

Un article sobre com vaig aconseguir executar un servidor VPN darrere del NAT d'un proveïdor domèstic (sense una adreça IP blanca). Deixa'm dir-te de seguida: el rendiment d'aquesta implementació depèn directament del tipus de NAT utilitzat pel vostre proveïdor, així com de l'encaminador.
Per tant, vaig tenir una necessitat de connectar-me des del meu telèfon intel·ligent Android a l'ordinador de casa, ambdós dispositius estan connectats a Internet mitjançant NAT del proveïdor, a més l'ordinador està connectat a través d'un encaminador domèstic, que també connecta NAT.
L'esquema clàssic que utilitza un VPS / VDS llogat amb una adreça IP blanca, així com el lloguer d'una adreça IP blanca al proveïdor, no es va considerar per diversos motius.
Tenir en compte experiència d'articles anteriors, havent fet diversos experiments amb STUN i NAT dels proveïdors. Vaig decidir fer un petit experiment executant l'ordre en un encaminador domèstic amb el microprogramari OpenWRT:

$ stun stun.sipnet.ru

resultat obtingut:

Versió del client STUN 0.97
Principal: mapes independents, filtre independent, port aleatori, forquilla
el valor de retorn és 0x000002

Traducció literal:
Mapes independents: visualització independent
Filtre independent: filtre independent
port aleatori - port aleatori
will hairpin - hi haurà una forquilla
Després d'executar una ordre similar al meu PC, vaig obtenir:

Versió del client STUN 0.97
Principal: mapes independents, filtre depenent del port, port aleatori, forquilla
el valor de retorn és 0x000006

Port Dependent Filter: filtre dependent del port
La diferència en els resultats de la sortida de les ordres va indicar que l'encaminador domèstic va fer "la seva contribució" al procés de difusió de paquets des d'Internet, això es va manifestar en el fet que quan l'ordre s'executava a l'ordinador:

stun stun.sipnet.ru -p 11111 -v

tinc el resultat:

...
MappedAddress = XX.1XX.1X4.2XX:4398
...

en aquell moment, es va obrir una sessió UDP durant un temps, si en aquell moment s'enviava una sol·licitud UDP (per exemple: netcat XX.1XX.1X4.2XX 4398 -u), aleshores la sol·licitud va arribar a l'encaminador domèstic, que era confirmat per TCPDump que s'executa, però la sol·licitud no va arribar a l'ordinador: IPtables com a traductor NAT de l'encaminador la va deixar caure.

Però el fet mateix de passar una sol·licitud UDP a través del NAT del proveïdor va donar esperança d'èxit. Com que l'encaminador es troba a la meva jurisdicció, vaig resoldre el problema redirigint el port UDP / 11111 a l'ordinador:

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

Així, vaig tenir l'oportunitat d'iniciar una sessió UDP i rebre peticions d'Internet des de qualsevol adreça IP. En aquest moment, vaig llançar el servidor OpenVPN (després de configurar-lo) escoltant el port UDP/11111, vaig indicar l'adreça IP externa i el port (XX.1XX.1X4.2XX:4398) al telèfon intel·ligent i vaig connectar amb èxit des del telèfon intel·ligent al ordinador. Però en aquesta implementació, va sorgir un problema, calia mantenir d'alguna manera la sessió UDP fins que el client OpenVPN es connectés al servidor, no em va agradar l'opció de llançar periòdicament el client STUN - no volia carregar els servidors STUN en va.
També va cridar l'atenció l'entrada "will hairpin - hi haurà una forquilla", aquest mode

Hairpinning permet que una màquina d'una xarxa local darrere de NAT accedeixi a una altra màquina de la mateixa xarxa a l'adreça externa de l'encaminador.

Com a resultat, vaig resoldre el problema de mantenir una sessió UDP simplement: vaig llançar el client al mateix ordinador amb el servidor.
Va funcionar així:

• va llançar el client STUN amb el port local 11111
• resposta rebuda amb adreça IP externa i port XX.1XX.1X4.2XX:4398
• enviat dades amb una adreça IP externa i un port al correu (qualsevol altre servei és possible) configurat al telèfon intel·ligent
• va llançar un servidor OpenVPN en un ordinador que escoltava al port UDP/11111
• va llançar un client OpenVPN en un ordinador especificant XX.1XX.1X4.2XX:4398 per connectar-se
• en qualsevol moment va llançar el client OpenVPN al telèfon intel·ligent, especificant l'adreça IP i el port (en el meu cas, l'adreça IP no va canviar) per connectar-se

Així, vaig tenir l'oportunitat de connectar-me al meu ordinador des d'un telèfon intel·ligent. Aquesta implementació us permet connectar qualsevol client OpenVPN.

Pràctica

Prendrà:

# apt install openvpn stun-client sendemail

Després d'escriure un parell d'scripts, un parell de fitxers de configuració, generar els certificats necessaris (ja que el client del telèfon intel·ligent només funciona amb certificats), vam aconseguir la implementació habitual del servidor OpenVPN.

Guió principal a l'ordinador

# 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'enviament de correu electrònic:

# 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"

Fitxer de configuració del servidor:

# 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

Fitxer de configuració del 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

Els certificats es van generar segons aquest article.
Execució del guió:

# ./vpn11.sh

Primer fent-lo executable

# chmod +x vpn11.sh

Al costat del telèfon intel·ligent

Mitjançant la instal·lació de l'aplicació Obriu VPN per a Android, copiant el fitxer de configuració, certificats i configurant-lo, va resultar així:
Consultant el correu electrònic al meu telèfon intel·ligent
Edito el número de port a la configuració
Engego el client i em connecto

En el procés d'escriure l'article, vaig transferir la configuració de l'ordinador al Raspberry Pi 3 i vaig intentar executar-ho tot en un mòdem LTE, però no va funcionar! resultat de l'ordre

# stun stun.ekiga.net -p 11111

Versió del client STUN 0.97
Principal: mapes independents, filtre depenent del port, port aleatori, forquilla
el valor de retorn és 0x000006

значение Filtre dependent del port impedit que el sistema s'iniciés.
Però el proveïdor domèstic va deixar que el sistema funcionés al Raspberry Pi 3 sense cap problema.
En combinació amb una càmera web, amb VLC per
creant un flux RTSP des d'una càmera web

$ 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

i VLC en un telèfon intel·ligent per veure'ls (stream rtsp://10.2.0.1:8554/), va resultar que no era un sistema de vigilància de vídeo dolent a distància, també podeu configurar Samba, encaminar el trànsit a través de VPN, controlar remotament un ordinador i molt més ...

Sortida

Com ha demostrat la pràctica, per organitzar un servidor VPN, podeu prescindir d'una adreça IP externa per la qual heu de pagar, així com d'un VPS / VDS llogat. Però tot depèn del proveïdor. Per descomptat, volia obtenir més informació sobre els diferents proveïdors i tipus de NAT utilitzats, però això només és el començament...
Gràcies!

Font: www.habr.com