ProHoster > Блог > Administrado > Lanĉante VPN-servilon malantaŭ la NAT de provizanto

Lanĉante VPN-servilon malantaŭ la NAT de provizanto

Artikolo pri kiel mi sukcesis funkciigi VPN-servilon malantaŭ la NAT de hejma provizanto (sen blanka IP-adreso). Lasu min diri al vi tuj: la agado de ĉi tiu efektivigo rekte dependas de la tipo de NAT uzata de via provizanto, same kiel la enkursigilo.
Do, mi devis konekti de mia Android-saĝtelefono al mia hejma komputilo, ambaŭ aparatoj estas konektitaj al la Interreto per provizanto NAT-oj, krome la komputilo estas konektita per hejma enkursigilo, kiu ankaŭ NAT-konektoj.
La klasika skemo uzante luitan VPS / VDS kun blanka IP-adreso, same kiel lui blankan IP-adreson de la provizanto, ne estis konsiderata pro pluraj kialoj.
Konsiderante sperto de pasintaj artikoloj, pasiginte plurajn eksperimentojn kun STUN-oj kaj NAT-oj de provizantoj. Mi decidis pri malgranda eksperimento per ekzekuto de la komando sur hejma enkursigilo, kiu funkcias OpenWRT-firmvaro: 

$ stun stun.sipnet.ru

ricevis la rezulton:

STUN-klienta versio 0.97
Ĉefa: Sendependa Mapado, Sendependa Filtrilo, hazarda haveno, harpinglo
revenvaloro estas 0x000002

Laŭvorta traduko:
Independent Mapping - sendependa ekrano
Independent Filter - sendependa filtrilo
random port - hazarda haveno
will harping - estos harpinglo
Post rulado de simila komando en mia komputilo, mi ricevis:

STUN-klienta versio 0.97
Ĉefa: Sendependa Mapo, Haveno Dependa Filtrilo, hazarda haveno, harpinglo
revenvaloro estas 0x000006

Port Dependent Filter - haveno dependa filtrilo
La diferenco en la rezultoj de la eligo de la komandoj indikis, ke la hejma enkursigilo faris "sia kontribuo" al la procezo de dissendado de pakaĵoj el Interreto, tio manifestiĝis en la fakto, ke kiam la komando estis ekzekutita en la komputilo:

stun stun.sipnet.ru -p 11111 -v

mi ricevis la rezulton:

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

en tiu momento, UDP-sesio estis malfermita por tempeto, se en tiu momento UDP-peto estis sendita (ekzemple: netcat XX.1XX.1X4.2XX 4398 -u), tiam la peto venis al la hejma enkursigilo, kiu estis konfirmite de TCPDump kuranta sur ĝi, sed la peto ne atingis la komputilon - IPtables kiel NAT-tradukisto sur la enkursigilo faligis ĝin.
Lanĉante VPN-servilon malantaŭ la NAT de provizanto
Sed la fakto mem trapasi UDP-peton tra la NAT de la provizanto donis esperon pri sukceso. Ĉar la enkursigilo estas en mia jurisdikcio, mi solvis la problemon redirektante la UDP / 11111-havenon al la komputilo:

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

Tiel, mi ricevis la ŝancon komenci UDP-sesion kaj ricevi petojn de la Interreto de iu ajn IP-adreso. En ĉi tiu momento, mi lanĉis OpenVPN-servilon (post agordi ĝin) aŭskultante UDP/11111-havenon, indikis la eksteran IP-adreson kaj havenon (XX.1XX.1X4.2XX:4398) sur la saĝtelefono kaj sukcese konektita de la inteligenta telefono al la komputilo. Sed en ĉi tiu efektivigo, aperis problemo, necesis iel konservi la UDP-sesion ĝis la OpenVPN-kliento konektita al la servilo, mi ne ŝatis la eblon periode lanĉi la STUN-klienton - mi ne volis ŝargi STUN-servilojn. vane.
Ankaŭ atentigis la enskribon "will harping - estos harpinglo", ĉi tiu reĝimo

Harpinglado permesas al unu maŝino sur loka reto malantaŭ NAT aliri alian maŝinon sur la sama reto ĉe la ekstera adreso de la enkursigilo.

