Navigate back to the homepage

WireGuard — VPN, u ktorej mysleli na využitie v reálnych podmienkach

Nedávno som prešiel z OpenVPN na WireGuard. Tento projekt na mňa urobil obrovský dojem a v tomto príspevku vám poviem prečo.
Vladimír Záhradník
May 3rd, 2020 · 12 min read

V mojom poslednom príspevku som písal o tom, ako som nahradil môj domáci router za Raspberry Pi 4. Jedným z dôvodov bolo zvýšenie priepustnosti mojej VPN. O WireGuarde som uvažoval, odkedy som sa dopočul, že samotnému Linusovi Torvaldsovi sa veľmi páči.

Môžem ešte raz zdôrazniť moju lásku preňho a dúfať, že bude čoskoro začlenený? Možno, že kód nie je dokonalý, ale rýchlo som ho prebehol a porovnal s hrôzami, akými sú OpenVPN a IPSec a je to proste umelecké dielo. — Linus Torvalds

Avšak nevedel som ako WireGuard funguje, aké zložité je ho nastaviť a či je pre mňa vhodný. Tento projekt som mal vo svojom zozname aktivít aspoň pol roka. Pôvodne som plánoval použiť iný hardvér, keďže RPi 4 ešte ani nebolo oznámené. Pozitívom na celej dnešnej koronakríze je to, že sa mi zmenšilo pracovné vyťaženie a môžem venovať určitý čas projektom a experimentom. Pretože WireGuard vyzeral sľubne na použitie v iných projektoch, rozhodol som sa pochopiť ako funguje prečítaním jeho technického dokumentu.

Linus hovorí o riešeniach OpenVPN a IPSec ako o hrôzach a musím súhlasiť. V minulosti som používal obe VPN. U IPsec som dokonca čítal niektoré RFC dokumenty. Vo firme Alcatel-Lucent som pracoval na funkčnosti s názvom ePDG, ktorá umožňuje mobilným operátorom prenášať dáta z vášho mobilného telefónu na mobilnú bránu v datacentre prostredníctvom Internetu. Možno ste počuli o Voice-over-WiFi. V tejto technológii zaisťuje IPsec tunel medzi vašim telefónom a operátorom.

Predtým, než vysvetlím, ako WireGuard funguje, a poviem vám, čo sa mi na ňom páči, pozrime sa najprv na existujúce riešenia.


IPsec

IPsec je de-facto priemyselný štandard. Keď už rozbeháte tunel, výkon je, dá sa povedať, slušný. Návrh IPsec a jeho stavebné prvky sú úplne otvorené a môžete si ich bezplatne prečítať v kolekcii RFC dokumentov. Napísaný prevažne akademikmi, má dokonalé oddelenie vrstiev — napríklad, výmena kľúčov (IKEv2) je oddelená od zabezpečeného dátového prenosu (ESP). Nevýhodou je však to, že nastaviť tieto prvky je dosť zložité. V Linuxe to riešenia ako strongSwan trochu uľahčujú, ale nepovedal by som, že nastaviť IPsec je jednoduché.

Na IPsec sa mi páči, že ESP obsah je možné priamo zabaliť za IP časťou paketu. Je to preto, že ESP je registrovaný ako jeden z povolených protokolov, ktoré môžete nastaviť vo vnútri poľa “Next Header” v IP hlavičke. Ak vašu VPN nastavíte takto, znížite prevádzkovú réžiu. Avšak v dnešnom zaNATovanom svete, IPsec dáta sú väčšinou zapuzdrené vnútri UDP.

IPsec môže fungovať v dvoch režimoch — site-to-site, kde prepájate dve LAN siete alebo v režime RoadWarrior, ktorý sa používa, keď chcete pripojiť vaše zariadenie do firemnej siete. RoadWarrior neumožňuje (pokiaľ viem) prepojenie celých LAN sietí. Osobne si myslím, že nikto takýto scenár nepredpokladal. Takže musíte použiť čistý site-to-site režim a ten má mnoho nevýhod.

