abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
    dnes 14:11 | Komunita

    O víkendu probíhá online The Raku Conference 2022, tj. konference věnovaná programovacímu jazyku Raku.

    Ladislav Hagara | Komentářů: 3
    včera 17:22 | IT novinky

    Včera skončila bezpečnostní konference Black Hat USA 2022 (Twitter) a začala bezpečnostní konference DEF CON 30 (Twitter). V rámci Black Hat byly vyhlášeny výsledky letošní Pwnie Awards (Twitter). Pwnie Awards oceňují to nejlepší, ale i to nejhorší z IT bezpečnosti (bezpečnostní Oscar a Malina v jednom).

    Ladislav Hagara | Komentářů: 0
    včera 15:00 | Nová verze

    Vývojáři PostgreSQL oznámili vydání verzí 14.5, 13.8, 12.12, 11.17, 10.22 a 15 Beta 3. Opraveno je více než 40 chyb a také zranitelnost CVE-2022-2625. Upstream podpora verze 10 končí 10. listopadu letošního roku.

    Ladislav Hagara | Komentářů: 0
    11.8. 18:11 | Nová verze

    Byla vydána verze 1.63.0 programovacího jazyka Rust (Wikipedie). Podrobnosti v poznámkách k vydání. Vyzkoušet Rust lze například na stránce Rust by Example.

    Ladislav Hagara | Komentářů: 11
    11.8. 17:55 | Nová verze

    Bylo vydáno Ubuntu 22.04.1 LTS, tj. první opravné vydání Ubuntu 22.04 LTS s kódovým názvem Jammy Jellyfish.

    Ladislav Hagara | Komentářů: 0
    11.8. 08:00 | Komunita

    Microsoft Fluent Emoji jsou nově k dispozici na GitHubu pod licencí MIT. Více v článku na Medium.

    Ladislav Hagara | Komentářů: 15
    11.8. 00:22 | IT novinky

    O víkendu proběhla v Kolíně nad Rýnem demopárty Evoke 2022. Publikována byla prezentovaná dema. Upozornit lze na Area 5150 (YouTube) běžící na IBM PC s procesorem Intel 8088 běžícím na 4,77 MHz a CGA.

    Ladislav Hagara | Komentářů: 3
    10.8. 19:55 | Zajímavý software

    smenu, nástroj pro příkazový řádek pro generování možností a potvrzení výběru, dospěl do verze 1.0.0.

    Ladislav Hagara | Komentářů: 0
    10.8. 19:11 | Bezpečnostní upozornění

    Byla potvrzena zranitelnost CVE-2021-46778 aneb SQUIP (Scheduler Queue Usage via Interference Probing) v procesorech AMD s mikroarchitekturou Zen 1, Zen 2 a Zen 3. Detaily v publikovaném paperu.

    Ladislav Hagara | Komentářů: 0
    10.8. 13:33 | Nová verze

    Turris OS, operační systém pro síťová zařízení Turris postavený na OpenWrt, byl vydán v nové verzi 5.4. Přehled novinek a diskuse v diskusním fóru.

    Ladislav Hagara | Komentářů: 2
    Audioknihy ve srovnání s knihami tištěnými (papírovými nebo elektronickými) poslouchám
     (34%)
     (3%)
     (6%)
     (57%)
    Celkem 194 hlasů
     Komentářů: 2, poslední dnes 11:46
    Rozcestník

    Zapomeňte na OpenVPN, používáme IKEv2 : Úvod

    21.7.2020 00:37 | Přečteno: 4247× | linux | Výběrový blog | poslední úprava: 21.7.2020 00:37

    OpenVPN je super, cool, ale i na pytel a není dostupné pro všechny platformy. Název je lehce nadsazen, ale na každém šprochu pravdy trochu.

    Howto : Debian + Strongswan + IKEv2 + BYOD (part 1)

    Aneb jak postavit všestranné VPN řešení.


    Porovnání IKEv2 s okolním světem

    Kromě komerčních řešení alá Cisco AnyConnect, Fortinet, Pulse Secure atd. máme i několik plně OSS variant, které stojí za používání.

    Několik let zpátky (možná rok 2016) jsem měl před sebou jasný úkol, rozjet BYOD řešení pro zaměstnance i externisty. Kdo nezná termín BYOD, tak jde o připojení čehokoli do firmy, hlavně privátních zařízení. Jde tedy o silně heterogenní prostředí. Úkol ale není jen umožnit připojení, ale umožnit ho jednoduše a pokud možno i bez admin práv.


    IKEv2 vs OpenVPN

    Proč né OpenVPN, ale IKEv2 (ipsec)?


    IKEv2 vs L2TP

    Občas někdo slyší něco o L2TP. Většinou se nepoužívá samotné L2TP, ale L2TP over IPSEC (samotné L2TP totiž není šifrované). Tzn., že se sestaví IPSEC spojení a v něm se pak tuneluje L2TP. Pro funkčnost tedy potřebujeme to samé jako u IPSECu (IKEv1/IKEv2), tj. jen porty UDP500 a UDP4500 (NAT-T). Když někde čtete návod, že musíte na firewallu povolit i L2TP port 1701, tak skončete se čtením takového návodu, protože autor neví, která bije a tohoto fudu je plný internet.

    Problém L2TP je na více stranách. Pokud máte server za NATem, tak máte ošklivý problém. Ten problém jsou špatné checksummy při komunikaci. V Linuxu není problém (špatný checksumm / poškozený natem lze ignorovat, resp. ignoruje se jen ten, co je zapouzdřený v ESP komunikaci/ipsec tunelu), ve Windows je potřeba povolit toto ignorantsví v registrech ("AssumeUDPEncapsulationContextOnSendRule") a FreeBSD je v tomto ohledu nepoužitelné, resp. celé roky bylo. Možná to je už fixnutý ve verzi 11, viz Bug 146190. V době, kdy jsem to tedy řešil, tak pfSense bylo na L2TP over IPSEC nepoužitelné.

    Můj případ je nat-nat (server i klienti za natem), takže L2TP za natem nepřicházelo v úvahu. Kromě tedy problému na straně klientů (nutno editovat registry ve Windows) neumí mobike, neumí always on, v určitých situacích (když se restartoval server) si klient nevšiml že k něčemu došlo a ve Windows se tvářil, že spojení je ok a nebylo. Tzn. v určitých situacích nekorektní chování.


    IKEv2 vs WireGuard

    Našlo by se několik jedinců, kteří by se na to určitě zeptali. Takže odpovědí je několik. V době kdy jsem to řešil, WireGuard nebyl dostupný. Dále přetrvává to, že není dostupný pro všechny platformy (stále se občas někdo najde s Windows mobile, Windows ARM apod.). Osobně jsem ho ještě netestoval, takže ani nevím, co aktuálně vše umí, ale always on prý problém není a funguje to parádně.


    IKEv2 vs SoftEther

    SoftEther jsem nezkoušel. Důvodů, proč jsem ho ani nezkoušel bylo několik:


    strongSwan : Úvod do historie

    Strongswan považuji v současné době za nejlepší oss implementaci IPSECu a velkým tahounem této implementace v oss světě.


    FreeS/WAN (Secure Wide Area Network)

    Vše začalo tímto projektem. Založil ho John Gilmore v roce 1996. Nelíbilo se mu, že komunikace po internetu není zabezpečena. A to chtěl změnit. Záměrem nebylo vydělat, financí měl dost z předešlých projektů, chtěl jen umožnit ochranu práv obyčejných lidí na internetu (zabránit odposlouchávání apod.). Administrativně projekt řídil Hugh Daniel. Narazilo se ale na to, že v té době vláda USA nedovolovala export cryptografie a podobných technologií. Jinými slovy, takový projekt vyvíjený v USA by nebylo možné použít v celém světě. Z toho důvodu se vývoj odehrával mimo USA (a všichni z USA měli zakázáno přispívat do kódu). O vývoj se zpočátku starali John Ioannidis a Angelos Keromytis. Projekt pak z technického hlediska řídil Henry Spencer a později pak Michael Richardson. IKE démon (userspace aplikaci) pak spravoval D. Hugh Redelmeier a implementaci v kernelu (KLIPS) Richard Guy Briggs. O dokumentaci se pak staral Sandy Harris a později Claudia Schmeing.

    Z hlediska funkčnosti byla první vize taková, že každý by měl doma krabičku, která by byla mezi počítačem (či více počítači/LAN sítí) a internetem. Pokud by probíhala komunikace s někým, kdo by tu krabičku měl také, tak by byl provoz automaticky šifrován. Krabička měla být založena na Linuxu.

    První verze měla vyjít v roce 1996, ale to se nepovedlo kvůli spoustě překážkám (jako třeba kvůli vývozním zákonům USA). Nakonec tedy první verze 1.00 vyšla v 1999/04.


    OpenSWAN a strongSwan

    Velice restriktivní přístup mohl zato, že byl FreeS/WAN forknutý. Andreas Steffen napsal rozsáhlý patch na implementaci X.509, ale Gilmore jej odmítl včlenit. Mathieu Lafon napsal podporu NAT-T (možnost provozovat IPSEC přes NAT) a taktéž bylo odmítnuté patch včlenit. Jeden maintener FreeS/WANu včlenil všechny patche a tento balíček pojmenoval "super-freeswan". To se Gilmorovi moc nelíbilo. Nakonec v roce 2003 na konferenci v Berlíně bylo rozhodnuto o forknutí projektu (tenkrát ve verzi 2.04), tím vznikl OpenSWAN. Gilmore vydal ještě dvě verze FreeS/WANu a pak projekt ukončil.

    Kromě forku OpenSWAN vznikl i fork pojmenovaný strongSwan. Za tímto forkem stál/stojí Andreas Steffen, profesor ze Švýcarské vysoké školy HSR (Hochschule für Technik Rapperswil). Projekt stále vede v rámci školy a rozhodně v tom není sám, pomáhají mu mj. Martin Willi a Tobias Brunner.


    LibreSWAN

    Vznikl v roce 2012 jako fork OpenSWAN projektu. Paul Wouters pomohl založit společnost Xelerance, která vyvíjela OpenSWAN. Následně došlo k neshodům, bojům o vlastnictví jména OpenSWAN apod. Výsledkem byl fork pojmenovaný LibreSWAN.


    Proč strongSwan?

    Myslím si, že se jedná o nejpokročilejší implementaci se stabilním vývojem, naprosto parádní dokumentací + příklady nastavení (Configuration Examples), dělají i věci okolo tohoto řešení jako např. aplikaci pro Android, která zjednodušuje deploy nastavení, umožňuje zasílání debug logů a další a další věci. Od samého počátku má pevné vedení na akademické půdě. Je vidět, že vývoj jde hodně kupředu. Naproti tomu např. OpenSWAN vypadá, že hodně stagnuje (github), resp. vypadá polomrtvě. Pokud jde o LibreSWAN, tak ten žije hodně, viz CHANGES. Ale upřímně tam nevidím moc oslňujících věcí a co je horší, všude se píše, že má problémy s EAP (pokud je to skutečně pravda, tak je to velká mezera). U VTI mají uvedeno "experimental", to samé u XFRM. strongSwan třeba zahodil Pluto už v roce 2012, mají implementaci HA, předělali syntaxy konfiguráků a vytvořili vici plugin a od verze 5.7.0 je možné využívat tento interface pro přístup aplikací třetích stran. Tzn. takový API řešení.

    Co dalšího mně přesvědčilo bylo, že strongSwan se používá v docela známých řešení. Pro mně nejblíže např. v pfSense, ZyXEL routery (aspoň myslím, že jsem to tam viděl v OSS balíčku), jedna nejmenovaná CZ firma, co poskytuje VPN, Sophos a další.

    Když jsem se před 4 lety rozhodoval, co nasadit, tak jsem byl na vážkách. Nakonec jsem se rozhodl pro strongSwan. Nyní musím říci, že to byla dobrá volba a v dnešní době už bych nezaváhal.


    Závěr

    Tolik asi tak ke stručné historii a důvodům, proč jsem vybral to, co jsem vybral. Příště už pronikneme do celého návrhu řešení, instalace a konfigurace.

    Zdar Max

           

    Hodnocení: 100 %

            špatnédobré        

    Anketa

    Co používáte za VPN řešení pro klienty (+ se podělte v diskusi o zkušenosti)?
     (59 %)
     (12 %)
     (6 %)
     (26 %)
     (23 %)
     (3 %)
     (15 %)
    Celkem 104 hlasů

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    21.7.2020 01:23 Cabrón
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    V anketě chybí možnost sshuttle :-) userspace VPN přes SSH.

    Řeší to situaci, kdy mám někde (v práci, u zákazníka, na anonymní VPS někde atd.) jen účet na mašině a nic víc. Pokud se do ní dokážu přihlásit přes SSH a spustit Python, mám tam díky tomuhle automaticky VPNku.
    Max avatar 21.7.2020 01:29 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Nojo, zapomněl jsem dát do ankety "něco jiného/uvedu v diskusi". Tak sorry, no :)
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 13:41 skajrajdr | skóre: 2 | blog: skajrajdr
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Dik!
    22.7.2020 14:59 luky
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    openssh podporuje jak vpn tak i socks proxy samo o sobe, takze prinos te aplikace muze byt jen v pripade, ze je dana funcionalita zakazana v konfiguraci a nemam prava to zmenit.
    21.7.2020 13:35 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    IKEv2 VPN z Windows 10 do firemní sítě na IPv6: https://www.hobrasoft.cz/cs/blog/bravenec/ikev2-vpn2
    21.7.2020 14:04 honza
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    ty brdo, Petr jeste zije a je aktivni ... :-)

    diky za link
    Max avatar 21.7.2020 14:24 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Promiň, ale né úplně dobře řešeno. Deploy na Win je řešeno nešťastně. Nemáš řešený ani accounting. Vedení hesel v plaintextu se v mém nasazení ukázalo jako silně nevhodné (stačí vynechat mezeru, nebo cokoli a všechny účty za chybou přestanou fungovat, dost často mi toto dělával jeden kolega, který měl problém vidět mezery, apostrofy atd.). Další problém je obsolete konfigurace, díky čemuž nemůžeš použít ani XFRM. Podle konfigurace to vypadá, že ty ale nepoužíváš ani VTI. ESP máš nastaveno nekompatibilně (tak, jak je nyní nastaveno, se ti některé OS budou při rekey odpojovat, tzn. vpn bude fungovat tak dlouho, než dojde k rekey, pak to může vypadnout, záleží na OS a verzi).
    Zdar Max
    Měl jsem sen ... :(
    Max avatar 21.7.2020 14:35 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    K tomu ESP, upřesním, že s prvním nastavením budou fungovat jen Win a možná něco, s druhým nastavením pro MAC/iOS nebudou Win fungovat (budou mít problém s rekey). Správně je použít oba typy, né jednou to a podruhý ono.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 14:40 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Není třeba se omlouvat, klidně se nechám poučit. Prioritou je pro mě fungující (či lépe fungující) tunel, na ego se snažím kašlat. Ke strongswan bych měl milióny dotazů, jakékoliv připomínky bych uvítal. Mohl by být třetí díl: "Co má Petr ve své konfiguraci špatně"?
    Max avatar 21.7.2020 15:39 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Ahoj, všechny připomínky jsem už napsal. ESP jsem rozvedl, použití txt k vedení účtu jsem také rozvedl. Obsolete konfiguraci také (používáš ipsec.conf a né swanctl.conf, takže nepodporuješ všechny novinky od stavu, kdy byl ipsec.conf formát prohlášen za obsolete, protože vše nové se cpe do swanct.conf formátu).
    Chybějící accounting, tam nevím, co dodat. Tak, jak to máš, tak nemáš přehledné výstupy (kdo kdy se přihlásil, kolik dat přenesl atd. Nějaké info lze zjistit parsováním auth logů, ale je to zbytečná drbačka). Chybějící accounting + lepší vedení účtů řeší Radius server (a strongswan mu umí posílat accounting info).
    Strongswan umí filtrovat spojení na skupiny, takže pokud máš v rámci radiusu uživatele v nějaké skupině, můžeš na základě toho řídit přístup.
    Kolize nejsou problém, není to tedy třeba řšit pomocí ipv6.
    Lepší je používat pro nastavení routy toto (příklad):
    Add-VpnConnectionRoute -ConnectionName "Company VPN" -DestinationPrefix "192.168.0.0/24"
    
    Deploy na Win stanice dle toho návodu není dotažen. Osobně řeším pomocí next next exáče, který jednoduše přednastaví celý tunel a uživatel si jen při prvním přihlášení zadá login a pw. Úroveň omylu při nastavování se blíží nule.
    Deploy na jiné OS tam také nevidím, v rámci iOS řeším vlastním mobileconf souborem, na který si uživatelé kliknou, next next a mají VPN v iOS.
    Deploy na Win Mobile taktéž konfigurákem, ale to už v dnešní době asi nemá smysl zmiňovat.
    Zdar Max
    Měl jsem sen ... :(
    Max avatar 21.7.2020 15:44 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Jop a nepoužíváš XFRM (což je jasné, když nepoužíváš swanct.conf), ale nepoužíváš ani VTI. Takže asi nepoužíváš žádný virtuální iface, kterým by jsi řídil provoz a máš to asi zavěšený všechno na wan interface, ne?
    Pokud ano, tak lepší je opravdu si směrovat provozo přes VTI, nebo lépe přes XFRM interface a ten si pak filtrovat.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 16:31 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    ...Chybějící accounting, tam nevím, co dodat. Tak, jak to máš, tak nemáš přehledné výstupy (kdo kdy se přihlásil, kolik dat přenesl atd. Nějaké info lze zjistit parsováním auth logů, ale je to zbytečná drbačka). Chybějící accounting + lepší vedení účtů řeší Radius server (a strongswan mu umí posílat accounting info)...
    Ten acounting mě zmátnul. Když jsi to popsal, pochopil jsem - já mám "tucet" uživatelů, v tvém případě to bude asi řádově více. Z toho vyplývá i deploying. Dělat next next exáč pro jakousi obskurní Windows platformu by vyšlo dráž, než to těm pěti lidem naklikat. Navíc to neklikám já :-)
    Max avatar 21.7.2020 20:22 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Tak je pravda, že mám těch klientů trochu více (cca 400 ve čtyřech různých státech) a nově mám klienty pro průmyslová zařízení/terminály, takže celé řešení se trochu rozšiřuje.
    Ale to nemění nic na tom, že je dobré mít ucelený přehled a info, kdo se kdy připojuje a kolik kdo přenese dat.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 16:03 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Dívám se sem: https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN, protože pojmy XFRM a VTI pro mě byly dosud neznámé. Ale ne tak úplně ten nápad za tím.

    Jestli to dobře chápu, VTI a XFRM si vytvářejí virtuální síťové rozhraní. To ale pro mě na IPv6 nemá valný význam. Ten případ s Windows je pro mě trochu okrajové použití, vetšinu tunelů mám mezi linuxovými zařízeními a výhradně na IPv6. Tam naopak vítám, že na cestu paketů se nijak nesahá a šifrované i nešifrované pakety jdou stejnou cestou.

    Mezi výhodami v odkazovaném článku uvádějí, že VTI či XFRM umožňuje výpis přenášených paketů v plaintextu (příjemné) a že lze snadno nastavit MTU. Nastavit MTU se mi zatím vždy podařilo, ale ze zkušenosti vím, že pokud po cestě něco sežere icmp pakety, je to na mašli. Každopádně díky za nasměrování.

    Jaký význam pro mě VTI nebo XFRM na IPv6 má? Při používání IPv6 a IPSec bych o "tunelu" hovořil jen s velkým sebezapřením, protože ty stanice na sebe normálně vidí. IPSec tam jenom zajišťuje šifrování. U https taky nemluvím o tom, že to "s" (ssl) tam dělá nějaký tunel, a dělat virtuální síťové rozhraní pro https je blbost.
    Max avatar 21.7.2020 16:36 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Ano, VTI/XFRM je virtuální rozhraní. Prostě vytvoříš si XFRM interface (pojmenuješ si ho jak chceš) a řekneš mu, že konkrétní IPSEC tunel má jít přes konkrétní xfrm interface (můžeš si specifikovat IN/OUT separátně, záleží na usecase). Díky tomu pak lze lépe ovládat takový traffic (přehlednější fw, shapping, priority atd.). Líp se nad tím pracuje, než když je vše zavěšeno na jednom interface, což je většinou ten wan interface. A také je to taková bezpečnější varianta, mít ten traffic takto oddělen od normálního provozu.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 16:57 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Rozumím. Na IPv4 bych nad tím takto asi uvažoval, je prima, když se na wan neobjevují pakety ze sítě 192.168.x.x. Na IPv6 je mi to jedno, ale je fakt, že někde ve firewallu (shorewall) už to mám rozdělené do různých zón a přístupy mezi zónami řeším - ve výsledku to vypadá velmi podobně, jako bych měl pro každou zónu samostatné síťové rozhraní. A zrovna pro tu síť pro uživatele Windows by virtuální rozhraní mít smysl mohlo i na úrovni systému.
    Max avatar 21.7.2020 20:07 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Já nerozlišuji protokol, jde mi vesměs o oddělení typu provozu, nic víc.
    Zdar Max
    Měl jsem sen ... :(
    22.7.2020 08:28 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod

    Ale ono to rozlišení protokolu je podstatné. Když zprovozňuji IPSec spojení mezi dvěma IPv6 stroji, postupuji takto:

    • nastavím IPv6 adresy na obou strojích (sítích)
    • zkontroluji, že mi vše chodí tak jak má (ping, http, ssh....)
    • nastavím firewall
    • zkontroluji, že mi vše chodí tak jak má (ping, http, ssh....)
    • zapnu IPSec šifrování
    • zkontroluji, že mi vše chodí tak jak má (ping, http, ssh....) - což chodí, protože IPSec nijak nesahá na nastavení sítě a to už mám zkontrolované

    Cituji z jinde v této diskusi uvedeného odkazu:

    Packets that are routed through such an interface are guaranteed to be IPsec transformed or dropped.

    Použití takového interface by mě nutilo k postupu na hlavu postavenému:

    • vytvořím interface
    • zkontrolovat interface nemůžu, protože propustí jen IPsec pakety
    • zprovozním (o zapnutí nelze mluvit, spojení neexistuje!) IPsec. Na jakých adresách vlastně?
    • nastavím IPv6 adresy
    • teprve nyní zkontroluji, že mi vše chodí tak jak má - ale to už mi to musí chodit IPSec vrstva...
    • nastavím firewall - většinu internetového provozu na jednom síťovém rozhraní, jiný internetový provoz na jiném rozhraní?!
    • ...

    Ať nad tím uvažuju jak chci, virtuální síťové rozhraní u IPv6 přináší jenom zmatek a bordel. U IPv4 může být situace jiná, tam může virtuální síťové rozhraní situaci trochu zpřehlednit. Ale nemyslím si, že by jakékoliv virtuální síťové rozhraní mělo tu moc nějak zvládnout ten zmatek a bordel, který už v IPv4 sítích obecně vládne.

    Max avatar 22.7.2020 09:01 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Zprovoznění s virtuálním iface je úplně stejný jako v prvním případě, jen s tím rozdílem, že si definuješ, že provoz v navázaném tunelu má jít přes nějaký virtuání iface (+ si můžeš např. říci, že IN má jít přes jiný iface než OUT). Virtuální iface nemá žádnou IP, jen slouží k rozlišování a filtrování takového trafficu, který do něj pošleme (pomocí konfigurace ve strongswanu). A nad takovým virtuálním iface pak můžeš zavěsit firewall pravidla (třeba i nezávislá na konkrétních IP). Tzn., že na WAN interface si povolíš klasiku (UDP500,UDP4500, icmp) a to je vše. Samotný provoz v tunelu pak řešíš nad virtuálním iface (jak firewall, tak shapping / omezování šířky pásma apod.).
    Ještě koukám, že v tom tvém článku nemáš zmínku nic o úpravě mss, přitom je to celkem nutnost.
    Zdar Max
    Měl jsem sen ... :(
    22.7.2020 09:13 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    ...provoz v navázaném tunelu...
    V jakém tunelu? IPSec mi nedělá žádný "tunel" (pomíjím tunel mod fungování). IPSec jenom říká, že provoz mezi adresou A a adresou B se šifruje!
    Max avatar 22.7.2020 10:14 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    IPSEC sestaví spojení a v rámci něj pak běží komunikace, uvnitř toho spojení zapouzdřená v ESP. A to je tunnel mode, který používáš i ty. Nebo u ipv6 je to jinak? Nebo jen slovíčkaříme? Je možné, že jsem jen něco nepochopil, přecijen mé podmínky mi neumožňují si moc hrát s ipv6.
    Zdar Max
    Měl jsem sen ... :(
    22.7.2020 11:16 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Nikoliv, ESP není tunel. IPSec má dva mody: transport mode a tunnel model. Transport mode funguje mezi dvěma IP adresami, tunnel model funguje mezi dvěma sítěmi. V síťovém provozu nebo nastavení samotném žádný zásadní rozdíl není, pokaždé probíhá šifrování mezi bodem A a bodem B, kde oba body (ip adresy nebo sítě) na sebe vidí. To, že na sebe dva počítače vidí, je normální stav (ovlivnitelný firewallem). IPv4 už dnes není možné považovat za normální protokol, tam na sebe počítače často vidět nemohou.

    Kromě StrongSwan, kde konfigurace tuto vlastnost IPSec skrývá, můžete vyzkoušet ipsectools - racoon a setkey. Tam je oddělená konfigurace pro domluvu parametrů (racoon) a konfigurace pro politiky (setkey). Politika se konfiguruje například takto:
    spdadd -6n 2001:db8:1::/64 2001:db8:2::/64 any -P out ipsec esp/tunnel/2001:db8:1::1-2001:db8:2::1/require;
    
    Zde se říká, že paket putující ze sítě 2001:db8:1::/64 přes router 2001:db8:1::1 se má na tomto routeru zašifrovat (parametry domlouvá racoon), na routeru 2001:db8:2::1 se paket rozšifruje a pošle dál do sítě 2001:db8:2::/64 (druhý směr se musí nakonfigurovat zvlášť). Naprosto stejné nastavení by bylo pro transport mode, změnily by se pouze adresy sítě a mod tunnel na transport. Když je politika zapnutá, šifruje se. Když je politika vypnutá, nešifruje se. Pro síťový provoz, firewall, routování atd. je IPSec transparentní. Ať tam IPSec je nebo ne, síťový provoz probíhá stále stejně. Nevnímám zašifrované pakety jako "tunelované" - jen transformované do jiné, nečitelné podoby.

    Tato část nastavení je v ipsectools velmi přímočará. StrongSwan tuhle část trochu skrývá, ale kdesi vespod funguje stejně.
    Max avatar 22.7.2020 11:49 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Já ti rozumím, s ipv6 to vypadá transparentněji, ale to nic nemění na té terminologii jako takové. Když v rámci IPSECu existuje terminologie tunnel / sestavení tunnel mode, tak jsem prostě sestavil tunel a to, že nevede skrz nějaký kopec nikoho nepřekvapí. Jedná se prostě o abstraktní označení. Aspoň tak to mám zažité a tak se o tom mluví v místech, kde se pohybuji (zywall, cisco aj. a ano, je to i v kombinaci s ipv6). Tvou připomínku tedy vnímám spíše jako slovíčkaření proti zažitému označení, které se prostě běžně používá.
    A pokud jde o virtuální iface, tak na tom ta ipv6 také nic nemění. Strongswan ipv6 prostě může směrovat přes nějaký virtuální iface, nad kterým si provedeš shapping či jiné věci a stále v takovém případě nevidím rozdíl mezi ipv4 a ipv6.
    Zdar Max
    Měl jsem sen ... :(
    22.7.2020 12:02 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    A jak naložíme s transport modem? Slouží to k témuž, běží to na ESP, používá to IPSec, šifrované to je, implementuje se to pomocí StrongSwan...
    Max avatar 22.7.2020 12:33 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    IPSEC Tunel v modu tunel nebo transport :).
    Když se podíváš na nějaké helpy od ciso, tak :
    Configure IKEv2 IPv6 Site-to-Site Tunnel Between ASA and FTD.
    Security for VPNs with IPsec Configuration Guide

    všude mluví o tunelu, dokonce toto označení mají v cmd pro sestavení ipsecu (a je jedno, v jakém modu).
    Takže toť k tvému dotazu :).
    Zdar Max
    Měl jsem sen ... :(
    22.7.2020 12:53 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Oba odkazy popisují fungování čistě v tunnel režimu. První to má už v názvu, ten další to uvádí hned v prvním odstavci. O transport modu tam není ani slovo. K čemu by taky transport režim na routeru byl (jde o cisco routery, chápu to správně?)
    Max avatar 22.7.2020 13:22 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    A ten typ ovládání / nastavení v cisco, kde se pořád mluví o tunelu (ať jde o tunel mode, nebo transport mode) ignoruješ? Nebo si vyhledej frázi "tunnel mode". Já tu fakt nechci slovíčkařit. Pokud se ti tyto termíny nelíbí, běž si stěžovat velkým hráčům, které je používají.
    Zdar Max
    Měl jsem sen ... :(
    22.7.2020 12:44 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Začínám rozumět tomu, že tunel/netunel je slovíčkaření a vychází to ze způsobu, jakým používáš a vnímáš IPSec ty, a ze způsobu, jakým používám a vnímám IPSec já.

    Dneska se to plošně udělat nedá, ale představme si situaci, že IPv4 zmizela. Pak bude "tunel" vypadat tak, že klient se svou (libovolnou) IPv6 adresou naváže spojení na firemní server, domluví se na šifrování a zapne se IPsec. Budeme tomu říkat tunel? Záměrně nezmiňuji router, to je jen hloupé zařízení někde po cestě, ani firewall, který na server propustí pouze IPSec.

    To je stejný režim fungování, jaký dnes používá https. Používají se k tomu dokonce stejné techniky: certifikáty pro ověření serveru, mohou se používat certifikáty pro ověření klienta (v praxi jsem viděl jen párkrát), zapouzdření jednoho protokolu (http nebo ip/udp/...) v jiném protokolu (ssl nebo esp). Přitom je absurdní říkat https protokolu tunel.

    Většinu IPSec spojení mám dělanou tímto přístupem. Můj ideální stav by byl, kdyby se moje servery a jiná různá zařízení mezi sebou bavili bod-bod a prokazovaly se certifikátem od Let's Encrypt. Konfigurace by pak byla pohádkově snadná. Ale StrongSwan s tím má nějaké potíže, jen nevím, jestli to svést na StrongSwan nebo na sebe :-/

    Kdybych dostal IPv6 všude, kde se k internetu připojím, dávno bych takový přístup ve vlastní firmě používal. Máme počítače rozmístěné přes čtvrt světa. Takhle musím na IPv4 udělat tunel (v tom skutečném smyslu slova, na kterém se všichni shodneme), abych se dostal na IPv6 a pak teprve můžu pokračovat...
    22.7.2020 13:12 PetrK
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Vždyť https je SSL/TLS tunel pro http. Na https server se normálně napojím přes stunnel a http.

    A ten příměr s IPSec kulhá. Není normální provozovat http a https na jednom portu, tak jako tvůj způsob s IPSec s jedním rozhraním. Právě to virtuální xfrm rozhraní dělá tu větší podobnost mezi http a https.
    22.7.2020 13:43 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Každé přirovnání kulhá. Na stunnel jsem zapomenul :-/

    Ani IPSec se neprovozuje na jednom "portu". Http - 80, https - 443, IPSec - protokol 50, TCP/UDP/ICMP... 6/17/1...

    Provozovat IPSec na jednom rozhraní normální je, ale nejste sám, kdo to vidí jinak: včera 18:25 Michal Kubeček

    Počkám, až se v Debianu objeví StrongSwan verze 5.8 (první podpora XFRM virtuálního rozhraní), vyzkouším to.

    Celá tahle diskuse je asi založená na různém použití IPSec. To se dá použít například pro VPN zajišťující home office, ale i jinak. Já jsem byl historicky především na té straně jinak, kde mi přijde nevhodné označit šifrování mezi dvěma počítači jako tunel a kde počítače na sebe normálně vidí.

    Pokud někdo staví tunel pro home office, tak především propojuje dvě sítě, které na sebe nevidí, zabezpečení je "navíc".

    Pokud propojuji dva počítače, které na sebe vidí, nestavím tunel. Jenom chci, aby byla komunikace zabezpečená.
    Max avatar 22.7.2020 13:53 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Používám Debian stable + z backports kernel a iproute (tím je zaručena podpora xfrm iface). Strongswan mám pak sestaven ze src balíčku ze SIDu, protože stejně je nejlepší používat aktuální verzi.
    Zdar Max
    PS: pokud jde o slovíčkaření, tak nevidím smysl v tom nějak pokračovat, neshledávám to nijak důležitým, spíše únavným...
    Měl jsem sen ... :(
    22.7.2020 14:24 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Souhlasím. Zabírá to spoustu času.

    Každopádně jsem se z diskuse hodně dozvěděl. Je tady hodně námětů k přemýšlení a hodně otázek k hledání nějakého řešení a je fuk, jak tomu budeme říkat.
    28.7.2020 10:54 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Není normální provozovat [...] IPSec s jedním rozhraním.

    Trochu jsem se v tom šťoural, přemýšlel a studoval manuály a z hlediska bezpečnosti se mi jeví použití vyhraženého interface jako klasický příklad "security by obscurity". Unixová filozofie říká, že program má dělat jednu věc a má ji dělat pořádně:

    • síťový protokol (IPv6) se stará o komunikaci mezi dvěma počítači
    • IPSec se stará o to, aby komunikaci po cestě nikdo nemohl přečíst či pozměnit
    • firewall se stará o to, aby mezi počítači probíhala pouze povolená komunikace

    První bod - síťový protokol - je naprostý základ. Pokud nefunguje, je šílené zkoušet rozchodit další dva body. IPSec skrz striktně šifrovaný interface ten první bod rozbíjí a fušuje do řemesla bodu třetímu.

    Když jste zvyklý používat IPSec místo firewallu, tak jakmile vám z nějakého důvodu zmizí interface (jak se to stalo v Linuxu před lety), zákonitě musí nastoupit pocit, že bez interface je zabezpečení špatně. Ve skutečnosti je IPSec správně, špatně (nebo vůbec) je nastavený firewall.

    Znovu upozorňuji: používám IPv6 a jen vyjímečně vytvářím tunely popsané v tomto článku. IPSec je o cosi obecnější nástroj, než by se z tohoto článku mohlo zdát.

    29.7.2020 15:07 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Jenže to, že vám z jednoho rozhraní tečou data občas šifrovaná a občas ne, je obskurita sama o sobě. Recept na to, abyste něco po..al a posílal cleartext tam, kde si myslíte, že šifrujete.
    Quando omni flunkus moritati
    29.7.2020 16:01 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    …což je přesně ten myšlenkový blok, o kterém jsem mluvil.
    29.7.2020 21:16 trekker.dk | skóre: 72
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Vy jste samozřejmě neomylný, někteří z nás ostatních nicméně radši pracují s tím, že tomu tak není, a snaží se předcházet následkům omylů...
    Quando omni flunkus moritati
    29.7.2020 21:25 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod

    To nemá nic společného s neomylností. Jen jsem se seznámil s tím, jak ta implementace funguje, a snažil jsem se ji pochopit místo toho, abych se "zašprajcoval" na stanovisku, že když je to jinak, než jsem byl zvyklý, je to nutně špatně navržené. Sice jsem taky začínal na FreeS/WAN, ale když jsem pak objevil ipsec-tools, měl jsem radost z toho, že konfigurace najednou docela dobře odpovídá tomu, jak ta implementace opravdu funguje.

    Co se týká té (ne)omylnosti, měl bych námět k zamyšlení: je opravdu tak principiální rozdíl mezi chybou v konfiguraci security policies a chybou v konfiguraci pravidel netfilteru? Je opravdu jedno na denním pořádku a druhé prakticky vyloučené? Já bych řekl že ne.

    27.7.2020 22:29 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod

    Není to slovíčkaření.

    V transportním režimu se vezme nešifrovaný packet, mezi IP hlavičku a payload se vloží AH hlavička (případně ESP, je-li třeba šifrování) a packet se pustí do světa, jako kdyby šifrovaný nebyl. O dešifrování se postará příjemce.

    V tunelovacím režimu se vezme nešifrovaný packet, celý se zabalí do AH (či ESP) a předřadí se mu úplně nová IP hlavička. Nová IP hlavička potřebuje nějakou zdrojovou a cílovou adresu. A těmi jsou adresy konců tunelu. Šifrovaný packet tudíž neputuje k původnímu příjemci, ale k druhému konci tunelu, kde se dešifruje a vybalený packet se odsměruje dál původnímu příjemci.

    Z toho vyplývají jiné způsoby použití. Transportní se používá při end-to-end šifrování, kdežto tunelovací při propojování sítí. Ono by se daly oba režimy znásilnit pro opačný způsob použití, ale nebylo by moc praktické. Určitou analogii lze najít s WDS v protokolu 802.11.

    27.7.2020 22:47 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Ono by se daly oba režimy znásilnit pro opačný způsob použití, ale nebylo by moc praktické.

    Tunnel mode se pro host to host IPsec používá celkem běžně. Dokonce jsem zaslechl, že existují i implementace, které transport mode ani nakonfigurovat neumožňují.

    Obráceně by to ale asi bylo opravdu trochu násilné. Nejjednodušší by v takovém případě asi bylo kombinovat transport mode s něčím jako ipip nebo GRE.

    22.7.2020 11:49 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Chápu, že jsem si vybral z následujích odkazů jen to, co se mi hodilo, ale přeci jen:

    https://en.wikipedia.org/wiki/IPsec#Security_architecture
    Encapsulating Security Payloads (ESP) provides confidentiality, connectionless data integrity, data-origin authentication, an anti-replay service (a form of partial sequence integrity), and limited traffic-flow confidentiality.
    https://en.wikipedia.org/wiki/IP_tunnel
    IP tunnels are often used for connecting two disjoint IP networks that don't have a native routing path to each other, via an underlying routable protocol across an intermediate transport network. In conjunction with the IPsec protocol they may be used to create a virtual private network between two or more private networks across a public network such as the Internet. Another prominent use is to connect islands of IPv6 installations across the IPv4 Internet.
    22.7.2020 12:56 PetrK
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    pb.: Tvůj postup má z hlediska bezpečnosti jednu nevýhodu, vypnuté šifrování nikdo nepozná. Vše bude fungovat dál, ale nezabezpečeně.
    22.7.2020 13:11 pb.
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod

    To je správná připomínka. Je to tak. Pokud na sebe počítače přímo vidí, funguje spojení i bez šifrování. To je na IPv6 normální stav.

    Řešení mě napadají hned čtyři:

    • nevypínat šifrování
    • označit ve StrongSwan šifrované pakety a ve firewallu neoznačené pakety zahodit (jde to?)
    • virtuální síťový interface
    • nedávat IPsec na router mezi internetem a sítí, ale přímo na server vevnitř sítě
    22.7.2020 13:51 Jana J. | skóre: 4 | blog: Sem_vlozte_jmeno_blogu | Praha
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    označit ve StrongSwan šifrované pakety a ve firewallu neoznačené pakety zahodit (jde to?)
    Pokud se nepletu, jde to, ale podle mě je jednodušší použít na netfilteru rovnou extension policy a zahazovat to, co jde nešifrovaně.
    22.7.2020 14:09 Jana J. | skóre: 4 | blog: Sem_vlozte_jmeno_blogu | Praha
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Příloha:
    Mimochodem, jak tu je níže zmiňovaný Mikrotik, tak tohle filtrování umí i aktuální RouterOS. Viz modrá položka v příloze.
    22.7.2020 13:30 Vantomas | skóre: 31 | Praha
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Přesně s tímto jsem se setkával při použití IPsec+L2TP z Linuxu proti Mikrotiku. Bylo to připojené přes LTE, takže to připojení dost vypadávalo a třeba po dvou dnech se zasekl strongswan na sestavování s protistranou a mezitím xl2tpd sestavilo tunel nešifrovaně.

    Samozřejmě jsem si vědom toho, že jsem měl vše špatně nastavené, ale přišel jsem k tomu "teď hned honem rychle, jenom na víkend" a howto, podle kterých jsem to nastavoval byly v tomhle směru dost strohé.
    Max avatar 22.7.2020 13:34 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Stačí nemít povolený L2TP port na WAN interface a on se bez ipsecu nesestaví. To je jen první nástřel, co mně napadá. Problém je, že ve spoustě návodech o L2TP over IPSEC autor článku radí, aby se L2TP port povolil na WAN interface, což je samozřejmě špatně.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 18:25 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod

    Především: xfrm není síťové rozhraní, xfrm je část linuxového síťového stacku, která zajišťuje transformaci paketů, nejčastějí šifrování nebo dešifrování pomocí ESP a autentizaci pomocí ESP nebo AH, tj. to, co známe jako IPsec.

    To je věc, která fungovala už od počátku řady 2.6, ale protože implementace nevytvářela pro bezpečnou komunikaci virtuální "tunelové" rozhraní, jak byli lidé zvyklí z (nejen) FreeS/WAN, prakticky od té doby se po všech fórech šířilo nepřetržité brblání, že je to celé úplně blbě, nedá se to pochopit, nedá se to používat atd. Spousta lidí má totiž myšlenkový blok, že když vidí "holé" i "zabezpečené" pakety na stejném interface, tak to přece nemůže být bezpečné, a nějakým security policies, které jsou v jádře teprve 16 let, přece věřit nebudou.

    Nakonec vývojáři tu možnost, aby se použil jakýsi virtuální interface pro xfrm, v jádře 4.19 implementovali. Ale naštěstí je to jen možnost, pokud si to tak nenastavíte, funguje všechno jako předtím.

    Max avatar 21.7.2020 20:19 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Já provozuji IPSEC bez xfrm i s xfrm. Osobně bych to tak nebagatelizoval. V xfrm vidím možnost lepší orientace v provozu, lepší blbuvzdornosti atd. U jednoduchého vpn není problém, ale jakmile se komplexita zvětšuje, je to velký přínos. Před xfrm byla možnost používat VTI (od kernelu 3.6). Před VTI to byl KLIPS. Takže stále tu nějaká možnost byla.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 22:11 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Já provozuji IPSEC bez xfrm

    To je na jakékoli současné linuxové distribuci velmi nepravděpodobné.

    Před xfrm byla možnost používat VTI (od kernelu 3.6).

    To není "před xfrm", xfrm je součástí linuxového jádra už od počátku řady 2.6 (technicky už od nějaké verze z řady 2.5). Jak už jsem se pokusil naznačit jednou, zaměňujete "xfrm" a "virtuální xfrm interface".

    U jednoduchého vpn není problém, ale jakmile se komplexita zvětšuje, je to velký přínos.

    Máme zákazníka, pro kterého jsem opravoval chybu, která se projevila, když v jednom netns vytvořili asi 17000 SA a pak ten netns zrušili. Měli se svými nasazeními všelijaké problémy, ale nevzpomínám si, že by si někdy stěžovali na absenci virtuálních xfrm rozhraní.

    Max avatar 21.7.2020 22:27 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    V tom případě nevím, proč jsi s tím začal, když se celou dobu bavíme o xfrm virtuálním iface, který přistál v kernelu 4.19. Pokud v kernelu v síťovým stacku existuje něco s názvem xfrm, tak super, teď o tom víme, ale o tom moc řeč nebyla a nevím, v čem nám to pomůže. Jediný, kdo nám to tu tedy zamýchal, jsi byl ty :).
    To, v čem vidím smysl virtuálního iface jsem zmínil a nevím, co bych k tomu dál dodal. Že se tobě o tom nějaká firma nezmínila(nebo nemá nasazeno) má celkem nulový informační přínos. Každopádně 17k SA je slušný nasazení, o tom žádná.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 22:38 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    V tom případě nevím, proč jsi s tím začal, když se celou dobu bavíme o xfrm virtuálním iface

    Protože opakovaně používáte určitý termín, ale myslíte tím něco úplně jiného, než co znamená. Termíny slouží k tomu, aby se lidé domluvili. Když si bude každý vymýšlet vlastní terminologii, bude to s tou domluvou docela problém.

    V tomto případě je to o to horší, že to děláte v textu, který je něco jako tutorial, takže je naprosto žádoucí chybnou terminologii opravit, aby se ji neučili další.

    Že se tobě o tom nějaká firma nezmínila(nebo nemá nasazeno) má celkem nulový informační přínos.

    Informační přínos je v tom, že je to příklad, že ani při dost značné komplexitě to bez těch virtuálních rozhraní není problém, stačí nepodléhat zažitým stereotypům.

    Max avatar 21.7.2020 22:46 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Sorry, ale virtuální iface se jmenuje XFRM a v článku je to zmíněno hned vedle VTI (další virtuální iface), takže kontext je naprosto jasný. Navíc kdo googlí xfrm, narazí v 99% na virtuální iface a né část stacku v kernelu. To, že ty máš skill na úrovni kodu je samozřejmě parádní a díky za upřesnění, ale hon na čarodejnice bych asi nedělal.

    Já neříkám, že bez xfrm iface je to problém, já jen tvrdím, že virtuální iface některé věci zjednodušuje a je škoda toho nevyužít, nic víc.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 23:08 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Navíc kdo googlí xfrm, narazí v 99% na virtuální iface a né část stacku v kernelu.

    Nedalo mi to a zkusil jsem to:

    1. manuálová stránka ip-xfrm(8) (1:0 pro mne)
    2. manuálová stránka ip-xfrm(8) (2:0)
    3. xfrm device - offloading the IPsec computations - tj. ne ten, který myslíte vy, je to o xfrm/IPsec offloadingu (3:0)
    4. Experimentation with Linux XFRM (4:0)
    5. XFRM Programming (5:0)
    6. Why are only 3 ip xfrm policies needed for a IPsec tunnel? (6:0)
    7. Linux ip xfrm: What is the purpose of the tmpl? (7:0)
    8. XFRM--A Kernel Implementation Framework of IPsec Protocol (8:0)
    9. Script to set up an ipsec tunnel between two machines For ... (9:0)
    10. xfrm.h source code [linux/include/net/xfrm.h] - Woboq Code Browser (10:0)

    Abych byl férový, na 11.  místě konečně XFRM Interface Development Notes - Libreswan.

    Je sice známé, že Google personalizuje výsledky vyhledávání, ale že by až tak moc?

    Max avatar 21.7.2020 23:29 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Nejdříve se vytvoří virtuální xfrm iface a následně se na něj pomocí ip xfrm aplikují policy.
    Takže vás nechápu, asi si nerozumíme.
    Zdar Max
    Měl jsem sen ... :(
    Max avatar 21.7.2020 23:32 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Tak už chápu, beru zpět, už mi bliklo.
    Zdar Max
    Měl jsem sen ... :(
    22.7.2020 15:43 MP
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Hele Maxi, nevis nahodou, jak dostat do ikev2 klienta ve W10 group_user/group_password? V klasicke nabidce je jen user/password....
    Max avatar 23.7.2020 16:01 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Abych byl upřímný, tak nevím, co to je. Když na to koukám, lze to najít jen ve spojitosti s Cisco, ale ti mají svého klienta.
    Co přesně tedy má ta skupina dělat? Resp. proč existuje? / Jakou má skupina funkci?
    díky
    Zdar Max
    Měl jsem sen ... :(
    24.7.2020 07:37 MP
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Hadam, ze je to neco jako 2FA...
    Max avatar 24.7.2020 08:08 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    To asi ne, ne? Takový login a pw bude znát hafec lidí.
    Spíš by mně zajímalo, co dělá ten vpn server, protože to asi nebude nějaký standard a v takovém případě budou mít vlastního klienta.
    Zdar Max
    Měl jsem sen ... :(
    24.7.2020 08:59 bigBRAMBOR | skóre: 36
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    ty jsi nejakej jinej MP nebo se ptas na neco co nevis co je?
    Jendа avatar 21.7.2020 19:23 Jendа | skóre: 77 | blog: Jenda | JO70FB
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    My jsme přecházeli z OpenVPN na WG kvůli výkonu. Na Mikrotiku RB750Gr3 (dvoujádrový dušný MIPSel s hitlerthreadingem) dala (UDPčková) OpenVPN 23 Mb/s, a to i když jsem snížil šifrování na AES-128-CBC (se silnějším to bylo kolem 18 Mb/s). WG teď vytíží všechna 4 jádra a saturuje 100 Mb/s.

    Ale problém máme s Windows WG klientem, na Windows 7 (jiná Windows jsem nezkoušel). Když se server resetuje natvrdo (výpadek napájení), tak pak timeoutuje handshake a nejde s tím nic dělat, jenom klienta restartovat. Potkali jste to někdo taky?

    Všude jinde ale není problém s výkonem (typicky server běží na dostatečně silném železe a klienti posílají dat málo) a tam máme radši OpenVPN. Částečně z historických důvodů, částečně protože out of tree modul do kernelu je další zbytečný opruz, ale především proto, že je to otestované a protože se strašně bojím, co se stane, až bude potřeba změnit handshake a jak to jako budu hromadně upgradovat (u openvpn to jednak tak nehrozí, protože protokol může podporovat třeba TLS1.2 a TLS1.3 a AES a BF současně, jednak si snadno můžu spustit dvě a upgradované klienty přesměrovávat na tu novou pomocí iptables pravidel; u kernelového WG bych na tohle musel pouštět virtuál).
    Není problém s kolizními segmenty (klient může být ve své lokální síti 192.168.1.0/24 a zároveň se pomocí VPN připojit do vzdálené 192.168.1.0/24 a není problém)
    Jak to funguje?
    Analýzou popisků na schránkách zjistil, že nejčastější české jméno je "Nevhazujte Letáky" a rozhodl se ho přijmout.
    Heron avatar 21.7.2020 20:23 Heron | skóre: 53 | blog: root_at_heron | Olomouc
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Mě se OpenVPN líbí z podobných důvodů. Jednak se mi líbí, jak je to postaveno, prostě vzali OpenSSL, pomocí toho šifrujou, vzali tap nebo tun a z toho mají interface. Pro auth stačí běžné PKI certifikáty. Jeden UDP port. Funguje to.

    Tj jak píšeš, umí to používat cokoliv, co aktuálně umí openssl nebo jiná podobná knihovna.
    21.7.2020 22:19 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod

    Hrubá propustnost je jen jedna část problému; openvpn totiž veškerý provoz zpracovává v jedné frontě jedním threadem, takže pokud přes openvpn běží větší datové přenosy, interaktivní provoz tím dost trpí. Dnes už sice tun/tap umí multiqueue, takže by multithreadové zpracování bylo možné, ale zatím openvpn nikdo nepřepsal.

    Dřív to bylo ještě horší, to se v tom jednom threadu dělalo úplně všechno a synchronně, takže se třeba stávalo, že když byla pomalejší odezva od LDAP serveru, každé přihlášení uživatele na pár sekund zablokovalo veškerý provoz.

    21.7.2020 22:22 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Pro úplnost: známý (a leckde používaný) workaround je spustit pro každého uživatele openvpn démona na jiném portu, aby nekolidovali mezi sebou (a aspoň jednotliví uživatelé se mohli rozložit na různé procesory). Ale to samozřejmě není řešení, ze kterého by byl člověk nadšený.
    Max avatar 21.7.2020 22:39 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Tak si říkám, že toto by možná mohl pořešit HAProxy a dělat loadbalancer mezi více OVPN servery. Z pohledu uživatel tedy stále jeden port a stále stejné nastavení, na backendu ale třeba 10 OpenVPN instancí.
    Zdar Max
    Měl jsem sen ... :(
    Max avatar 21.7.2020 22:37 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Jo, ten výkon je stále problém. V době CoV jsme vyřešili HO i částečně za pomocí OpenVPN, přes 120 klientů na jednom OpenVPN serveru (outsourcovaného) a nevím nevím, zda to bylo pomalý kvůli tomu serveru jako takovému (kromě OVPN tam jsou i další věci) nebo zda za to mohlo i OpenVPN jako takové. Každopádně TCP nepoužitelné, UDP šlo, většinou měl uživatel jedno RDP spojení ve fullhd, výjimečně v QHD. Každopádně jsem z toho měl smíšené pocity :-/.
    Zdar Max
    Měl jsem sen ... :(
    21.7.2020 22:48 Michal Kubeček | skóre: 72 | Luštěnice
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    přes 120 klientů na jednom OpenVPN serveru (outsourcovaného) a nevím nevím, zda to bylo pomalý kvůli tomu serveru jako takovému (kromě OVPN tam jsou i další věci) nebo zda za to mohlo i OpenVPN jako takové

    Při 120 klientech a pravděpodobně i nezanedbatelném procentu skutečně aktivních je skoro jisté, že je to ten problém, který jsem popisoval (všechno v jedné frontě a jednom threadu).

    TCP nepoužitelné

    Tunelování v TCP je problém skoro vždy, to by mělo být brané jen jako nouzová alternativa pro situace, kdy UDP z nějakého důvodu nejde použít - třeba proto, že je jedna strana za nějakým nesmyslně nakonfigurovaným firewallem. Zejména TCP v TCP funguje rozumně jen za ideálních podmínek, jakmile se začnou ztrácet pakety, dělá to psí kusy.

    JiK avatar 3.9.2020 21:40 JiK | skóre: 12 | blog: Jirkoviny | Virginia
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    co ten slibovany druhy dil? Nebude?
    Max avatar 3.9.2020 22:07 Max | skóre: 71 | blog: Max_Devaine
    Rozbalit Rozbalit vše Re: Zapomeňte na OpenVPN, používáme IKEv2 : Úvod
    Jop, připravuji, připletly se mi do toho dvě věci. Ty problémy s TV, co jsem sepsal, a pak jsem nasazoval OSS Cam systém. V jobu hodně práce a hodně bokovek mimo, nicméně tento víkend bych měl mít konečně volno, tak to dodělám a snad v po/ut vydám.
    Zdar Max
    Měl jsem sen ... :(

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.