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
OpenVPN blev oprindeligt valgt som protokollen til at implementere denne opgave, da den for det første kan skabe en tapenhed, der kan tilføjes til broen uden problemer, og for det andet understøtter OpenVPN drift over TCP-protokollen, hvilket også var vigtigt, fordi ingen af lejlighederne havde en dedikeret IP-adresse, og jeg kunne ikke bruge STUN, fordi min internetudbyder af en eller anden grund blokerer indgående UDP-forbindelser fra deres netværk, mens TCP-protokollen tillod mig at videresende VPN-serverporten på lejet VPS ved hjælp af SSH. Ja, denne tilgang giver en stor belastning, da dataene er krypteret to gange, men jeg ønskede ikke at introducere VPS'en i mit private netværk, da der stadig var en risiko for, at tredjeparter fik kontrol over det, og derfor havde en sådan en enhed på hjemmenetværket var yderst uønsket, og det blev besluttet at betale for sikkerheden med en stor overhead.
For at videresende porten på routeren, som det var planlagt at installere serveren på, blev sshtunnel-programmet brugt. Jeg vil ikke beskrive forviklingerne i dens konfiguration - dette gøres ret nemt, jeg bemærker bare, at dens opgave var at videresende TCP-port 1194 fra routeren til VPS'en. Dernæst blev OpenVPN-serveren konfigureret på tap0-enheden, som var forbundet til br-lan-broen. Efter at have kontrolleret forbindelsen til den nyoprettede server fra den bærbare computer, blev det klart, at ideen om portvideresendelse retfærdiggjorde sig selv, og min bærbare computer blev medlem af routerens netværk, selvom den ikke var fysisk i den.
Sagen forblev lille: det var nødvendigt at distribuere IP-adresser i forskellige lejligheder, så de ikke kom i konflikt og konfigurerede routere 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 præcis disse adresser til klientrouterne på OpenVPN-serveren ved at tilføje linjen 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 enhedsnavnene, der er angivet ved generering af certifikater til forbindelse til OpenVPN
Dernæst blev OpenVPN-klienter konfigureret på routerne, tap0-enhederne på begge blev tilføjet til br-lan-broen. På dette tidspunkt så alt ud til at være i orden, da alle tre netværk ser hinanden og fungerer som en helhed. En ikke særlig behagelig detalje viste sig dog: Nogle gange kunne enheder få en IP-adresse, der ikke var fra deres router, med alle de deraf følgende konsekvenser. Af en eller anden grund havde routeren i en af lejlighederne ikke tid til at svare på DHCPDISCOVER i tide, og enheden modtog den forkerte adresse. Jeg indså, at jeg er nødt til at filtrere sådanne anmodninger i tap0 på hver af routerne, men som det viste sig, kan iptables ikke fungere med en enhed, hvis den er en del af en bro, og ebtables skulle komme mig til undsætning. Til min beklagelse var det ikke i min firmware, og jeg var nødt til at genopbygge billederne for hver enhed. Ved at gøre dette og tilføje disse linjer til /etc/rc.local for 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: Introduktion af WireGuard
For nylig har internettet i stigende grad talt om WireGuard og beundret enkelheden i dens konfiguration, høj overførselshastighed, lav ping med sammenlignelig sikkerhed. At søge efter mere information om det gjorde det klart, at hverken arbejde som bromedlem eller arbejde over TCP-protokollen understøttes af det, hvilket fik mig til at tro, at der stadig ikke er nogen alternativer til OpenVPN for mig. Så jeg udskyde at lære WireGuard at kende.
For et par dage siden spredte nyheden sig gennem ressourcer på den ene eller anden måde relateret til IT, at WireGuard endelig vil blive inkluderet i Linux-kernen, startende med version 5.6. Nyhedsartikler roste som altid WireGuard. Jeg kastede mig igen ud i søgen efter måder at erstatte den gode gamle OpenVPN på. Denne gang løb jeg ind i . 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 10022Deaktiver derefter 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 starter OpenVPN på routeren i lejlighed 2 og sørger for, at netværket fungerer korrekt igen, og at forbindelserne ikke falder. Søger jeg støder på fora, hvor folk klager over de samme problemer, hvor de rådes til at hæve MTU. Ikke før sagt end gjort. Indtil MTU'en blev indstillet til en tilstrækkelig stor værdi på 7000 for gretap-enheder, blev enten tabte TCP-forbindelser eller langsomme transmissioner observeret. På grund af den høje MTU for gretap blev MTU'erne for WireGuard-forbindelser på første og andet niveau 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 genstart af klientrouterne fandt jeg ud af, at de af en eller anden grund ikke oprettede forbindelse til serveren. Ved at forbinde til deres SSH (heldigvis havde jeg tidligere konfigureret sshtunnel til dette), blev det opdaget, at WireGuard af en eller anden grund opretter en rute for endepunktet, mens det er forkert. Så for 192.168.30.2 blev rutetabellen specificeret i rutetabellen gennem pppoe-wan-grænsefladen, det vil sige gennem internettet, selvom ruten til den skulle have været dirigeret gennem wg0-grænsefladen. Efter sletning af denne rute blev forbindelsen genoprettet. Jeg kunne ikke finde instruktioner nogen steder om, hvordan man tvinger WireGuard til ikke at oprette disse ruter. Desuden forstod jeg ikke engang, om dette er en funktion af OpenWRT eller af WireGuard selv. Uden at skulle håndtere dette problem i lang tid, tilføjede jeg simpelthen til begge routere i et script, der blev sløjfet af en timer, en linje, der slettede denne rute:
route del 192.168.30.2
Sammenfatter
Jeg har endnu ikke opnået en fuldstændig afvisning af OpenVPN, da jeg nogle gange har brug for at oprette forbindelse til et nyt netværk fra en bærbar eller telefon, og det er generelt umuligt at konfigurere en gretap-enhed på dem, men på trods af dette fik jeg en fordel i dataoverførsel hastighed mellem lejligheder og for eksempel at bruge VNC er ikke længere ubelejligt. Ping faldt lidt, men blev mere stabilt:
Når du bruger 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
Når du bruger 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 markant. Så i en lejlighed med en router-server har jeg en internetforbindelseshastighed på 30 Mbps, og i andre lejligheder 5 Mbps. Samtidig kunne jeg, mens jeg brugte OpenVPN, ikke opnå en dataoverførselshastighed mellem netværk på mere end 3,8 Mbps ifølge iperf, mens WireGuard "pumpede" det op til de samme 5 Mbps.
WireGuard-konfiguration på 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
WireGuard-konfiguration 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'
WireGuard-konfiguration på MK2 (fø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'
WireGuard-konfiguration på MK3 (fø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 port 51821 til WireGuard-klienter. I teorien er dette ikke nødvendigt, da klienten vil etablere en forbindelse fra en hvilken som helst ledig ikke-privilegeret port, men jeg gjorde det sådan, at alle indgående forbindelser kan afvises på wg0-grænseflader på alle routere, undtagen indgående UDP-forbindelser på 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: OpenVPN server og klientkonfiguration
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