IPsec přes IPv6... aneb VPN tam, kde žádnou nepotřebujete

24.2.2011 10:45 | Přečteno: 2660× | Počítače | | poslední úprava: 24.2.2011 10:42

Když jsem začal před pár týdny experimentovat s IPv6, začaly mi docházet některé věci, především ta, že IPv4 je zbytečně složité a že čím dřív přejde internet na IPv6, tím bude má práce síťového administrátora jednodušší. Ostatně o IPv6 už jsem zde jeden zápisek zvěřejnil.

Odkazy

IPsec na IPv6 - podrobnější článek o rozdílu IPsec na IPv4 a IPv6. Hlavní myšlenka článku: "VPN pro IPv6 neexistuje".
IPv4 nefunguje! Ať žije IPv6! - dřívější zápisek v mém blogu.

Na svém routeru mám nainstalovaný systém OpenWrt. Kdysi jsem experimentoval na tomto routeru s IPsec, ale poněkud jsem pohořel. Ze dvou důvodů:

IPv4

Potřeboval jsem propojit sítě 10.10.1/24 a 10.100.1/24. I když mám na svém routeru veřejnou IP adresu, ke svému ISP jsem připojený přes PPTP a spojovací síť je, jak na potvoru, 10.10.1/24.

Malý výkon

I když se mi kvůli IPv4 nepodařilo napojit šifrovaně na síť 10.10.1/24, dokázal jsem udělat šifrovaný kanál na síť s jinou, nekolidující adresou. Tam se ukázalo, že výkon mého zařízení s OpenWrt je hrubě nedostatečný. Přenosy byly až k nepotřebě pomalé.

Zkušenosti s IPv6

Na jiném routeru (mírně rychlejší CPU, větší flash) jsem se k IPsec vrátil. Nainstaloval jsem si nejnovější verzi OpenWrt (BackFire) - s IPv6 jsem problémy nezaznamenal, pouze u IPsec na IPv6 nepamatovali a musel jsem si balík ipsec-tools opatchovat a přeložit ručně.

U IPv6 naprosto nehrozí konflikt adresy s mým ISP - zádrhel, který mi znemožnil nastartovat IPsec na routeru, zcela zmizel. S podivem se neobjevily ani nejmenší problémy s výkonem. Buď je výkon novějšího software vyšší v několika řádech, nebo je několikařádový rozdíl mezi procesorem 200 MHz a 266 MHz.

IPv6 komunikace mezi oběma propojovanými sítěmi mi pochopitelně fungovala už před zprovozněním IPsec, pomocí IPsec komunikaci pouze zabezpečím.

       

Komentáře

[pasmen]

Možná jsem úplně mimo, IPv6 do detailu neznám a prakticky jsem to pouze testoval v tunelu, ale v čemu potřebuješ IPsec, pokud je IP protokolem IPv6? Není náhodou zabezpečení součástí toho protokolu?

[Michal Kubeček]

IPsec je právě to zabezpečení, které je součástí protokolu IPv6. IPsec původně vznikl jako bezpečnostní rozšíření protokolu IPv6 a teprve později byl v upravené podobě implementován i pro IPv4.

[Michal Kubeček]

Pro přesnost: místo "součástí" by mělo být "povinně implementovaným rozšířením".

[pasmen]

OK, podobně jsem to myslel, jen neznám detaily.

[Ondrej 'SanTiago' Zajicek]

Odkazovany clanek pouziva IPsec v esp/transport mode. Pokud se IPsec pouziva v esp/tunnel mode, jde v podstate o VPN. Takze neni pravda, ze by v IPv6 nebylo VPN, je tam a dokonce vestavene.

[Michal Kubeček]

A naopak: transport mode lze používat i s IPv4.

[Petr Bravenec]

Odkazovaný článek používá IPsec v transport i tunnel modu a vysvětluje rozdíly. V tunnel modu se mimo obsah šifrují i hlavičky.

