Názory k článku WireGuard: moderní a snadno použitelná VPN v linuxovém jádře

Zaujimavy clanok, dakujem. Zaujimalo by ma, ci nie su tie pevne IP adresy klientov VPN obmedzujuce - co ak dopredu neviem z akej adresy sa do VPN pripajam (hotel, public hot-spot,...)? Alebo jednalo sa uz o pridelene adresy klienta (adresy vo vnutri VPN)? Ospravedlnujem sa, nejako som to z kontextu nepochopil.
Dalsia vec - ako su na tom klienti? Pozeral som na Android klienta, tam pisu, ze je zatial unstable...
Kazdopadne tesim sa na pokracovanie.

Pevně jsou přidělené adresy uvnitř sítě, tedy ty „virtuální“. Vím, že konkrétní uživatel má adresu 10.0.0.5, nikdy mi nebude data posílat z jiné a zároveň ji nemůže použít nikdo jiný.

Skutečně síťové adresy se konfigurují naopak velmi volně a nejsou dokonce v konfiguraci ani povinné. Jsou ale nutné pro první kontakt s protistranou. Obvykle se to tedy dělá tak, že se zvolí jeden bod, ten na začátku nezná skutečné IP adresy ostatních a slouží jako server. Ostatní znají jeho adresu, musí ho kontaktovat jako první a vystupují vlastně v roli klientů. I když tohle rozdělení formálně ve WireGuardu neexistuje.

Vdaka za odpoved - mam v tom trocha jasnejsie. Cize ak to mam zhrnut, obidve protistrany musia navzajom poznat svoje IP aby nadviazali komunikaciu a nasledne sa "dohodnu" na tom, ze IP niektorej z nich sa moze zmenit. Toto mi pripada trocha ako zbytocna komplikacia - ocakaval by som, ze to bude fungovat podobne ako napr. OpenVPN - poznam adresu servera a tomu je v principe jedno z akej IP sa klient pripoji za predpokladu ze ma spravne kluce.
Okrem toho, kedze ide cez UDP, zrejme bude aj problem s pripojenim spoza proxy serverov, takze momentalne to asi nebude uplne plnohodnotna alternativa k OpenVPN...
Kazdopadne tesim sa na pokracovanie - velmi rad si o tom precitam viac.

Ne, pořád to asi není jasné. Ona to ukáže dobře ta praktická část, ale pokusím se to objasnit ještě jednou a nějak lépe.

Když se konfiguruje WireGuard, musíme mu předat svůj místní pár klíčů. Kromě toho mu ale sdělujeme, s jakými protistranami se budeme spojovat. Každá protistrana má vždy svůj veřejný klíč, vždy pevnou adresu uvnitř VPN a pak volitelně skutečnou síťovou adresu.

Pokud skutečnou adresu nezadáme, nemůžeme inicializovat spojení s druhou stranou, dokud se ona nespojí s námi. To je klasický přístup na serveru: ten nemá v konfiguraci obvykle pevné IP adresy klientů, kteří se mohou připojovat třeba na cestách. Naopak klienti musí mít v konfiguraci adresu serveru, aby věděli, kam se připojit. Z tohohle pohledu to funguje stejně jako zmíněná OpenVPN.

Ovšem může existovat i jiný scénář, kdy chceme spojit několik statických sítí (třeba na pobočkách). Tam můžeme na všech stranách zadat IP adresy partnerů (typicky nějakých routerů), protože ty se měnit nebudou. Vytvoříme si tak vlastně statické tunely.

Je to jasnější?

Aha OK, cize pokial mame jeden staticky VPN server, klienti sa pripoja normalne k nemu a server dopredu adresy klientov poznat nemusi (potrebuje len tie vnutorne/virtualne) - toto uz dava zmysel ;-)
Vdaka za ozrejmenie....

Těším se na praktickou část. Bylo by fajn v ní i zmínit podporu v openWRT. V mnoha případech se asi bude používat k přístupu do domácí sítě a server část bude běžet na domácím routeru. Díky.

Díky, to je samozřejmě v plánu. Bude to součástí některého z dalších dílů.

Super článek, i ta přednáška. Vypadá to zajímavě, hned to jdu testnout :)
Škoda, že to nepřišlo o týden dřív (zrovna jsem dokončil VPNku s OpenVPN ) :)

"Celý WireGuard má jen 4000 řádků."

Mohl bych se zeptat, jak autor k tomuto číslu došel? Když si vezmu naposledy submitnutou sérii (v9), tak mi vychází 48271+/214-, tj. více než dvanáctkrát víc, než se tvrdí v článku. A to je jen kernel, u ostatních řešení autor počítá jádro a userspace dohromady (a u openvpn dokonce započítal i openssl).

Není součástí toho pull requestu i Zinc?

