🥇OpenVPN-tik WireGuard-era migratzea sareak L2 sare batean konbinatzeko

Geografikoki urrun dauden hiru apartamentutan sareak konbinatzearen esperientzia partekatu nahiko nuke, eta horietako bakoitzak OpenWRT bideratzaileak atebide gisa erabiltzen ditu sare komun batean. L3 azpisareen bideraketarekin eta L2 zubiarekin sareak konbinatzeko metodo bat aukeratzerakoan, sareko nodo guztiak azpisare berean egongo direnean, bigarren metodoari lehentasuna eman zitzaion, konfiguratzeko zailagoa dena, baina aukera handiagoak ematen baititu. Wake-on-Lan eta DLNA sortzen ari diren sarean teknologien erabilera gardena aurreikusi zen.

1. zatia: Aurrekariak

Hasieran OpenVPN aukeratu zen ataza hau ezartzeko protokolo gisa, lehenik eta behin, zubiari arazorik gabe gehitzeko moduko ukipen-gailu bat sor baitezake eta, bigarrenik, OpenVPN-k TCP protokoloaren bidez funtzionatzea onartzen du, hori ere garrantzitsua zen, inork ez zuelako. apartamentuek IP helbide dedikatu bat zuten, eta ezin izan nuen STUN erabili, nire hornitzaileak arrazoiren bategatik blokeatzen baititu bere sareetatik sarrerako UDP konexioak, eta TCP protokoloak VPN zerbitzariaren ataka SSH erabiliz alokatutako VPSra birbidaltzeko aukera ematen zidan bitartean. Bai, ikuspegi honek karga handia ematen du, datuak bi aldiz enkriptatuta daudenez, baina ez nuen VPS bat sartu nahi nire sare pribatuan, oraindik hirugarrenek kontrola izateko arriskua zegoenez, beraz, gailu hori edukitzea. nire etxeko sarean oso desiragarria zen eta segurtasuna gainkostu handi batekin ordaintzea erabaki zen.

Zerbitzaria zabaltzea aurreikusita zegoen bideratzailearen ataka birbidaltzeko, sshtunnel programa erabili zen. Ez ditut konfigurazioaren korapilatsuak deskribatuko - nahiko erraz egiten da, bere zeregina TCP ataka 1194 bideratzailetik VPSra bidaltzea zela ohartuko naiz. Ondoren, OpenVPN zerbitzaria tap0 gailuan konfiguratu zen, zeina br-lan zubira konektatuta zegoen. Ordenagailu eramangarritik sortu berri den zerbitzariarekiko konexioa egiaztatu ondoren, argi geratu zen portuaren birbidaltzearen ideia justifikatuta zegoela eta nire ordenagailu eramangarria bideratzailearen sareko kide bihurtu zen, fisikoki bertan ez zegoen arren.

Gauza txiki bakarra geratzen zen egiteko: IP helbideak apartamentu ezberdinetan banatzea beharrezkoa zen gatazkarik ez egoteko eta bideratzaileak OpenVPN bezero gisa konfiguratu.
Bideratzaileen IP helbide eta DHCP zerbitzari barruti hauek hautatu dira:

192.168.10.1 sortarekin 192.168.10.2 - 192.168.10.80 zerbitzariarentzat
192.168.10.100 sortarekin 192.168.10.101 - 192.168.10.149 2. zenbakiko apartamentuko bideratzailearentzat
192.168.10.150 sortarekin 192.168.10.151 - 192.168.10.199 3. zenbakiko apartamentuko bideratzailearentzat

Helbide hauek zehatz-mehatz esleitzea ere beharrezkoa zen OpenVPN zerbitzariaren bezero-bideratzaileei lerroa bere konfigurazioari gehituta:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

eta lerro hauek gehituz /etc/openvpn/ipp.txt fitxategian:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

non flat1_id eta flat2_id OpenVPNra konektatzeko ziurtagiriak sortzean zehaztutako gailu izenak dira