Plusy a mínusy site-to-site IPsec

  • ✔️ Slušný výkon VPN
  • ✔️ Menšia prevádzková réžia v čistom ESP režime
  • ❌ Je ťažké ho nastaviť
  • ❌ Konfigurácia je na oboch koncoch statická, s napevno zadanými IP adresami, pravidlami firewallu, trasami (routami) a ďalšími nastaveniami
  • ❌ Oba konce tunela vyžadujú verejnú statickú IP adresu
  • ❌ Oba konce vyžadujú výnimky vo firewalle pre konkrétne protokoly a čísla portov
  • ❌ IPsec neumožňuje isté porty zmeniť. Sú napevno “zadrôtované” v RFC štandarde
  • ❌ Je ťažké ho debugovať

V mojom prípade som nemal statické IP adresy, ale aspoň boli verejné. Jeden koniec tunela bol v Bratislave a ten druhý na druhom konci krajiny, v Chmiňanoch. Na oboch koncoch som používal routre od Mikrotiku. Zmena dynamickej IP adresy bola problém. Ak používate VPN ako OpenVPN, môžete namiesto IP adresy vášho rovesníka (peer) zadať názov domény. Preto môžete použiť dynamické DNS služby, ktoré sú integrované v mnohých spotrebných routroch od výroby. Avšak IPsec takýto scenár neočakáva a musíte nastaviť všetko. Skončil som tak, že som si napísal trochu komplikovaný skript, ktorý aktualizoval konfiguráciu na rozhraniach, pravidlá firewallu a mnoho ďalších záludností. Stále ho môžete nájsť v mojom repozitáre na GitHube. Takto mi IPsec fungoval a výkon bol v pohode. No jedného dňa som zmenil poskytovateľa Internetu, už som nemal verejnú IP adresu a musel som si nájsť iné riešenie, ako opäť prepojiť dva konce. Skončil som pri OpenVPN, ktorú Mikrotik RouterOS tiež podporoval.


OpenVPN

Toto riešenie má klasickú architektúru typu klient-server. OpenVPN server musíte spustiť na routri (alebo akomkoľvek zariadení), ktoré má dostupnú verejnú IP adresu. Druhý koniec môže byť za NATom s privátnou IP. Za predpokladu, že sa klient dokáže pripojiť k serveru, OpenVPN funguje bez problémov. Len čo klient iniciuje reláciu, po ceste sa dynamicky aplikujú NAT pravidlá, aby relácia ostala otvorená. Aby sme sa uistili, že NAT pravidlá zostanú aplikované, raz za čas klient pošle cez tunel tzv. keepalive paket. Keď sa dynamická IP adresa zmení, VPN spojenie sa na krátky čas preruší. Avšak klient sa zvyčajne pripája prostredníctvom názvu domény, ktorý je aktualizovaný na novú IP adresu servera, a preto sa spojenie znovu vytvorí.

Plusy a mínusy

  • ✔️ Dokáže premostiť dve LAN siete, aj keď má jeden z klientov privátnu IP adresu
  • ✔️ Podporuje prenos cez TCP a UDP
  • ✔️ Klient môže pristupovať k serveru prostredníctvom doménového záznamu v DNS
  • ✔️ Server môže voliteľne oznamovať iné trasy, ako napríklad jeho LAN sieť
  • ✔️ Klient môže mať vnútri OpenVPN statickú IP adresu. To sa hodí, keď chcete vytvoriť statickú trasu na LAN klienta
  • ❌ Je ťažké ho nastaviť, ale je to jednoduchšie ako u IPsec
  • ❌ Klient nemôže oznamovať svoje trasy. Server si musí vytvoriť statickú trasu mimo konfigurácie OpenVPN
  • ❌ Je ťažké ho debugovať
  • ❌ Slabý výkon. Priepustnosť je oveľa nižšia ako u IPsec
  • ❌ Bezpečnostné zraniteľnosti a kód, ktorý je ťažko auditovateľný výskumníkmi

