🥇Kalimi nga OpenVPN në WireGuard për bashkimin e rrjeteve në një rrjet të vetëm L2

Do të doja të ndaja përvojën time të bashkimit të rrjeteve në tre apartamente të largëta gjeografikisht, ku në secilin si gateway përdoren ruterë me OpenWRT, në një rrjet të përbashkët. Gjatë zgjedhjes së mënyrës së ndërlidhjes së rrjeteve midis L3 me rutimin e nënrrjeteve dhe L2 me bridging, ku të gjitha nyjet e rrjetit do të ndodheshin në të njëjtin nënrrjet, u zgjodh opsioni i dytë. Ai është më i ndërlikuar për t'u konfiguruar, por ofron më shumë mundësi, pasi në rrjetin që po krijohej ishte planifikuar përdorimi transparent i teknologjive Wake-on-Lan dhe DLNA.

Pjesa 1: Sfondi

Si protokoll për zbatimin e kësaj detyre fillimisht u zgjodh OpenVPN, sepse, së pari, ai mund të krijojë një pajisje tap, e cila shtohet pa problem në bridge, dhe së dyti, OpenVPN mbështet punën përmes protokollit TCP, gjë që ishte po aq e rëndësishme, pasi në asnjë nga apartamentet nuk kishte një adresë IP të dedikuar. Gjithashtu, nuk arrita të përdor STUN, sepse ofruesi im, për ndonjë arsye, bllokon lidhjet hyrëse përmes protokollit UDP nga rrjetet e veta, ndërsa protokolli TCP më lejonte të bënim forward të portës së serverit VPN te VPS i marrë me qira me ndihmën e SSH. Po, kjo qasje krijon ngarkesë më të madhe, sepse të dhënat enkriptohen dy herë, por nuk desha ta fusja VPS në rrjetin tim privat, pasi mbetej rreziku që palë të treta të merrnin kontrollin mbi të. Për pasojë, prania e një pajisjeje të tillë në rrjetin e shtëpisë ishte shumë e padëshirueshme dhe u vendos që për sigurinë të paguhej me një overhead më të lartë.

Për forward të portës në ruterin ku planifikohej të ngrihej serveri, u përdor programi sshtunnel. Nuk do të ndalem te hollësitë e konfigurimit të tij, pasi kjo bëhet mjaft lehtë; do të theksoj vetëm se detyra e tij ishte forward i portës TCP 1194 nga ruteri te VPS. Më pas u konfigurua serveri OpenVPN në pajisjen tap0, e cila shtohej në bridge br-lan. Pasi u testua lidhja me serverin e sapokrijuar nga laptopi, u bë e qartë se ideja e forward të portës funksionoi dhe laptopi im u bë pjesë e rrjetit të ruterit, megjithëse fizikisht nuk ndodhej në të.

Mbeti vetëm hapi i fundit: duhej të shpërndaheshin adresat IP në apartamente të ndryshme në mënyrë që të mos kishin konflikte dhe të konfiguroheshin ruterët si klientë OpenVPN.
U zgjodhën këto adresa IP për ruterët dhe intervalet e serverëve DHCP:

192.168.10.1 me intervalin 192.168.10.2 — 192.168.10.80 për serverin
192.168.10.100 me intervalin 192.168.10.101 — 192.168.10.149 për ruterin në apartamentin nr. 2
192.168.10.150 me intervalin 192.168.10.151 — 192.168.10.199 për ruterin në apartamentin nr. 3

Gjithashtu ishte e nevojshme të caktoheshin pikërisht këto adresa për ruterët-klientë të serverit OpenVPN, duke shtuar në konfigurimin e tij rreshtin:

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

dhe duke shtuar rreshtat e mëposhtëm në skedarin /etc/openvpn/ipp.txt:

flat1_id 192.168.10.100
flat2_id 192.168.10.150

ku flat1_id dhe flat2_id janë emrat e pajisjeve që përcaktohen gjatë krijimit të certifikatave për lidhje me OpenVPN