V předcházející větě se k openvpn připočítá i celá openssl, takže počítat wireguard bez Zincu by byla příliš průhledná manipulace. (Mimochodem, i bez něj bychom pořád byli na 7667+ jen v jádře, tj. téměř dvojnásobku uváděné velikosti.)

To je číslo, které uvádí sám Jason Donenfeld, například ve své prezentaci o WireGuardu [PDF].

Tak to je smutné, zatím jsem si myslel, že ta zavádějící propaganda není dílem samotného autora projektu a že ten je v tom nevinně. :-(

Navíc v té prezentaci nikde nevidím ta obrovská čísla pro openvpn+openssl resp. xfrm+strongswan, takže ta pocházejí odjinud, což jen popporuje mé pochybnosti, jestli byla použita stejná nebo aspoň podobná metodika a jestli jsou ty hodnoty aspoň trochu porovnatelné.

Asi za to může špatná metodika míchající na různých místech kód s knihovnami a bez nich. Můžeme to napravit, asi by bylo nejrozumnější to od těch knihoven očistit a nechat tam data, která uvádí Donenfeld v prezentaci na BlackHat. Tedy 116K OpenVPN, 119K XFRM a 405K StrongSwan. Dává vám to takhle větší smysl?

Jediné, co by dávalo smysl, by bylo, kdyby to porovnání provedl někdo nezávislý, kdo nejdřív stanoví jasnou metodiku, co započítat a co ne, a pak podle stejných pravidel spočítal velikost pro všechny tři varianty. Teď jsem třeba zkusil narychlo xfrm v jádře a vyšlo mi ~23000 řádků včetně dokumentace a selftestů, takže netuším, jak dokázal Jason Donenfeld napočítat čtyřnásobek. Ono to ale stejně nikdy úplně férové nebude - právě proto, že každý z těch projektů dělá něco jiného a je založen na výrazně odlišné filosofii.

Chtěl jsem jen poukázat na to, že ta impozantní čísla z článku jsou tak zavádějící, že až nedávají smysl. A to je právě to, co mne od wireguardu odrazuje. Je docela dobře možné, že je wireguard opravdu tak skvělý, jak se tvrdí; ale ta nekritická propaganda a mediální masáž, to jsou metody, které patří do úplně jiných oborů. Tady to spíš vzbuzuje nedůvěru.

Hodně dlouho používám N2N. Jak se to liší?

Jedna vec me udivuje, to opravdu nikdo neumi vysaturovat 1Gbs pres OpenVPN (po TCP) na jednom spojeni? Ja to pouzivam dost casto na kopirovani dat a uz nejednou jsem sejmul 1Gbs konektivitu do "nemale" spolecnosti kde nebyl aktivni QoS. (Ja za to nemohl, rozkaz znel jasne, co nejrychleji...) Je pravda, ze na 10Gbs jsem to nezkousel a stalo by to za to vedet kdy to neda CPU.

23. 5. 2019, 18:30 editováno autorem komentáře

Měli jsme statický tunel pomocí OpenVPN mezi dvěma lokalitami (městy) a vytížit 1Gbps (100MB/s) nebyl žádný problém. Ovšem graf propustnosti jednotlivých technologií je přímo od autora WireGuardu, tak je otázka, zda si i tohle nepřikrášlil (viz komentáře Michala Kubečka o problematice metriky počtu řádků kódu).

Že openvpn má při vyšší zátěži výkonové problémy, to se ví. Jeden problém je nešťastná single thread implementace, která může za určitých okolností docela zamávat s latencemi. (Před časem jsme na to narazili kvůli autentizaci přes LDAP, kdy při pomalejší odezvě LDAP serveru musel na odpověď čekat veškerý provoz - to už je ale opravené.) Při vyšších rychlostech (to už ale spíš víc než "jen" gigabit) může být problém ne úplně efektivní návrh tun/tap rozhraní, které používá znakové zařízení.

Oproti klasickému ESP bych nějak zásadní rozdíl nečekal, tam to bude IMHO záviset na konkrétních použitých algoritmech a asi i dalších implementačních detailech. Koneckonců ani v těch prezentacích od autora není ten rozdíl moc velký.

Mimochodem pro ty z vás, co máte NordVPN, tak jim stačí napsat na support, že chcete zkusit WireGuard a oni vám pošlou konfig/QR kód a můžete se připojit.
Zatím mají ale pouze dva servery, jeden v US a jeden v UK. Já na tom jedu a funguje to dobře na W10 desktopu i Androidu.

Bohužel nemůžu sloužit, protože Windows nemám, nepoužívám a neznám. Může to ale samozřejmě udělat někdo jiný, pokud máte zájem doplnit seriál o WireGuardu návodem pro Windows, stačí se ozvat redakci.

TunSafe - https://tunsafe.com/, formát konfigurace je stejný jako na linuxu, t.j. konfigurační soubor možno nastojato přebrat z Linuxu.