Ek wil graag my ervaring deel van die kombinasie van netwerke in drie geografies verafgeleë woonstelle, wat elkeen routers met OpenWRT as 'n poort gebruik, in een gemeenskaplike netwerk. By die keuse van 'n metode vir die kombinasie van netwerke tussen L3 met subnet roetering en L2 met oorbrugging, wanneer alle netwerk nodusse in dieselfde subnet sal wees, is voorkeur gegee aan die tweede metode, wat moeiliker is om te konfigureer, maar bied meer geleenthede, aangesien deursigtige gebruik van tegnologie is beplan in die geskep netwerk Wake-on-Lan en DLNA.
Deel 1: Agtergrond
OpenVPN is aanvanklik gekies as die protokol vir die implementering van hierdie taak, aangesien dit eerstens 'n kraantoestel kan skep wat sonder enige probleme by die brug gevoeg kan word, en tweedens ondersteun OpenVPN werking oor die TCP-protokol, wat ook belangrik was, want nie een van die woonstelle het 'n toegewyde IP-adres gehad nie, en ek kon nie STUN gebruik nie, want om een of ander rede blokkeer my ISP inkomende UDP-verbindings vanaf hul netwerke, terwyl die TCP-protokol my toegelaat het om die VPN-bedienerpoort op gehuurde VPS met SSH aan te stuur. Ja, hierdie benadering gee 'n groot las, aangesien die data twee keer geënkripteer word, maar ek wou nie die VPS in my private netwerk inbring nie, aangesien daar steeds 'n risiko bestaan dat derde partye beheer daaroor kry, dus so 'n toestel op die tuisnetwerk was uiters ongewens en daar is besluit betaal vir sekuriteit met 'n groot oorhoofse koste.
Om die poort op die roeteerder aan te stuur waarop beplan was om die bediener te ontplooi, is die sshtunnel-program gebruik. Ek sal nie die ingewikkeldhede van sy konfigurasie beskryf nie - dit word redelik maklik gedoen, ek let net op dat sy taak was om TCP-poort 1194 van die router na die VPS aan te stuur. Vervolgens is die OpenVPN-bediener op die tap0-toestel gekonfigureer, wat aan die br-lan-brug gekoppel is. Nadat u die verbinding met die nuutgeskepte bediener vanaf die skootrekenaar nagegaan het, het dit duidelik geword dat die idee van poortaanstuur homself regverdig en my skootrekenaar het 'n lid van die router se netwerk geword, hoewel dit nie fisies daarin was nie.
Die saak het klein gebly: dit was nodig om IP-adresse in verskillende woonstelle te versprei sodat hulle nie bots nie en routers as OpenVPN-kliënte konfigureer.
Die volgende router-IP-adresse en DHCP-bedienerreekse is gekies:
- 192.168.10.1 met reeks 192.168.10.2 - 192.168.10.80 vir die bediener
- 192.168.10.100 met reeks 192.168.10.101 - 192.168.10.149 vir 'n router in woonstel nr. 2
- 192.168.10.150 met reeks 192.168.10.151 - 192.168.10.199 vir 'n router in woonstel nr. 3
Dit was ook nodig om presies hierdie adresse aan die kliëntrouters van die OpenVPN-bediener toe te ken deur die lyn by die konfigurasie daarvan te voeg:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0en voeg die volgende reëls by die /etc/openvpn/ipp.txt-lêer:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
waar flat1_id en flat2_id die toestelname is wat gespesifiseer word wanneer sertifikate gegenereer word om aan OpenVPN te koppel
Vervolgens is OpenVPN-kliënte op die routers gekonfigureer, die tap0-toestelle op albei is by die br-lan-brug gevoeg. Op hierdie stadium het alles gelyk of dit in orde was, aangesien al drie netwerke mekaar sien en as 'n geheel werk. 'n Nie baie aangename detail het egter geblyk: soms kon toestelle 'n IP-adres kry wat nie van hul router af is nie, met al die gevolge daarvan. Om een of ander rede het die router in een van die woonstelle nie tyd gehad om betyds op DHCPDISCOVER te reageer nie en die toestel het die verkeerde adres ontvang. Ek het besef dat ek sulke versoeke in tap0 op elk van die routers moet filter, maar soos dit geblyk het, kan iptables nie met 'n toestel werk as dit deel van 'n brug is nie en ebtables moet tot my redding kom. Tot my spyt was dit nie in my firmware nie en ek moes die beelde vir elke toestel herbou. Deur dit te doen en hierdie lyne by /etc/rc.local van elke router te voeg, is die probleem opgelos:
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
Hierdie opset het vir drie jaar geduur.
Deel 2: Stel WireGuard bekend
Onlangs het die internet al hoe meer oor WireGuard gepraat en die eenvoud van sy konfigurasie, hoë oordragspoed, lae ping met vergelykbare sekuriteit bewonder. Soek na meer inligting daaroor het dit duidelik gemaak dat nie werk as 'n bruglid of werk oor die TCP-protokol daardeur ondersteun word nie, wat my laat dink het dat daar nog geen alternatiewe vir OpenVPN vir my is nie. Ek het dus uitgestel om WireGuard te leer ken.
'n Paar dae gelede het die nuus versprei deur middel van hulpbronne op een of ander manier wat verband hou met IT dat WireGuard uiteindelik by die Linux-kern ingesluit sal word, vanaf weergawe 5.6. Nuusartikels het WireGuard soos altyd geprys. Ek het weer gedompel in die soeke na maniere om die goeie ou OpenVPN te vervang. Hierdie keer het ek raakgeloop . Dit het gepraat oor die skep van 'n Ethernet-tonnel oor L3 met GRE. Hierdie artikel het my hoop gegee. Dit het onduidelik gebly wat om met die UDP-protokol te doen. Soektogte het my gelei na artikels oor die gebruik van socat in samewerking met 'n SSH-tonnel om 'n UDP-poort aan te stuur, maar hulle het opgemerk dat hierdie benadering slegs in enkelverbindingsmodus werk, wat beteken dat verskeie VPN-kliënte onmoontlik sou wees. Ek het met die idee vorendag gekom om 'n VPN-bediener op 'n VPS op te stel, en GRE vir kliënte op te stel, maar soos dit geblyk het, ondersteun GRE nie enkripsie nie, wat sal lei tot die feit dat indien derde partye toegang tot die bediener kry , alle verkeer tussen my netwerke is in hul hande wat my glad nie gepas het nie.
Weereens is die besluit ten gunste van oortollige enkripsie geneem deur VPN oor VPN te gebruik volgens die volgende skema:
Laag XNUMX VPN:
VPS is bediener met interne adres 192.168.30.1
MC is kliënt VPS met interne adres 192.168.30.2
MK2 is kliënt VPS met interne adres 192.168.30.3
MK3 is kliënt VPS met interne adres 192.168.30.4
Laag XNUMX VPN:
MC is bediener met eksterne adres 192.168.30.2 en interne 192.168.31.1
MK2 is kliënt MC met die adres 192.168.30.2 en het 'n interne IP van 192.168.31.2
MK3 is kliënt MC met die adres 192.168.30.2 en het 'n interne IP van 192.168.31.3
* MC - router-bediener in woonstel 1, MK2 - router in woonstel 2, MK3 - router in woonstel 3
* Toestelkonfigurasies word in die bederf aan die einde van die artikel gepubliseer.
En so, pings tussen die nodusse van die netwerk 192.168.31.0/24 gaan, is dit tyd om aan te beweeg na die opstel van die GRE-tonnel. Voor dit, om nie toegang tot roeteerders te verloor nie, is dit die moeite werd om SSH-tonnels op te stel om poort 22 na die VPS aan te stuur, sodat byvoorbeeld 'n roeteerder vanaf woonstel 10022 beskikbaar sal wees op poort 2 van die VPS, en 'n router vanaf woonstel 11122 sal beskikbaar wees op poort 3 van die VPS router vanaf woonstel XNUMX. Dit is die beste om die aanstuur met dieselfde sshtonnel te konfigureer, aangesien dit die tonnel sal herstel indien dit val.
Die tonnel is gekonfigureer, jy kan aan SSH koppel deur die aangestuurde poort:
ssh root@МОЙ_VPS -p 10022Deaktiveer dan OpenVPN:
/etc/init.d/openvpn stopKom ons stel nou 'n GRE-tonnel op die router vanaf woonstel 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
En voeg die geskepte koppelvlak by die brug:
brctl addif br-lan grelan0
Kom ons voer 'n soortgelyke prosedure op die bedienerroeteerder uit:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
En voeg ook die geskepte koppelvlak by die brug:
brctl addif br-lan grelan0
vanaf hierdie oomblik begin pings suksesvol na die nuwe netwerk gaan en ek, met tevredenheid, gaan drink koffie. Dan, om te sien hoe die netwerk aan die ander kant van die draad werk, probeer ek SSH in een van die rekenaars in woonstel 2, maar die ssh-kliënt vries sonder om my vir 'n wagwoord te vra. Ek probeer om aan hierdie rekenaar te koppel via telnet op poort 22 en sien 'n lyn vanwaar jy kan verstaan dat die verbinding tot stand gebring word, die SSH-bediener reageer, maar om een of ander rede bied dit my nie om in te gaan nie.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Ek probeer om dit te koppel via VNC en ek sien 'n swart skerm. Ek oortuig myself dat die saak in die afgeleë rekenaar is, want ek kan maklik met die interne adres vanaf hierdie woonstel aan die router koppel. Ek besluit egter om deur die router in hierdie rekenaar te SSH en is verbaas om te vind dat die verbinding slaag en die afgeleë rekenaar werk goed, maar kon ook nie aan my rekenaar koppel nie.
Ek haal die grelan0-toestel uit die brug en begin OpenVPN op die router in woonstel 2 en maak seker die netwerk werk weer reg en verbindings val nie. Soektog kom ek op forums af waar mense kla oor dieselfde probleme, waar hulle aangeraai word om die MTU te verhoog. Nie gou gesê as gedaan nie. Totdat die MTU egter op 'n groot genoeg waarde van 7000 gestel is vir gretap-toestelle, is óf gedaalde TCP-verbindings óf stadige uitsendings waargeneem. As gevolg van die hoë MTU vir gretap, is die MTU's vir WireGuard-verbindings van die eerste en tweede vlakke op onderskeidelik 8000 en 7500 gestel.
Ek het 'n soortgelyke opstelling op die router vanaf woonstel 3 gedoen, met die enigste verskil dat 'n tweede gretap-koppelvlak genaamd grelan1 by die bedienerroeteerder gevoeg is, wat ook by die br-lan-brug gevoeg is.
Alles werk. Nou kan jy die groottap-samestelling in outolaai plaas. Vir dit:
Het hierdie lyne in /etc/rc.local op die router in woonstel 2 geplaas:
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
Het dit bygevoeg by /etc/rc.local op die router in woonstel 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
En op die bediener router:
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
Nadat ek die kliëntrouters herlaai het, het ek gevind dat hulle om een of ander rede nie aan die bediener gekoppel het nie. Deur aan hul SSH te koppel (gelukkig het ek voorheen sshtunnel hiervoor gekonfigureer), is ontdek dat WireGuard om een of ander rede 'n roete vir die eindpunt skep, terwyl dit verkeerd is. Dus, vir 192.168.30.2, is die roetetabel in die roetetabel gespesifiseer deur die pppoe-wan-koppelvlak, dit wil sê deur die internet, alhoewel die roete daarheen deur die wg0-koppelvlak gerig moes gewees het. Nadat hierdie roete uitgevee is, is die verbinding herstel. Ek kon nêrens instruksies vind oor hoe om WireGuard te dwing om nie hierdie roetes te skep nie. Boonop het ek nie eers verstaan of dit 'n kenmerk van OpenWRT of van WireGuard self is nie. Sonder om hierdie probleem vir 'n lang tyd te hanteer, het ek eenvoudig by beide routers gevoeg in 'n skrip wat deur 'n timer gelus is, 'n reël wat hierdie roete uitgevee het:
route del 192.168.30.2
Opsomming
Ek het nog nie 'n volledige verwerping van OpenVPN bereik nie, aangesien ek soms vanaf 'n skootrekenaar of foon aan 'n nuwe netwerk moet koppel, en dit is oor die algemeen onmoontlik om 'n grootmaaktoestel op hulle op te stel, maar ten spyte hiervan het ek 'n voordeel in data-oordrag gekry spoed tussen woonstelle en, byvoorbeeld, die gebruik van VNC is nie meer ongerieflik nie. Ping het effens afgeneem, maar het meer stabiel geword:
Wanneer jy OpenVPN gebruik:
[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
Wanneer jy WireGuard gebruik:
[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
Dit word meestal beïnvloed deur hoë ping na VPS wat ongeveer 61.5ms is
Die spoed het egter aansienlik toegeneem. Dus, in 'n woonstel met 'n router-bediener, het ek 'n internetverbindingspoed van 30 Mbps, en in ander woonstelle, 5 Mbps. Terselfdertyd, terwyl ek OpenVPN gebruik het, kon ek volgens iperf nie 'n data-oordragtempo tussen netwerke van meer as 3,8 Mbps bereik nie, terwyl WireGuard dit tot dieselfde 5 Mbps "gepomp" het.
WireGuard-konfigurasie op 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-konfigurasie op MS (bygevoeg by /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-konfigurasie op MK2 (bygevoeg by /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-konfigurasie op MK3 (bygevoeg by /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'
In die beskryfde konfigurasies vir die tweede vlak VPN spesifiseer ek poort 51821 aan WireGuard-kliënte. In teorie is dit nie nodig nie, aangesien die kliënt 'n verbinding vanaf enige gratis nie-bevoorregte poort sal vestig, maar ek het dit so gemaak dat alle inkomende verbindings kan op die wg0-koppelvlakke van alle routers geweier word, behalwe inkomende UDP-verbindings op poort 51821.
Ek hoop dat die artikel vir iemand nuttig sal wees.
PS Ek wil ook my skrif deel wat vir my 'n PUSH-kennisgewing na my foon in die WirePusher-toepassing stuur wanneer 'n nuwe toestel op my netwerk verskyn. Hier is 'n skakel na die draaiboek: .
UPDATE: OpenVPN-bediener en kliënte-konfigurasie
OpenVPN-bediener
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 kliënt
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
Ek het easy-rsa gebruik om sertifikate te genereer.
Bron: will.com