VPN serverio veikimas už teikėjo NAT

Straipsnis apie tai, kaip man pavyko paleisti VPN serverį už savo namų teikėjo NAT (be balto IP adreso). Leiskite man iš karto rezervuoti: tai šio diegimo našumas tiesiogiai priklauso nuo jūsų teikėjo naudojamo NAT tipo ir maršrutizatoriaus.
Taigi, man reikėjo prisijungti iš savo Android išmaniojo telefono prie namų kompiuterio, abu įrenginiai yra prijungti prie interneto per teikėjo NAT, be to, kompiuteris prijungtas per namų maršrutizatorių, kuris taip pat yra NAT jungtys.
Klasikinė schema, naudojant nuomojamą VPS/VDS su baltu IP adresu, taip pat balto IP adreso nuoma iš tiekėjo, nebuvo svarstoma dėl kelių priežasčių.
Atsižvelgiant į patirtis iš ankstesnių straipsnių, atlikęs keletą eksperimentų su tiekėjų STUN ir NAT. Nusprendžiau atlikti nedidelį eksperimentą paleisdamas komandą namų maršrutizatoriuje, kuriame veikia OpenWRT programinė įranga:

$ stun stun.sipnet.ru

gavosi rezultatas:

STUN kliento versija 0.97
Pagrindinis: nepriklausomas atvaizdavimas, nepriklausomas filtras, atsitiktinis prievadas, plaukų segtukas
Grąžinimo vertė yra 0x000002

Pažodinis vertimas:
Independent Mapping – nepriklausomas žemėlapių sudarymas
Nepriklausomas filtras – nepriklausomas filtras
atsitiktinis prievadas – atsitiktinis prievadas
bus plaukų segtukas - bus segtukas
Vykdydamas panašią komandą savo kompiuteryje, gavau:

STUN kliento versija 0.97
Pagrindinis: nepriklausomas atvaizdavimas, prievado priklausomas filtras, atsitiktinis prievadas, segtukas
Grąžinimo vertė yra 0x000006

Port Dependent Filter – nuo ​​prievado priklausomas filtras
Komandos išvesties rezultatų skirtumas parodė, kad namų maršrutizatorius įnešė „savo indėlį“ į paketų perdavimo iš interneto procesą; tai pasireiškė tuo, kad vykdant komandą kompiuteryje:

stun stun.sipnet.ru -p 11111 -v

Sulaukiau rezultato:

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

šiuo metu kuriam laikui buvo atidaryta UDP sesija, jei šiuo metu siunčiate UDP užklausą (pvz.: netcat XX.1XX.1X4.2XX 4398 -u), tada užklausa atėjo į namų maršrutizatorių, kuris buvo patvirtino jame veikiantis TCPDump, tačiau užklausa kompiuterio nepasiekė – IPtables, kaip maršrutizatoriaus NAT vertėjas, jį numetė.

Tačiau pats faktas, kad UDP užklausa buvo perduota per teikėjo NAT, suteikė sėkmės. Kadangi maršrutizatorius yra mano jurisdikcijoje, problemą išsprendžiau nukreipdamas UDP/11111 prievadą į kompiuterį:

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

Taigi galėjau inicijuoti UDP sesiją ir gauti užklausas iš interneto iš bet kurio IP adreso. Šiuo metu paleidau OpenVPN serverį (anksčiau jį sukonfigūravus), klausydamas UDP/11111 prievado, nurodžiau išorinį IP adresą ir prievadą (XX.1XX.1X4.2XX:4398) išmaniajame telefone ir sėkmingai prisijungiau iš išmaniojo telefono prie kompiuteris. Tačiau šiame diegime iškilo problema: reikėjo kažkaip palaikyti UDP sesiją, kol OpenVPN klientas prisijungs prie serverio; man nepatiko galimybė periodiškai paleisti STUN klientą - nenorėjau eikvoti apkrovos STUN serveriai.
Taip pat pastebėjau įrašą „bus plaukų segtukas - bus segtukas“, šis režimas