Më pas, në ruterë u konfiguruan klientët OpenVPN, ndërsa pajisjet tap0 në të dy u shtuan në urën br-lan. Në këtë fazë dukej se gjithçka ishte në rregull, pasi të tria rrjetet e shihnin njëra-tjetrën dhe funksiononin si një e tërë. Megjithatë, doli një detaj jo fort i këndshëm: ndonjëherë pajisjet mund të merrnin adresë IP jo nga ruteri i tyre, me të gjitha pasojat që rridhnin prej kësaj. Për ndonjë arsye, ruteri në njërin nga apartamentet nuk arrinte të përgjigjej në kohë ndaj DHCPDISCOVER dhe pajisja merrte një adresë që nuk i përkiste. E kuptova se duhej t’i filtroja këto kërkesa në tap0 në secilin nga ruterët, por, siç doli, iptables nuk mund të punojë me një pajisje nëse ajo është pjesë e një ure, ndaj në ndihmë duhej të vinte ebtables. Për fat të keq, ai nuk ishte i pranishëm në firmware-et e mia dhe m’u desh të rikompiloja imazhet për secilën pajisje. Pasi e bëra këtë dhe shtova rreshtat e mëposhtëm në /etc/rc.local të çdo ruteri, problemi u zgjidh:

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

Ky konfigurim mbeti në përdorim për tre vjet.

Pjesa 2: Njohja me WireGuard

Kohët e fundit, në internet po flitet gjithnjë e më shpesh për WireGuard, duke vlerësuar thjeshtësinë e konfigurimit të tij, shpejtësinë e lartë të transmetimit dhe ping-un e ulët me një nivel të krahasueshëm sigurie. Kërkimi i më shumë informacioni për të tregonte se ai nuk mbështet as punën si pjesë e një ure, as punën përmes protokollit TCP, gjë që më çonte në mendimin se për mua ende nuk kishte alternativa ndaj OpenVPN. Kështu, e shtyja njohjen me WireGuard.

Disa ditë më parë, në burime të ndryshme që lidhen me IT, qarkulloi lajmi se WireGuard më në fund do të përfshihet në kernel-in e Linux, duke filluar nga versioni 5.6. Si zakonisht, artikujt e lajmeve e lëvdonin WireGuard. Unë iu riktheva sërish kërkimit të mënyrave për të zëvendësuar OpenVPN-in e vjetër dhe të besueshëm. Këtë herë hasa në ky artikull. Aty flitej për krijimin e një tuneli Ethernet mbi L3 me ndihmën e GRE. Ky artikull më dha shpresë. Mbeti e paqartë çfarë të bëja me protokollin UDP. Kërkimi më çonte te artikuj mbi përdorimin e socat së bashku me një tunel SSH për të përcjellë portën UDP, megjithatë aty theksohej se kjo qasje funksionon vetëm në modalitetin e një lidhjeje të vetme, që do të thotë se përdorimi i disa klientëve VPN do të ishte i pamundur. Më lindi ideja të ngreja një server VPN në VPS dhe për klientët të konfiguroja GRE, por, siç doli, GRE nuk mbështet enkriptim, gjë që do të sillte si pasojë që, në rast se palë të treta do të fitonin akses në server, i gjithë trafiku midis rrjeteve të mia do të binte në duart e tyre, çka për mua ishte krejtësisht e papranueshme.

Sërish u mor vendimi në favor të enkriptimit të tepërt, duke përdorur VPN mbi VPN sipas skemës së mëposhtme:

VPN i nivelit të parë:
VPS është server me adresë të brendshme 192.168.30.1
MC është klient VPS me adresë të brendshme 192.168.30.2
MK2 është klient VPS me adresë të brendshme 192.168.30.3
MK3 është klient VPS me adresë të brendshme 192.168.30.4

VPN i nivelit të dytë:
MC është server me adresë të jashtme 192.168.30.2 dhe të brendshme 192.168.31.1
MK2 është klient MC me adresë 192.168.30.2 dhe ka IP të brendshme 192.168.31.2
MK3 është klient MC me adresë 192.168.30.2 dhe ka IP të brendshme 192.168.31.3

* MC — ruter-server në apartamentin 1, MK2 — ruter në apartamentin 2, MK3 — ruter në apartamentin 3
* Konfigurimet e pajisjeve janë publikuar te spoiler-i në fund të artikullit.

