Aș dori să împărtășesc experiența mea de a combina rețele în trei apartamente îndepărtate geografic, fiecare dintre ele utilizând routere cu OpenWRT ca gateway, într-o singură rețea comună. La alegerea unei metode de combinare a rețelelor între L3 cu rutare subrețea și L2 cu punte, când toate nodurile de rețea vor fi în aceeași subrețea, s-a acordat preferință celei de-a doua metode, care este mai dificil de configurat, dar oferă oportunități mai mari, deoarece utilizarea transparentă a tehnologiilor a fost planificată în rețeaua fiind creată Wake-on-Lan și DLNA.
Partea 1: Context
Protocolul ales pentru implementarea acestei sarcini a fost inițial OpenVPN, deoarece, în primul rând, poate crea un dispozitiv de conectare care poate fi adăugat la punte fără probleme și, în al doilea rând, OpenVPN Acceptă TCP, ceea ce a fost, de asemenea, important, deoarece niciunul dintre apartamente nu avea o adresă IP dedicată. Nu am putut folosi STUN deoarece ISP-ul meu, dintr-un anumit motiv, blochează conexiunile UDP primite din rețelele sale. TCP mi-a permis să redirecționez portul serverului VPN către VPS-ul închiriat folosind SSH. Deși această abordare creează o suprasarcină semnificativă, deoarece datele sunt criptate dublu, nu am vrut să integrez VPS-ul în rețeaua mea privată, deoarece exista riscul ca terțe părți să preia controlul asupra acestuia. Prin urmare, a avea un astfel de dispozitiv în rețeaua mea de acasă era extrem de nedorit, așa că am decis să plătesc o suprasarcină semnificativă pentru securitate.
Pentru a redirecționa portul de pe routerul unde urma să fie instalat serverul, am folosit programul sshtunnel. Nu voi intra în detaliile configurației sale - este destul de simplă. Voi menționa doar că scopul său era de a redirecționa portul TCP 1194 de la router la VPS. Apoi, am configurat serverul. OpenVPN Pe dispozitivul tap0, care era conectat la bridge-ul br-lan. După testarea conexiunii la serverul nou creat de pe laptopul meu, a devenit clar că ideea de redirecționare a porturilor funcționase, iar laptopul meu devenise membru al rețelei routerului, chiar dacă nu făcea parte fizic din aceasta.
Singurul lucru care mai rămânea de făcut era să distribuim adresele IP în apartamente diferite, astfel încât să nu intre în conflict și să configurez routerele ca OpenVPN-clienți.
Au fost selectate următoarele adrese IP ale routerului și intervale de server DHCP:
- 192.168.10.1 cu raza de actiune 192.168.10.2 - 192.168.10.80 pentru server
- 192.168.10.100 cu raza de actiune 192.168.10.101 - 192.168.10.149 pentru routerul din apartamentul nr. 2
- 192.168.10.150 cu raza de actiune 192.168.10.151 - 192.168.10.199 pentru routerul din apartamentul nr. 3
De asemenea, a fost necesară atribuirea acestor adrese routerelor client. OpenVPN-server, adăugând următoarea linie la configurația sa:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0și adăugând următoarele linii în fișierul /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
unde flat1_id și flat2_id sunt numele dispozitivelor specificate la crearea certificatelor pentru conectarea la OpenVPN
În continuare, routerele au fost configurate OpenVPN- clienți, dispozitivele tap0 de pe ambele au fost adăugate la bridge-ul br-lan. În acest moment, totul părea în regulă, deoarece toate cele trei rețele se puteau vedea reciproc și funcționa ca o singură unitate. Cu toate acestea, a apărut un detaliu destul de neplăcut: uneori dispozitivele primeau o adresă IP de la routerul greșit, cu toate consecințele care decurg din acesta. Din anumite motive, routerul dintr-unul dintre apartamente nu a răspuns la DHCPDISCOVER la timp, iar dispozitivul a primit adresa greșită. Mi-am dat seama că trebuie să filtrez astfel de solicitări în tap0 pe fiecare router, dar, după cum s-a dovedit, iptables nu poate funcționa cu un dispozitiv dacă face parte dintr-un bridge, așa că a trebuit să utilizez ebtables. Din păcate, firmware-ul meu nu îl includea, așa că a trebuit să reconstruiesc imaginile pentru fiecare dispozitiv. După ce am făcut acest lucru și am adăugat următoarele linii la /etc/rc.local pe fiecare router, problema a fost rezolvată:
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
Această configurație a durat trei ani.
Partea a 2-a: Cunoașterea WireGuard
În ultima vreme, pe internet se vorbește din ce în ce mai mult despre WireGuard, admirând ușurința configurației, viteza mare de transfer, ping-ul scăzut și securitatea comparabilă. O căutare de informații suplimentare despre acesta a relevat că nu acceptă nici protocolul bridge member, nici protocolul TCP, ceea ce m-a făcut să cred că nu există alternativă. OpenVPN pentru mine încă nu este acolo. Așa că am amânat să cunosc WireGuard.
Acum câteva zile, s-au răspândit știri prin intermediul resurselor legate de IT, într-un fel sau altul, că WireGuard va fi în final inclus în kernel Linux, începând cu versiunea 5.6. Articolele de știri, ca întotdeauna, au fost lăudate WireGuardM-am cufundat din nou în căutarea unor modalități de a înlocui bunul și vechiul OpenVPNDe data aceasta am dat peste . Se vorbea despre crearea unui tunel Ethernet peste L3 folosind GRE. Acest articol mi-a dat speranță. A rămas neclar ce să facă cu protocolul UDP. Căutarea m-a condus la articole despre utilizarea socat împreună cu un tunel SSH pentru a redirecționa un port UDP, totuși, ei au observat că această abordare funcționează doar în modul de conexiune unică, adică munca mai multor clienți VPN ar fi imposibilă. Mi-a venit ideea de a instala un server VPN pe un VPS și de a configura GRE pentru clienți, dar după cum s-a dovedit, GRE nu acceptă criptarea, ceea ce va duce la faptul că, dacă terții vor obține acces la server , tot traficul dintre rețelele mele va fi în mâinile lor , ceea ce nu mi se potrivea deloc.
Încă o dată, decizia a fost luată în favoarea criptării redundante, prin utilizarea VPN peste VPN folosind următoarea schemă:
VPN de nivel XNUMX:
VPS este Server cu adresa internă 192.168.30.1
MS este client VPS cu adresa internă 192.168.30.2
МК2 este client VPS cu adresa internă 192.168.30.3
МК3 este client VPS cu adresa internă 192.168.30.4
VPN de al doilea nivel:
MS este Server cu adresa externă 192.168.30.2 și internă 192.168.31.1
МК2 este client MS cu adresa 192.168.30.2 și are un IP intern 192.168.31.2
МК3 este client MS cu adresa 192.168.30.2 și are un IP intern 192.168.31.3
* MS — router-server în apartamentul 1, МК2 - router în apartamentul 2, МК3 - router in apartamentul 3
* Configurațiile dispozitivului sunt publicate în spoilerul de la sfârșitul articolului.
Și astfel, ping-urile rulează între nodurile de rețea 192.168.31.0/24, este timpul să trecem la configurarea unui tunel GRE. Înainte de aceasta, pentru a nu pierde accesul la routere, merită să configurați tuneluri SSH pentru a transmite portul 22 către VPS, astfel încât, de exemplu, routerul din apartamentul 10022 să fie accesibil pe portul 2 al VPS-ului, iar routerul din apartamentul 11122 va fi accesibil pe portul 3 routerul din apartamentul XNUMX. Cel mai bine este să configurați redirecționarea folosind același sshtunnel, deoarece va restabili tunelul dacă nu reușește.
Tunelul este configurat, vă puteți conecta la SSH prin portul redirecționat:
ssh root@МОЙ_VPS -p 10022În continuare, ar trebui să dezactivați OpenVPN:
/etc/init.d/openvpn stopAcum să instalăm un tunel GRE pe routerul din apartamentul 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
Și adăugați interfața creată la punte:
brctl addif br-lan grelan0
Să efectuăm o procedură similară pe routerul serverului:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
Și adăugați, de asemenea, interfața creată la punte:
brctl addif br-lan grelan0
incepand din acest moment, ping-urile incep sa mearga cu succes in noua retea si eu, cu satisfactie, merg sa beau cafea. Apoi, pentru a evalua modul în care funcționează rețeaua la celălalt capăt al liniei, încerc să fac SSH într-unul dintre computerele din apartamentul 2, dar clientul ssh se blochează fără a cere o parolă. Încerc să mă conectez la acest computer prin telnet pe portul 22 și văd o linie de la care pot înțelege că se stabilește conexiunea, serverul SSH răspunde, dar din anumite motive pur și simplu nu mă solicită să mă înregistrez în.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Încerc să mă conectez la el prin VNC și văd un ecran negru. Mă conving că problema este la computerul de la distanță, pentru că mă pot conecta cu ușurință la router din acest apartament folosind adresa internă. Cu toate acestea, decid să mă conectez la SSH-ul acestui computer prin router și sunt surprins să constat că conexiunea este reușită, iar computerul de la distanță funcționează destul de normal, dar nici nu se poate conecta la computerul meu.
Scot dispozitivul grelan0 din bridge și îl rulez. OpenVPN Pe routerul din apartamentul 2, am confirmat că rețeaua funcționa din nou corect și că conexiunile nu se întrerupeau. Căutând, am dat peste forumuri unde oamenii se plângeau de aceleași probleme și unde li se recomanda să crească MTU-ul. Zis și făcut. Cu toate acestea, până când MTU-ul nu a fost setat suficient de mare - 7000 pentru dispozitivele gretap - am experimentat fie pierderi de conexiuni TCP, fie viteze de transfer scăzute. Din cauza MTU-ului mare pentru gretap, MTU-ul pentru conexiuni... WireGuard Primul și al doilea nivel au fost stabilite la 8000, respectiv 7500.
Am efectuat o configurare similară pe routerul din apartamentul 3, singura diferență fiind că la router-ul serverului a fost adăugată o a doua interfață gretap numită grelan1, care a fost adăugată și la podul br-lan.
Totul merge. Acum puteți pune ansamblul gretap la pornire. Pentru aceasta:
Am plasat aceste linii în /etc/rc.local pe routerul din apartamentul 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
Am adăugat acest lucru la /etc/rc.local pe routerul din apartamentul 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
Și pe routerul serverului:
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
După ce am repornit routerele client, am descoperit că, dintr-un anumit motiv, acestea nu se conectau la server. După ce m-am conectat la SSH-ul lor (din fericire, configurasem anterior sshtunnel-ul pentru asta), am descoperit că WireGuard Din anumite motive, creează o rută pentru punctul final, dar este incorectă. De exemplu, pentru 192.168.30.2, tabela de rutare a specificat o rută prin interfața pppoe-wan, adică prin internet, deși ruta către aceasta ar fi trebuit să fie direcționată prin interfața wg0. După ștergerea acestei rute, conexiunea a fost restabilită. Pot găsi instrucțiuni undeva despre cum să forțez... WireGuard Nu am putut evita crearea acestor rute. Mai mult, nici măcar nu am înțeles dacă aceasta era o caracteristică a OpenWRT sau a WireGuardFără a pierde mult timp încercând să rezolv problema, am adăugat pur și simplu o linie la scriptul timer-loop de pe ambele routere care a șters această rută:
route del 192.168.30.2
Rezumând
Respingere completă OpenVPN Nu am reușit încă acest lucru, deoarece ocazional trebuie să mă conectez la o rețea nouă de pe un laptop sau telefon, iar configurarea unui dispozitiv gretap pe acestea este în general imposibilă. Cu toate acestea, în ciuda acestui fapt, am obținut un avantaj în ceea ce privește viteza de transfer de date între apartamente, iar utilizarea VNC, de exemplu, este acum fără probleme. Ping-ul a scăzut ușor, dar a devenit mai stabil:
Când utilizați 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
Când utilizați 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
Este mai afectat de ping-ul ridicat la VPS, care este de aproximativ 61.5 ms
Totuși, viteza a crescut semnificativ. Așadar, în apartamentul cu router-server, am o viteză de conexiune la internet de 30 Mbps, iar în celelalte apartamente este de 5 Mbps. Mai mult, în timpul utilizării... OpenVPN Nu am reușit să ating o viteză de transfer de date între rețele mai mare de 3,8 Mbps conform citirilor iperf, în timp ce WireGuard l-a „pompat” până la aceiași 5 Mbit/sec.
configurație WireGuard pe VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>
[Peer]
CheiePublică = <VPN_1_MS_CHEIE_PUBLICĂ>
AllowedIPs = 192.168.30.2/32
[Peer]
CheiePublică = <VPN_2_MK2_CHEIE_PUBLICĂ>
AllowedIPs = 192.168.30.3/32
[Peer]
CheiePublică = <VPN_2_MK3_CHEIE_PUBLICĂ>
AllowedIPs = 192.168.30.4/32
configurație WireGuard pe MS (adăugat la /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'
configurație WireGuard pe MK2 (adăugat la /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'
configurație WireGuard pe MK3 (adăugat la /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'
În configurațiile descrise pentru VPN-ul de nivel doi, le indic clienților WireGuard Portul 51821. Acest lucru nu ar trebui să fie necesar, deoarece clientul va stabili o conexiune de pe orice port liber, neprivilegiat, dar am procedat astfel pentru a putea refuza toate conexiunile primite pe interfețele wg0 ale tuturor routerelor, cu excepția conexiunilor UDP primite către portul 51821.
Sper ca articolul sa fie de folos cuiva.
PS De asemenea, vreau să partajez scriptul meu care îmi trimite o notificare PUSH către telefonul meu în aplicația WirePusher atunci când apare un dispozitiv nou în rețeaua mea. Iată link-ul către script: .
ACTUALIZAȚI: configurație OpenVPN-servere și clienți
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- clientul
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 Am folosit easy-rsa pentru a genera certificate
Sursa: www.habr.com
