VPN servera darbināšana aiz pakalpojumu sniedzēja NAT

Raksts par to, kā man izdevās palaist VPN serveris aiz mājas pakalpojumu sniedzēja NAT (bez publiskas IP adreses). Ļaujiet man uzreiz precizēt: šīs ieviešanas veiktspēja ir tieši atkarīga no jūsu pakalpojumu sniedzēja izmantotā NAT veida, kā arī no maršrutētāja.
Итак, возникла у меня необходимость подключаться со своего Android-смартфона к домашнему компьютеру, оба девайса подключены к Интернету через провайдерские NAT’ы, плюсом компьютер подключен через домашний роутер, который тоже NAT’ил соединения.
Klasiskā shēma, kurā tiek izmantots nomāts VPS/VDS ar baltu IP adresi, kā arī baltas IP adreses noma no pakalpojumu sniedzēja, netika apsvērta vairāku iemeslu dēļ.
Ņemot vērā pieredze no iepriekšējiem rakstiem, veicot vairākus eksperimentus ar pakalpojumu sniedzēju STUN un NAT. Es nolēmu veikt nelielu eksperimentu, palaižot komandu mājas maršrutētājā, kurā darbojas OpenWRT programmaparatūra:

$ stun stun.sipnet.ru

ieguva rezultātu:

STUN klienta versija 0.97
Primārais: neatkarīga kartēšana, neatkarīgs filtrs, nejaušs ports, matadata
Atdeves vērtība ir 0x000002

Burtiskais tulkojums:
Independent Mapping - neatkarīga kartēšana
Neatkarīgais filtrs - neatkarīgs filtrs
nejaušs ports - nejaušs ports
būs matadata - būs matadata
Palaižot līdzīgu komandu savā datorā, es saņēmu:

STUN klienta versija 0.97
Primārais: neatkarīga kartēšana, portatkarīgais filtrs, nejaušs ports, matadata
Atdeves vērtība ir 0x000006

Portatkarīgais filtrs — no porta atkarīgs filtrs
Komandas izvades rezultātu atšķirība liecināja, ka mājas maršrutētājs sniedza “savu ieguldījumu” pakešu pārsūtīšanas procesā no interneta; tas izpaudās faktā, ka, izpildot komandu datorā:

stun stun.sipnet.ru -p 11111 -v

Es saņēmu rezultātu:

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

uz šo brīdi kādu laiku tika atvērta UDP sesija, ja šajā brīdī nosūtāt UDP pieprasījumu (piemēram: netcat XX.1XX.1X4.2XX 4398 -u), tad pieprasījums nonāca mājas maršrutētājā, kas tika apstiprināja TCPDump, kas tajā darbojas, bet pieprasījums nesasniedza datoru - IPtables kā NAT tulkotājs maršrutētājā to atmeta.

Bet pats fakts, ka UDP pieprasījums tika nosūtīts caur pakalpojumu sniedzēja NAT, deva cerību uz panākumiem. Tā kā maršrutētājs atrodas manā jurisdikcijā, es atrisināju problēmu, novirzot UDP/11111 portu uz datoru:

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

Тем самым получил возможность инициировать UDP-сессию и получать запросы из Интернета с любого IP-адреса. В этот момент запустил OpenVPN-server (предварительно сконфигурировав) слушая UDP/11111 порт, указал на смартфоне внешний IP-адрес и порт (XX.1XX.1X4.2XX:4398) и успешно подключился со смартфона к компьютеру. Но в данной реализации возникла проблема, нужно было как-то поддерживать UDP-сессию до момента подключения OpenVPN-клиента к серверу, вариант с периодическим запуском STUN-клиента мне не понравился — не хотелось впусту нагружать STUN-серверы.
Es arī pamanīju ierakstu "būs matadata - būs matadata", šis režīms

Matu piespraušana ļauj vienai iekārtai lokālajā tīklā aiz NAT piekļūt citai iekārtai tajā pašā tīklā maršrutētāja ārējā adresē.

Rezultātā es vienkārši atrisināju UDP sesijas uzturēšanas problēmu - palaižu klientu vienā datorā ar serveri.
Tas strādāja šādi:

• palaida STUN klientu vietējā portā 11111
• saņēma atbildi ar ārējo IP adresi un portu XX.1XX.1X4.2XX:4398
• nosūtīja datus ar ārējo IP adresi un portu uz viedtālrunī konfigurētu e-pastu (iespējams jebkurš cits pakalpojums).
• запускал OpenVPN-сервер на компьютере с прослушкой UDP/11111 порта
• запускал OpenVPN-клиента на компьютере с указанием XX.1XX.1X4.2XX:4398 для подключения
• в любое время запускал OpenVPN-клиента на смартфоне с указанием IP-адреса и порта (в моем случае IP-адрес не менялся) для подключения

Таким образом я получил возможность подключаться к своему компьютеру со смартфона. Данная реализация позволяет подключать любого OpenVPN-клиента.

Prakse

Jums būs nepieciešams:

# apt install openvpn stun-client sendemail

Написав пару скриптов, пару конфигурационных файлов, сгенерировав необходимые сертификаты (так как клиент на смартфоне работает только по сертификатам) получилась обычная реализация OpenVPN-сервера.

Galvenais skripts datorā

# 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

Skripts datu nosūtīšanai pa e-pastu:

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

Servera konfigurācijas fails:

# 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 konfigurācijas fails:

# 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

Sertifikāti tika ģenerēti, izmantojot Šis raksts.
Skripta palaišana:

# ./vpn11.sh

Vispirms padarot to izpildāmu

# chmod +x vpn11.sh

Viedtālruņa pusē

Instalējot lietojumprogrammu OpenVPN par Android, nokopējot konfigurācijas failu, sertifikātus un konfigurējot to, tas izrādījās šādi:
Es pārbaudu savu e-pastu savā viedtālrunī
Iestatījumos rediģēju porta numuru
Palaižu klientu un izveidoju savienojumu

Rakstot šo rakstu, es pārsūtīju konfigurāciju no sava datora uz Raspberry Pi 3 un mēģināju visu palaist LTE modemā, taču tas nedarbojās! Komandas rezultāts

# stun stun.ekiga.net -p 11111

STUN klienta versija 0.97
Primārais: neatkarīga kartēšana, portatkarīgais filtrs, nejaušs ports, matadata
Atdeves vērtība ir 0x000006

vērtība Portatkarīgais filtrs neļāva sistēmai startēt.
Bet mājas pakalpojumu sniedzējs ļāva sistēmai startēt Raspberry Pi 3 bez problēmām.
Savienojumā ar tīmekļa kameru ar VLC priekš
izveidojot RTSP straumi no tīmekļa kameras

$ 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

un VLC viedtālrunī skatīšanai (straume rtsp://10.2.0.1:8554/), izrādījās laba attālinātā videonovērošanas sistēma, var arī instalēt Samba, maršrutēt trafiku caur VPN, attālināti vadīt datoru un daudz ko citu vairāk...

secinājums

Kā rāda prakse, VPN servera organizēšanai var iztikt bez ārējas IP adreses, par kuru jāmaksā, tāpat kā par īrētu. VPS / VDSBet tas viss ir atkarīgs no pakalpojumu sniedzēja. Protams, es vēlētos iegūt vairāk informācijas par dažādiem pakalpojumu sniedzējiem un viņu izmantotajiem NAT veidiem, bet tas ir tikai sākums...
Спасибо за внимание!

Avots: www.habr.com