Souhlasím s tím, že VPN v IPv6 existuje a je vestavěné. Ale myslím si, že pojem VPN s rozšířením IPv6 zmizí, ztratí význam. Je dnes například někdo, kdo by dával nějaká zvláštní jména tomu S v httpS?

Článek především ukazuje na rozdíl v přístupu k jedné a téže věci na IPv4 a IPv6. V praxi bude tento rozdíl ještě větší:

IPv4: Tak vy chcete propojit dvě pobočky? Tak to budeme muset nainstalovat VPN. Můžete si stáhnout OpenVPN, ale tenhle SuperIpVpnŠifrátor je lepší a klikavější a bezpečnější. A tady tenhle Šifrofáč dokonce funguje i přes nat a ve firewallu se nemusí nic nastavovat! Nojo, hádá se nám to s adresama ISP, tak něco přečíslujeme. Jono, VPN, to je složitá technilogia. Pošlu vám fakturu...

IPv6: Pro přenosy mezi pobočkami zapneme šifrování, ok?

U zákazníků narážím v souvislosti s VPN na velmi neuvěřitelné věci. Nad vynalézavostí mých předchůdců-administrátorů mi zůstává rozum stát. VPN je málokdy nainstalovaná kvůli bezpečnosti - většinou se tak obchází nutnost NATu v IPv4. Pokud už VPN slouží k zabezpečení, propojuje naprosto nesmyslně podnikovou síť (SElinux, milióny řádků v logu o útocích, portnocking - zabezpečeno mimózním paranoikem) s domácím počítačem syna agresivně asertivního firemního účetního s pochybným zabezpečením a se zapnutým forwardingem, aby mohl tatínek v sobotu večer provádět zabezpečené účetní operace. Heh :-/

IPsec ve spojení s IPv6 přináší takové zjednodušení, že o VPN fakt nemá cenu hovořit.

[Ondrej 'SanTiago' Zajicek]

VPN je v podstate synonymum pro sifrovany tunel (a duraz na 'tunel' je stejny jako na 'sifrovany'), nelze to zjednodusit jen na 'sfrovane spojeni'. A tunely v dohledne budocnosti nejspis stale budou obcas potreba, at uz sifrovene (treba IPsec tunnel mode) nebo nesifrovane (GRE).

Takze tu mame tri ruzne pojmy pro tri ruzne moznosti pouzivane pri ruznych prilezitostech - sifrovane spojeni (IPsec transport), sifrovany tunel (IPsec tunnel) a (nesifrovany) tunel.

Takze jde v podsate o tom, zda se v situaci vedouci k nasazeni sifrovaneho tunelu bude jeden admin ptat druheho:

"Pro prenosy mezi pobockama nastavime sifrovany tunel?" nebo "Pro prenosy mezi pobockama nastavime VPN?".

Netusim, proc by mel pojem "sifrovany tunel" nutne zvitezit nad pojmem "VPN" (ackoliv sam osobne preferuju ten prvni).

[Petr Bravenec]

"Pro prenosy mezi pobockama nastavime sifrovany tunel?" nebo "Pro prenosy mezi pobockama nastavime VPN?".

"Spojíme ty sítě pomocí VPN?" (ipv4 - kombinace šifrování, tunelování, routování a natu, složité tak, že to potřebuje vlastní jméno)

"Zapneme mezi těmi sítěmi šifrování?" (ipv6 - jednoduché tak, že lze označit obecným pojmem "šifrování")

V IPsec znamená režim "tunnel" jen to, že se zašifrují i hlavičky. Česky: "šifrováním jsme skryli i adresy".

Ke svému ISP jsem připojený přes PPTP, to je taky šifrovaný tunel. Je mi ukradené tomu "nějak říkat", pro mě to je "připojení".

Až bude "šifrování" v IP znamenat "IPsec zapnuto", nebude potřeba tomu říkat jménem.

Dneska VPN zahrnuje velkou skupinu různých postupů a produktů, které se většinou ani nepoužívají kvůli zabezpečení.

[Ondrej 'SanTiago' Zajicek]