Mikrotik používa vlastnú implementáciu OpenVPN, ktorá funguje iba prostredníctvom TCP. Ľudia neúspešne žiadajú o podporu UDP už roky. OpenVPN cez TCP je menej efektívne, pretože TCP vždy žiada o potvrdenie, že paket bol doručený. A nad týmto protokolom udržiava OpenVPN jeho vlastnú reláciu. Časom, keď som prešiel z RouterOS na OpenWrt, bola zmena tejto VPN, aby používala UDP, medzi prvými vecami v mojom zozname.

Hoci beží OpenVPN lepšie cez UDP, jeho výkon je stále slabý. Jedným z dôvodov je ten, že v Linuxe je OpenVPN implementovaný ako klient v používateľskom priestore. Keď OpenVPN vygeneruje paket, ten sa skopíruje niekoľkokrát, kým opustí rozhranie sieťovej karty. Taktiež OpenVPN nefunguje efektívne s mnohojadrovými procesormi.

Konfigurácia OpenVPN je oveľa priamočiarejšia ako nastavenie IPsec. Avšak stále to nie je jednoduché. Ľudia musia vedieť, ako vygenerovať OpenSSL kľúče, ideálne pomocou easy-rsa skriptov, ktoré sa dodávajú spolu s OpenVPN. Bezpečnosť v OpenVPN je taktiež problém. V minulosti našli výskumníci viacero zraniteľností v knižnici OpenSSL a aj v jadre knižnice OpenVPN. Kód je obrovský, čím sa audit a hľadanie chýb dosť komplikuje.


WireGuard

Na tomto mieste by som rád spomenul, že IPsec aj OpenVPN sú dosť staré protokoly. Časom našli ľudia v ich návrhoch nedostatky, ale nie je jednoduché, občas dokonca nemožné, opraviť podstatné chyby v návrhu. Autori WireGuardu si boli dobre vedomí problémov s IPsec a OpenVPN, ktoré sa vyskytovali v reálnych podmienkach, a napísali protokol, aby tieto problémy vyriešil.

WireGuard® je extrémne jednoduchá a pritom rýchla a moderná VPN, ktorá využíva najnovšie poznatky v kryptografii. Cieli na to, aby bol rýchlejší, jednoduchší, štíhlejší a užitočnejší ako IPsec, pričom sa snaží vyhýbať jeho masívnym bolestiam. Jeho cieľom je byť oveľa výkonnejší ako OpenVPN. — webová stránka WireGuardu

Keď som si prečítal ich technický dokument a mal som v hlave všetky tieto informácie, napísal som si hlavné body do odrážkového zoznamu. Pridám ho sem ako referenciu.

Plusy a mínusy

  • ✔️ Kód je jednoduchý. Ovládač v jadre má podľa jeho autorov menej ako 4 000 riadkov kódu
  • ✔️ Preto, že je jednoduchý, je jednoducho auditovateľný ohľadom bezpečnostných zraniteľností
  • ✔️ Jednoducho sa konfiguruje a používa
  • ✔️ Podporuje presúvanie sa klientov medzi sieťami bez straty VPN spojenia
  • ✔️ Používa najmodernejšiu kryptografiu
  • ✔️ Beží dobre na výkonných serveroch ako aj vstavaných routroch
  • ✔️ Veľmi vysoký výkon, porovnateľný s IPsec
  • ✔️ Podporuje linuxové kontajnery a umožňuje im získať prístup iba k VPN a to prostredníctvom menného priestoru Wireguardu
  • ✔️ Je k dispozícii na mnohých platformách, vrátane Androidu a iOS. Podpora pre WireGuard je aktívne pridávaná aj do starších linuxových jadier, čím sa rozširuje podpora ešte viac
  • ❌ Ovládač jadra je zatiaľ k dispozícii iba pre Linux. Ostatné platformy používajú klienta v používateľskom priestore, ktorý je napísaný v Go. Avšak podľa autorov je stále dosť výkonný