Ondoren, OpenVPN bezeroak bideratzaileetan konfiguratu ziren, bietan tap0 gailuak gehitu ziren br-lan zubian. Etapa honetan, dena ondo zegoela zirudien hiru sareek elkar ikusi eta bat bezala funtzionatzen zutelako. Hala ere, detaile ez oso atsegina agertu zen: batzuetan gailuek beren bideratzailetik ez IP helbide bat jaso zezaketen, ondoriozko ondorio guztiekin. Arrazoiren batengatik, apartamentuetako bideratzaileak ez zuen denborarik izan DHCPDISCOVER-i garaiz erantzuteko eta gailuak nahi ez zen helbide bat jaso zuen. Konturatu nintzen bideratzaile bakoitzean tap0-n iragazi behar ditudala eskaerak, baina, ondorioz, iptables-ek ezin du gailuarekin funtzionatu zubi baten parte bada eta ebtables-ek nire laguntza etorri behar du. Nire damurako, nire firmwarean ez zegoen eta gailu bakoitzeko irudiak berreraiki behar izan nituen. Hau eginez eta bideratzaile bakoitzaren /etc/rc.local-era lerro hauek gehituz, arazoa konpondu zen:

ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A INPUT --in-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-destination-port 67:68 -j DROP
ebtables -A FORWARD --out-interface tap0 --protocol ipv4 --ip-protocol udp --ip-source-port 67:68 -j DROP

Konfigurazio honek hiru urte iraun zuen.

2. zatia: WireGuard aurkezten

Duela gutxi, Interneten gero eta gehiago hasi da WireGuard-i buruz hitz egiten, bere konfigurazioaren sinpletasuna, transmisio-abiadura handia, ping baxua segurtasun parekoarekin miretsiz. Horri buruzko informazio gehiago bilatuz gero, argi geratu zen ez zegoela zubi-kide gisa lan egitea, ez TCP protokoloaren gainean lan egitea, eta horrek oraindik OpenVPNrako alternatibarik ez zegoela niretzat pentsarazten zidan. Beraz, WireGuard ezagutzea atzeratu nuen.

Duela egun batzuk, informatikarekin lotutako baliabideetan nola edo hala zabaldu zen WireGuard azkenik Linux nukleoan sartuko zelako albistea, 5.6 bertsiotik hasita. Albiste artikuluek, beti bezala, WireGuard goraipatu zuten. OpenVPN zahar ona ordezkatzeko moduen bila murgildu nintzen berriro. Oraingoan topo egin nuen Artikulu hau. GRE erabiliz L3n Ethernet tunel bat sortzeari buruz hitz egin zuen. Artikulu honek itxaropena eman zidan. Ez zegoen argi zer egin UDP protokoloarekin. Bilaketak SSH tunel batekin batera UDP ataka birbidaltzeko socat erabiltzeari buruzko artikuluetara eraman ninduen, hala ere, ikuspegi honek konexio bakarrean soilik funtzionatzen duela adierazi zuten, hau da, hainbat VPN bezeroren lana ezinezkoa izango zela. VPN zerbitzari bat VPS batean instalatzea eta bezeroentzako GRE konfiguratzea bururatu zitzaidan, baina ondorioztatu zenez, GREk ez du enkriptatzea onartzen, eta horrek hirugarrenek zerbitzarirako sarbidea lortzen badute. , nire sareen arteko trafiko guztia haien esku egongo da, eta hori ez zitzaidan batere komeni.

Berriro ere, enkriptazio erredundantearen aldeko erabakia hartu zen, VPN bidez VPN bidez erabiliz eskema hau erabiliz:

XNUMX. mailako VPN:
VPS da zerbitzaria 192.168.30.1 barne helbidea duena
MS da bezeroa Barne helbidea 192.168.30.2 duen VPS
MK2 da bezeroa Barne helbidea 192.168.30.3 duen VPS
MK3 da bezeroa Barne helbidea 192.168.30.4 duen VPS

