VPN-kiszolgáló futtatása a szolgáltató NAT-ja mögött

Egy cikk arról, hogyan sikerült VPN-kiszolgálót futtatnom az otthoni szolgáltatóm NAT-ja mögött (fehér IP-cím nélkül). Hadd foglaljak le azonnal: azt ennek a megvalósításnak a teljesítménye közvetlenül függ a szolgáltató által használt NAT típusától, valamint az útválasztótól.
Tehát csatlakoznom kellett az Android okostelefonomról az otthoni számítógépemre, mindkét eszköz a szolgáltatói NAT-okon keresztül csatlakozik az internethez, valamint a számítógép egy otthoni útválasztón keresztül csatlakozik, amely szintén NAT-kapcsolatokkal rendelkezik.
A klasszikus sémát, amelyben fehér IP-címmel bérelt VPS/VDS-t használnak, valamint fehér IP-címet bérelnek egy szolgáltatótól, több okból nem vették figyelembe.
Számításba vesz tapasztalatok korábbi cikkekből, miután számos kísérletet végzett a szolgáltatók STUN-jaival és NAT-jaival. Úgy döntöttem, hogy egy kis kísérletet végzek úgy, hogy futtatom a parancsot egy OpenWRT firmware-t futtató otthoni útválasztón:

$ stun stun.sipnet.ru

megvan az eredmény:

STUN kliens verzió 0.97
Elsődleges: Független leképezés, független szűrő, véletlenszerű port, hajtű
A visszatérési érték 0x000002

Szó szerinti fordítás:
Independent Mapping – független térképezés
Független szűrő - független szűrő
véletlenszerű port - véletlenszerű port
lesz hajtű – lesz hajtű
Hasonló parancsot futtatva a számítógépemen, ezt kaptam:

STUN kliens verzió 0.97
Elsődleges: Független leképezés, portfüggő szűrő, véletlenszerű port, hajtű
A visszatérési érték 0x000006

Port Dependent Filter – portfüggő szűrő
A parancskimenet eredményének különbsége azt jelezte, hogy az otthoni útválasztó „hozzájárul” az internetről érkező csomagok továbbításának folyamatához; ez abban nyilvánult meg, hogy a parancs végrehajtása során a számítógépen:

stun stun.sipnet.ru -p 11111 -v

Megkaptam az eredményt:

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

ebben a pillanatban egy UDP-munkamenet nyílt egy ideig, ha ebben a pillanatban küld egy UDP-kérést (például: netcat XX.1XX.1X4.2XX 4398 -u), akkor a kérés megérkezett az otthoni útválasztóhoz, ami megerősítette a rajta futó TCPDump, de a kérés nem jutott el a számítógéphez - az IPtables, mint a routeren lévő NAT fordító, eldobta.

De maga a tény, hogy az UDP-kérés átment a szolgáltató NAT-ján, reményt adott a sikerre. Mivel a router az én joghatóságomban található, a problémát úgy oldottam meg, hogy átirányítottam az UDP/11111 portot a számítógépre:

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

Így tudtam UDP-munkamenetet kezdeményezni és kéréseket fogadni az internetről bármilyen IP-címről. Ebben a pillanatban elindítottam az OpenVPN-szervert (miután korábban konfiguráltam), amely az UDP/11111 portot figyeli, jeleztem a külső IP-címet és portot (XX.1XX.1X4.2XX:4398) az okostelefonon, és sikeresen csatlakoztam az okostelefonról a a számítógép. Ebben a megvalósításban azonban felmerült egy probléma: valahogyan fenn kellett tartani az UDP-munkamenetet, amíg az OpenVPN kliens nem csatlakozik a szerverhez; nem tetszett a STUN kliens időszakos elindítása - nem akartam a terhelést pazarolni a STUN szerverek.
Észrevettem a bejegyzést is:lesz hajtű – lesz hajtű", ez a mód