Pre tých technickejších čitateľov pridám ešte niekoľko plusov:

  • ✔️ Ovládač v linuxovom jadre nepoužíva Crypto API. Namiesto toho WireGuard reimplementuje niektoré funkcie napriamo, aby sa vyhol dynamickej alokácii pamäte
  • ✔️ WireGuard podporuje konfigurácie čisto iba so staticky alokovanou pamäťou
  • ✔️ Kryptografické kľúče sa jednoducho generujú dodaným nástrojom wg
  • ✔️ Implicitný utajený (stealth) režim. Štandardne posielajú rovesníci (peeri) vo WireGuarde iba, keď potrebujú a služba WireGuard neodpovedá na náhodné požiadavky bez správne vyplnených hlavičiek. Takže keď náhodný sieťový skener pošle požiadavku na port, na ktorom počúva WireGuard, nedostane naspäť žiadnu odpoveď a vôbec netuší, že tam beží nejaká VPN. Klienti za NATom môžu udržiavať VPNku v prevádzke pomocou voliteľného keepalive parametra. Štandardne je keepalive vypnutý
  • ✔️ Pretože WireGuard na Linux beží priamo v jadre a nie v používateľskom priestore, vnútorné pakety sa nekopírujú niekoľkokrát, kým opustia sieťovú kartu
  • ✔️ Na rozdiel od OpenVPN využíva WireGuard všetky jadra procesora efektívne
  • ✔️ Vrstva na výmenu kľúčov a transportná vrstva nie sú oddelené (na rozdiel od IPsec), aby bola implementácia a údržba pre sieťových inžiniérov jednoduchšia
  • ✔️ V Linuxe autori WireGuardu čiastočne integrovali jeho konfiguráciu do štandardných linuxových nástrojov ako ip. Pre zvyšnú funkčnosť poskytujú nástroj wg a časom plánujú integrovať všetku túto funkčnosť do štandardných nástrojov a úplne sa zbaviť tohto wg nástroja

Ako môžete vidieť, tento zoznam je dosť dlhý, a to sú len hlavné body, ktoré som dal dokopy. Kým vám poviem, ako jednoducho sa to nastavuje, vysvetlím vám ešte, čo je WireGuard rovesník (peer).

Každý je rovesník

Vo WireGuarde nie je žiadny vzťah typu klient-server. WireGuard zavádza koncept rovesníkov, čo sú navzájom prepojení klienti. A z definície nie je žiadny nadradený, ani podradený rovesník.

Aby ste zostavili spojenie, potrebujete zaistiť následovné:

  • Na každom rovesníkovi vytvoriť WireGuard rozhranie a priradiť mu IP adresu s nástrojom ip. Ide o adresu vnútri VPN siete, ktorá je navždy previazaná s rovesníkom
  • Na každom rovesníkovi vytvoriť privátny kľúč pomocou nástroja wg a priradiť ho WireGuard rozhraniu
  • Odvodiť verejný kľúč, opäť pomocou nástroja wg, a pridať ho u všetkých rovesníkov, s ktorými chcete komunikovať. WireGuard neurčuje, ako sa majú vymeniť kľúče. Ja som otvoril SSH na každom zariadení a ručne som ich skopíroval
  • Voliteľne, povedať každému rovesníkovi ako sa spojiť s tými ostatnými, zadaním verejnej IP adresy (alebo domény) a portu. Nie všetci rovesníci potrebujú vedieť ako sa spojiť s ostatnými. Stačí, že ostatní vedia, ako sa spojiť s nimi. Veď uvidíte neskôr

Generovanie kľúča pre rovesníka

Generovanie verejného a privátneho kľúča je priamočiaré. Uistite sa, že máte nainštalované WireGuard nástroje. Postup sa líši v závislosti od vášho systému. Najprv vygenerujte privátny kľúč:

1root@OpenWrt:~# wg genkey
2CKqTfzJBQgg4Vefi38IpBkzPUYUdJdneyZCf4bkBsm0=

Tento privátny kľúč potrebujete uložiť do súboru, na ktorý sa odkážete z WireGuard konfigurácie. Z tohto privátneho kľúča potrebujete odvodiť verejný kľúč a distribuovať ho ostatným rovesníkom:

1root@OpenWrt:~# echo "CKqTfzJBQgg4Vefi38IpBkzPUYUdJdneyZCf4bkBsm0=" | wg pubkey
2pKIHvamNAEpnH11czVMDDv/GD0ivVwp8Jwhp0qUH7UU=

Tieto kroky musíte zopakovať pre každého rovesníka vo vašej VPN sieti.