Pra, ping-et midis nyjeve të rrjetit 192.168.31.0/24 po kalojnë, ndaj është koha të kalojmë te konfigurimi i tunelit GRE. Përpara kësaj, që të mos humbni aksesin te ruterët, duhet të konfiguroni tunelet SSH për përcjelljen e portës 22 te VPS, në mënyrë që, për shembull, në portën 10022 të VPS të jetë i qasshëm ruteri nga apartamenti 2, ndërsa në portën 11122 të VPS të jetë i qasshëm ruteri nga apartamenti 3. Konfigurimi i përcjelljes bëhet më mirë po me sshtunnel, pasi ai do ta rikthejë tunelin në rast se ndërpritet.

Tuneli është konfiguruar, mund të lidheni me SSH përmes portës së përcjellë:

ssh root@МОЙ_VPS -p 10022

Më pas duhet të çaktivizoni OpenVPN:

/etc/init.d/openvpn stop

Tani le të konfigurojmë tunelin GRE në ruterin e apartamentit 2:

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

Dhe ta shtojmë ndërfaqen e krijuar në urë:

brctl addif br-lan grelan0

Të njëjtën procedurë do ta kryejmë edhe në routerin-server:

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

Dhe, po ashtu, ta shtojmë ndërfaqen e krijuar në urë:

brctl addif br-lan grelan0

Që nga ky moment, ping-et fillojnë të kalojnë me sukses në rrjetin e ri dhe unë, i kënaqur, shkoj të pi një kafe. Më pas, për të vlerësuar se si funksionon rrjeti në anën tjetër të lidhjes, përpiqem të lidhem me SSH me një nga kompjuterët në apartamentin 2, por klienti SSH «ngrijnë», pa më ofruar të fus fjalëkalimin. Provoj të lidhem me këtë kompjuter përmes telnet në portën 22 dhe shoh një rresht nga i cili kuptohet se lidhja po vendoset, serveri SSH përgjigjet, por për ndonjë arsye thjesht nuk më lejon të identifikohem.

$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1

Përpiqem të lidhem me të njëjtin kompjuter përmes VNC dhe shoh një ekran të zi. Bind veten se problemi është te kompjuteri në distancë, sepse me routerin nga ky apartament mund të lidhem pa problem përmes adresës së brendshme. Megjithatë, vendos të lidhem me SSH të këtij kompjuteri përmes routerit dhe me habi zbuloj se lidhja realizohet, kompjuteri në distancë funksionon krejt normalisht, por njëkohësisht ai gjithashtu nuk mund të lidhet me kompjuterin tim.

E nxjerr pajisjen grelan0 nga ura dhe nis OpenVPN në routerin e apartamentit 2, duke u siguruar që rrjeti sërish funksionon siç duhet dhe lidhjet nuk ndërpriten. Gjatë kërkimit has në forume ku njerëzit ankohen për të njëjtat probleme dhe ku u këshillohet të rrisin MTU. Thënë e bërë. Megjithatë, derisa MTU nuk u vendos mjaftueshëm i lartë — 7000 për pajisjet gretap — vëreheshin ose ndërprerje të lidhjeve TCP, ose shpejtësi e ulët transferimi. Për shkak të MTU-së së lartë për gretap, MTU për lidhjet WireGuard të nivelit të parë dhe të dytë u vendosën përkatësisht në 8000 dhe 7500.

Kryeva të njëjtin konfigurim edhe në routerin e apartamentit 3, me të vetmin ndryshim se në routerin-server u shtua një ndërfaqe e dytë gretap me emrin grelan1, e cila gjithashtu u shtua në urën br-lan.

Gjithçka funksionon. Tani mund ta vendosni konfigurimin gretap në nisjen automatike. Për këtë:

I vendosa këto rreshta në /etc/rc.local në routerin e apartamentit 2:

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

E shtova këtë në /etc/rc.local në ruterin e apartamentit 3:

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

Dhe në ruterin-server:

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

