ProHoster > Blogs > Administrācija > VPN servera darbināŔana aiz pakalpojumu sniedzēja NAT

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

Raksts par to, kā man izdevās palaist VPN serveri aiz sava mājas pakalpojumu sniedzēja NAT (bez baltas IP adreses). Ä»aujiet man nekavējoties veikt rezervāciju: tas Ŕī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.
Tātad, man vajadzēja izveidot savienojumu no sava Android viedtālruņa ar mājas datoru, abas ierÄ«ces ir savienotas ar internetu, izmantojot pakalpojumu sniedzēja NAT, kā arÄ« dators ir savienots, izmantojot mājas marÅ”rutētāju, kas arÄ« ir savienots ar 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.
VPN servera darbināŔana aiz pakalpojumu sniedzēja NAT
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

Tādējādi es varēju uzsākt UDP sesiju un saņemt pieprasÄ«jumus no interneta no jebkuras IP adreses. Å ajā brÄ«dÄ« es palaižu OpenVPN-serveri (to iepriekÅ” konfigurējot), kas klausās UDP/11111 portu, norādÄ«ju viedtālruņa ārējo IP adresi un portu (XX.1XX.1X4.2XX:4398) un veiksmÄ«gi izveidoju savienojumu no viedtālruņa ar datoru. Bet Å”ajā realizācijā radās problēma: bija nepiecieÅ”ams kaut kā uzturēt UDP sesiju, lÄ«dz OpenVPN klients ir izveidojis savienojumu ar serveri; man nepatika iespēja periodiski palaist STUN klientu - es negribēju tērēt slodzi STUN serveriem.
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ē.

VPN servera darbināŔana aiz pakalpojumu sniedzēja NAT
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).
  • palaida OpenVPN serveri datorā, kas klausās UDP/11111 portu
  • palaida OpenVPN klientu datorā, savienojumam norādot XX.1XX.1X4.2XX:4398
  • jebkurā laikā viedtālrunÄ« palaida OpenVPN klientu, norādot IP adresi un portu (manā gadÄ«jumā IP adrese nemainÄ«jās), lai izveidotu savienojumu

VPN servera darbināŔana aiz pakalpojumu sniedzēja NAT
Tādā veidā es varēju izveidot savienojumu ar datoru no sava viedtālruņa. Å Ä« ievieÅ”ana ļauj izveidot savienojumu ar jebkuru OpenVPN klientu.

Prakse

Jums būs nepiecieŔams: 

# apt install openvpn stun-client sendemail

UzrakstÄ«juÅ”i pāris skriptus, pāris konfigurācijas failus un Ä£enerējuÅ”i nepiecieÅ”amos sertifikātus (tā kā klients viedtālrunÄ« strādā tikai ar sertifikātiem), mēs ieguvām parasto OpenVPN servera ievieÅ”anu.

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 operētājsistēmai 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Ä«VPN servera darbināŔana aiz pakalpojumu sniedzēja NAT
IestatÄ«jumos rediģēju porta numuruVPN servera darbināŔana aiz pakalpojumu sniedzēja NAT
Palaižu klientu un izveidoju savienojumuVPN servera darbināŔana aiz pakalpojumu sniedzēja NAT

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ā liecina prakse, VPN servera organizÄ“Å”anai jÅ«s varat iztikt bez ārējās IP adreses, par kuru jums ir jāmaksā, tāpat kā par Ä«rētu VPS/VDS. Bet tas viss ir atkarÄ«gs no pakalpojumu sniedzēja. Protams, es gribēju iegÅ«t vairāk informācijas par dažādiem pakalpojumu sniedzējiem un izmantotajiem NAT veidiem, taču tas ir tikai sākums...
Š”ŠæŠ°ŃŠøŠ±Š¾ Š·Š° Š²Š½ŠøŠ¼Š°Š½ŠøŠµ!

Avots: www.habr.com

Pievieno komentāru