Unë do të doja të ndaj përvojën time të kombinimit të rrjeteve në tre apartamente gjeografikisht të largëta, secila prej të cilave përdor ruterat OpenWRT si një portë, në një rrjet të përbashkët. Kur zgjidhni një metodë për kombinimin e rrjeteve midis L3 me rrugëzimin e nënrrjetit dhe L2 me urë, kur të gjitha nyjet e rrjetit do të jenë në të njëjtin nënrrjet, preferenca iu dha metodës së dytë, e cila është më e vështirë për t'u konfiguruar, por ofron mundësi më të mëdha, pasi Përdorimi transparent i teknologjive ishte planifikuar në rrjetin që po krijohej Wake-on-Lan dhe DLNA.
Pjesa 1: Sfondi
OpenVPN fillimisht u zgjodh si protokoll për zbatimin e kësaj detyre, pasi, së pari, mund të krijojë një pajisje trokitjeje që mund të shtohet në urë pa probleme, dhe së dyti, OpenVPN mbështet funksionimin mbi protokollin TCP, i cili ishte gjithashtu i rëndësishëm, sepse asnjë nga apartamentet kishin një adresë IP të dedikuar dhe unë nuk mund të përdorja STUN, pasi ofruesi im për disa arsye bllokon lidhjet hyrëse UDP nga rrjetet e tyre, ndërsa protokolli TCP më lejoi të përcjell portin e serverit VPN te VPS e marrë me qira duke përdorur SSH. Po, kjo qasje jep një ngarkesë të madhe, pasi të dhënat janë të koduara dy herë, por unë nuk doja të futja një VPS në rrjetin tim privat, pasi ekzistonte ende rreziku që palët e treta të fitonin kontrollin mbi të, prandaj, të kesh një pajisje të tillë në rrjetin tim të shtëpisë ishte jashtëzakonisht i padëshirueshëm dhe u vendos të paguaj për sigurinë me një shpenzim të madh.
Për të përcjellë portin në ruterin në të cilin ishte planifikuar të vendosej serveri, u përdor programi sshtunnel. Unë nuk do të përshkruaj ndërlikimet e konfigurimit të tij - është bërë mjaft lehtë, thjesht do të vërej se detyra e tij ishte të përcillte portin TCP 1194 nga ruteri në VPS. Më pas, serveri OpenVPN u konfigurua në pajisjen tap0, e cila ishte e lidhur me urën br-lan. Pasi kontrollova lidhjen me serverin e krijuar rishtazi nga laptopi, u bë e qartë se ideja e përcjelljes së portit ishte e justifikuar dhe laptopi im u bë anëtar i rrjetit të ruterit, megjithëse nuk ishte fizikisht në të.
Mbeti vetëm një gjë e vogël për të bërë: ishte e nevojshme të shpërndaheshin adresat IP në apartamente të ndryshme në mënyrë që ato të mos bien ndesh dhe të konfigurojnë ruterët si klientë OpenVPN.
U zgjodhën adresat IP të ruterit të mëposhtëm dhe diapazoni i serverit DHCP:
- 192.168.10.1 me varg 192.168.10.2 - 192.168.10.80 për serverin
- 192.168.10.100 me varg 192.168.10.101 - 192.168.10.149 për ruterin në apartamentin nr.2
- 192.168.10.150 me varg 192.168.10.151 - 192.168.10.199 për ruterin në apartamentin nr.3
Ishte gjithashtu e nevojshme të caktoheshin saktësisht këto adresa në ruterat e klientit të serverit OpenVPN duke shtuar linjën në konfigurimin e tij:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0dhe 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 të specifikuara gjatë krijimit të certifikatave për t'u lidhur me OpenVPN
Më pas, klientët OpenVPN u konfiguruan në ruterat, pajisjet tap0 në të dy u shtuan në urën br-lan. Në këtë fazë, gjithçka dukej se ishte në rregull pasi të tre rrjetet mund të shihnin njëri-tjetrin dhe të punonin si një. Megjithatë, doli një detaj jo shumë i këndshëm: ndonjëherë pajisjet mund të merrnin një adresë IP jo nga ruteri i tyre, me të gjitha pasojat që pasonin. Për disa arsye, ruteri në një nga apartamentet nuk pati kohë t'i përgjigjej DHCPDISCOVER në kohë dhe pajisja mori një adresë që nuk ishte menduar. Kuptova se duhet të filtroja kërkesa të tilla në tap0 në secilin nga ruterët, por siç doli, iptables nuk mund të funksionojë me pajisjen nëse është pjesë e një ure dhe ebtables duhet të më vijnë në ndihmë. Për keqardhjen time, nuk ishte në firmware-in tim dhe më duhej të rindërtoja imazhet për secilën pajisje. Duke bërë këtë dhe duke shtuar këto rreshta 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 zgjati tre vjet.
Pjesa 2: Prezantimi i WireGuard
Kohët e fundit, njerëzit në internet kanë filluar gjithnjë e më shumë të flasin për WireGuard, duke admiruar thjeshtësinë e konfigurimit të tij, shpejtësinë e lartë të transmetimit, ping të ulët me siguri të krahasueshme. Kërkimi për më shumë informacion në lidhje me të e bëri të qartë se as puna si anëtar i urës dhe as puna mbi protokollin TCP nuk mbështetej prej tij, gjë që më bëri të mendoj se nuk kishte ende alternativa ndaj OpenVPN për mua. Kështu që e shtyva njohjen me WireGuard.
Disa ditë më parë, lajmet u përhapën nëpër burime në një mënyrë apo tjetër në lidhje me IT-në se WireGuard më në fund do të përfshihej në kernelin Linux, duke filluar me versionin 5.6. Artikujt e lajmeve, si gjithmonë, vlerësuan WireGuard. Unë përsëri u zhyta në kërkimin e mënyrave për të zëvendësuar OpenVPN-në e vjetër të mirë. Këtë herë u përplasa . Ai foli për krijimin e një tuneli Ethernet mbi L3 duke përdorur GRE. Ky artikull më dha shpresë. Mbeti e paqartë se çfarë të bëhej me protokollin UDP. Kërkimi më çoi në artikuj rreth përdorimit të socat në lidhje me një tunel SSH për të përcjellë një port UDP, megjithatë, ata vunë re se kjo qasje funksionon vetëm në modalitetin e lidhjes së vetme, domethënë, puna e disa klientëve VPN do të ishte e pamundur. Unë dola me idenë e instalimit të një serveri VPN në një VPS dhe vendosjes së GRE për klientët, por siç doli, GRE nuk mbështet enkriptimin, gjë që do të çojë në faktin se nëse palët e treta fitojnë akses në server , i gjithë trafiku midis rrjeteve të mia do të jetë në duart e tyre, gjë që nuk më përshtatej aspak.
Edhe një herë, vendimi u mor në favor të kriptimit të tepërt, duke përdorur VPN mbi VPN duke përdorur skemën e mëposhtme:
Niveli XNUMX VPN:
VPS është server me adresë të brendshme 192.168.30.1
MS ë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 e nivelit të dytë:
MS është server me adresë të jashtme 192.168.30.2 dhe të brendshme 192.168.31.1
MK2 është klient MS me adresën 192.168.30.2 dhe ka një IP të brendshme 192.168.31.2
MK3 është klient MS me adresën 192.168.30.2 dhe ka një IP të brendshme 192.168.31.3
* MS — ruter-server në apartamentin 1, MK2 - router në apartamentin 2, MK3 - router në apartamentin 3
* Konfigurimet e pajisjes publikohen në spoiler në fund të artikullit.
Dhe kështu, ping po ekzekutohet midis nyjeve të rrjetit 192.168.31.0/24, është koha për të kaluar në ngritjen e një tuneli GRE. Para kësaj, për të mos humbur aksesin në ruterat, ia vlen të vendosni tunele SSH për të përcjellë portin 22 në VPS, në mënyrë që, për shembull, ruteri nga apartamenti 10022 të jetë i aksesueshëm në portin 2 të VPS, dhe ruteri nga apartamenti 11122 do të jetë i aksesueshëm në ruterin e portit 3 nga apartamenti XNUMX. Është më mirë të konfiguroni përcjelljen duke përdorur të njëjtin sshtunnel, pasi ai do të rivendosë tunelin nëse dështon.
Tuneli është i konfiguruar, mund të lidheni me SSH përmes portit të përcjellë:
ssh root@МОЙ_VPS -p 10022Më pas duhet të çaktivizoni OpenVPN:
/etc/init.d/openvpn stopTani le të vendosim një tunel GRE në ruterin nga apartamenti 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Dhe shtoni ndërfaqen e krijuar në urë:
brctl addif br-lan grelan0
Le të kryejmë një procedurë të ngjashme në ruterin e serverit:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Dhe gjithashtu shtoni ndërfaqen e krijuar në urë:
brctl addif br-lan grelan0
duke filluar nga ky moment, ping-t fillojnë të shkojnë me sukses në rrjetin e ri dhe unë i kënaqur shkoj të pi kafe. Më pas, për të vlerësuar se si funksionon rrjeti në skajin tjetër të linjës, përpiqem të fut SSH në një nga kompjuterët në apartamentin 2, por klienti ssh ngrin pa kërkuar një fjalëkalim. Po përpiqem të lidhem me këtë kompjuter përmes telnet në portin 22 dhe shoh një linjë nga e cila mund të kuptoj që lidhja po krijohet, serveri SSH po përgjigjet, por për disa arsye thjesht nuk më kërkon të regjistrohem në.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Po përpiqem të lidhem me të nëpërmjet VNC dhe të shoh një ekran të zi. E bind veten se problemi është me kompjuterin në distancë, sepse mund të lidhem lehtësisht me ruterin nga ky apartament duke përdorur adresën e brendshme. Megjithatë, vendos të lidhem me SSH-në e këtij kompjuteri përmes ruterit dhe jam i befasuar kur konstatoj se lidhja është e suksesshme dhe kompjuteri në distancë funksionon mjaft normalisht, por gjithashtu nuk mund të lidhet me kompjuterin tim.
Unë heq pajisjen grelan0 nga ura dhe ekzekutoj OpenVPN në ruterin në apartamentin 2 dhe sigurohem që rrjeti të funksionojë përsëri siç pritej dhe lidhjet të mos hiqen. Duke kërkuar hasem në forume ku njerëzit ankohen për të njëjtat probleme, ku këshillohen të rrisin MTU-në. E thënë më shpejt se sa bëhet. Megjithatë, derisa MTU u caktua mjaftueshëm e lartë - 7000 për pajisjet gretap, u vunë re ose ndërprerje të lidhjeve TCP ose shpejtësi të ulëta transferimi. Për shkak të MTU-së së lartë për gretap, MTU-të për lidhjet WireGuard të Shtresës 8000 dhe të Shtresës 7500 u vendosën përkatësisht në XNUMX dhe XNUMX.
Kam kryer një konfigurim të ngjashëm në ruterin nga apartamenti 3, me ndryshimin e vetëm që një ndërfaqe e dytë gretap me emrin grelan1 u shtua në ruterin e serverit, i cili gjithashtu u shtua në urën br-lan.
Gjithçka po funksionon. Tani mund ta vendosni asamblenë gretap në fillim. Për këtë:
I vendosa këto rreshta në /etc/rc.local në ruterin në apartamentin 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 shtoi këtë në /etc/rc.local në ruterin në apartamentin 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 e serverit:
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 rindezjes së ruterave të klientit, zbulova se për ndonjë arsye ata nuk po lidheshin me serverin. Pasi u lidha me SSH-në e tyre (për fat të mirë, unë kisha konfiguruar më parë sshtunnel për këtë), u zbulua se WireGuard për disa arsye po krijonte një rrugë për pikën përfundimtare, por ishte e pasaktë. Pra, për 192.168.30.2, tabela e itinerarit tregoi një rrugë përmes ndërfaqes pppoe-wan, domethënë përmes internetit, megjithëse rruga për në të duhej të ishte drejtuar përmes ndërfaqes wg0. Pas fshirjes së kësaj rruge, lidhja u rivendos. Nuk munda të gjeja kudo udhëzime se si ta detyroja WireGuard të mos krijonte këto rrugë. Për më tepër, as që e kuptova nëse kjo ishte një veçori e OpenWRT apo vetë WireGuard. Pa pasur nevojë të merrem me këtë problem për një kohë të gjatë, thjesht shtova një linjë në të dy ruterat në një skript me kohë që fshiu këtë rrugë:
route del 192.168.30.2
Përmbledhur
Unë nuk kam arritur ende një braktisje të plotë të OpenVPN, pasi ndonjëherë më duhet të lidhem me një rrjet të ri nga një kompjuter portativ ose telefon, dhe vendosja e një pajisje gretap në to është përgjithësisht e pamundur, por pavarësisht kësaj, kam një avantazh në shpejtësinë transferimi i të dhënave ndërmjet apartamenteve dhe, për shembull, përdorimi i VNC nuk është më i papërshtatshëm. Ping u ul pak, por u bë më i qëndrueshëm:
Kur përdorni 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ërdorni 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
Ai ndikohet më shumë nga ping-u i lartë në VPS, i cili është afërsisht 61.5 ms
Megjithatë, shpejtësia është rritur ndjeshëm. Pra, në një apartament me një ruter serveri kam një shpejtësi të lidhjes në internet prej 30 Mbit/sek, dhe në apartamentet e tjera është 5 Mbit/sek. Në të njëjtën kohë, gjatë përdorimit të OpenVPN, nuk arrita të arrij një shpejtësi të transferimit të të dhënave midis rrjeteve më shumë se 3,8 Mbit/sek sipas leximeve iperf, ndërsa WireGuard e "rriti" atë në të njëjtat 5 Mbit/sek.
Konfigurimi i WireGuard në VPS[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
Konfigurimi i WireGuard në MS (shtuar në /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 (shtuar në /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 (shtuar në /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ë, i drejtoj klientët WireGuard në portin 51821. Në teori, kjo nuk është e nevojshme, pasi klienti do të krijojë një lidhje nga çdo port i paprivilegjuar falas, por e bëra në mënyrë që të ishte e mundur të ndalohej të gjitha lidhjet hyrëse në ndërfaqet wg0 të të gjithë ruterave, përveç lidhjeve hyrëse UDP në portin 51821.
Shpresoj se artikulli do të jetë i dobishëm për dikë.
PS Gjithashtu, dua të ndaj skriptin tim që më dërgon një njoftim PUSH në telefonin tim në aplikacionin WirePusher kur një pajisje e re shfaqet në rrjetin tim. Këtu është lidhja me skenarin: .
UPDATE: 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-lzoKlienti OpenVPN
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
Kam përdorur easy-rsa për të gjeneruar certifikata
Burimi: www.habr.com