Dëshiroj të ndaj përvojën time të bashkimit të rrjeteve në tri apartamente gjeografikisht të ndara, nga të cilat çdo një përdor një router me OpenWRT si portë për të formuar një rrjet të përbashkët. Gjatë zgjedhjes mes mënyrës L3 me ruterim të nënrrjeteve dhe L2 me bridging, ku të gjitha nyjet e rrjetit do të ishin në një nënrrjet, u preferua opsioni i dytë, më i komplikuar për t'u konfiguruar, por që ofron mundësi më të mëdha, pasi në rrjetin e krijuar planifikohej përdorimi i qartë i teknologjive Wake-on-Lan dhe DLNA.
Pjesa 1: Historia e paravendosur
Si një protokoll për zbatimin e këtij projekti, u zgjodh fillimisht OpenVPN, pasi, së pari, ai mund të krijojë një pajisje tap, e cila shtohet lehtësisht në urë, dhe së dyti, OpenVPN mbështet funksionimin përmes protokollit TCP, gjë që gjithashtu ishte shumë e rëndësishme, pasi në asnjë nga apartamentet nuk kishte një adresë IP të dedikuar, dhe nuk mund të përdorja STUN, pasi provider-i im e bllokonte për një arsye të panjohur lidhjen e ardhshme përmes protokollit UDP nga rrjetet e tij, ndërsa protokolli TCP më lejonte të hapja portin e VPN-serverit në VPS-në e marrë me anë të SSH. Po, ky qasje sjell një ngarkesë më të madhe, pasi të dhënat enkriptohen dy herë, por nuk doja ta fusja VPS-në në rrjetin tim privat, pasi ishte një rrezik që palët e treta mund të merrnin kontroll mbi të, prandaj, të kenë një pajisje të tillë në rrjetin e shtëpisë ishte jashtëzakonisht e padëshiruar dhe u vendos të paguaja për siguri me një mbingarkesë të madhe.
Për kalimin e portit në routerin, ku ishte planifikuar të zhvillohej serveri, u përdor programi sshtunnel. Nuk do ta përshkruaj hollësinë e konfigurimit të tij — është mjaft e lehtë, thjesht do të theksoj se qëllimi i tij ishte kalimi i portit TCP 1194 nga routeri në VPS. Më pas, u konfigurua serveri OpenVPN në pajisjen tap0, e cila u lidh me urën br-lan. Pasi kontrollova lidhjen me serverin e sapo krijuar nga laptopi, u kuptua se ideja e kalimit të portit kishte funksionuar, dhe laptopi im u bë një anëtar i rrjetit të routerit, edhe pse fizikisht nuk ishte aty.
Tani mbeti që të shpërndaheshin IP-të në apartamente të ndryshme në një mënyrë që ato të mos përplasen dhe të konfigurohen routerat si klientë të OpenVPN.
I zgjodhën këto IP të routerave 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 routerin në apartamentin Nr. 2
- 192.168.10.150 me intervalin 192.168.10.151 — 192.168.10.199 për routerin në apartamentin Nr. 3
Gjithashtu, ishte e nevojshme të caktoheshin ekzaktesisht këto adresa për routerat-klientë të serverit OpenVPN, duke shtuar në konfigurimin e tij rreshtin:
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 – emra të pajisjeve që përcaktohen gjatë krijimit të certifikatave për lidhjen me OpenVPN
Më pas, klientët OpenVPN u konfiguruan në routerë, pajisjet tap0 në të dyja u vendosën në urën br-lan. Në këtë fazë dukej se gjithçka ishte në rregull, pasi të tre rrjetet shihnin njëri-tjetrin dhe funksiononin si njësi e vetme. Megjithatë, rezultoi një detaj jo shumë i këndshëm: ndonjëherë pajisjet mund të merrnin një adresë IP jo nga routeri i tyre, me të gjitha pasojat që rrjedhin prej saj. Për një arsye, routeri në ndonjë nga apartamentet nuk arrinte të përgjigjej në kohë për DHCPDISCOVER dhe pajisja merrte adresën e gabuar. E kuptova se duhej të filtroja këto kërkesa në tap0 në çdo router, por, siç rezultoi, iptables nuk mund të punonte me pajisjen nëse ishte pjesë e urës dhe ebtables duhet të vinin në ndihmë. Për fat të keq, në firmat e mia nuk kishte dhe duhej të rigrupoja imazhet për çdo pajisje. Pasi e bëra këtë dhe shtova këto rreshta në /etc/rc.local të çdo routeri, 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
Kjo konfigurim ka qëndruar për tri vjet.
Pjesa 2: Njohja me WireGuard
Së fundi, më shumë se kurrë, në internet po flitet për WireGuard, duke u mahnitur nga thjeshtësia e konfigurimit të tij, shpejtësia e lartë e transmetimit dhe ping-u i ulët me siguri të krahasueshme. Kërkimi për informacion shtesë për të më bëri të kuptoj se as puna si anëtar i urës, as funksionimi sipas protokollit TCP nuk mbështeten, e kjo më çoi në mendimin se nuk ka ende alternativa për OpenVPN për mua. Kështu, unë e shtyva njohjen me WireGuard.
Para disa ditësh, në burimet që lidhen në një farë mënyre me IT, kaloi lajmi se WireGuard do të përfshihej përfundimisht në bërthamën Linux, duke filluar nga versioni 5.6. Artikujt e lajmeve, si gjithmonë, e lavdëronin WireGuard. Unë u futa përsëri në kërkimin e alternativave për OpenVPN-in e vjetër të mirë. Këtë herë kam gjetur . Artikulli përmbante informacion mbi krijimin e një tuneli Ethernet mbi L3 duke përdorur GRE. Ky artikull më dha shpresë. Mbeti e paqartë se çfarë të bëja me protokollin UDP. Kërkimi më çoi në artikuj për përdorimin e socat me SSH-tunnel për të kaluar portin UDP, megjithatë, ato theksonin se ky qasje funksionon vetëm në modin e një lidhjeje, pra punimi i disa VPN-klientëve do të ishte i pamundur. Më lindi ideja për të ngritur një VPN-server në VPS, dhe për klientët të konfiguroj GRE, por, siç duket, GRE nuk mbështet kriptimin, dhe kjo do të sillte që në rast të qasjes së palëve të treta në server, do të binte në duar të tyre i gjithë trafiku mes rrjetit tim, gjë që mua nuk më përkëdhelte në parim.
Përsëri u vendos për një zgjidhje të tepërt të kriptimit, duke përdorur VPN mbi VPN sipas skemës së mëposhtme:
VPN i nivelit të parë:
VPS është serverin me adresë të brendshme 192.168.30.1
MS është klienti VPS me adresë të brendshme 192.168.30.2
MK2 është klienti VPS me adresë të brendshme 192.168.30.3
MK3 është klienti VPS me adresë të brendshme 192.168.30.4
VPN i nivelit të dytë:
MS është serverin me adresë të jashtme 192.168.30.2 dhe brendshme 192.168.31.1
MK2 është klienti MS me adresë 192.168.30.2 dhe ka IP të brendshme 192.168.31.2
MK3 është klienti MS me adresën 192.168.30.2 dhe ka IP të brendshëm 192.168.31.3
* MS — router-server në apartamentin 1, MK2 — router në apartamentin 2, MK3 — router në apartamentin 3
* Konfiguracionet e pajisjeve janë publikuar në spoiler në fund të artikullit.
Tani, pinget midis nyjeve të rrjetit 192.168.31.0/24 ndodhin, është koha për të kaluar në konfigurimin e tunelit GRE. Para kësaj, që të mos humbni qasjen në routerat, është e mençur të konfiguroni tunel SSH për përcjelljen e portit 22 në VPS, në këtë mënyrë që, për shembull, në portin 10022 VPS do të jetë i aksesueshëm routeri nga apartamenti 2, ndërsa në portin 11122 VPS do të jetë i aksesueshëm routeri nga apartamenti 3. Konfigurimin e përcjelljes është më mirë ta bëni me sshtunnel, pasi ai do të rikthejë tunelin në rast se ai dështon.
Tuneli është konfiguruar, mund të lidheni me SSH përmes portit të përcjellë:
ssh root@MOJ_VPS -p 10022Më pas duhet të çaktivizoni OpenVPN:
/etc/init.d/openvpn stopTani le të konfiguroni tunelin GRE në routerin 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 do ta shtojmë interfacin e krijuar në urë:
brctl addif br-lan grelan0
Procedurë të ngjashme do të kryejmë 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, gjithashtu, do ta shtojmë interfacin e krijuar në urë:
brctl addif br-lan grelan0
nga ky moment ping-et fillojnë të funksionojnë me sukses në rrjetin e ri dhe unë, me kënaqësi, shkoj të pi kafe. Më pas, për të vlerësuar se si funksionon rrjeti në skajin tjetër të telit, përpiqem të lidhem me një nga kompjuterët në apartamentin 2 përmes SSH, por klienti SSH "ngjitet", duke mos ofruar për të shtypur fjalëkalimin. Provoj të lidhem me këtë kompjuter përmes telnet në portin 22 dhe shoh një rresht, nga i cili kuptohet se lidhja është duke u krijuar, serveri SSH përgjigjet, thjesht për një arsye të caktuar nuk më ofron mundësinë për të hyrë.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Provoj të lidhem me të përmes VNC dhe shoh një ekran të zi. E bind veten se është problemi te kompjuteri i largët, sepse mund të lidhëm pa probleme me router-in nga ky apartament përmes adresës së brendshme. Megjithatë, vendos të lidhem me SSH të këtij kompjuteri përmes router-it dhe me habi zbuloj se lidhja është e suksesshme, dhe kompjuteri i largët funksionon krejt normal, por gjithashtu nuk mund të lidhet me kompjuterin tim.
Unë po e heq pajisjen grelan0 nga ura dhe po e nis OpenVPN në routerin në apartamentin 2, duke siguruar që rrjeti të funksionojë siç duhet dhe lidhjet të mos shqiptohen. Duke kërkuar, përballesh me forume ku njerëzit ankojnë për probleme të ngjashme, ku u këshillohet të rrisin MTU. E thënë — e bërë. Megjithatë, derisa MTU të mos ishte vendosur mjaftueshëm i madh — 7000 për pajisjet gretap, u vërejtën ose shqitje lidhjesh TCP ose shpejtësi e ulët transmetimi. Për shkak të MTU të lartë për gretap — MTU për lidhjet e WireGuard të katit të parë dhe të dytë ishin vendosur në 8000 dhe 7500 përkatësisht.
Kam kryer një konfigurim të ngjashëm edhe në routerin nga apartamenti 3, me ndryshimin e vetëm se në routerin server iu shtua një ndërfaqe e dytë gretap me emrin grelan1, e cila gjithashtu u shtua në urën br-lan.
Tani gjithçka funksionon. Tani mund të vendos grupimin e gretap në ngarkesën automatik. Për këtë:
Vura këto rreshta në /etc/rc.local në routerin 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 shtova këtë në /etc/rc.local në routerin 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ë router-server:
ip link add grelan0 tip 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 tip 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ë routerëve klientë, zbulova që ata për një arsye të caktuar nuk janë duke u lidhur me serverin. Pasi u lidhja me SSH e tyre (fatkeqësisht, unë paraprakisht e kisha konfigururar sshtunnel për këtë), u zbulua se WireGuard për ndonjë arsyetim krijon një rrugë për endpoint, megjithatë, të gabuar. Për 192.168.30.2, tabela e rrugëve tregonte një rrugë përmes interfaces pppoe-wan, pra përmes internetit, megjithatë, rruga për të duhej të kishte qenë e drejtuar përmes interfaces wg0. Pasi e hoqa këtë rrugë, lidhja u rikuperua. Nuk arrita të gjej ndonjë informacion mbi se si ta bëj WireGuard të mos krijojë këto ruta. Më shumë, nuk e kuptova nëse kjo ishte një veçori e OpenWRT, ose e WireGuard vetë. Duke mos dashur të merrem me këtë problem për një kohë të gjatë, thjesht shtova në dy routerët një skriptë, të cikluar sipas timerit, që fshinte këtë rrugë:
route del 192.168.30.2
Për të përfunduar
Nuk nuk arrita të heq plotësisht OpenVPN, pasi më nevojitet të lidhem nganjëherë në një rrjet të ri me laptopin ose telefonin tim, dhe konfigurimi i pajisjes gretap në to në përgjithësi është e pamundur, megjithatë, përkundër kësaj, kam fituar një avantazh në shpejtësinë e transferimit të të dhënave midis apartamenteve, dhe, për shembull, përdorimi i VNC tani nuk shkakton shqetësime. Ping-u është paksa zvogëluar, por është bërë më stabil:
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 statistikë ping ---
20 paketa të dërguara, 20 të pranuara, 0% humbje pakete, kohë 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 statistikë ping ---
20 paketa të dërguara, 20 të pranuara, 0% humbje pakete, kohë 19003ms
rtt min/avg/max/mdev = 123.954/124.423/126.708/0.675 ms
I ndikohet më së shumti nga ping-u i lartë deri te VPS, i cili është rreth 61.5 ms
Megjithatë, shpejtësia u rrit ndjeshëm. Kështu, në apartamentin me një router-server kam një shpejtësi lidhjeje në internet prej 30 Mbit/s, ndërsa në apartamentet e tjera është 5 Mbit/s. Në këtë mënyrë, gjatë përdorimit të OpenVPN nuk mund të arrija një shpejtësi transmetimi midis rrjetesh më shumë se 3,8 Mbit/s sipas të dhënave nga iperf, ndërsa WireGuard e rriti atë në 5 Mbit/s.
Konfigurimi i WireGuard në VPS[Interface]
Adresa = 192.168.30.1/24
Porti i Dëgjimit = 51820
Çelësi Privat =
[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 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 (shtohet 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 (shtohet 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-në e nivelit të dytë, u jap klientëve WireGuard portin 51821. Në teorik është e panevojshme, pasi klienti do të vendosë lidhjen nga çdo port të lirë jo të privilegjuar, por e bëra kështu që të mund të ndaloja të gjitha lidhjet e ardhshme në ndërfaqet wg0 të të gjithë routerëve, përveç lidhjeve UDP që vijnë në portin 51821.
Shpresoj që ky artikull të jetë i dobishëm për dikë.
P.S. Gjithashtu, dëshiroj të ndaj skriptin tim, i cili më dërgon njoftime PUSH në telefon në aplikacionin WirePusher, kur një pajisje e re shfaqet në rrjetin tim. Ja lidhja e skriptit: .
AZHURNIM: 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 # Ndrysho në IP-në e Jashtme të router-it 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 të gjeneruar certifikatat përdora easy-rsa
Burimi: habr.com