A hajrögzítés lehetővé teszi, hogy a NAT mögötti helyi hálózat egyik gépe hozzáférjen egy másik géphez ugyanazon a hálózaton az útválasztó külső címén.

Ennek eredményeként egyszerűen megoldottam az UDP-munkamenet fenntartásának problémáját - elindítottam a klienst ugyanazon a számítógépen a szerverrel.
Ez így működött:

• elindította a STUN klienst a 11111-es helyi porton
• külső IP-címmel és XX.1XX.1X4.2XX:4398 porttal kapott választ
• Külső IP-címmel és porttal küldött adatokat az okostelefonon konfigurált e-mailbe (bármilyen más szolgáltatás is lehetséges).
• elindította az OpenVPN szervert egy UDP/11111 portot figyelő számítógépen
• elindította az OpenVPN klienst a számítógépen, és megadta az XX.1XX.1X4.2XX:4398 kódot a csatlakozáshoz
• bármikor elindította az OpenVPN klienst az okostelefonon, jelezve az IP-címet és a portot (esetemben az IP-cím nem változott) a csatlakozáshoz

Így tudtam csatlakozni a számítógéphez az okostelefonomról. Ez a megvalósítás lehetővé teszi bármely OpenVPN-kliens csatlakoztatását.

Gyakorlat

Szükséged lesz:

# apt install openvpn stun-client sendemail

Miután megírtunk néhány szkriptet, néhány konfigurációs fájlt, és létrehoztuk a szükséges tanúsítványokat (mivel az okostelefonon lévő kliens csak tanúsítványokkal működik), megkaptuk az OpenVPN szerver szokásos megvalósítását.

Fő szkript a számítógépen

# 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

Szkript adatok e-mailben történő küldéséhez:

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

Szerver konfigurációs fájl:

# 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

Kliens konfigurációs fájl:

# 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

A tanúsítványok a következővel készültek ezt a cikket.
A szkript futtatása:

# ./vpn11.sh

Először végrehajthatóvá tételével

# chmod +x vpn11.sh

Az okostelefon oldalán

Az alkalmazás telepítésével OpenVPN Androidhoz, a konfigurációs fájl, a tanúsítványok és a konfigurálás után a következőképpen alakult:
Megnézem az e-mailjeimet az okostelefonomon
A port számot szerkesztem a beállításokban
Elindítom a klienst és csatlakozom

A cikk írásakor átvittem a konfigurációt a számítógépemről a Raspberry Pi 3-ra, és megpróbáltam az egészet LTE modemen futtatni, de nem működött! Parancs eredménye

# stun stun.ekiga.net -p 11111

STUN kliens verzió 0.97
Elsődleges: Független leképezés, portfüggő szűrő, véletlenszerű port, hajtű
A visszatérési érték 0x000006

jelentés Port Dependent Filter nem engedélyezte a rendszer elindítását.
De a hazai szolgáltató engedélyezte, hogy a rendszer minden probléma nélkül elinduljon a Raspberry Pi 3-on.
Webkamerával együtt, VLC-vel
RTSP adatfolyam létrehozása webkameráról

$ 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

és VLC-t okostelefonon megtekintésre (stream rtsp://10.2.0.1:8554/), jó távoli videó megfigyelő rendszernek bizonyult, telepítheti a Samba-t, irányíthatja a forgalmat VPN-en keresztül, távolról vezérelheti a számítógépet és sok minden mást. több...

Teljesítmény

Amint a gyakorlat azt mutatja, a VPN-kiszolgáló megszervezéséhez nem kell külső IP-címet használnia, amelyért fizetnie kell, akárcsak egy bérelt VPS/VDS-ért. De minden a szolgáltatótól függ. Természetesen szerettem volna több információt szerezni a különböző szolgáltatókról és a használt NAT típusokról, de ez még csak a kezdet...
Спасибо за внимание!

Forrás: will.com