ProHoster > Blog > Administrácia > Prechod z OpenVPN na WireGuard zlúčiť siete do jednej siete L2

Prechod z OpenVPN na WireGuard zlúčiť siete do jednej siete L2

Prechod z OpenVPN na WireGuard zlúčiť siete do jednej siete L2

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

Protokol zvolený na implementáciu tejto úlohy bol pôvodne OpenVPN, pretože po prvé, dokáže vytvoriť odpojovacie zariadenie, ktoré sa dá bez problémov pridať na mostík, a po druhé, OpenVPN Podporuje TCP, čo bolo tiež dôležité, pretože žiadny z bytov nemal vyhradenú IP adresu. Nemohol som použiť STUN, pretože môj poskytovateľ internetových služieb z nejakého dôvodu blokuje prichádzajúce UDP pripojenia zo svojich sietí. TCP mi umožnil presmerovať port VPN servera na prenajatý VPS pomocou SSH. Hoci tento prístup vytvára značné režijné náklady, pretože dáta sú dvojito šifrované, nechcel som integrovať VPS do svojej súkromnej siete, pretože existovalo riziko, že nad ním získajú kontrolu tretie strany. Preto bolo mať takéto zariadenie v mojej domácej sieti veľmi nežiaduce, a tak som sa rozhodol zaplatiť značné režijné náklady za zabezpečenie.

Na presmerovanie portu na routeri, kde mal byť server nasadený, som použil program sshtunnel. Nebudem zachádzať do detailov jeho konfigurácie – je to celkom jednoduché. Len poznamenám, že jeho účelom bolo presmerovať TCP port 1194 z routera na VPS. Ďalej som nakonfiguroval server. OpenVPN Na zariadení tap0, ktoré bolo pripojené k mostu br-lan. Po otestovaní pripojenia k novovytvorenému serveru z môjho notebooku sa ukázalo, že myšlienka presmerovania portov fungovala a môj notebook sa stal členom siete routera, aj keď fyzicky nebol jej súčasťou.

Zostávalo už len rozdeliť IP adresy do rôznych bytov, aby nekolidovali, a nakonfigurovať routery podľa OpenVPN-klienti.
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

Bolo tiež potrebné priradiť tieto adresy klientskym smerovačom. OpenVPN-server pridaním nasledujúceho riadku do jeho konfigurácie:

ifconfig-pool-persist /etc/openvpn/ipp.txt 0

a 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 nakonfigurované routery OpenVPN- klienti, zariadenia tap0 na oboch boli pridané do mosta br-lan. V tomto bode sa všetko zdalo v poriadku, pretože všetky tri siete sa navzájom videli a fungovali ako jeden celok. Objavil sa však dosť nepríjemný detail: niekedy zariadenia dostali IP adresu z nesprávneho routera so všetkými z toho vyplývajúcimi následkami. Z nejakého dôvodu router v jednom z bytov nereagoval včas na DHCPDISCOVER a zariadenie dostalo nesprávnu adresu. Uvedomil som si, že musím takéto požiadavky filtrovať v tap0 na každom routeri, ale ako sa ukázalo, iptables nemôže fungovať so zariadením, ak je súčasťou mosta, takže som musel použiť ebtables. Bohužiaľ, môj firmvér to neobsahoval, takže som musel pre každé zariadenie znova vytvoriť obrazy. Po vykonaní tohto kroku a pridaní nasledujúcich riadkov do /etc/rc.local na každom routeri 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: Zoznámenie sa WireGuard

V poslednej dobe sa na internete čoraz viac hovorí o WireGuard, obdivujúc jeho jednoduchú konfiguráciu, vysokú prenosovú rýchlosť, nízky ping a porovnateľné zabezpečenie. Vyhľadávanie ďalších informácií o ňom odhalilo, že nepodporuje ani mostíkový člen, ani protokol TCP, čo ma viedlo k presvedčeniu, že neexistuje žiadna alternatíva. OpenVPN pre mňa to stále nie je tam. Takže som odkladal spoznávanie WireGuard.

Pred pár dňami sa prostredníctvom zdrojov súvisiacich s IT rozšírila správa, že WireGuard bude konečne zahrnutý v jadre Linux, počnúc verziou 5.6. Novinové články boli ako vždy chválené WireGuardOpäť som sa ponoril do hľadania spôsobov, ako nahradiť staré dobré OpenVPNTentoraz som narazil na tento článok. 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 stop