Prejdime si teraz spolu niekoľko scenárov a snáď lepšie pochopíte, ako to celé funguje.

Scenár č.1: Site-to-site VPN, kde majú obaja rovesníci verejnú IP adresu

V tomto prvom scenári navzájom prepájame dva routre.

Rovesník A:

  • LAN sieť: 10.0.0.0/24
  • VPN IP: 192.168.1.1/32
  • Verejná IP: 46.43.215.66 (alebo doména rovesnikjeden.priklad.sk)
  • WireGuard port: 1194 (použite akýkoľvek port len chcete, len ho nesmie blokovať váš poskytovateľ)

Rovesník B:

  • LAN sieť: 10.0.1.0/24
  • VPN IP: 192.168.1.2/32
  • Verejná IP: 12.35.181.48 (alebo doména rovesnikdva.priklad.sk)
  • WireGuard port: 1194
Scenár 1
Scenár 1: Site-to-site VPN

Najprv na každom rovesníkovi vytvorte WireGuard rozhranie:

Rovesník A:

1rovesnik A# ip link add dev wg0 type wireguard

Rovesník B:

1rovesnik B# ip link add dev wg0 type wireguard

Ďalej priraďte rozhraniu IP adresu. Slúži ako IP adresa rovesníka vnútri vašej VPN a nikdy sa nemení (samozrejme, pokiaľ to nespravíte vy).

Rovesník A:

1rovesnik A# ip address add dev wg0 192.168.1.1/32

Rovesník B:

1rovesnik B# ip address add dev wg0 192.168.1.2/32

Ďalej vygenerujte kľúče podľa postupu vyššie a priraďte ich rovesníkom.

Rovesník A:

1rovesnik A# wg genkey > private
2rovesnik A# cat private
3iFtTfEwI/+Bc0M2olXuytEVPU4TXhCDVGezFt7H8ylg=
4rovesnik A# wg pubkey < private
5AqyBazhsen/jzTJ0MzyyU16wOYovBPZ+DIu6x4rSH3Y=
6
7# Priradenie privátneho kľúča rozhraniu wg0
8rovesnik A# wg set wg0 private-key ./private

Rovesník B:

1rovesnik B# wg genkey > private
2rovesnik B# cat private
3uPBLlBHptZahFKaX9mSFmIgSNjAEd1kwB+MSAE+QVE0=
4rovesnik B# wg pubkey < private
5i8nniZCkTISUfaLMQ+FV0Sewvq0f68UrkLkeV0a4BnA=
6
7# Priradenie privátneho kľúča rozhraniu wg0
8rovesnik B# wg set wg0 private-key ./private

A u oboch rovesníkov povoľte rozhranie wg0:

Rovesník A:

1rovesnik A# ip link set wg0 up

Rovesník B:

1rovesnik B# ip link set wg0 up

V tejto fáze je WireGuard rozhranie nakonfigurované, ale rovesníci navzájom o sebe nevedia. Poďme to napraviť.

Rovesník A:

1rovesnik A# wg set wg0 peer i8nniZCkTISUfaLMQ+FV0Sewvq0f68UrkLkeV0a4BnA= allowed-ips 192.168.1.2/32,10.0.1.0/24 endpoint 12.35.181.48:1194

Rovesník B:

1rovesnik B# wg set wg0 peer AqyBazhsen/jzTJ0MzyyU16wOYovBPZ+DIu6x4rSH3Y= allowed-ips 192.168.1.1/32,10.0.0.0/24 endpoint 46.43.215.66:1194

Teraz je VPN nakonfigurovaná a rovesníci by mali vedieť spolu komunikovať.

Parameter peer je verejný kľúč rovesníka, s ktorým chcete začať komunikovať.

Parameter allowed-ips uvádza všetky siete, ktoré poskytuje druhý rovesník. V našom príklade uvádza IP adresu priradenú WireGuard rozhraniu a IP adresu siete LAN pripojenej k rovesníkovi. Máte plnú kontrolu nad tým, aké siete budete oznamovať ostatným, ale minimálne by ste sem mali uviesť IP adresu rovesníka.

