Rád by som sa podelil o svoje skúsenosti z kombinovania sietí v troch geograficky vzdialených apartmánoch, z ktorých každý používa routery OpenWRT ako bránu, do jednej spoločnej siete. Pri výbere spôsobu kombinovania sietí medzi L3 so smerovaním podsiete a L2 s premostením, keď všetky uzly siete budú v rovnakej podsieti, bola uprednostnená druhá metóda, ktorá je náročnejšia na konfiguráciu, ale poskytuje väčšie možnosti, pretože vo vytváranej sieti Wake-on-Lan a DLNA sa plánovalo transparentné využitie technológií.
Časť 1: Pozadie
OpenVPN bol pôvodne vybraný ako protokol na implementáciu tejto úlohy, pretože po prvé dokáže vytvoriť odpichové zariadenie, ktoré sa dá bez problémov pridať do mosta, a po druhé, OpenVPN podporuje prevádzku cez protokol TCP, čo bolo tiež dôležité, pretože žiadne bytov mal vyhradenú IP adresu a nemohol som použiť STUN, pretože môj poskytovateľ z nejakého dôvodu blokuje prichádzajúce UDP pripojenia z ich sietí, zatiaľ čo protokol TCP mi umožnil preposlať port servera VPN na prenajaté VPS pomocou SSH. Áno, tento prístup spôsobuje veľké zaťaženie, pretože údaje sú šifrované dvakrát, ale nechcel som zaviesť VPS do mojej súkromnej siete, pretože stále existovalo riziko, že nad ním získajú kontrolu tretie strany, a preto mať takéto zariadenie na mojej domácej sieti bolo mimoriadne nežiaduce a bolo rozhodnuté platiť za bezpečnosť veľkou réžiou.
Na presmerovanie portu na smerovači, na ktorom bolo plánované nasadenie servera, bol použitý program sshtunnel. Nebudem popisovať zložitosť jeho konfigurácie - robí sa to celkom jednoducho, len poznamenám, že jeho úlohou bolo presmerovať port TCP 1194 zo smerovača do VPS. Ďalej bol server OpenVPN nakonfigurovaný na zariadení tap0, ktoré bolo pripojené k mostu br-lan. Po skontrolovaní pripojenia k novovytvorenému serveru z prenosného počítača sa ukázalo, že myšlienka presmerovania portov bola opodstatnená a môj prenosný počítač sa stal členom siete smerovača, hoci v nej fyzicky nebol.
Zostávala už len jedna maličkosť: bolo potrebné rozdeliť IP adresy do rôznych bytov tak, aby nekolidovali a nakonfigurovať routery ako OpenVPN klientov.
Boli vybraté nasledujúce adresy IP smerovača a rozsahy serverov DHCP:
- 192.168.10.1 s rozsahom 192.168.10.2 - 192.168.10.80 pre server
- 192.168.10.100 s rozsahom 192.168.10.101 - 192.168.10.149 pre router v byte č.2
- 192.168.10.150 s rozsahom 192.168.10.151 - 192.168.10.199 pre router v byte č.3
Presne tieto adresy bolo potrebné priradiť aj klientskym smerovačom servera OpenVPN pridaním riadku do jeho konfigurácie:
ifconfig-pool-persist /etc/openvpn/ipp.txt 0a pridaním nasledujúcich riadkov do súboru /etc/openvpn/ipp.txt:
flat1_id 192.168.10.100
flat2_id 192.168.10.150
kde flat1_id a flat2_id sú názvy zariadení zadané pri vytváraní certifikátov na pripojenie k OpenVPN
Ďalej boli klienti OpenVPN nakonfigurovaní na smerovačoch, zariadenia tap0 na oboch boli pridané do mosta br-lan. V tejto fáze sa zdalo byť všetko v poriadku, pretože všetky tri siete sa navzájom videli a fungovali ako jedna. Objavil sa však nie veľmi príjemný detail: niekedy zariadenia mohli dostať IP adresu nie zo svojho routera, so všetkými z toho vyplývajúcimi dôsledkami. Router v jednom z bytov z nejakého dôvodu nestihol zareagovať na DHCPDISCOVER včas a zariadenie dostalo adresu, ktorá nebola určená. Uvedomil som si, že takéto požiadavky potrebujem filtrovať v tap0 na každom z routerov, no ako sa ukázalo, iptables nedokážu spolupracovať so zariadením, ak je súčasťou mosta a na pomoc mi musia prísť ebtables. Na moje poľutovanie to nebolo v mojom firmvéri a musel som znova zostaviť obrázky pre každé zariadenie. Týmto a pridaním týchto riadkov do /etc/rc.local každého smerovača bol problém vyriešený:
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
Táto konfigurácia trvala tri roky.
Časť 2: Predstavenie WireGuard
V poslednej dobe sa medzi ľuďmi na internete čoraz častejšie hovorí o WireGuard, obdivujúc jednoduchosť jeho konfigurácie, vysokú prenosovú rýchlosť, nízky ping pri porovnateľnej bezpečnosti. Hľadanie ďalších informácií o ňom ukázalo, že to nepodporuje ani prácu ako člen mosta, ani prácu cez protokol TCP, čo ma prinútilo myslieť si, že pre mňa stále neexistujú žiadne alternatívy k OpenVPN. Zoznámenie sa s WireGuardom som teda odložil.
Pred niekoľkými dňami sa medzi zdrojmi tak či onak rozšírili správy súvisiace s IT, že WireGuard bude konečne zahrnutý do linuxového jadra, počnúc verziou 5.6. Spravodajské články, ako vždy, chválili WireGuard. Opäť som sa vrhol do hľadania spôsobov, ako nahradiť staré dobré OpenVPN. Tentokrát som narazil . Hovorilo sa o vytvorení ethernetového tunela cez L3 pomocou GRE. Tento článok mi dal nádej. Zostalo nejasné, čo robiť s protokolom UDP. Hľadanie ma priviedlo k článkom o používaní socat v spojení s tunelom SSH na presmerovanie portu UDP, poznamenali však, že tento prístup funguje iba v režime jedného pripojenia, to znamená, že práca niekoľkých klientov VPN by bola nemožná. Prišiel som s myšlienkou nainštalovať server VPN na VPS a nastaviť GRE pre klientov, ale ako sa ukázalo, GRE nepodporuje šifrovanie, čo povedie k tomu, že ak tretie strany získajú prístup k serveru , všetka prevádzka medzi mojimi sieťami bude v ich rukách, čo mi vôbec nevyhovovalo.
Opäť bolo prijaté rozhodnutie v prospech redundantného šifrovania pomocou VPN cez VPN podľa nasledujúcej schémy:
VPN úrovne XNUMX:
VPS je server s internou adresou 192.168.30.1
MS je zákazník VPS s internou adresou 192.168.30.2
MK2 je zákazník VPS s internou adresou 192.168.30.3
MK3 je zákazník VPS s internou adresou 192.168.30.4
VPN druhej úrovne:
MS je server s externou adresou 192.168.30.2 a internou 192.168.31.1
MK2 je zákazník MS s adresou 192.168.30.2 a má interné IP 192.168.31.2
MK3 je zákazník MS s adresou 192.168.30.2 a má interné IP 192.168.31.3
* MS — router-server v apartmáne 1, MK2 - router v apartmáne 2, MK3 - router v byte 3
* Konfigurácie zariadení sú zverejnené v spojleri na konci článku.
A tak medzi sieťovými uzlami 192.168.31.0/24 prebiehajú pingy, je čas prejsť k nastaveniu tunela GRE. Predtým, aby ste nestratili prístup k routerom, stojí za to nastaviť SSH tunely na presmerovanie portu 22 do VPS, takže napríklad router z bytu 10022 bude prístupný na porte 2 VPS a router z bytu 11122 bude prístupný na porte 3 router z bytu XNUMX. Najlepšie je nakonfigurovať presmerovanie pomocou rovnakého tunela ssh, pretože v prípade zlyhania tunel obnoví.
Tunel je nakonfigurovaný, môžete sa pripojiť k SSH cez presmerovaný port:
ssh root@МОЙ_VPS -p 10022Ďalej by ste mali vypnúť OpenVPN:
/etc/init.d/openvpn stopTeraz nastavíme GRE tunel na smerovači z bytu 2:
ip link add grelan0 type gretap remote 192.168.31.1 local 192.168.31.2
ip link set grelan0 up
A pridajte vytvorené rozhranie do mosta:
brctl addif br-lan grelan0
Vykonajte podobný postup na smerovači servera:
ip link add grelan0 type gretap remote 192.168.31.2 local 192.168.31.1
ip link set grelan0 up
A tiež pridajte vytvorené rozhranie do mosta:
brctl addif br-lan grelan0
od tohto momentu začínajú pingy úspešne chodiť do novej siete a ja spokojne idem piť kávu. Potom, aby som zhodnotil, ako sieť funguje na druhom konci linky, skúsim pripojiť SSH do jedného z počítačov v byte 2, ale klient ssh zamrzne bez výzvy na zadanie hesla. Pokúšam sa pripojiť k tomuto počítaču cez telnet na porte 22 a vidím riadok, z ktorého môžem pochopiť, že sa vytvára spojenie, SSH server odpovedá, ale z nejakého dôvodu ma jednoducho nevyzve na prihlásenie v.
$ telnet 192.168.10.110 22
SSH-2.0-OpenSSH_8.1
Skúšam sa k nemu pripojiť cez VNC a vidím čiernu obrazovku. Presviedčam sám seba, že problém je vo vzdialenom počítači, pretože z tohto bytu sa môžem jednoducho pripojiť k routeru pomocou internej adresy. Rozhodol som sa však pripojiť k SSH tohto počítača cez smerovač a s prekvapením zistím, že pripojenie je úspešné a vzdialený počítač funguje úplne normálne, ale tiež sa nemôže pripojiť k môjmu počítaču.
Odstránim zariadenie grelan0 z mosta a spustím OpenVPN na smerovači v byte 2 a uistím sa, že sieť opäť funguje podľa očakávania a že pripojenia nie sú prerušené. Vyhľadávaním narážam na fóra, kde sa ľudia sťažujú na rovnaké problémy, kde sa im odporúča zvýšiť MTU. Len čo sa povie, tak urobí. Kým však nebolo MTU nastavené dostatočne vysoko – 7000 pre zariadenia gretap, boli pozorované buď prerušené TCP spojenia alebo nízke prenosové rýchlosti. Kvôli vysokej MTU pre gretap boli MTU pre pripojenia Layer 8000 a Layer 7500 WireGuard nastavené na XNUMX a XNUMX.
Podobné nastavenie som vykonal na routeri z bytu 3, len s tým rozdielom, že do serverového routera bolo pridané druhé rozhranie gretap s názvom grelan1, ktoré bolo tiež pridané do br-lan bridge.
Všetko funguje. Teraz môžete zostavu gretap spustiť. Pre to:
Tieto riadky som umiestnil do /etc/rc.local na router v byte 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
Pridané do /etc/rc.local na smerovači v apartmáne 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
A na smerovači servera:
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
Po reštarte klientskych smerovačov som zistil, že sa z nejakého dôvodu nepripájajú k serveru. Po pripojení k ich SSH (našťastie som na to predtým nakonfiguroval sshtunnel) sa zistilo, že WireGuard z nejakého dôvodu vytvára trasu pre koncový bod, ale bolo to nesprávne. Takže pre 192.168.30.2 smerovacia tabuľka uvádzala cestu cez rozhranie pppoe-wan, teda cez internet, hoci cesta k nej mala byť smerovaná cez rozhranie wg0. Po odstránení tejto trasy sa spojenie obnovilo. Nikde sa mi nepodarilo nájsť návod, ako prinútiť WireGuard, aby tieto trasy nevytváral. Navyše som ani nerozumel, či to bola funkcia samotného OpenWRT alebo WireGuard. Bez toho, aby som sa s týmto problémom dlho zaoberal, som jednoducho pridal do oboch smerovačov riadok v časovom skripte, ktorý túto trasu vymazal:
route del 192.168.30.2
Zhrnieme
Ešte som nedosiahol úplné opustenie OpenVPN, pretože sa niekedy potrebujem pripojiť k novej sieti z notebooku alebo telefónu a nastaviť na nich zariadenie gretap je vo všeobecnosti nemožné, ale napriek tomu som získal výhodu v rýchlosti prenosu dát medzi bytmi a napríklad používanie VNC už nie je nepohodlné. Ping sa mierne znížil, ale stal sa stabilnejším:
Pri používaní 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
Pri používaní 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
Viac ho ovplyvňuje vysoký ping na VPS, ktorý je približne 61.5 ms
Rýchlosť sa však výrazne zvýšila. Takže v byte so serverovým routerom mám rýchlosť internetového pripojenia 30 Mbit/s a v ostatných bytoch je to 5 Mbit/s. Zároveň sa mi pri používaní OpenVPN nepodarilo dosiahnuť rýchlosť prenosu dát medzi sieťami vyššiu ako 3,8 Mbit/sec podľa údajov iperf, pričom WireGuard ju „posilnil“ na rovnakých 5 Mbit/s.
Konfigurácia WireGuard na 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
Konfigurácia WireGuard na MS (pridaná do /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'
Konfigurácia WireGuard na MK2 (pridaná do /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'
Konfigurácia WireGuard na MK3 (pridaná do /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'
V popísaných konfiguráciách pre VPN druhej úrovne nasmerujem klientov WireGuard na port 51821. Teoreticky to nie je potrebné, keďže klient nadviaže spojenie z akéhokoľvek voľného neprivilegovaného portu, ale urobil som to tak, aby bolo možné zakázať všetky prichádzajúce pripojenia na rozhraniach wg0 všetkých smerovačov okrem prichádzajúcich pripojení UDP na port 51821.
Dúfam, že článok bude pre niekoho užitočný.
PS Tiež sa chcem podeliť o svoj skript, ktorý mi v aplikácii WirePusher posiela PUSH upozornenie na môj telefón, keď sa v mojej sieti objaví nové zariadenie. Tu je odkaz na skript: .
UPDATE: Konfigurácia OpenVPN servera a klientov
Server OpenVPN
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-lzoKlient OpenVPN
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
Na generovanie certifikátov som použil easy-rsa
Zdroj: hab.com