Teraz 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.

Vyberiem zariadenie grelan0 z mostíka a spustím ho. OpenVPN Na routeri v byte 2 som potvrdil, že sieť opäť funguje správne a pripojenia sa nerozpadajú. Pri hľadaní som narazil na fóra, kde sa ľudia sťažovali na rovnaké problémy a kde im bolo odporúčané zvýšiť MTU. Čo sa stalo. Avšak, kým nebola hodnota MTU nastavená dostatočne vysoko – 7000 pre zariadenia gretap – zaznamenal som buď výpadky TCP pripojení, alebo nízke prenosové rýchlosti. Kvôli vysokej hodnote MTU pre gretap, MTU pre pripojenia... WireGuard Prvá a druhá úroveň boli stanovené na 8 000 a 7 500.

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 routerov som zistil, že z nejakého dôvodu sa nepripájajú k serveru. Po pripojení k ich SSH (našťastie som predtým na to nakonfiguroval sshtunnel) som zistil, že WireGuard Z nejakého dôvodu vytvorí trasu pre koncový bod, ale je nesprávna. Napríklad pre 192.168.30.2 smerovacia tabuľka špecifikovala trasu cez rozhranie pppoe-wan, t. j. cez internet, hoci trasa k nemu mala smerovať cez rozhranie wg0. Po odstránení tejto trasy sa pripojenie obnovilo. Môžem niekde nájsť návod, ako to vynútiť? WireGuard Nemohol som sa vyhnúť vytváraniu týchto trás. Navyše som ani nechápal, či je to vlastnosť OpenWRT alebo... WireGuardBez toho, aby som strávil veľa času zisťovaním problému, som jednoducho pridal riadok do skriptu založeného na časovači na oboch routeroch, ktorý túto trasu odstránil:

route del 192.168.30.2

Zhrnieme

Úplné odmietnutie OpenVPN Zatiaľ sa mi to nepodarilo, keďže sa občas potrebujem pripojiť k novej sieti z notebooku alebo telefónu a nastavenie zariadenia gretap na nich je vo všeobecnosti nemožné. Napriek tomu som však získal výhodu v rýchlosti prenosu dát medzi bytmi a napríklad používanie VNC je teraz bezproblémové. Ping sa mierne znížil, ale stal sa stabilnejším:

Pri použití 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žití 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 s routerom-serverom mám rýchlosť internetového pripojenia 30 Mbps a v ostatných bytoch je to 5 Mbps. Navyše, počas používania OpenVPN Podľa údajov iperf sa mi nepodarilo dosiahnuť rýchlosť prenosu dát medzi sieťami vyššiu ako 3,8 Mbps, zatiaľ čo WireGuard „napumpoval“ to na rovnakých 5 Mbit/s.

konfigurácia WireGuard na VPS[Interface]
Address = 192.168.30.1/24
ListenPort = 51820
PrivateKey = <ЗАКРЫТЫЙ_КЛЮЧ_ДЛЯ_VPS>

[Peer]
Verejný kľúč = <VPN_1_MS_PUBLIC_KEY>
Povolené IP = 192.168.30.2/32

[Peer]
VerejnýKľúč = <VPN_2_MK2_VEREJNÝ_KĽÚČ>
Povolené IP = 192.168.30.3/32

[Peer]
VerejnýKľúč = <VPN_2_MK3_VEREJNÝ_KĽÚČ>
Povolené IP = 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 opísaných konfiguráciách pre VPN druhej úrovne klientom uvádzam WireGuard Port 51821. Toto by nemalo byť potrebné, pretože klient nadviaže pripojenie z akéhokoľvek voľného, ​​neprivilegovaného portu, ale ja som to urobil takto, aby som mohol zakázať všetky prichádzajúce pripojenia na rozhraniach wg0 všetkých smerovačov, okrem prichádzajúcich UDP pripojení 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: github.com/r0ck3r/device_discover.

UPDATE: konfigurácia OpenVPN-servery a klienti

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-lzo

OpenVPN-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

Na generovanie certifikátov som použil easy-rsa

Zdroj: hab.com

Kúpte si spoľahlivý hosting pre stránky s DDoS ochranou, VPS VDS servery 🔥 Kúpte si spoľahlivý webhosting s ochranou DDoS, VPS VDS servery | ProHoster