Jeg vil gjerne dele min erfaring med å kombinere nettverk i tre geografisk avsidesliggende leiligheter, som hver bruker OpenWRT-rutere som en gateway, til ett felles nettverk. Ved valg av metode for å kombinere nettverk mellom L3 med subnettruting og L2 med brobygging, når alle nettverksnoder vil være i samme subnett, ble den andre metoden foretrukket, som er vanskeligere å konfigurere, men gir større muligheter, siden transparent bruk av teknologier var planlagt i nettverket som ble opprettet Wake-on-Lan og DLNA.
Del 1: Bakgrunn
Protokollen som ble valgt for å implementere denne oppgaven var opprinnelig OpenVPN, fordi den for det første kan lage en tappeenhet som kan legges til broen uten problemer, og for det andre, OpenVPN Den støtter TCP, noe som også var viktig, ettersom ingen av leilighetene hadde en dedikert IP-adresse. Jeg kunne ikke bruke STUN fordi internettleverandøren min, av en eller annen grunn, blokkerer innkommende UDP-tilkoblinger fra nettverkene sine. TCP tillot meg å videresende VPN-serverporten til den leide VPS-en ved hjelp av SSH. Selv om denne tilnærmingen skaper en betydelig overhead, ettersom dataene er dobbeltkryptert, ønsket jeg ikke å integrere VPS-en i mitt private nettverk, da det var en risiko for at tredjeparter fikk kontroll over den. Derfor var det svært uønsket å ha en slik enhet på hjemmenettverket mitt, så jeg bestemte meg for å betale en betydelig overhead for sikkerhet.
For å videresende porten på ruteren der serveren var planlagt å bli distribuert, brukte jeg sshtunnel-programmet. Jeg vil ikke gå inn på detaljene om konfigurasjonen – det er ganske enkelt. Jeg vil bare nevne at formålet var å videresende TCP-port 1194 fra ruteren til VPS-en. Deretter konfigurerte jeg serveren. OpenVPN På tap0-enheten, som var koblet til br-lan-broen. Etter å ha testet forbindelsen til den nyopprettede serveren fra den bærbare datamaskinen min, ble det klart at portvideresendingsidéen hadde fungert, og den bærbare datamaskinen min hadde blitt medlem av ruterens nettverk, selv om den ikke fysisk var en del av det.
Det eneste som gjensto å gjøre var å fordele IP-adresser i forskjellige leiligheter slik at de ikke kom i konflikt, og konfigurere ruterne som OpenVPN-klienter.
Følgende ruter-IP-adresser og DHCP-serverområder ble valgt:
- 192.168.10.1 med rekkevidde 192.168.10.2 - 192.168.10.80 for serveren
- 192.168.10.100 med rekkevidde 192.168.10.101 - 192.168.10.149 for ruteren i leilighet nr. 2
- 192.168.10.150 med rekkevidde 192.168.10.151 - 192.168.10.199 for ruteren i leilighet nr. 3
Det var også nødvendig å tilordne disse adressene til klientruterne. OpenVPN-server, ved å legge til følgende linje i konfigurasjonen:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0og legger til følgende linjer i filen /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
der flat1_id og flat2_id er enhetsnavnene som er spesifisert når du oppretter sertifikater for tilkobling til OpenVPN
Deretter ble ruterne konfigurert OpenVPN- klienter, tap0-enheter på begge ble lagt til br-lan-broen. På dette tidspunktet virket alt i orden, ettersom alle tre nettverkene kunne se hverandre og fungere som én enhet. Imidlertid dukket det opp en ganske ubehagelig detalj: noen ganger mottok enheter en IP-adresse fra feil ruter, med alle de påfølgende konsekvensene. Av en eller annen grunn klarte ikke ruteren i en av leilighetene å svare på DHCPDISCOVER i tide, og enheten mottok feil adresse. Jeg innså at jeg måtte filtrere slike forespørsler i tap0 på hver ruter, men det viste seg at iptables ikke kan fungere med en enhet hvis den er en del av en bro, så jeg måtte bruke ebtables. Dessverre inkluderte ikke fastvaren min det, så jeg måtte gjenoppbygge avbildningene for hver enhet. Etter å ha gjort dette og lagt til følgende linjer i /etc/rc.local på hver ruter, ble problemet løst:
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
Denne konfigurasjonen varte i tre år.
Del 2: Bli kjent WireGuard
I det siste har det vært mer snakk på internett om WireGuard, og beundrer den enkle konfigurasjonen, høye overføringshastigheten, lave ping og sammenlignbare sikkerheten. Et søk etter ytterligere informasjon om den viste at den ikke støtter verken bromedlem eller TCP-protokollstøtte, noe som fikk meg til å tro at det ikke fantes noe alternativ. OpenVPN for meg er den fortsatt ikke der. Så jeg utsatte å bli kjent med WireGuard.
For noen dager siden spredte nyheter seg gjennom ressurser relatert til IT på en eller annen måte som WireGuard vil endelig bli inkludert i kjernen Linux, startende med versjon 5.6. Nyhetsartikler ble som alltid rost WireGuardJeg kastet meg nok en gang ut i å lete etter måter å erstatte det gode gamle på OpenVPNDenne gangen møtte jeg på . Den snakket om å lage en Ethernet-tunnel over L3 ved å bruke GRE. Denne artikkelen ga meg håp. Det forble uklart hva de skulle gjøre med UDP-protokollen. Søket førte meg til artikler om bruk av socat i forbindelse med en SSH-tunnel for å videresende en UDP-port, men de bemerket at denne tilnærmingen bare fungerer i enkelt tilkoblingsmodus, det vil si at arbeidet til flere VPN-klienter ville være umulig. Jeg kom på ideen om å installere en VPN-server på en VPS og sette opp GRE for klienter, men som det viste seg, støtter ikke GRE kryptering, noe som vil føre til at hvis tredjeparter får tilgang til serveren , vil all trafikk mellom nettverkene mine være i deres hender, noe som ikke passet meg i det hele tatt.
Nok en gang ble avgjørelsen tatt til fordel for redundant kryptering, ved å bruke VPN over VPN ved å bruke følgende skjema:
Nivå XNUMX VPN:
VPS er server med intern adresse 192.168.30.1
MS er klient VPS med intern adresse 192.168.30.2
MK2 er klient VPS med intern adresse 192.168.30.3
MK3 er klient VPS med intern adresse 192.168.30.4
Andre nivå VPN:
MS er server med ekstern adresse 192.168.30.2 og intern 192.168.31.1
MK2 er klient MS med adressen 192.168.30.2 og har en intern IP 192.168.31.2
MK3 er klient MS med adressen 192.168.30.2 og har en intern IP 192.168.31.3
* MS — ruter-server i leilighet 1, MK2 - ruter i leilighet 2, MK3 - ruter i leilighet 3
* Enhetskonfigurasjoner er publisert i spoileren på slutten av artikkelen.
Og så, ping kjører mellom nettverksnoder 192.168.31.0/24, det er på tide å gå videre til å sette opp en GRE-tunnel. Før dette, for ikke å miste tilgangen til rutere, er det verdt å sette opp SSH-tunneler for å videresende port 22 til VPS, slik at for eksempel ruteren fra leilighet 10022 vil være tilgjengelig på port 2 til VPS, og ruter fra leilighet 11122 vil være tilgjengelig på port 3 ruter fra leilighet XNUMX. Det er best å konfigurere videresending med samme sshtunnel, siden den vil gjenopprette tunnelen hvis den svikter.
Tunnelen er konfigurert, du kan koble til SSH via den videresendte porten:
ssh root@МОЙ_VPS -p 10022Deretter bør du deaktivere OpenVPN:
/etc/init.d/openvpn stopLa oss nå sette opp en GRE-tunnel på ruteren fra leilighet 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Og legg til det opprettede grensesnittet til broen:
brctl addif br-lan grelan0
La oss utføre en lignende prosedyre på serverruteren:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Og legg også til det opprettede grensesnittet til broen:
brctl addif br-lan grelan0
fra og med dette øyeblikket begynner pings å gå til det nye nettverket, og jeg, med tilfredshet, drar for å drikke kaffe. Deretter, for å evaluere hvordan nettverket fungerer på den andre enden av linjen, prøver jeg å SSH inn i en av datamaskinene i leilighet 2, men ssh-klienten fryser uten å spørre om et passord. Jeg prøver å koble til denne datamaskinen via telnet på port 22, og jeg ser en linje som jeg kan forstå at tilkoblingen blir opprettet fra, SSH-serveren svarer, men av en eller annen grunn ber den meg bare ikke om å logge i.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Jeg prøver å koble til den via VNC og ser en svart skjerm. Jeg overbeviser meg selv om at problemet er med den eksterne datamaskinen, fordi jeg enkelt kan koble til ruteren fra denne leiligheten ved å bruke den interne adressen. Imidlertid bestemmer jeg meg for å koble til SSH-en til denne datamaskinen gjennom ruteren og er overrasket over å finne at tilkoblingen er vellykket, og den eksterne datamaskinen fungerer ganske normalt, men den kan heller ikke koble til datamaskinen min.
Jeg tar grelan0-enheten ut av broen og kjører den OpenVPN På ruteren i leilighet 2 bekreftet jeg at nettverket fungerte som det skulle igjen, og at tilkoblingene ikke falt fra. Ved å søke kom jeg over forum der folk klaget over de samme problemene, og der de ble rådet til å øke MTU-en. Ikke før sagt enn gjort. Men inntil MTU-en var satt høyt nok – 7000 for gretap-enheter – opplevde jeg enten tapte TCP-tilkoblinger eller lave overføringshastigheter. På grunn av den høye MTU-en for gretap, ble MTU-en for tilkoblinger WireGuard Det første og andre nivået ble satt til henholdsvis 8000 og 7500.
Jeg utførte et lignende oppsett på ruteren fra leilighet 3, med den eneste forskjellen at et andre gretap-grensesnitt kalt grelan1 ble lagt til serverruteren, som også ble lagt til br-lan-broen.
Alt fungerer. Nå kan du sette gretap-enheten til oppstart. For dette:
Jeg plasserte disse linjene i /etc/rc.local på ruteren i leilighet 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
Lagt dette til /etc/rc.local på ruteren i leilighet 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
Og på serverruteren:
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
Etter å ha startet klientruterne på nytt, oppdaget jeg at de av en eller annen grunn ikke koblet seg til serveren. Etter å ha koblet til SSH-en deres (heldigvis hadde jeg konfigurert sshtunnel for dette tidligere), oppdaget jeg at WireGuard Av en eller annen grunn oppretter den en rute for endepunktet, men den er feil. For eksempel, for 192.168.30.2, spesifiserte rutetabellen en rute gjennom pppoe-wan-grensesnittet, dvs. gjennom internett, selv om ruten dit skulle ha blitt dirigert gjennom wg0-grensesnittet. Etter at denne ruten ble slettet, ble forbindelsen gjenopprettet. Kan jeg finne instruksjoner noe sted om hvordan jeg tvinger frem WireGuard Jeg kunne ikke unngå å lage disse rutene. Dessuten forsto jeg ikke engang om dette var en funksjon i OpenWRT eller i WireGuardUten å bruke mye tid på å finne ut av problemet, la jeg ganske enkelt til en linje i timer-loop-skriptet på begge ruterne som slettet denne ruten:
route del 192.168.30.2
Oppsummering
Fullstendig avvisning OpenVPN Jeg har ikke oppnådd dette ennå, ettersom jeg av og til må koble til et nytt nettverk fra en bærbar PC eller telefon, og det er vanligvis umulig å sette opp en gretap-enhet på dem. Til tross for dette har jeg fått en fordel i dataoverføringshastighet mellom leiligheter, og det er nå problemfritt å bruke for eksempel VNC. Ping har blitt noe mindre, men har blitt mer stabil:
Ved bruk 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
Ved bruk 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
Den er mer påvirket av den høye ping til VPS, som er omtrent 61.5 ms
Hastigheten har imidlertid økt betraktelig. Så i leiligheten med ruter-server har jeg en internettforbindelseshastighet på 30 Mbps, og i de andre leilighetene er den 5 Mbps. Dessuten, under bruk OpenVPN Jeg klarte ikke å oppnå en dataoverføringshastighet mellom nettverk på over 3,8 Mbps i henhold til iperf-avlesninger, mens WireGuard "pumpet" den opp til de samme 5 Mbit/sek.
Konfigurasjon WireGuard på VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Likemann]
Offentlig nøkkel = <VPN_1_MS_PUBLIC_KEY>
TillatteIPs = 192.168.30.2/32
[Likemann]
Offentlig nøkkel = <VPN_2_MK2_PUBLIC_KEY>
TillatteIPs = 192.168.30.3/32
[Likemann]
Offentlig nøkkel = <VPN_2_MK3_PUBLIC_KEY>
TillatteIPs = 192.168.30.4/32
Konfigurasjon WireGuard på MS (lagt til i /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'
Konfigurasjon WireGuard på MK2 (lagt til i /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'
Konfigurasjon WireGuard på MK3 (lagt til i /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'
I de beskrevne konfigurasjonene for VPN på andre nivå indikerer jeg til klienter WireGuard Port 51821. Dette burde ikke være nødvendig, ettersom klienten vil opprette en forbindelse fra en hvilken som helst ledig, uprivilegert port, men jeg gjorde det på denne måten slik at jeg kunne nekte alle innkommende forbindelser på wg0-grensesnittene til alle rutere, bortsett fra innkommende UDP-forbindelser til port 51821.
Jeg håper at artikkelen vil være nyttig for noen.
PS Jeg vil også dele skriptet mitt som sender meg et PUSH-varsel til telefonen min i WirePusher-applikasjonen når en ny enhet dukker opp på nettverket mitt. Her er linken til manuset: .
UPDATE: Konfigurasjon OpenVPN-servere og klienter
OpenVPN-server
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-lzoOpenVPN-klient
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 Jeg brukte easy-rsa for å generere sertifikater
Kilde: www.habr.com