Bigarren mailako VPN:
MS da zerbitzaria kanpoko helbidearekin 192.168.30.2 eta barneko 192.168.31.1
MK2 da bezeroa MS 192.168.30.2 helbidearekin eta barne IP 192.168.31.2 du
MK3 da bezeroa MS 192.168.30.2 helbidearekin eta barne IP 192.168.31.3 du

* MS - bideratzaile-zerbitzaria 1. apartamentuan, MK2 - bideratzailea 2 apartamentuan, MK3 - bideratzailea 3. apartamentuan
* Gailuaren konfigurazioak artikuluaren amaierako spoiler-ean argitaratzen dira.

Beraz, ping-ak 192.168.31.0/24 sareko nodoen artean exekutatzen ari dira, GRE tunel bat konfiguratzera pasatzeko garaia da. Horren aurretik, bideratzaileetarako sarbidea ez galtzeko, merezi du SSH tunelak ezartzea 22. ataka VPSra birbidaltzeko, horrela, adibidez, 10022. apartamentuko bideratzailea VPSaren 2 atakan eskuragarri egongo da, eta 11122 apartamentuko bideratzailea 3 atakan XNUMX. apartamentuko bideratzailean eskuragarri egongo da. Hobe da birbidaltzea sshtunnel bera erabiliz konfiguratzea, tunela berreskuratuko baitu huts egiten badu.

Tunela konfiguratuta dago, birbidaltutako atakaren bidez SSHra konekta zaitezke:

ssh root@МОЙ_VPS -p 10022

Ondoren, OpenVPN desgaitu beharko zenuke:

/etc/init.d/openvpn stop

Orain konfigura dezagun GRE tunel bat 2 apartamentuko bideratzailean:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up

Eta gehitu sortutako interfazea zubian:

brctl addif br-lan grelan0

Egin dezagun antzeko prozedura bat zerbitzariaren bideratzailean:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up

Era berean, gehitu sortutako interfazea zubiari:

brctl addif br-lan grelan0

une honetatik hasita, ping-ak arrakastaz joaten hasten dira sare berrira eta ni, pozik, kafea edatera joaten naiz. Ondoren, sarearen beste muturrean nola funtzionatzen duen ebaluatzeko, 2. apartamentuko ordenagailuetako batean SSH egiten saiatzen naiz, baina ssh bezeroa izoztu egiten da pasahitzik eskatu gabe. Ordenagailu honekin 22 atakan telnet bidez konektatzen saiatzen ari naiz eta konexioa ezartzen ari dela uler dezakedan lerro bat ikusten dut, SSH zerbitzariak erantzuten ari dela, baina arrazoiren batengatik ez dit saioa hasteko eskatzen. urtean.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

VNC bidez konektatzen saiatzen ari naiz eta pantaila beltz bat ikusten ari naiz. Nire burua konbentzitzen dut arazoa urruneko ordenagailuarekin dagoela, apartamentu honetatik bideratzailera erraz konektatu naitekeelako barne helbidea erabiliz. Hala ere, ordenagailu honen SSHra bideratzailearen bidez konektatzea erabakitzen dut eta harrituta nago konexioa arrakastatsua dela eta urruneko ordenagailuak nahiko normal funtzionatzen duela, baina ezin da nire ordenagailura konektatu.

Grelan0 gailua zubitik kentzen dut eta OpenVPN exekutatzen dut 2 apartamentuko bideratzailean eta ziurtatzen dut sarea berriro espero bezala funtzionatzen duela eta konexioak ez direla galtzen. Bilatuz, jendea arazo berberengatik kexatzen den foroekin topatzen dut, non MTU igotzea gomendatzen zaien. Esan baino lehenago egin. Hala ere, MTU nahikoa altua ezarri zen arte - 7000 gretap gailuetarako, TCP konexioak jaitsi ziren edo transferentzia-tasa baxuak ikusi ziren. Gretap-en MTU altua dela eta, Layer 8000 eta Layer 7500 WireGuard konexioetarako MTUak XNUMX eta XNUMX gisa ezarri ziren hurrenez hurren.

