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

21.7.2020 00:37 | Přečteno: 5019× | linux | | 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)?

• OpenVPN není dostupné pro všechny platformy, IKEv2 je. Řešil jsem pokrytí pro Android, Windows Phone 8.1, Windows Phone 10, Windows 10, Windows 10 ARM, iPhone/iPad.
• IKEv2 podporuje Mobike a fci AlwaysOn. Mobike znamená, že lze s telefonem přecházet mezi LTE a WIFI a VPN nevypadne. AlwaysOn je pak fce, která umožňuje při zjištění funkčního internetu automaticky navázat VPN spojení.
• Implementace ve všech zařízení/OS je naprosto parádní a nebývá problém.
• Vzhledem k integraci v OS nejsou třeba admin práva pro nastavení spojení.
• IKEv2 neumí moc dobře pushovat rozsahy ke koncovému zařízení (je to různé implementace od implentace, ale vesměs ne). Toto ale není problém, aspoň za poslední asi 4 roky provozu nebyl.
• Není problém s nat-nat (server i klient za natem) i s více klienty za stejným natem. U OpenVPN tento problém také není.
• Jde velmi dobře škálovat a má velkou variabilitu nastavení pro šifrování a další věci s tím spojené (podpora více úrovní ověřování atd.).
• Podpora TNC (Trusted Network Connect)
• setkal jsem se s uživatelskými stanicemi (windows), kde byl velký problém nainstalovat tap driver, takže ani nešlo zprovoznit OpenVPN spojení. Naposled jsem se s tímto problém setkal asi ve 2020/04. Problém to nebyl OpenVPN, ale té klientské stanice, nicméně mně v případě BYOD nezajímá, kde je problém, nechci mít problém, i na sebedementnější konfiguraci
• Jde se setkat s místy, kde je blokován veškerý provoz kromě http. V ČR těch míst moc není, ale občas nějaký hotel v Německu nebo Polsku se najde, co to má omezený. Tam by teoreticky provoz OpenVPN na https portu (samozřejmě přes TCP) mohl projít. Nicméně v dnešní době mobilních dat to také nepředstavuje velký problém.
• Relativně nedávno měl OpenVPN problém s funkčností pod obyčejným uživatelem. Řešeních bylo hafec, vesmě shodně složitých, případně používat neoficiální klienty, které přinášely jiné problémy. Aktuálně OpenVPN umí funkgovat v režimu klient(ovládací GUI v systray) server, takže už to neplatí a přecijen se aspoň toto posunulo.
• 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)

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:

• Implementuje všechny možné protokoly včetně ipsecu, který jako jediný podporuje u všech platforem. Proč bych ho tedy měl používat, když mohu používat standardní implemetaci.
• Ovládání serveru bylo vždy primárně pro Windows (teď už to vypadá, že mají i nějaký web face, ale těžko říci)
• Vývoj nevypadal nijak zuřivě
• Nepřišlo mi, že má kolem sebe nějak velkou komunitu, takže jsem měl trochu obavy, jak rychle bych mohl řešit nějaké problémy v provozu

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

       

Anketa

Komentáře

[Cabrón]

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]

Nojo, zapomněl jsem dát do ankety "něco jiného/uvedu v diskusi". Tak sorry, no :)
Zdar Max

[skajrajdr]

Dik!

[luky]

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.

[pb.]

IKEv2 VPN z Windows 10 do firemní sítě na IPv6: https://www.hobrasoft.cz/cs/blog/bravenec/ikev2-vpn2

[honza]

ty brdo, Petr jeste zije a je aktivni ...

diky za link

[Max]

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

[Max]

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

[pb.]

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]

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

[Max]

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

[pb.]

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

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

[pb.]

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]

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

[pb.]

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]

Já nerozlišuji protokol, jde mi vesměs o oddělení typu provozu, nic víc.
Zdar Max

[pb.]

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]

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

[pb.]

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

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

[pb.]

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]

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

[pb.]

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]

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

[pb.]

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]

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

[pb.]

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

[PetrK]

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.

[pb.]

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]

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

[pb.]

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.

[pb.]

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.

[trekker.dk]

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.

[Michal Kubeček]

…což je přesně ten myšlenkový blok, o kterém jsem mluvil.

[trekker.dk]

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

[Michal Kubeček]

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.

[petr_p]

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.

[Michal Kubeček]

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.

[pb.]

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.

[PetrK]

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

[pb.]

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ě

[Jana J.]

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

[Jana J.]

Příloha:

• Screenshot_20200722_140702.png (38403 bytů)

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.

[Vantomas]

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]

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

[Michal Kubeček]

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]

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

[Michal Kubeček]

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]

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

[Michal Kubeček]

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]

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

[Michal Kubeček]

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]

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

[Max]

Tak už chápu, beru zpět, už mi bliklo.
Zdar Max

[MP]

Hele Maxi, nevis nahodou, jak dostat do ikev2 klienta ve W10 group_user/group_password? V klasicke nabidce je jen user/password....

[Max]

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

[MP]

Hadam, ze je to neco jako 2FA...

[Max]

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

[bigBRAMBOR]

ty jsi nejakej jinej MP nebo se ptas na neco co nevis co je?

[Jendа]

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?

[Heron]

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.

[Michal Kubeček]

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.

[Michal Kubeček]

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]

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

[Max]

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

[Michal Kubeček]

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]

co ten slibovany druhy dil? Nebude?

[Max]

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

[prasopes]

co ten slibovany druhy dil? Nebude?