Lanĉante VPN-servilon malantaŭ la NAT de provizanto
Kiel rezulto, mi solvis la problemon pri konservado de UDP-sesio simple - mi lanĉis la klienton en la sama komputilo kun la servilo.
Ĝi funkciis tiel:

  • lanĉis STUN-klienton kun loka haveno 11111
  • ricevis respondon kun ekstera IP-adreso kaj haveno XX.1XX.1X4.2XX:4398
  • sendis datumojn kun ekstera IP-adreso kaj haveno al la poŝto (iu ajn alia servo eblas) agordita sur la inteligenta telefono
  • lanĉis OpenVPN-servilon sur komputilo aŭskultanta sur UDP/11111-haveno
  • lanĉis OpenVPN-klienton en komputilo specifantan XX.1XX.1X4.2XX:4398 por konekti
  • iam ajn lanĉis la OpenVPN-klienton sur la inteligenta telefono, specifante la IP-adreson kaj havenon (en mia kazo, la IP-adreso ne ŝanĝiĝis) por konekti

Lanĉante VPN-servilon malantaŭ la NAT de provizanto
Tiel, mi ricevis la ŝancon konekti al mia komputilo de inteligenta telefono. Ĉi tiu efektivigo permesas vin konekti ajnan OpenVPN-klienton.

Praktiko

Ĝi prenos: 

# apt install openvpn stun-client sendemail

Post verkado de kelkaj skriptoj, kelkaj agordaj dosieroj, generinte la necesajn atestojn (ĉar la kliento en la inteligenta telefono funkcias nur per atestiloj), ni ricevis la kutiman efektivigon de la OpenVPN-servilo.

Ĉefa skripto en komputilo

# 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

Retpoŝto senda skripto:

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

Servila agordosiero:

# 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

Klienta agordosiero:

# 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

Atestiloj estis generitaj laŭ ĉi tiu artikolo.
Rugante la skripton:

# ./vpn11.sh

Farante ĝin efektivigebla unue 

# chmod +x vpn11.sh

Sur la saĝtelefona flanko

Instalante la aplikaĵon Malfermu VPN por Android, kopiante la agordan dosieron, atestojn kaj agordante ĝin, ĝi rezultis jene:
Kontrolante retpoŝton sur mia inteligenta telefonoLanĉante VPN-servilon malantaŭ la NAT de provizanto
Mi redaktas la pordan numeron en la agordojLanĉante VPN-servilon malantaŭ la NAT de provizanto
Mi komencas la klienton kaj konektasLanĉante VPN-servilon malantaŭ la NAT de provizanto

En la procezo de verkado de la artikolo, mi translokigis la agordon de la komputilo al la Raspberry Pi 3 kaj provis ruli la tuton per LTE-modemo, sed ĝi ne funkciis! komanda rezulto 

# stun stun.ekiga.net -p 11111

STUN-klienta versio 0.97
Ĉefa: Sendependa Mapo, Haveno Dependa Filtrilo, hazarda haveno, harpinglo
revenvaloro estas 0x000006

signifo Haveno Dependa Filtrilo malhelpis la sistemon komenci.
Sed la hejma provizanto lasis la sistemon funkcii sur la Raspberry Pi 3 sen problemoj.
Kune kun retkamerao, kun VLC por
kreante RTSP-rivereton de retkamerao

$ 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

kaj VLC sur inteligenta telefono por spektado (fluo rtsp://10.2.0.1:8554/), ĝi rezultis ne malbona videogvatsistemo malproksime, vi ankaŭ povas agordi Samba, direkti trafikon per VPN, malproksime kontroli komputilon. kaj multe pli...

konkludo

Kiel praktiko montris, por organizi VPN-servilon, vi povas malhavi eksteran IP-adreson, por kiu vi devas pagi, kaj ankaŭ por luita VPS / VDS. Sed ĉio dependas de la provizanto. Kompreneble, mi volis akiri pli da informoj pri la diversaj provizantoj kaj specoj de uzataj NAT-oj, sed ĉi tio estas nur la komenco...
Спасибо за внимание!

fonto: www.habr.com

Aldoni komenton