Parameter endpoint vraví rovesníkovi, ako sa spojiť s druhým rovesníkom, a je voliteľný. Avšak, predstavte si situáciu, že ani u jedného rovesníka túto informáciu nezadáte. Ako sa navzájom spoja? Pravdou je, že sa nespoja. V každom scenári by mal mať aspoň jeden rovesník napevno zadanú cestu, ako sa spojiť s druhým rovesníkom. Predstavte si, že som nezadal koncový bod pre rovesníka A na rovesníkovi B. Preto, keď chce rovesník B poslať paket, dostanete chybu, ktorá vraví, že k rovesníkovi A neexistuje trasa. Ale ak chce rovesník A komunikovať s rovesníkom B, môže, pretože má zadaný jeho koncový bod. Hneď ako rovesník B príjme paket od rovesníka A, poznačí si jeho WAN IP adresu a od tejto chvíle môžu obaja komunikovať.

WireGuard udržiava virtuálnu smerovaciu tabuľku, v ktorej priradzuje verejný kľúč k IP adrese rovesníka:

Verejný kľúč rovesníkaPovolené zdrojové IP adresy
i8nniZCkTISUfaLMQ+FV0Sewvq0f68UrkLkeV0a4BnA=192.168.1.2/32,10.0.1.0/24

Táto tabuľka priradzuje verejný kľúč rovesníka k priradeným IP adresám. Predstavte si, že rovesník A chce poslať paket na zariadenie v LAN sieti za rovesníkom B (IP: 10.0.1.10). WireGuard sa pozrie do tejto tabuľky a nájde príslušný verejný kľúč (to znamená, že trasa existuje). Potom WireGuard paket zašifruje verejným kľúčom priradeným s cieľovou IP adresou a odošle paket na koncový bod rovesníka B. Na druhom konci VPN príjme rovesník B paket na WireGuard porte 1194. Potom sa ho pokúsi paket dešifrovať jeho privátnym kľúčom. Ak rovesník B uspeje, paket spracuje. V opačnom prípade ho WireGuard zahodí.

Verejný kľúč rovesníkaPovolené zdrojové IP adresy
AqyBazhsen/jzTJ0MzyyU16wOYovBPZ+DIu6x4rSH3Y=192.168.1.1/32,10.0.0.0/24

Keď chce počítač na IP adrese 10.0.1.0 odoslať odpoveď rovesníkovi A, uvedie IP adresu rovesníka A ako cieľovú adresu. Potom sa rovesník B pozrie do tabuľky, aby našiel príslušný verejný kľúč pre túto cieľovú adresu. Ak uspeje, zašifruje paket príslušným verejným kľúčom rovesníka A a paket odošle. Ten sa spracuje na inštancii WireGuardu na rovesníkovi A.

Scenár č.2: Dvaja rovesníci za NATom a jeden rovesník s verejnou IP

Tento scenár predstavuje typickú situáciu, keď máte routre za NATom a chcete zostaviť zabezpečenú VPN. V takom prípade musí mať aspoň jedno zariadenie verejnú IP adresu.

Rovesník A:

  • LAN sieť: 10.0.0.0/24
  • VPN IP: 192.168.1.1/32
  • Za NATom (nemá verejnú IP)

Rovesník B:

  • LAN sieť: 10.0.1.0/24
  • VPN IP: 192.168.1.2/32
  • Za NATom (nemá verejnú IP)

Rovesník C:

  • LAN sieť: 10.0.2.0/24
  • VPN IP: 192.168.1.3/32
  • Verejná IP: 12.35.181.48
  • WireGuard port: 1194
Scenár 2
Scenár 2: Site-to-site VPN s rovesníkmi za NATom

