Spuštění serveru VPN za NAT poskytovatele

Článek o tom, jak se mi podařilo zprovoznit VPN server za NATem domácího poskytovatele (bez bílé IP adresy). Řeknu vám rovnou: výkon této implementace přímo závisí na typu NAT používaného vaším poskytovatelem a také routerem.
Potřeboval jsem se tedy připojit ze svého smartphonu Android k domácímu počítači, obě zařízení jsou připojena k internetu přes NAT poskytovatele a počítač je připojen přes domácí router, který také NAT připojení.
Klasické schéma využívající pronajaté VPS / VDS s bílou IP adresou, stejně jako pronájem bílé IP adresy od poskytovatele, nepřicházelo v úvahu z několika důvodů.
S přihlédnutím zkušenosti z minulých článků, který strávil několik experimentů s STUN a NAT poskytovatelů. Rozhodl jsem se pro malý experiment provedením příkazu na domácím routeru s firmwarem OpenWRT:

$ stun stun.sipnet.ru

dostal výsledek:

Verze klienta STUN 0.97
Primární: Nezávislé mapování, nezávislý filtr, náhodný port, bude vlásenka
návratová hodnota je 0x000002

Doslovný překlad:
Nezávislé mapování - nezávislé zobrazení
Nezávislý filtr - nezávislý filtr
náhodný port - náhodný port
bude vlásenka - bude vlásenka
Po spuštění podobného příkazu na mém PC jsem dostal:

Verze klienta STUN 0.97
Primární: Nezávislé mapování, filtr závislý na portu, náhodný port, bude vlásenka
návratová hodnota je 0x000006

Port Dependent Filter - filtr závislý na portu
Rozdíl ve výsledcích výstupu příkazů naznačoval, že domácí router „přispěl“ k procesu vysílání paketů z internetu, což se projevilo ve skutečnosti, že když byl příkaz proveden na počítači:

stun stun.sipnet.ru -p 11111 -v

dostal jsem výsledek:

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

v tu chvíli byla na chvíli otevřena UDP relace, pokud byl v tu chvíli odeslán požadavek UDP (např.: netcat XX.1XX.1X4.2XX 4398 -u), tak požadavek přišel na domácí router, který byl potvrzeno na něm běžícím TCPDump, ale požadavek nedorazil do počítače - IPtables jako překladač NAT na routeru jej zahodil.
Spuštění serveru VPN za NAT poskytovatele
Ale samotný fakt předání požadavku UDP přes NAT poskytovatele dával naději na úspěch. Protože je router v mé jurisdikci, vyřešil jsem problém přesměrováním portu UDP / 11111 do počítače:

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

Tak jsem dostal příležitost zahájit relaci UDP a přijímat požadavky z internetu z libovolné IP adresy. V tuto chvíli jsem spustil OpenVPN-server (po jeho konfiguraci) poslouchající port UDP/11111, uvedl externí IP adresu a port (XX.1XX.1X4.2XX:4398) na smartphonu a úspěšně se připojil ze smartphonu k počítač. V této implementaci ale nastal problém, bylo nutné nějak udržovat UDP relaci, dokud se OpenVPN klient nepřipojí k serveru, nelíbila se mi možnost periodického spouštění STUN klienta - nechtěl jsem načítat STUN servery nadarmo.
Také upozornil na záznam "bude vlásenka - bude vlásenka“, tento režim

Hairpinning umožňuje jednomu počítači v místní síti za NAT přistupovat k jinému počítači ve stejné síti na externí adrese routeru.

Spuštění serveru VPN za NAT poskytovatele
V důsledku toho jsem problém s udržováním relace UDP vyřešil jednoduše - spustil jsem klienta na stejném počítači se serverem.
Fungovalo to takto:

  • spustil klienta STUN s místním portem 11111
  • přijatá odpověď s externí IP adresou a portem XX.1XX.1X4.2XX:4398
  • odeslala data s externí IP adresou a portem na poštu (je možná jakákoli jiná služba) nakonfigurovanou na smartphonu
  • spustil OpenVPN server na počítači naslouchajícím na portu UDP/11111
  • spustil klienta OpenVPN na počítači s uvedením XX.1XX.1X4.2XX:4398 pro připojení
  • kdykoli spusťte klienta OpenVPN na smartphonu a zadejte IP adresu a port (v mém případě se IP adresa nezměnila) pro připojení

Spuštění serveru VPN za NAT poskytovatele
Tak jsem dostal příležitost připojit se k počítači ze smartphonu. Tato implementace umožňuje připojit libovolného klienta OpenVPN.

Praxe

Budete potřebovat:

# apt install openvpn stun-client sendemail

Po napsání několika skriptů, několika konfiguračních souborů, vygenerování potřebných certifikátů (protože klient na smartphonu pracuje pouze s certifikáty) jsme dostali obvyklou implementaci OpenVPN serveru.

Hlavní skript na počítači

# 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

Skript pro odesílání e-mailů:

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

Konfigurační soubor serveru:

# 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

Konfigurační soubor klienta:

# 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

Certifikáty byly generovány podle tento článek.
Spuštění skriptu:

# ./vpn11.sh

Nejprve jej udělejte spustitelným

# chmod +x vpn11.sh

Na straně smartphonu

Instalací aplikace Otevřete VPN pro Android, zkopírování konfiguračního souboru, certifikátů a jeho konfigurace dopadlo takto:
Kontrola e-mailu na mém smartphonuSpuštění serveru VPN za NAT poskytovatele
Číslo portu upravím v nastaveníSpuštění serveru VPN za NAT poskytovatele
Spustím klienta a připojím seSpuštění serveru VPN za NAT poskytovatele

V procesu psaní článku jsem přenesl konfiguraci z počítače do Raspberry Pi 3 a zkusil jsem to celé spustit na LTE modemu, ale nefungovalo to! výsledek příkazu

# stun stun.ekiga.net -p 11111

Verze klienta STUN 0.97
Primární: Nezávislé mapování, filtr závislý na portu, náhodný port, bude vlásenka
návratová hodnota je 0x000006

hodnota Filtr závislý na portu zabránil spuštění systému.
Domácí poskytovatel ale nechal systém na Raspberry Pi 3 bez problémů běžet.
Ve spojení s webovou kamerou, s VLC pro
vytvoření streamu RTSP z webové kamery

$ 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

a VLC na smartphonu pro prohlížení (stream rtsp://10.2.0.1:8554/), ukázalo se, že to není špatný video monitorovací systém na dálku, můžete také nastavit Sambu, směrovat provoz přes VPN, vzdáleně ovládat počítač a mnohem víc ...

Výkon

Jak ukázala praxe, k uspořádání serveru VPN se můžete obejít bez externí adresy IP, za kterou musíte platit, a také za pronajaté VPS / VDS. Vše ale záleží na poskytovateli. Samozřejmě jsem chtěl získat více informací o různých poskytovatelích a typech používaných NAT, ale to je jen začátek ...
Спасибо за внимание!

Zdroj: www.habr.com

Přidat komentář