V IPsec znamená režim "tunnel" jen to, že se zašifrují i hlavičky.

Pokud vim, tak i v IPsec znamena tunnel rezim vicemene to same, jako v jakykoliv jinem tunelovem protokolu - tedy vytvoreni virtualni linky pomoci zapouzdreni celych paketu. Oproti prostemu sifrovani je mozne skrz takovou linku routovat.

[Petr Bravenec]

OK. Přečtěte si ten článek ještě jednou. Třeba i pozpátku, jestli vám to pomůže.

Proč vytvářet nějakou speciální "linku" kvůli zabezpečení, když cesta už existuje a stačí jen zapnout šifrování?

Speciální linku potřebujete vytvářet u IPv4, kde "vpn" znamená soubor různých technologií zabalených do jednoho balíku (šifrování, routování a nat) a prodávaný pod konkrétním obchodním jménem.

V IPv6 cesta existuje a není třeba nic dalšího. Jo, krom případu, kdy potřebuji skrýt své přenosy, potom jen zapnu šifrování. Přičemž mi dává protokol na výběr ze dvou možností - buď šifrovat pouze data, nebo i hlavičky.

V IPv6 skrz tu linku neroutujete. Ta linka existuje nezávisle na IPsec. Pomocí IPsec pouze říkáte, jakým způsobem se data přenášejí. Platí to i v případě režimu "tunnel".

I z jiných diskusí mi připadá, že jste příliš hluboko v zajetí toho, co znáte. Proč se držíte slovíček a vyjadřujete se k věcem, kterým zcela zjevně nerozumíte, nebo vám je maximálně někdo sdělil zpoza katedry?

Rozchoďte si IPv6 a zkuste nastavit i IPsec. Zkuste si IPsec mezi dvěma konkrétními počítači. Vyzkoušejte si oba režimy. Zapojte takhle třeba celou síť nebo dvě. Pak se vám rozsvítí a řeknete si: "Routovat přes tunel v ipv6? Bože, to je bejkárna! Jak mě mohla taková volovina vůbec napadnout!?"

V IPv4 a IPv6 jsou velké, opravdu velké rozdíly.

[Ondrej 'SanTiago' Zajicek]

Proč vytvářet nějakou speciální "linku" kvůli zabezpečení, když cesta už existuje a stačí jen zapnout šifrování?

Ale ta linka (tunel) se nevytvari kvuli zabezpeceni! Tunely neslouzi primarne kvuli zabezpeceni, ale kvuli uplne jinym vecem (primarne ruznym formam uprav routovani). Proto se take casto pouzivaji i nesifrovane, nezabezpecene tunely (treba GRE).

Samozrejme, pokud potrebuju pouze zajistit sifrovane spojeni, pak nepotrebuju zadnou tunelovaci technologii, ale casto clovek potrebuje neco jineho.

Napriklad:

- propojeni oddelenych siti pouzivajicich ULA adresy (kvuli multihomingu).

- propojeni oddelenych siti na L2 urovni.

- pouzivan adres z jine site, nez pres kterou jsem fyzicky pripojen (napr, kvuli multihomingu nebo mobilite nebo proste proto, ze potrebuju pripojit celou sit a fyzicky ISP me poskytl jen /128).

...

Me pro zmenu prijde, ze nemate predstavu, k cemu vsemu se pouzivaji (at uz sifrovane nebo nesifrovane) tunely resp. VPN. Zdaleka ne jen kvuli bezpecnosti.

[Ondrej 'SanTiago' Zajicek]

Nebo jeden priklad za vsechny - mam dve oddelene site pouzivajici verejne adresy a mam je propojene vlastni optickou linkou, ale kazde misto ma take samostatne pripojeni do Internetu. Chci mit failover pres internet pro pripad vypadku te opticke linky. Opticke lince duveruju, tak pres ni sifrovat nepotrebuju (a navic pri jeji rychlosti by se to ani nestihalo), ale failover linka pres internet musi byt sifrovana (je take pomalejsi). Pri pouziti sifrovaneho tunelu (VPN) trivialita - na tunelu a opticke lince pustim OSPF a jenom zmenou routovaci tabulky (coz dela OSPF demon) zajistim, zda provoz do stejneho cile bude sifrovan pres tunel nebo pujde nesifrovane pres optickou linku.