Pas rinisjes së ruterëve klientë, vura re se për ndonjë arsye ata nuk po lidheshin me serverin. Pasi u lidha me ta përmes SSH (fatmirësisht, paraprakisht kisha konfiguruar sshtunnel për këtë), u zbulua se WireGuard po krijonte një rrugë për endpoint-in dhe, për më tepër, të pasaktë. Për shembull, për 192.168.30.2 në tabelën e rutimit ishte vendosur një rrugë përmes ndërfaqes pppoe-wan, pra përmes internetit, ndërkohë që rruga drejt tij duhej të kalonte përmes ndërfaqes wg0. Pas fshirjes së kësaj rruge, lidhja u rikthye. Nuk arrita të gjeja askund udhëzime se si ta detyroja WireGuard të mos i krijonte këto rrugë. Madje, as nuk e kuptova nëse kjo ishte një veçori e OpenWRT apo e vetë WireGuard. Pa u zgjatur shumë me zgjidhjen e këtij problemi, thjesht shtova në të dy ruterët, në një skript që ekzekutohej me timer, një rresht që e fshinte këtë rrugë:

route del 192.168.30.2

Duke përmbledhur

Ende nuk kam arritur të heq dorë plotësisht nga OpenVPN, sepse ndonjëherë më duhet të lidhem me rrjetin e ri nga laptopi ose telefoni, ndërsa konfigurimi i një pajisjeje gretap në to, në rastin e përgjithshëm, nuk është i mundur. Megjithatë, fitova në shpejtësinë e transmetimit të të dhënave midis apartamenteve dhe, për shembull, përdorimi i VNC tani nuk shkakton më bezdi. Ping-u u ul vetëm pak, por u bë më i qëndrueshëm:

Kur përdoret OpenVPN:

[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

Kur përdoret WireGuard:

[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

Kjo ndikohet në masë më të madhe nga ping-u i lartë drejt VPS, i cili është afërsisht 61.5 ms

Megjithatë, shpejtësia u rrit ndjeshëm. Për shembull, në apartamentin ku ndodhet ruteri-server kam një shpejtësi lidhjeje me internetin prej 30 Mbit/s, ndërsa në apartamentet e tjera nga 5 Mbit/s. Gjatë përdorimit të OpenVPN nuk arrita të marr shpejtësi transferimi mes rrjeteve më të lartë se 3,8 Mbit/s sipas matjeve të iperf, ndërsa WireGuard e çoi atë deri në të njëjtat 5 Mbit/s.

Konfigurimi i WireGuard në VPS[Interface] Adresa = 192.168.30.1/24 Porta e dëgjimit = 51820 PrivateKey =

[Peer]
PublicKey =
AllowedIPs = 192.168.30.2/32

[Peer]
PublicKey =
AllowedIPs = 192.168.30.3/32

[Peer]
PublicKey =
AllowedIPs = 192.168.30.4/32

Konfigurimi i WireGuard në MS (shtohet te /etc/config/network)

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

Konfigurimi i WireGuard në MK2 (shtohet te /etc/config/network)

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

Konfigurimi i WireGuard në MK3 (shtohet te /etc/config/network)

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

Në konfigurimet e përshkruara, për VPN të nivelit të dytë u caktoj klientëve WireGuard portën 51821. Në parim kjo nuk është e nevojshme, pasi klienti do ta vendosë lidhjen nga çdo port i lirë jo i privilegjuar, por e bëra kështu që të mund të ndalohen të gjitha lidhjet hyrëse në ndërfaqet wg0 të të gjithë ruterëve, përveç lidhjeve hyrëse UDP në portën 51821.

Shpresoj që ky artikull t’i vlejë dikujt.

P.S. Gjithashtu, dua të ndaj skriptin tim, i cili më dërgon një njoftim PUSH në telefon në aplikacionin WirePusher kur në rrjetin tim shfaqet një pajisje e re. Ja lidhja për skriptin: github.com/r0ck3r/device_discover.

PËRDITËSIM: Konfigurimi i serverit dhe klientëve OpenVPN

Serveri OpenVPN

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

Klienti OpenVPN

client
tls-client
dev tap
proto tcp
remote VPS_IP 1194 # Ndryshojeni me IP-në e jashtme të ruterit tuaj
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

Për gjenerimin e certifikatave përdora easy-rsa

Burimi: habr.com

Kalimi nga OpenVPN te WireGuard për bashkimin e rrjeteve në një rrjet të vetëm L2

Pjesa 1: Sfondi

Pjesa 2: Njohja me WireGuard

Duke përmbledhur