V tomto príklade sú rovesníci A a B za NATom. Nie je žiadny spôsob, ako by mohli spolu napriamo komunikovať. Avšak môžu si posielať dáta cez rovesníka C, s ktorým sa vedia spojiť obaja. Stále tu máme rovesníkov, ktorí sú si vo WireGuard terminológii “rovní”. Avšak tým, že nastavíme konfiguráciu tak, aby sa posielali dáta z rovesníka A na rovesníka B cez rovesníka C (a opačne), v podstate sme vytvorili architektúru klient-server. Rovesníci A a B sú klienti a všetky ich dáta idú cez rovesníka C. Obaja klienti, A aj B, majú definovaný koncový bod na rovesníka C. Nebudem sem dávať celú konfiguráciu, keďže som ju podrobne vysvetlil v predchádzajúcom scenári. Ale ukážem vám aspoň konfiguráciu pre rovesníka A.

1# Vytvorenie rozhrania
2rovesnik A# ip link add dev wg0 type wireguard
3rovesnik A# ip address add dev wg0 192.168.1.1/32
4
5# Vygenerovanie kľúča
6rovesnik A# wg genkey > private
7rovesnik A# cat private
8iFtTfEwI/+Bc0M2olXuytEVPU4TXhCDVGezFt7H8ylg=
9rovesnik A# wg pubkey < private
10AqyBazhsen/jzTJ0MzyyU16wOYovBPZ+DIu6x4rSH3Y=
11
12# Priradenie privátneho kľúča rozhraniu wg0
13rovesnik A# wg set wg0 private-key ./private
14
15# Povolenie rozhrania
16rovesnik A# ip link set wg0 up
17
18# Sem pridáme iba rovesníka C (rovesník B je dostupný cez rovesníka C)
19# Pridajte siete od rovesníka B aj C, ktoré chcete oznamovať ako
20# dostupné cez rovesníka C
21rovesnik A# wg set wg0 peer <verejný-kľúč-rovesníka-c> allowed-ips 192.168.1.2/32,192.168.1.3/32,10.0.1.0/24,10.0.2.0/24 endpoint 12.35.181.48:1194

Ak chce v tejto chvíli rovesník A poslať paket do LAN siete LAN 10.0.1.0/24 na rovesníkovi B, pozrie sa do tabuľky, vyhľadá pre cieľovú trasu príslušný verejný kľúč rovesníka C a pošle paket. Rovesník C má spojenie s rovesníkom B a paket mu prepošle. Aby sme sa uistili, že sú všetci rovesníci kedykoľvek dostupní, musíme nastaviť voliteľný parameter persistent-keepalive. NAT relácia sa zvyčajne uzavrie dosť rýchlo a keďže štandardne WireGuard posiela dáta iba vtedy, keď má čo poslať, spojenie medzi rovesníkom A a rovesníkom C, ako aj medzi rovesníkom B a rovesníkom B, sa uzavrie. Znovu sa zostaví vtedy, keď pošle rovesník dáta rovesníkovi C a rovesník B musí spraviť to isté. Aby sme ponechali NAT reláciu aktívnu pre oboch rovesníkov, môžeme nastaviť keepalive na rovesníkoch A a B, ktorí raz za 25 sekúnd pošlu rovesníkovi C paket (je to odporučená hodnota, dostatočne bezpečná, aby sme zabránili uzavretiu relácie). A teda, rovesník C môže komunikovať s oboma rovesníkmi kedykoľvek a preposielať ich dáta podľa potreby.

Zmeňme posledný riadok, kde pridávame informáciu o rovesníkovi C na rovesníkovi A. Všimnite si, že keepalive nastavujeme na 25 sekúnd:

1rovesnik A# wg set wg0 peer <verejný_kľúč> allowed-ips <siete> endpoint <koncový-bod-rovesníka-c> persistent-keepalive 25

Scenár č.3: RoadWarrior klienti pristupujúci k firemnej VPN

Nasledujúci scenár je dosť typický. Zamestnanec chce pristupovať k firemnej VPN s jeho firemným notebookom a telefónom, aby si prečítal nejaké dokumenty.

Scenár 3
Scenario 3: RoadWarrior klienti pristupujúci k firemnej VPN