Obecne IPsec tunnel mode tak, jak je navrzen, umi delat bezne tunely (VPN). Mozna jedna z jeho mnoha implementaci, ta, kterou jsi zkousel, to neumi, ale to je pak spis problem te implementace.

[Petr Bravenec]

I v tomto případě je šifrování jen zabezpečením existující cesty a speciální "linku" tvořenou pomocí VPN nepotřebuje. Router budu mít nastavený pořád stejně, pakety budou putovat pořád stejně, jenom se na část trasy zapne šifrování.

Nemáte pocit, že oba mluvíme o něčem jiném? Já jsem postavil proti sobě šifrované propojení dvou sítí protokolem IPv6 a obvyklý komplikovaný postup známý z IPv4 (nat, tunel, routing, šifrování). Slova jsem volil záměrně provokativní, abych vyzdvihnul rozdíl.

Říkám: "Pro zabezpečení přenosů VPN netřeba" a vy na to: "Ale tunel se dá použít i na úplně jiné věci".

To je jakobych říkal: "Přes most můžete přejít pěšky a klidně i bos" a vy na to: "Ale tunelem metra se můžete projet taky!"

Obojí je pravda, ale nijak to spolu nesouvisí.

[Ondrej 'SanTiago' Zajicek]

Říkám: "Pro zabezpečení přenosů VPN netřeba" a vy na to: "Ale tunel se dá použít i na úplně jiné věci".

Ten clanek (a predchozi prispevky) rika ale neco jineho - "v IPv6 VPN netreba" a demonstuje to tim, ze VPN neni treba pro zabezpeceni prenosu, ja na to "v IPv6 sice neni VPN treba pro zabezpeceni prenosu, ale VPN se pouziva i na spoustu jinych veci, proto je v IPv6 VPN potreba taky".

Neboli nedorozumeni mohlo vznikout pouzivanim prilis bombastickych tvrzeni.

[Petr Bravenec]

Ahááááá, vy jste si nepřečetl ani nadpis!

Ten článek se jmenuje "IPsec na IPv6" a věnuje se čistě zabezpečení přenosu, ničemu jinému. Kdyby se jmenoval "Význam tunelovacích technologií v praxi síťového administrátora" a já bych v něm rozebíral zbytečnost tunelů, teprve pak by šlo o nedorozumění.

[Ondrej 'SanTiago' Zajicek]

Clanek (a nadpis) jsem si precetl, ale me i tve reakce v tomto threadu dalece presahuji pouze oblast zabezpeceni prenosu. Napr. veta "Ale myslím si, že pojem VPN s rozšířením IPv6 zmizí, ztratí význam." lze tezko chapat pouze v kontextu zabezpeceni prenosu.

Jinymi slovy, tve reakce vypadaji, jako by vychazely z implicitniho predpokladu, ze lide pouzivaji VPN hlavne kvuli tomu, aby obchazeli problemy spojene s IPv4 a privatnima adresama a vzajemnou neviditelnosti. Ja tvrdim, ze v znacne casti pripadu tomu tak neni.

[Petr Bravenec]

Několikrát jsem tady v diskusi řekl, že většina VPN, na které v praxi narážím, neslouží k zabezpečení, případně k němu nijak významně nepřispívají.

A ano - většina VPN, na které narážím, je nainstalovaná právě k tomu, aby se obcházely problémy s NAT v IPv4.

Může to být dané okruhem mých zákazníků.

S IPv6 by většina těchto VPN nevznikla a s přechodem na IPv6 jejich existence ztratí smysl. Pro ty "administrátory", kteří tyto VPN uváděli v život, ztratí tím pádem svůj význam i VPN. Přestanou se těmito VPN zabývat, začne to pro ně být prázdné slovo. Na jednoho člověka schopného pochopit a nastavit skutečný tunel bude připadat dvacet dalších, pro které bude tunelem šifrování hlaviček v IPsec, případně si nepředstaví vůbec nic. Slovo VPN a tunel z jejich slovníku zmizí, tak jak přestanou tuto technologii používat.

