Executar un servidor VPN detrás do NAT do provedor

Un artigo sobre como conseguín executar un servidor VPN detrás do NAT do meu provedor doméstico (sen un enderezo IP branco). Permíteme facer unha reserva de inmediato: iso o rendemento desta implementación depende directamente do tipo de NAT utilizado polo teu provedor, así como do router.
Entón, necesitaba conectarme desde o meu teléfono intelixente Android ao meu ordenador doméstico, ambos os dispositivos están conectados a Internet mediante NAT do provedor, ademais de que o ordenador está conectado a través dun enrutador doméstico, que tamén conecta conexións NAT.
O esquema clásico que utiliza un VPS/VDS alugado cun enderezo IP branco, así como alugar un enderezo IP branco a un provedor, non se considerou por varias razóns.
Tendo en conta experiencia de artigos pasados, tendo realizado varios experimentos con STUN e NAT de provedores. Decidín facer un pequeno experimento executando o comando nun enrutador doméstico que executa o firmware OpenWRT:

$ stun stun.sipnet.ru

obtivo o resultado:

Versión do cliente STUN 0.97
Principal: Mapeo independente, filtro independente, porto aleatorio, forquilla
O valor de retorno é 0x000002

Tradución literal:
Mapeo independente - cartografía independente
Filtro independente - filtro independente
random port - porto aleatorio
will hairpin - haberá unha horquilla
Executando un comando semellante no meu PC, teño:

Versión do cliente STUN 0.97
Principal: Mapeo independente, filtro dependente do porto, porto aleatorio, forquilla
O valor de retorno é 0x000006

Filtro dependente do porto: filtro dependente do porto
A diferenza nos resultados da saída do comando indicaba que o enrutador doméstico estaba facendo "a súa contribución" ao proceso de transmisión de paquetes desde Internet; isto manifestouse no feito de que ao executar o comando no ordenador:

stun stun.sipnet.ru -p 11111 -v

Estaba obtendo o resultado:

...
Enderezo mapeado = XX.1XX.1X4.2XX:4398
...

neste momento, abriuse unha sesión UDP durante algún tempo, se neste momento envía unha solicitude UDP (por exemplo: netcat XX.1XX.1X4.2XX 4398 -u), entón a solicitude chegou ao enrutador doméstico, que foi confirmado por TCPDump en execución, pero a solicitude non chegou ao ordenador: IPtables, como tradutor NAT do enrutador, abandonouno.

Pero o feito mesmo de que a solicitude de UDP pasase polo NAT do provedor deu esperanzas de éxito. Dado que o enrutador está situado na miña xurisdición, resolvín o problema redirixindo o porto UDP/11111 ao ordenador:

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

Así, puiden iniciar unha sesión UDP e recibir solicitudes de Internet desde calquera enderezo IP. Neste momento, lancei o servidor OpenVPN (configurado previamente) escoitando o porto UDP/11111, indiquei o enderezo IP externo e o porto (XX.1XX.1X4.2XX:4398) no teléfono intelixente e conectou correctamente desde o teléfono intelixente a o ordenador. Pero nesta implementación xurdiu un problema: era necesario manter dalgún xeito a sesión UDP ata que o cliente OpenVPN se conectase ao servidor; non me gustaba a opción de lanzar periódicamente o cliente STUN, non quería perder a carga. os servidores STUN.
Tamén notei a entrada "will hairpin - haberá unha horquilla", este modo

O hairpinning permite que unha máquina dunha rede local detrás dun NAT acceda a outra máquina da mesma rede no enderezo externo do enrutador.

Como resultado, simplemente resolvín o problema de manter unha sesión UDP: lancei o cliente no mesmo ordenador co servidor.
Funcionou así:

• lanzou o cliente STUN no porto local 11111
• recibiu unha resposta cun enderezo IP externo e un porto XX.1XX.1X4.2XX:4398
• enviou datos cun enderezo IP externo e un porto ao correo electrónico (calquera outro servizo é posible) configurado no teléfono intelixente
• lanzou o servidor OpenVPN nun ordenador que escoitaba o porto UDP/11111
• lanzou o cliente OpenVPN no ordenador especificando XX.1XX.1X4.2XX:4398 para a conexión
• en calquera momento lanzou o cliente OpenVPN no teléfono intelixente indicando o enderezo IP e o porto (no meu caso o enderezo IP non cambiou) para conectar

Deste xeito puiden conectarme ao meu ordenador desde o meu teléfono intelixente. Esta implementación permítelle conectar calquera cliente OpenVPN.

Práctica

Tomará:

# apt install openvpn stun-client sendemail

Despois de escribir un par de scripts, un par de ficheiros de configuración e xerar os certificados necesarios (xa que o cliente nun teléfono intelixente só funciona con certificados), conseguimos a implementación habitual dun servidor OpenVPN.

Script principal no ordenador

# 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 para enviar datos por correo electrónico:

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

Ficheiro de configuración do 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

Ficheiro de configuración do cliente:

# 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

Os certificados foron xerados usando Este artigo.
Execución do script:

# ./vpn11.sh

Primeiro facéndoo executable

# chmod +x vpn11.sh

No lado do teléfono intelixente

Ao instalar a aplicación OpenVPN para Android, despois de copiar o ficheiro de configuración, certificados e configuralo, resultou así:
Comprobo o meu correo electrónico no meu teléfono intelixente
Edito o número de porto na configuración
Lanzo o cliente e conecto

Mentres escribía este artigo, transferín a configuración do meu ordenador ao Raspberry Pi 3 e tente executar todo nun módem LTE, pero non funcionou. Comando Resultado

# stun stun.ekiga.net -p 11111

Versión do cliente STUN 0.97
Principal: Mapeo independente, filtro dependente do porto, porto aleatorio, forquilla
O valor de retorno é 0x000006

significado Filtro dependente do porto non permitiu que o sistema se inicie.
Pero o provedor doméstico permitiu que o sistema comezase na Raspberry Pi 3 sen ningún problema.
En conxunto cunha cámara web, con VLC para
creando un fluxo RTSP desde unha cámara 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

e VLC nun teléfono intelixente para ver (stream rtsp://10.2.0.1:8554/), resultou ser un bo sistema de videovixilancia remota, tamén podes instalar Samba, enrutar o tráfico a través de VPN, controlar remotamente o teu ordenador e moito. máis...

Saída

Como demostrou a práctica, para organizar un servidor VPN, pode prescindir dun enderezo IP externo polo que cómpre pagar, igual que para un VPS/VDS alugado. Pero todo depende do provedor. Por suposto, quería obter máis información sobre os diferentes provedores e tipos de NAT utilizados, pero isto é só o comezo...
Спасибо за внимание!

Fonte: www.habr.com