3. apartamentuko bideratzailean antzeko konfigurazio bat egin nuen, desberdintasun bakarra zerbitzariaren bideratzaileari grelan1 izeneko bigarren gretap interfazea gehitu zitzaiola, br-lan zubiari ere gehitu zitzaiola.

Dena dabil. Orain gretap muntaia abiaraztean jar dezakezu. Honetarako:

Lerro hauek /etc/rc.local-en jarri ditut 2. apartamentuko bideratzailean:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

Hau gehitu da /etc/rc.local 3. apartamentuko bideratzailean:

ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

Eta zerbitzariaren bideratzailean:

ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set dev grelan0 mtu 7000
ip link set grelan0 up
brctl addif br-lan grelan0

ip link add grelan1 type gretap remote 192.168.31.3 local 192.168.31.1
ip link set dev grelan1 mtu 7000
ip link set grelan1 up
brctl addif br-lan grelan1

Bezero-bideratzaileak berrabiarazi ondoren, arrazoiren batengatik zerbitzariarekin konektatzen ez zirela konturatu nintzen. Beren SSHra konektatu ondoren (zorionez, aurretik sshtunnel konfiguratu nuen horretarako), WireGuard arrazoiren batengatik amaierako punturako ibilbide bat sortzen ari zela ikusi zen, baina okerra zen. Beraz, 192.168.30.2-rako, bide-taulak pppoe-wan interfazearen bidezko ibilbidea adierazten zuen, hau da, Interneten bidez, nahiz eta bertarainoko ibilbidea wg0 interfazearen bidez bideratu behar izan zuen. Ibilbide hau ezabatu ondoren, konexioa berrezarri zen. Ezin izan dut inon aurkitu WireGuard bide hauek ez sortzera behartzeko argibideak. Gainera, ez nuen ulertzen OpenWRT edo WireGuard beraren ezaugarri bat zen. Arazo honi denbora luzez aurre egin beharrik gabe, ibilbide hau ezabatzen zuen denborazko script batean lerro bat gehitu nuen bi bideratzaileei:

route del 192.168.30.2

Laburbiltzea

Oraindik ez dut lortu OpenVPN erabat uztea, batzuetan sare berri batera konektatu behar baitut ordenagailu eramangarri edo telefono batetik, eta gretap gailu bat konfiguratzea, oro har, ezinezkoa da, baina hala ere, abantaila bat lortu nuen abiaduran. apartamentuen arteko datu-transferentzia eta, adibidez, VNC erabiltzea jada ez da deserosoa. Ping apur bat jaitsi zen, baina egonkorrago bihurtu zen:

OpenVPN erabiltzean:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=133 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=125 ms

--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19006ms
rtt min/avg/max/mdev = 124.722/126.152/136.907/3.065 ms

WireGuard erabiltzean:

[r0ck3r@desktop ~]$ ping -c 20 192.168.10.110
PING 192.168.10.110 (192.168.10.110) 56(84) bytes of data.
64 bytes from 192.168.10.110: icmp_seq=1 ttl=64 time=124 ms
...
64 bytes from 192.168.10.110: icmp_seq=20 ttl=64 time=124 ms
--- 192.168.10.110 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms

VPSaren ping altuak eragin handiagoa du, hau da, 61.5 ms gutxi gorabehera

Hala ere, abiadura nabarmen handitu da. Beraz, zerbitzari-bideratzailea duen apartamentu batean 30 Mbit/seg-eko Interneteko konexioaren abiadura daukat, eta beste apartamentuetan 5 Mbit/seg. Aldi berean, OpenVPN erabiltzen ari nintzen bitartean, ezin izan nuen sareen artean 3,8 Mbit/seg baino gehiagoko datu-transferentzia abiadura lortu iperf-ren irakurketen arabera, WireGuard-ek 5 Mbit/seg berdinera "haztatu" zuen bitartean.