Abych nebyl nařčen, že "všechny tunely přece neslouží pro obcházení natu", podotýkám, že potkávám i tunely a VPN, které slouží svému účelu dobře a budou sloužit i nadále.

[sigma]

Ony ty tunely "na obcházení NATu" nejsou jen kvůli tomu NATu. Není výjimkou, že pro notebook někde dostanete veřejnou IPv4, ale příchozí spojení jsou blokována, a pro odchozí jdou jen porty 80 a 443. Proto často buzzword "SSL VPN, connect from any network". A tohle se s IPv6 nikterak nezmění. Kde mají administrátoři důvod dělat takovéto firewallové obstrukce, tam IPv6 nepomůže. Kde není fw až takto restriktivní, bývají obvykle blokovány SMTP porty, a to IPsec fakt neřeší. SSL VPN ano.

Když máme na IPv6 ten IPsec povinně podporovaný, není pak zbytečné i HTTPS? Ono bude v praxi velký rozdíl v tom, co říká o podpoře různých IPv6 features standard, a co se bude v reálných sítích často blokovat a zakazovat, a jaký společný základ, na který se lze jakž-takž spolehnout, z toho vznikne. Tohle bude podle mě i zabiják pro větší využitelnost mobility extensions.

Pro člověka cestujícího s notebookem je u VPN podstatné, že se do firemní sítě bezpečně připojí všude, kde je "internet" -- rozuměj tam, kde jde otevřít facebook přes HTTP(s).

[Ondrej 'SanTiago' Zajicek]

I v tomto případě je šifrování jen zabezpečením existující cesty a speciální "linku" tvořenou pomocí VPN nepotřebuje

Tu virtualni linku potrebuju uz jen kvuli tomu, abych na ni mohl pusit OSPF. I kdyz je pravda, ze v tomto pripade by asi stacilo mit OSPF jen na opticke linke a zbytek nechat na defaultni route, cistci reseni by asi ale bylo mit OSPF na obou.

[Petr Bravenec]

Proč vytvářet nějakou speciální "linku" kvůli zabezpečení, když cesta už existuje a stačí jen zapnout šifrování?

Ale ta linka (tunel) se nevytvari kvuli zabezpeceni!

Ta linka se především vůbec nevytváří. Ta linka už existuje.

[Ondrej 'SanTiago' Zajicek]

Ta linka se především vůbec nevytváří. Ta linka už existuje.

linka (ve smyslu ptp spoj tvarici se vicemene jako jeden hop, fungujici vicemene na linkove urovni, transparentne bez ohledu na zdrojove a cilove adresy) neexistuje, existuje akorat cesta vedouci skrz nekolik (obvykle cizich) routeru.

[Atom321]

V tunnel modu (pokud je to tak nastavené) se dá přenášet i jiný protokol než IPv6. To je pro postupný přechod z IPv4 dost důležitá věc.

[Kvakor]

V Linuxu jsou dokonce ošetřeny obě možnosti tím, že se dá vybrat mezi zaříením TUN a TAP. Zatímco to první se chová jako klasický tunel na IP vrstvě (tj. jde skrz něj routovat), TAP se chová jako bridge, takže vzálený stroj jen na tom stejně, jako kdyby byl zapojen do místního switche. V ideálním světě by stačila ta první možnost, ale bohužel je tu třeba i ta druhá, protože některé trhlé protokoly (např. sdílení ve Windows) fungují jen na lokálnáí síti.

[Ondrej 'SanTiago' Zajicek]

