Jeg vil gerne dele min erfaring med at kombinere netværk i tre geografisk fjerne lejligheder, som hver især bruger routere med OpenWRT som gateway, til ét fælles netværk. Ved valg af metode til at kombinere netværk mellem L3 med subnet routing og L2 med bridging, når alle netværksnoder vil være i samme subnet, blev den anden metode givet fortrinsret, som er sværere at konfigurere, men giver flere muligheder, da transparent brug af teknologier var planlagt i det oprettede netværk Wake-on-Lan og DLNA.
Del 1: Baggrund
Den valgte protokol til at implementere denne opgave var oprindeligt OpenVPN, fordi den for det første kan skabe en tap-enhed, der kan tilføjes til broen uden problemer, og for det andet, OpenVPN Den understøtter TCP, hvilket også var vigtigt, da ingen af lejlighederne havde en dedikeret IP-adresse. Jeg kunne ikke bruge STUN, fordi min internetudbyder af en eller anden grund blokerer indgående UDP-forbindelser fra sine netværk. TCP tillod mig at videresende VPN-serverporten til den lejede VPS ved hjælp af SSH. Selvom denne tilgang skaber en betydelig overhead, da dataene er dobbeltkrypterede, ønskede jeg ikke at integrere VPS'en i mit private netværk, da der var risiko for, at tredjeparter fik kontrol over den. Derfor var det meget uønsket at have en sådan enhed på mit hjemmenetværk, så jeg besluttede at betale en betydelig overhead for sikkerhed.
For at videresende porten på routeren, hvor serveren var planlagt at blive installeret, brugte jeg programmet sshtunnel. Jeg vil ikke gå i detaljer med dets konfiguration – det er ret nemt. Jeg vil blot bemærke, at dets formål var at videresende TCP-port 1194 fra routeren til VPS'en. Dernæst konfigurerede jeg serveren. OpenVPN På tap0-enheden, som var forbundet til br-lan-broen. Efter at have testet forbindelsen til den nyoprettede server fra min bærbare computer, blev det klart, at port forwarding-ideen havde virket, og min bærbare computer var blevet medlem af routerens netværk, selvom den ikke fysisk var en del af det.
Det eneste, der var tilbage at gøre, var at fordele IP-adresser i forskellige lejligheder, så de ikke kom i konflikt, og konfigurere routerne som OpenVPN-klienter.
Følgende router-IP-adresser og DHCP-serverintervaller blev valgt:
- 192.168.10.1 med rækkevidde 192.168.10.2 — 192.168.10.80 for serveren
- 192.168.10.100 med rækkevidde 192.168.10.101 — 192.168.10.149 til en router i lejlighed nr. 2
- 192.168.10.150 med rækkevidde 192.168.10.151 — 192.168.10.199 til en router i lejlighed nr. 3
Det var også nødvendigt at tildele disse adresser til klientrouterne. OpenVPN-server, ved at tilføje følgende linje til dens konfiguration:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0og tilføje følgende linjer til filen /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
hvor flat1_id og flat2_id er de enhedsnavne, der er angivet ved oprettelse af certifikater til forbindelse til OpenVPN
Dernæst blev routerne konfigureret OpenVPN- klienter, tap0-enheder på begge blev tilføjet til br-lan-broen. På dette tidspunkt virkede alt fint, da alle tre netværk kunne se hinanden og fungere som en enkelt enhed. En ret ubehagelig detalje dukkede dog op: Nogle gange modtog enheder en IP-adresse fra den forkerte router, med alle de deraf følgende konsekvenser. Af en eller anden grund svarede routeren i en af lejlighederne ikke på DHCPDISCOVER i tide, og enheden modtog den forkerte adresse. Jeg indså, at jeg var nødt til at filtrere sådanne anmodninger i tap0 på hver router, men det viste sig, at iptables ikke kan fungere med en enhed, hvis den er en del af en bro, så jeg var nødt til at bruge ebtables. Desværre inkluderede min firmware det ikke, så jeg var nødt til at genopbygge billederne for hver enhed. Efter at have gjort dette og tilføjet følgende linjer til /etc/rc.local på hver router, blev 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 konfiguration varede i tre år.
Del 2: Lær at kende WireGuard
På det seneste har der været stigende snak på internettet om WireGuard... og beundrer dens nemme konfiguration, høje overførselshastighed, lave ping med sammenlignelig sikkerhed. En søgning efter yderligere information om den afslørede, at den hverken understøtter bridge member- eller TCP-protokolunderstøttelse, hvilket fik mig til at tro, at der ikke var nogen alternativer. OpenVPN for mig er den der stadig ikke. Så jeg udsatte at lære at kende WireGuard.
For et par dage siden spredte nyheder sig gennem ressourcer relateret til IT på den ene eller anden måde, at WireGuard vil endelig blive inkluderet i kernen Linux, startende med version 5.6. Nyhedsartikler blev som altid rost WireGuardJeg kastede mig endnu engang ud i at søge efter måder at erstatte det gode gamle på OpenVPNDenne gang stødte jeg på . Det talte om at skabe en Ethernet-tunnel over L3 ved hjælp af GRE. Denne artikel gav mig håb. Det forblev uklart, hvad man skulle gøre med UDP-protokollen. Søgning førte mig til artikler om at bruge socat i forbindelse med en SSH-tunnel til at videresende en UDP-port, men de bemærkede, at denne tilgang kun virker i enkeltforbindelsestilstand, hvilket betyder, at flere VPN-klienter ville være umulige. Jeg fik ideen til at opsætte en VPN-server på en VPS, og konfigurere GRE til klienter, men som det viste sig, understøtter GRE ikke kryptering, hvilket vil føre til, at hvis tredjeparter får adgang til serveren, al trafik mellem mine netværk er i deres hænder, hvilket slet ikke passede mig.
Igen blev beslutningen truffet til fordel for redundant kryptering ved at bruge VPN over VPN i henhold til følgende skema:
Layer 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
Layer XNUMX 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 på 192.168.31.2
MK3 er klient MS med adressen 192.168.30.2 og har en intern IP på 192.168.31.3
* MS - router-server i lejlighed 1, MK2 - router i lejlighed 2, MK3 - router i lejlighed 3
* Enhedskonfigurationer er offentliggjort i spoileren i slutningen af artiklen.
Og så, ping mellem noderne på netværket 192.168.31.0/24 go, er det tid til at gå videre til opsætning af GRE-tunnelen. Inden da, for ikke at miste adgangen til routere, er det værd at opsætte SSH-tunneler til at videresende port 22 til VPS'en, så der f.eks. vil være en router fra lejlighed 10022 tilgængelig på port 2 i VPS'en, og en router fra lejlighed 11122 vil være tilgængelig på port 3 i VPS routeren fra lejlighed XNUMX. Det er bedst at konfigurere videresendelsen med den samme sshtunnel, da den vil genoprette tunnelen, hvis den falder.
Tunnelen er konfigureret, du kan oprette forbindelse til SSH gennem den videresendte port:
ssh root@МОЙ_VPS -p 10022Dernæst skal du deaktivere OpenVPN:
/etc/init.d/openvpn stopLad os nu opsætte en GRE-tunnel på routeren fra lejlighed 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Og tilføj den oprettede grænseflade til broen:
brctl addif br-lan grelan0
Lad os udføre en lignende procedure på serverrouteren:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Og føj også den oprettede grænseflade til broen:
brctl addif br-lan grelan0
fra dette øjeblik begynder pings med succes at gå til det nye netværk, og jeg går med tilfredshed for at drikke kaffe. Derefter, for at se, hvordan netværket i den anden ende af ledningen fungerer, prøver jeg at SSH ind i en af computerne i lejlighed 2, men ssh-klienten fryser uden at bede mig om en adgangskode. Jeg forsøger at oprette forbindelse til denne computer via telnet på port 22 og ser en linje, hvorfra du kan forstå, at forbindelsen er ved at blive etableret, SSH-serveren svarer, men af en eller anden grund tilbyder den mig ikke at komme ind.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Jeg prøver at oprette forbindelse til den via VNC, og jeg ser en sort skærm. Jeg overbeviser mig selv om, at sagen ligger i fjerncomputeren, fordi jeg nemt kan oprette forbindelse til routeren fra denne lejlighed ved hjælp af den interne adresse. Jeg beslutter mig dog for at SSH ind på denne computer gennem routeren og er overrasket over at opdage, at forbindelsen lykkes, og fjerncomputeren fungerer fint, men heller ikke kan oprette forbindelse til min computer.
Jeg tager grelan0-enheden ud af broen og kører den OpenVPN På routeren i lejlighed 2 bekræftede jeg, at netværket fungerede korrekt igen, og at forbindelserne ikke faldt fra hinanden. Ved at søge stødte jeg på fora, hvor folk klagede over de samme problemer, og hvor de blev rådet til at hæve MTU'en. Så snart det var sagt, var det gjort. Men indtil MTU'en var sat højt nok – 7000 for gretap-enheder – oplevede jeg enten tabte TCP-forbindelser eller lave overførselshastigheder. På grund af den høje MTU for gretap, var MTU'en for forbindelser... WireGuard Det første og andet niveau blev sat til henholdsvis 8000 og 7500.
Jeg lavede en lignende opsætning på routeren fra lejlighed 3, med den eneste forskel, at der blev tilføjet et andet gretap-interface ved navn grelan1 til serverrouteren, som også blev tilføjet til br-lan-broen.
Alt fungerer. Nu kan du sætte gretap-samlingen i autoload. For det:
Placerede disse linjer i /etc/rc.local på routeren i lejlighed 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
Føjede dette til /etc/rc.local på routeren i lejlighed 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å serverrouteren:
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
Efter at have genstartet klientrouterne, opdagede jeg, at de af en eller anden grund ikke oprettede forbindelse til serveren. Efter at have oprettet forbindelse til deres SSH (heldigvis havde jeg tidligere konfigureret sshtunnel til dette), opdagede jeg, at WireGuard Af en eller anden grund opretter den en rute til slutpunktet, men den er forkert. For eksempel, for 192.168.30.2, specificerede rutetabellen en rute gennem pppoe-wan-grænsefladen, dvs. via internettet, selvom ruten til den skulle have været dirigeret via wg0-grænsefladen. Efter sletning af denne rute blev forbindelsen gendannet. Kan jeg finde instruktioner et sted om, hvordan man tvinger WireGuard Jeg kunne ikke undgå at oprette disse ruter. Desuden forstod jeg ikke engang, om dette var en funktion i OpenWRT eller i WireGuardUden at bruge meget tid på at finde ud af problemet, tilføjede jeg simpelthen en linje til timer-loop-scriptet på begge routere, der slettede denne rute:
route del 192.168.30.2
Sammenfatter
Fuldstændig afvisning OpenVPN Jeg har ikke opnået dette endnu, da jeg af og til har brug for at oprette forbindelse til et nyt netværk fra en bærbar computer eller telefon, og det er generelt umuligt at sætte en gretap-enhed op på dem. Men på trods af dette har jeg opnået en fordel i dataoverførselshastigheden mellem lejligheder, og det er nu problemfrit at bruge f.eks. VNC. Ping er faldet en smule, men er blevet mere stabil:
Ved brug af 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 brug af 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
Det er for det meste påvirket af høj ping til VPS, som er cirka 61.5 ms
Hastigheden er dog steget betydeligt. Så i lejligheden med router-server har jeg en internetforbindelseshastighed på 30 Mbps, og i de andre lejligheder er den 5 Mbps. Desuden under brug OpenVPN Jeg kunne ikke opnå en dataoverførselshastighed mellem netværk på over 3,8 Mbps ifølge iperf-aflæsninger, mens WireGuard "pumpede" den op til de samme 5 Mbit/sek.
Konfiguration WireGuard på VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer]
Offentlignøgle = <VPN_1_MS_PUBLIC_KEY>
TilladteIPs = 192.168.30.2/32
[Peer]
Offentlig nøgle = <VPN_2_MK2_PUBLIC_KEY>
TilladteIPs = 192.168.30.3/32
[Peer]
Offentlig nøgle = <VPN_2_MK3_PUBLIC_KEY>
TilladteIPs = 192.168.30.4/32
Konfiguration WireGuard på MS (tilføjet til /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'
Konfiguration WireGuard på MK2 (tilføjet til /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'
Konfiguration WireGuard på MK3 (tilføjet til /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 konfigurationer for VPN på andet niveau angiver jeg til klienter WireGuard Port 51821. Dette burde ikke være nødvendigt, da klienten vil etablere en forbindelse fra enhver ledig, uprivilegeret port, men jeg gjorde det på denne måde, så jeg kunne afvise alle indgående forbindelser på wg0-grænsefladerne på alle routere, undtagen indgående UDP-forbindelser til port 51821.
Jeg håber, at artiklen vil være nyttig for nogen.
PS Jeg vil også dele mit script, der sender mig en PUSH-meddelelse til min telefon i WirePusher-applikationen, når en ny enhed dukker op på mit netværk. Her er et link til scriptet: .
UPDATE: Konfiguration 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 brugte easy-rsa til at generere certifikater.
Kilde: www.habr.com