„Hairpining“ leidžia vienam įrenginiui vietiniame tinkle, esančiame už NAT, pasiekti kitą įrenginį tame pačiame tinkle išoriniu maršruto parinktuvo adresu.

Dėl to aš tiesiog išsprendžiau UDP seanso palaikymo problemą – paleidau klientą tame pačiame kompiuteryje su serveriu.
Veikė taip:

• paleido STUN klientą vietiniame prievade 11111
• gavo atsakymą su išoriniu IP adresu ir prievadu XX.1XX.1X4.2XX:4398
• siunčia duomenis su išoriniu IP adresu ir prievadu į el. paštą (galima bet kokia kita paslauga), sukonfigūruotą išmaniajame telefone
• paleido OpenVPN serverį kompiuteryje, kuris klausosi UDP/11111 prievado
• kompiuteryje paleido „OpenVPN“ klientą, nurodydamas prisijungimo XX.1XX.1X4.2XX:4398
• bet kuriuo metu paleido „OpenVPN“ klientą išmaniajame telefone, nurodydamas IP adresą ir prievadą (mano atveju IP adresas nepasikeitė), kad prisijungtų

Tokiu būdu galėjau prisijungti prie kompiuterio iš savo išmaniojo telefono. Šis įgyvendinimas leidžia prijungti bet kurį „OpenVPN“ klientą.

Praktika

Jums reikės:

# apt install openvpn stun-client sendemail

Parašę porą scenarijų, porą konfigūracijos failų ir sugeneravę reikiamus sertifikatus (kadangi klientas išmaniajame telefone dirba tik su sertifikatais), gavome įprastą OpenVPN serverio diegimą.

Pagrindinis scenarijus kompiuteryje

# 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

Duomenų siuntimo el. paštu scenarijus:

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

Serverio konfigūracijos failas:

# 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

Kliento konfigūracijos failas:

# 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

Sertifikatai buvo sukurti naudojant Šis straipsnis.
Scenarijaus vykdymas:

# ./vpn11.sh

Pirmiausia padarydami jį vykdomą

# chmod +x vpn11.sh

Išmaniojo telefono pusėje

Įdiegę programą „OpenVPN“, skirta „Android“., nukopijavus konfigūracijos failą, sertifikatus ir sukonfigūravus, pasirodė taip:
El. paštą tikrinu išmaniajame telefone
Nustatymuose redaguoju prievado numerį
Paleidžiu klientą ir prisijungiu

Rašydamas šį straipsnį, perkėliau konfigūraciją iš savo kompiuterio į Raspberry Pi 3 ir bandžiau viską paleisti LTE modeme, bet tai nepavyko! Komandos rezultatas

# stun stun.ekiga.net -p 11111

STUN kliento versija 0.97
Pagrindinis: nepriklausomas atvaizdavimas, prievado priklausomas filtras, atsitiktinis prievadas, segtukas
Grąžinimo vertė yra 0x000006

vertė Nuo uosto priklausomas filtras neleido sistemai paleisti.
Tačiau namų paslaugų teikėjas leido sistemai paleisti Raspberry Pi 3 be jokių problemų.
Kartu su žiniatinklio kamera su VLC
sukurti RTSP srautą iš internetinės kameros

$ 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

ir VLC išmaniajame telefone peržiūrai (srautas rtsp://10.2.0.1:8554/), tai pasirodė gera nuotolinio vaizdo stebėjimo sistema, taip pat galite įdiegti Samba, nukreipti srautą per VPN, nuotoliniu būdu valdyti kompiuterį ir daug daugiau daugiau...

Produkcija

Kaip parodė praktika, norėdami sutvarkyti VPN serverį, galite apsieiti be išorinio IP adreso, už kurį reikia mokėti, kaip ir už nuomojamą VPS/VDS. Bet viskas priklauso nuo tiekėjo. Žinoma, norėjau gauti daugiau informacijos apie įvairius naudojamus NAT teikėjus ir tipus, bet tai tik pradžia...
Dėkojame už dėmesį!

Šaltinis: www.habr.com