TUN a TAP zarizeni ve skutecnosti s tunelovanim a VPN nemusi dvakrat souviset - to jsou akorat rozhrani urcena pro predavani packetu do userspace. Samozrejme mnohe tunelovaci nastroje jako OpenVPN jsou implementovane v userspace a tak tato rozhrani vyuzivaji, ale jine (treba jiz zminene GRE) jsou implementovane prevazne v kernelu a nic takoveho nepotrebuji.

[Michal Kubeček]

Odkazovaný článek používá PSK, to má smysl v podstatě jen tam, kde není jiného zbytí - např. když protistrana nic jiného neumí. Je-li na obou stranách Racoon, upřednostnil bych certifikáty.

[Petr Bravenec]

Není to v některých případech trochu overkill? Mám-li takto propojené dvě pevné sítě, je starost o certifikáty jaksi navíc...

[Michal Kubeček]

PSK je pořád shared secret, tj. tajná informace sdílená na obou stranách. Což není šťastné ani z bezpečnostního ani z praktického hlediska. Při použití certifikátů má každý uzel svůj pár klíčů a ten může používat pro komunikaci se všemi ostatními.

[Atom321]

Při použití certifikátů má každý uzel svůj pár klíčů a ten může používat pro komunikaci se všemi ostatními.

"Všichni ostatní" jsou v tomto případě jeden uzel - brána druhé LAN. Kompromitace jednoho uzlu tedy vždy znamená odhalení veškeré šifrované komunikace. Jaký je tedy v tomto případě praktický a bezpečnostní rozdíl mezi certifikáty a PSK?

[Josef Kufner]

Že nic neodhalíš. Pokud je použito asymetrické šifrování, tak ti je klíč k serveru na nic, protože si nepřečteš už zašifrované pakety od ostatních. Můžeš se vydávat za ten kompromitovaný uzel, ale to je tak všechno.

[Petr Bravenec]

Nepletu-li se, IKE2 server domlouvá pro každé spojení nové klíče, navíc v každém směru různé.

Takže stejně jako s certifikáty, ani s psk nic neodhalím. Můžu se vydávat za ten kompromitovaný uzel, ale to je tak všechno.

Heslo není špatně. Privátní klíč bez hesla a volně uložený na disku je totéž, jako heslo zapsané v souboru. Z hlediska bezpečnosti to vyjde na stejno a nastavení pro pár šifrovaných kanálů je s heslem neporovnatelně jednodušší.

[Josef Kufner]

To že se domlouvají klíče je úplně jedno, pokud zachytíš domluvu. U sdíleného hesla máš na obou stranách totéž, takže můžeš dopočítat klíče úplně stejně jako to dělá server. Pokud máš jen půlku klíče, tak máš smůlu (nebo je to alespoň o poznání těžší).

[Petr Bravenec]

Domluvu nezachytím. Při navazování spojení mezi dvěma IKE servery se v prvním kroku vytváří šifrovaný kanál pomocí jednorázových asymetrických klíčů, teprve potom se ověřuje totožnost (heslem či certifikátem). Z tohoto pohledu je bezpečnost hesla i certifikátu stejná.

Výhodu certifikátů bych viděl spíš jinde: s přibývajícím počtem připojených klientů stoupají nároky na správu certifikátů mnohem pomaleji, než u hesel. U pěti statických linek je správa hesel snadná. U patnácti neposedných klientů už mohou být hesla administrátorovou noční můrou a certifikáty vysvobozením.

[Josef Kufner]

Kdybych si z diskrétní matematiky pamatoval, jak se ty jednorázové klíče počítají, tak bych ti teď asi vysvětlil, že se sdíleným heslem to bude mnohem snáze prolomitelné, protože máš v těch rovnicích o jednu neznámou méně.

[petr_p]

Mnohem snáze je stále příliš obtížné. Obvykle se používá něco na způsob Diffie-Helmanna. Dokonce existuje rozšíření do TLS, kde klient zná otevřené heslo a server zná pouze jeho „otisk“ a přesto se dokáží obě strany vzájemně autentizovat.

[alkoholik]

Prosil bych v odkazovanem clanku nahradit MD5 a 3DES necim na urovni roku 2011.

[Petr Bravenec]