WireGuard konfigurazioa VPS-n[Interface] Address = 192.168.30.1/24 ListenPort = 51820 PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>


[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_1_МС>

AllowedIPs = 192.168.30.2/32
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2>

AllowedIPs = 192.168.30.3/32
[Peer]
PublicKey = <ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3>

AllowedIPs = 192.168.30.4/32

WireGuard konfigurazioa MS-n (/etc/config/network-en gehituta)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.2/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МС'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option route_allowed_ips '1'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - сервер
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option listen_port '51821'
        list addresses '192.168.31.1/24'
        option auto '1'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list allowed_ips '192.168.31.2'

config wireguard_wg1ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.3

        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list allowed_ips '192.168.31.3'

WireGuard konfigurazioa MK2-n (/etc/config/network-en gehituta)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.3/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК2'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК2'
        list addresses '192.168.31.2/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

WireGuard konfigurazioa MK3-n (/etc/config/network-en gehituta)

#VPN первого уровня - клиент
config interface 'wg0'
        option proto 'wireguard'
        list addresses '192.168.30.4/24'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_1_МК3'
        option auto '1'
        option mtu '8000'

config wireguard_wg0
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_1_VPS'
        option endpoint_port '51820'
        option persistent_keepalive '25'
        list allowed_ips '192.168.30.0/24'
        option endpoint_host 'IP_АДРЕС_VPS'

#VPN второго уровня - клиент
config interface 'wg1'
        option proto 'wireguard'
        option private_key 'ЗАКРЫТЫЙ_КЛЮЧ_VPN_2_МК3'
        list addresses '192.168.31.3/24'
        option auto '1'
        option listen_port '51821'
        option mtu '7500'

config wireguard_wg1
        option public_key 'ОТКРЫТЫЙ_КЛЮЧ_VPN_2_МС'
        option endpoint_host '192.168.30.2'
        option endpoint_port '51821'
        option persistent_keepalive '25'
        list allowed_ips '192.168.31.0/24'

Bigarren mailako VPNrako deskribatutako konfigurazioetan, WireGuard bezeroak 51821 atakara seinalatzen ditut. Teorian, hori ez da beharrezkoa, bezeroak doako pribilegiorik gabeko edozein atakatik konexioa ezarriko baitu, baina debekatu ahal izateko egin nuen. bideratzaile guztien wg0 interfazeetan sarrerako konexio guztiak 51821 atakarako sarrerako UDP konexioak izan ezik.

Espero dut artikulua norbaitentzat erabilgarria izatea.

PS Gainera, nire telefonora PUSH jakinarazpena bidaltzen didan gidoia partekatu nahi dut WirePusher aplikazioan nire sarean gailu berri bat agertzen denean. Hona hemen gidoiaren esteka: github.com/r0ck3r/device_discover.

UPDATE: OpenVPN zerbitzariaren eta bezeroen konfigurazioa

OpenVPN zerbitzaria

client-to-client

ca /etc/openvpn/server/ca.crt
cert /etc/openvpn/server/vpn-server.crt
dh /etc/openvpn/server/dh.pem
key /etc/openvpn/server/vpn-server.key

dev tap
ifconfig-pool-persist /etc/openvpn/ipp.txt 0
keepalive 10 60
proto tcp4
server-bridge 192.168.10.1 255.255.255.0 192.168.10.80 192.168.10.254
status /var/log/openvpn-status.log
verb 3
comp-lzo

OpenVPN bezeroa

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Change to your router's External IP
resolv-retry infinite
nobind

ca client/ca.crt
cert client/client.crt
key client/client.key
dh client/dh.pem

comp-lzo
persist-tun
persist-key
verb 3

Ziurtagiriak sortzeko easy-rsa erabili dut

Iturria: www.habr.com

OpenVPN-tik WireGuard-era migratzea sareak L2 sare batean finkatzeko

1. zatia: Aurrekariak

2. zatia: WireGuard aurkezten

Laburbiltzea

Gehitu iruzkin berria Idatzi