V tomto prípade sú notebook aj telefón za NATom. Ich lokalita sa môže kedykoľvek zmeniť, ako aj ich IP adresy. “Klientskí” rovesníci nezdieľajú žiadne siete a chcú komunikovať iba so “serverovým” rovesníkom. Parameter persistent-keepalive nepotrebujeme, pretože firemný server nikdy nepotrebuje pripojenie k zariadeniu zamestnanca. Zvyčajne sa zamestnanec pripojí s WireGuard VPN iba vtedy, keď chce preniesť nejaké dáta a hneď potom sa odpojí. Aj keď je klientská aplikácia stále pripojená a NAT relácia sa preruší, počas najbližšieho dátového prenosu sa vytvorí nová NAT relácia a firemný server si poznačí aktualizovanú IP adresu a port. Všetko funguje tak ako má.

Toto nastavenie má jeden nedostatok. Pokiaľ viem, neexistuje spôsob ako dynamicky priradiť IP adresu klientovi vnútri VPN. Ako sa postupne nástroje vylepšujú, očakávam, že sa tento problém vyrieši.

Podpora v aplikáciách

WireGuard je podporovaný na mnohých platformách. Mimo Linuxu môžete použiť jeho aplikáciu napísanú v Go. Mnoho nástrojov ako systemd-networkd alebo NetworkManager pridalo natívnu podporu, vďaka čomu sa WireGuard používa ešte jednoduchšie. V mojom prípade som nastavoval WireGuard na OpenWrt routri. Ich grafické prostredie s názvom LuCI má pre WireGuard balík. Cez webové rozhranie routra môžete vytvárať rozhrania, ako aj pridávať rovesníkov. A pokiaľ rozumiete terminológii, nastaviť to je hračka.

WireGuard na LuCI
WireGuard vo webovom rozhraní LuCI

Priepustnosť

WireGuard používam vyše dvoch týždňov. Nemám presné dáta priepustnosti, pretože kvôli situácii ohľadom COVID-19 je Internet dosť vyťažený a moja rýchlosť počas dňa dosť kolíše. Avšak urobil som zopár rýchlych testov mimo špičky a výsledky boli ohromné.

Rýchlosť sťahovania môjho Internetu u rovesníka v Chmiňanoch je zhruba 100 Mbit/s. Vzdialený koniec má optické pripojenie s oveľa vyššími rýchlosťami sťahovania a nahrávania. Keď som skúsil kopírovať video z môjho vzdialeného servera, dostával som priepustnosť v rozsahu 70–80 Mbit/s. Skontroloval som tiež vyťaženie procesora v RPi a bola tam ešte rezerva.

Toto sú hrubé dáta len pre ilustráciu. Ak chcete vidieť aspoň nejaké porovnanie, pozrite si technický dokument, kde autori WireGuardu porovnávajú WireGuard, IPsec a OpenVPN. Rozdiel medzi OpenVPN a WireGuardom je enormný.


Záver

Verím, že má WireGuard jasnú budúcnosť a teším sa na vylepšenú podporu na existujúcich zariadeniach ako aj na pridanie podpory na tých nových. V časti o IPsec som stručne spomenul ePDG, ktoré beží v cloude u mobilného operátora a prenáša hlas cez IPsec. Aj keď štandard definuje pre transport IPsec, viem si predstaviť, že by sa časom nahradil za WireGuard a celkovo, že ho uvidíme v mnohých aplikáciách, kde IPsec roky dominoval.

More articles from Vladimír Záhradník

Raspberry Pi ako domáci router

Najnovšia generácia Raspberry Pi je už dostatočne výkonná, aby nám poslúžila ako slušný domáci router. Čo ma viedlo k rozhodnutiu použiť ho a aké sú moje skúsenosti?

April 17th, 2020 · 9 min read

Raspberry Pi as a home router

The latest generation of Raspberry Pi is powerful enough to serve as a decent home router. What leads to my decision to use it, and what's my experience?

April 17th, 2020 · 9 min read
© 2018–2020 Vladimír Záhradník
Link to $https://github.com/vzahradnikLink to $https://medium.com/@vladimir.zahradnikLink to $https://www.youtube.com/channel/UCogZ6qxqKa_WIsw7NnU2IaALink to $https://twitter.com/VladoZahradnikLink to $https://www.linkedin.com/in/vladimirzahradnikLink to $https://www.facebook.com/vzahradnikLink to $https://www.instagram.com/vladimir.zahradnik