VPN-serveri käivitamine pakkuja NAT-i taga

Artikkel sellest, kuidas mul õnnestus VPN-serverit käivitada koduteenusepakkuja NAT-i taga (ilma valge IP-aadressita). Ütlen teile kohe: selle teostuse jõudlus sõltub otseselt teie teenusepakkuja kasutatavast NAT-i tüübist ja ruuterist.
Seega tekkis vajadus luua ühendus Android-nutitelefonist koduarvutiga, mõlemad seadmed on Internetiga ühendatud pakkuja NAT-ide kaudu, lisaks on arvuti ühendatud koduruuteri kaudu, mis on samuti NAT-ühendused.
Klassikalist skeemi, milles kasutati valge IP-aadressiga renditud VPS-i / VDS-i, ega ka pakkujalt valge IP-aadressi rentimist, ei võetud mitmel põhjusel arvesse.
Võttes arvesse varasemate artiklite kogemus, olles teinud mitmeid katseid teenusepakkujate STUN-ide ja NAT-idega. Otsustasin teha väikese katse, täites OpenWRT püsivara käitavas koduruuteris käsu:

$ stun stun.sipnet.ru

sai tulemuse:

STUN kliendi versioon 0.97
Peamine: sõltumatu kaardistamine, sõltumatu filter, juhuslik port, juuksenõel
tagastusväärtus on 0x000002

Sõnasõnaline tõlge:
Sõltumatu kaardistamine – sõltumatu kuva
Sõltumatu filter – sõltumatu filter
juhuslik port - juhuslik port
hakkab juuksenõel - tuleb juuksenõel
Pärast sarnase käsu käivitamist oma arvutis sain:

STUN kliendi versioon 0.97
Peamine: sõltumatu kaardistamine, pordist sõltuv filter, juhuslik port, juuksenõel
tagastusväärtus on 0x000006

Port Dependent Filter – pordist sõltuv filter
Käskude väljundi tulemuste erinevus näitas, et koduruuter andis "oma panuse" Internetist pakettide edastamise protsessi, see väljendus selles, et kui käsk arvutis käivitati:

stun stun.sipnet.ru -p 11111 -v

sain tulemuse:

...
Kaardistatud aadress = XX.1XX.1X4.2XX:4398
...

sel hetkel avati korraks UDP seanss, kui sel hetkel saadeti UDP päring (näiteks: netcat XX.1XX.1X4.2XX 4398 -u), siis tuli päring koduruuterisse, mis oli kinnitas sellel töötav TCPDump, kuid päring ei jõudnud arvutisse – IPtables kui ruuteri NAT-i tõlkija jättis selle maha.

Kuid juba see, et UDP päring edastati teenusepakkuja NAT-i kaudu, andis lootust edule. Kuna ruuter on minu jurisdiktsioonis, lahendasin probleemi UDP / 11111 pordi ümbersuunamisega arvutisse:

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

Nii sain võimaluse algatada UDP seanss ja saada Internetist päringuid mis tahes IP-aadressilt. Sel hetkel käivitasin OpenVPN-serveri (pärast selle seadistamist), mis kuulab UDP/11111 porti, näitasin nutitelefoni välise IP-aadressi ja pordi (XX.1XX.1X4.2XX:4398) ning ühendasin edukalt nutitelefonist arvuti. Kuid selles teostuses tekkis probleem, oli vaja UDP-seanssi kuidagi säilitada, kuni OpenVPN-i klient on serveriga ühendatud, mulle ei meeldinud STUN-kliendi perioodilise käivitamise võimalus - ma ei tahtnud STUN-servereid laadida. asjatult.
Samuti juhtis tähelepanu kirjele "hakkab juuksenõel - tuleb juuksenõel", see režiim

Juuksenõelus võimaldab ühel NAT-i taga asuval kohalikul võrgul asuval masinal ruuteri välisaadressil juurde pääseda teisele samas võrgus olevale masinale.

Selle tulemusena lahendasin UDP-seansi säilitamise probleemi lihtsalt - käivitasin kliendi serveriga samas arvutis.
See töötas nii:

• käivitas STUN-i kliendi kohaliku pordiga 11111
• sai vastuse välise IP-aadressi ja pordiga XX.1XX.1X4.2XX:4398
• saatis andmed välise IP-aadressi ja pordiga nutitelefonis konfigureeritud posti (võimalik on ka mis tahes muu teenus).
• käivitas OpenVPN-serveri arvutis, mis kuulab UDP/11111 porti
• käivitas OpenVPN-i kliendi arvutis, mis määrab ühenduse loomiseks XX.1XX.1X4.2XX:4398
• käivitas igal ajal nutitelefonis OpenVPN-kliendi, määrates ühenduse loomiseks IP-aadressi ja pordi (minu puhul IP-aadress ei muutunud)

Nii sain võimaluse nutitelefonist arvutiga ühenduda. See rakendus võimaldab teil ühendada mis tahes OpenVPN-i kliendi.

Tava

Sul läheb vaja:

# apt install openvpn stun-client sendemail

Pärast paari skripti, paari konfiguratsioonifaili kirjutamist, vajalike sertifikaatide genereerimist (kuna nutitelefonis olev klient töötab ainult sertifikaatidega), saime OpenVPN-serveri tavapärase juurutuse.

Põhiskript arvutis

# 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

Meili saatmise skript:

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

Serveri konfiguratsioonifail:

# 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

Kliendi konfiguratsioonifail:

# 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

Sertifikaadid genereeriti vastavalt see artikkel.
Skripti käivitamine:

# ./vpn11.sh

Esmalt käivitatavaks muutmine

# chmod +x vpn11.sh

Nutitelefoni poolel

Rakenduse installimisega Avage Androidi VPN, kopeerides konfiguratsioonifaili, sertifikaadid ja konfigureerides, selgus selline:
Kontrollin nutitelefonis e-posti
Muudan seadetes pordi numbrit
Käivitan kliendi ja ühendan

Artikli kirjutamise käigus teisaldasin konfiguratsiooni arvutist Raspberry Pi 3-le ja proovisin kogu asja LTE-modemil käivitada, kuid see ei töötanud! käsu tulemus

# stun stun.ekiga.net -p 11111

STUN kliendi versioon 0.97
Peamine: sõltumatu kaardistamine, pordist sõltuv filter, juhuslik port, juuksenõel
tagastusväärtus on 0x000006

väärtus Pordist sõltuv filter takistas süsteemi käivitumist.
Kuid koduteenusepakkuja lasi süsteemil Raspberry Pi 3-l probleemideta töötada.
Koos veebikaameraga koos VLC-ga
RTSP-voo loomine veebikaamerast

$ 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

ja vaatamiseks nutitelefonis VLC-d (voog rtsp://10.2.0.1:8554/), ei osutus kaugeltki paha videovalvesüsteem, saate ka Samba seadistada, liiklust VPN-i kaudu suunata, arvutit kaugjuhtida ja palju muud...

Väljund

Nagu praktika on näidanud, saate VPN-serveri korraldamiseks hakkama ilma välise IP-aadressita, mille eest peate maksma, aga ka renditud VPS-i / VDS-i eest. Kuid kõik sõltub teenusepakkujast. Muidugi tahtsin saada rohkem teavet erinevate pakkujate ja kasutatavate NAT-tüüpide kohta, kuid see on alles algus ...
Tänan teid tähelepanu eest!

Allikas: www.habr.com