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
Die protokol wat gekies is om hierdie taak te implementeer, was aanvanklik OpenVPN, want eerstens kan dit 'n taptoestel skep wat sonder probleme by die brug gevoeg kan word, en tweedens, OpenVPN Dit ondersteun TCP, wat ook belangrik was, aangesien geeneen van die woonstelle 'n toegewyde IP-adres gehad het nie. Ek kon nie STUN gebruik nie, want my internetdiensverskaffer (ISP) blokkeer om een of ander rede inkomende UDP-verbindings vanaf sy netwerke. TCP het my toegelaat om die VPN-bedienerpoort na die gehuurde VPS aan te stuur deur SSH te gebruik. Alhoewel hierdie benadering 'n aansienlike oorhoofse koste skep, aangesien die data dubbel geïnkripteer is, wou ek nie die VPS in my privaat netwerk integreer nie, aangesien daar 'n risiko was dat derde partye beheer daaroor sou kry. Daarom was dit hoogs ongewens om so 'n toestel op my tuisnetwerk te hê, so ek het besluit om 'n aansienlike oorhoofse koste vir sekuriteit te betaal.
Om die poort op die router aan te stuur waar die bediener beplan was om ontplooi te word, het ek die sshtunnel-program gebruik. Ek sal nie in die besonderhede van die konfigurasie daarvan ingaan nie – dis redelik maklik. Ek sal net daarop let dat die doel daarvan was om TCP-poort 1194 van die router na die VPS aan te stuur. Volgende het ek die bediener gekonfigureer. OpenVPN Op die tap0-toestel, wat aan die br-lan-brug gekoppel was. Nadat ek die verbinding met die nuutgeskepte bediener vanaf my skootrekenaar getoets het, het dit duidelik geword dat die idee van poortaanstuur gewerk het, en my skootrekenaar het 'n lid van die router se netwerk geword, al was dit nie fisies deel daarvan nie.
Die enigste ding wat oorgebly het, was om IP-adresse in verskillende woonstelle te versprei sodat hulle nie sou bots nie en die routers as sodanig te konfigureer. OpenVPN-kliënte.
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 hierdie adresse aan die kliëntrouters toe te ken. OpenVPN-bediener, deur die volgende reël by die konfigurasie 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 geskep word vir verbinding met OpenVPN
Volgende is die routers gekonfigureer OpenVPN- kliënte, tap0-toestelle op beide is by die br-lan-brug gevoeg. Op hierdie stadium het alles goed gelyk, aangesien al drie netwerke mekaar kon sien en as 'n enkele eenheid kon funksioneer. 'n Nogal onaangename detail het egter na vore gekom: soms sou toestelle 'n IP-adres van die verkeerde router ontvang, met al die gevolglike gevolge. Om die een of ander rede het die router in een van die woonstelle nie betyds op DHCPDISCOVER gereageer nie, en die toestel het die verkeerde adres ontvang. Ek het besef ek moes sulke versoeke in tap0 op elke router filter, maar soos dit geblyk het, kan iptables nie met 'n toestel werk as dit deel van 'n brug is nie, so ek moes ebtables gebruik. Ongelukkig het my firmware dit nie ingesluit nie, so ek moes die beelde vir elke toestel herbou. Nadat ek dit gedoen het en die volgende lyne by /etc/rc.local op elke router gevoeg het, 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: Leer ken WireGuard
Daar is die afgelope tyd toenemend gepraat op die internet oor WireGuard, en bewonder die gemak van konfigurasie, hoë oordragspoed, lae ping en vergelykbare sekuriteit. 'n Soektog na bykomende inligting daaroor het aan die lig gebring dat dit nie bruglid- of TCP-protokolondersteuning ondersteun nie, wat my laat glo het dat daar geen alternatief was nie. OpenVPN vir my is dit steeds nie daar nie. So ek het uitgestel om te leer ken WireGuard.
'n Paar dae gelede het nuus op een of ander manier deur hulpbronne met betrekking tot IT versprei dat WireGuard sal uiteindelik in die kern ingesluit word Linux, beginnende met weergawe 5.6. Nuusartikels, soos altyd, is geprys WireGuardEk het weer eens gesoek na maniere om die goeie oue te vervang OpenVPNHierdie keer het ek vasgeloop . 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 10022Volgende moet jy deaktiveer 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 laat dit loop OpenVPN Op die router in woonstel 2 het ek bevestig dat die netwerk weer behoorlik werk en dat verbindings nie val nie. Deur te soek, het ek op forums afgekom waar mense oor dieselfde probleme gekla het, en waar hulle aangeraai is om die MTU te verhoog. Sodra dit gesê is, is dit gedaan. Totdat die MTU egter hoog genoeg gestel was – 7000 vir gretap-toestelle – het ek óf TCP-verbindings wat verloor het óf lae oordragspoed ervaar. As gevolg van die hoë MTU vir gretap, is die MTU vir verbindings... WireGuard Die eerste en tweede vlakke is onderskeidelik op 8000 en 7500 vasgestel.
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ëntroeters herbegin het, het ek ontdek dat hulle om een of ander rede nie aan die bediener kon koppel nie. Nadat ek aan hul SSH gekoppel het (gelukkig het ek voorheen sshtunnel hiervoor gekonfigureer), het ek ontdek dat WireGuard Om die een of ander rede skep dit 'n roete vir die eindpunt, maar dit is verkeerd. Byvoorbeeld, vir 192.168.30.2 het die roetetabel 'n roete deur die pppoe-wan-koppelvlak gespesifiseer, d.w.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. Kan ek enige plek instruksies vind oor hoe om dit te forseer? WireGuard Ek kon nie vermy om hierdie roetes te skep nie. Boonop het ek nie eers verstaan of dit 'n kenmerk van OpenWRT of van die ... was nie. WireGuardSonder om veel tyd te spandeer om die probleem uit te vind, het ek eenvoudig 'n reël bygevoeg tot die timer-gebaseerde skrip op beide routers wat hierdie roete uitgevee het:
route del 192.168.30.2
Opsomming
Volledige verwerping OpenVPN Ek het dit nog nie 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 gretap-toestel daarop op te stel. Ten spyte hiervan het ek egter 'n voordeel in data-oordragspoed tussen woonstelle gekry, en die gebruik van VNC, byvoorbeeld, is nou moeitevry. Ping het effens afgeneem, maar het meer stabiel geword:
As u gebruik 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
As u gebruik 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
Dit word meestal beïnvloed deur hoë ping na VPS wat ongeveer 61.5ms is
Die spoed het egter aansienlik toegeneem. So, in die woonstel met die router-bediener, het ek 'n internetverbindingspoed van 30 Mbps, en in die ander woonstelle is dit 5 Mbps. Boonop, tydens gebruik OpenVPN Ek kon nie 'n data-oordragspoed tussen netwerke van groter as 3,8 Mbps volgens iperf-lesings behaal nie, terwyl WireGuard het dit "opgepomp" na dieselfde 5 Mbit/sek.
opset WireGuard op VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Eweknie]
PubliekeSleutel = <VPN_1_MS_PUBLIC_KEY>
Toegelate IP's = 192.168.30.2/32
[Eweknie]
PubliekeSleutel = <VPN_2_MK2_PUBLIC_SLEUTEL>
Toegelate IP's = 192.168.30.3/32
[Eweknie]
PubliekeSleutel = <VPN_2_MK3_PUBLIC_SLEUTEL>
Toegelate IP's = 192.168.30.4/32
opset WireGuard op MS (bygevoeg tot /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'
opset WireGuard op MK2 (bygevoeg tot /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'
opset WireGuard op MK3 (bygevoeg tot /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 beskrewe konfigurasies vir die tweede vlak VPN, dui ek aan kliënte WireGuard Poort 51821. Dit behoort nie nodig te wees nie, aangesien die kliënt 'n verbinding vanaf enige vrye, onbevoorregte poort sal vestig, maar ek het dit so gedoen sodat ek alle inkomende verbindings op die wg0-koppelvlakke van alle routers kon weier, behalwe vir inkomende UDP-verbindings na 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: opset OpenVPN-bedieners en kliënte
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
