Názory k článku Tuneluji, tuneluješ, tunelujeme: IPSec

vdaka

mno dobre a co kdyz jsem na wifi, za maskaradou a mam na netu server pres ktery bych chtel jet. tzn kdykoliv pustim muj domaci stroj, tak aby nahodil ipsec na ten stroj na netu a tim padem sifroval komunikaci az na ten stroj. ten stroj ale nesmi automaticky navazovat spojeni ke me jen pasivne cekat na koneksi ode me.

Dale v clanku jsem nejak nenasel jesli ipsec jede nad udp nebo tcp

Dejte auto=add. Tunel bude pridan, pokud se jej nekdo pokusi nahodit (i zvenku), tak nabehne, ale IPSec na teto masine jej sam startovat nebude.

Ad protokol: Mozna jste to tam nenasel proto, ze nejede ani nad jednim, alebrz nad dvema vlastnimi IP protokoly (ESP a AH) :-)

Ale s IPSecem pres nat budete mit problemy. Viz http://www.cisco.com/warp/public/759/ipj_3-4/ipj_3-4_nat.html

Je mozne pouzit NAT-T (NAT traversal) mode, ktery bali ESP a AH pakety do UDP, ktere jiz NATem projdou. Samozrejme je nutne mit podporu na obou stranach tunelu.

Taky stoji za zminku Super FreeS/WAN - tedy hodne opatchovana verze freeswanu, ktera obsahuje mj. i ten NAT-T, dal podporu pro X.509 certifikaty, a mnoho dalsich uzitechnych vychytavek:

http://www.freeswan.ca/

No ja by som dodal ze to nie je celkom pravda. Na negociaciu klucov sa pouziva IKE co je UDP port 500 a potom sa pouziva bude ESP alebo zastaralejsie AH. Komercne implementacia vacsinou AH nepouzivaju alebo snazia sa nepouzivat. V pripadoch kde nie je mozne pouzivat L2 protokoly, je mozna UDP encapsulacia a teda je mozne mat aj IPSEC cisto cez UDP.

Jedna sa o ciastkove informacie, ktore by si jeden mohol zle vysvetlit...

Hlavny rozdiel medzi ESP a AH je, ze:
ESP = "!confidentiality guarantee! for packets, by encrypting packets..."
a AH = "provides !authenticity guarantee! for packets, by attaching strong crypto checksum to packets...". Teda zalezi len na tom, co povazujeme za bezpecnejsie, ci zakryptovat cely packet, alebo len pridavat kryptovane checksumy. Stale ale mame na vyber aj ESP aj AH!

Neda sa teda jednoznacne povedat co je zastaralejsie. ?Mozno len vzhladom na casovu chronologiu ich vzniku?

zdroj: www.netbsd.org/Documentation/network/ipsec/

Předně bych chtěl pochválit kvalitu všech tří dílů o tunelování. V praxi je často takovýto návod k nezaplacení.
Zajímalo by mne, do jaké míry jsou použitelná řešení v praxi, kdy konce tunelu nejsou provozovány na stejné platformě. Zajimá mne kombinace Microsoft a linux, Cisco a linux.

IPSec spojení mezi Linuxem a WinXP jsem testoval, návody jsou na stránkách FreeS/WANu (i když pozor, jsou tam trošku nepřesně popsána generování certifikátů, musel jsem si to dogooglovat, nakonec jsem to nastavoval podle nějakých stránek v němčině - mám je stažené, kdyžtak můžu zaslat), pouze je nutno ověřovat připojení přes klientske certifikáty. Problém nastane v okamžiku, kdy potřebujete na protunelovaná data nasadit firewall nebo NAT, protože všechny mnou testované programy pro Windows (samozřejmě včetně těch, co jsou přímo v systému), které jsem zkoušel, filtrují a překládají pouze to, co najdou na síťovém rozhraní. To, co vyleze z tunelu, už ignorují. Takže třeba v mém případě byly Windows nepoužitelné, protože jsem IPSecem tuneloval pouze přes wifi spojení, přes které jsem napíchnutý do Internetu. :-( Ale při propojení třeba dvou poboček nebo pro napíchnutí do firemní sítě zvenku by mělo spojení Linux <-> Windows fungovat celkem spolehlivě.

Spojenie Cisco a Linux (ale aj Cisco a Checkpoint) je problematicke koli implementacii. Cisco si nie vzdy dobre rozumie s VPN peer pokial sa pouzije Diffie-Helmans (takto sa to pise? ;) Group 2 a Freeswan pouziva Group 2, podobne ako vacsina inych rieseni.

Přesně toho jsem se obával, že Cisco - Linux nebo
Win XP - Linux nebudou mit uplne stejnou implementaci IPsec. Je to skoda, protoze v praxi jsou obvykle potreba prave tyto ruznorode pripady.

Moment, komunikace Windows <-> Linux jde nastavit tak, aby šlapala bez problémů. Jediný problém je v tom, že windowsový konec tunelu se vynořuje až za případným firewallem nebo NAT, takže se tyto technologie nedají ve spojení s IPSec pod Windows použít (pokud někdo ví, jak by to přece jen šlo, nechť se ozve, zajímá mě to). Čili pokud nepotřebujete překládat adresy nebo filtrovat pakety (což u většiny sítí potřeba není, pokud propojujete pobočky, obvykle si vystačíte s normálním routováním), je možné to dostupnými prostředky zajistit.
Jak je to s Ciscem nevím...

Predpokladam, ze ta sit 192.168.0.0/16 ma spatnou masku. Mela by mit /24, jinak by se pocitace na teto siti snazili dorucit pakety do site 192.168.1.0/24 lokalne. Jinak Lemmingu skvely clanek ;-)

O nikoli. Narozdil od minuleho clanku ( :-) ) je to tu dobre. Pocitace v siti maji routu do 192.168.0.1/24 do lokalni site pres kterou jsou pripojeny, default gateway pres koncovy pocitac IPSec tunelu. Na tom jsou pravidla 192.168.0.1/24 do lokalni site a 192.168.0.0/16 do tunelu. Protoze se pri routingu preferuje delsi prefix, tak to bude fungovat spravne. Na druhem konci zadne problemy nevzniknou, nebot tam se podle te specifikace s /16 nic nevytvari.

Bude dalsi dil venovany subj. nebo to je jiz konec ?
Nejaky navod jak pres FreeSwan zprovoznit
bezpecnou komunikaci definovanych uzivatelu v Internetu
do LAN pres VPN a MASKARADU by se hodil.
Diky za odpoved.

Dil bude (nektere vychytavky). RoadWarriory jsem nikdy nepripojoval (natoz pres maskaradu), takze tim nemohu slouzit. Ale neco o maskarade se pise v prispevcich vyse.

Adresy su fiktivne ale konfiguracia je pripadom nasadeneho riesenia. Maly problem je ze to nie je Xauth a teda bezpecnost to nie je bohvieaka. Neviem ci je mozne vobec Xauth s freeswanom.
Da sa to upravit na X509 certifikaty, ale to je narocnejsie na nasadenie.

conn win2k1
right=162.22.175.140
rightnexthop=162.22.175.137
rightsubnet=10.1.0.0/16
left=%any
keyexchange=ike
rekey=no
auth=esp
authby=secret
auto=add

S xauth je problém. Pokoušel jsem se to rozchodit proti Ciscu a z toho co jsem našel, jsem vyrozuměl, že to FreeSWAN neumí.

Right a Left se nemini v konfiguraci jako prava, leva, ale jako (R)emote, (L)ocal.

Na tom jsem pred rokem pohorel a na druhe masine jsem musel prohodit hodnoty Right<->Left, abych tunel rozbehl.

A proc se tedy nastaveni jmenuji left a right? ;-) Asi jste mel nekde chybu (nebo stara verze SW?), me to zcela bez problemu chodi s identickou konfiguraci na obou koncich.

Nemáte pravdu. Naopak, označení left a right se používá právě proto, aby tak konfigurace mohla být přesně stejná na obou koncích. Máte to napsáno i v dokumentaci.

My jsme nedavno resili problem, ze freeswan umi na kazdem konci (levem i pravem) jen jednu sit. Kdyz pak mame z centraly tunely do pobocka1 a pobocka2, chodi z centraly vse OK, ale z pobocka1 se do pobocka2 nikdo nedostane. Musel by se vyrobit kanal p1-p2, coz bohuzel znamena pri vzrustajicim poctu pobocek nutnost mit n^2 kanalu. Druhe reseni je NAT n:1, kdy se sit kazde pobocky na centrale premapuje na jednu IP ze site centraly (fuj!).

Nemate s tim nekdo zkusenosti, nejake lepsi reseni?

No, pokud to budes dusledne konfigurovat tak, jak je to naznaceno v clanku, tak to bude fungovat s n tunely, kde n je pocet pobocek bez centraly. Mejme firmu, sit 192.168.0.0/16. Centrala samotna ma 192.168.0.0/24, pobocka 1 192.168.1.0/24, pobocka 2 192.168.2.0/16. Trik je v tom, dat do konfigurace pro konec tunelu na centrale sit 192.168.0.0/16. Pokud z pobocky 1 chci na pobocku 2, pujde to podle pravidla 192.168.0.0/16 na centralu a tam na pobocku 2. Samozrejme v tomto pripade jde vsechno pres centralu, pokud by to vadilo, mohou se nektere tunely udelat naprimo. Viz take moje odpoved Pavoukovi vyse.

Dakujem autorovi za tieto vydarene clanky.

Jaka leva a prava strana, cetli jste snad RFC k IPSecu, tak prosim pouzivejte me oblibene Alice a Boba :-)

Zdravim

Clanek je sice napsany pekne, ale pro me neuzitecny. Ja bych radsi uvital cesky a srozumitelny navod na vtun nebo openvpn (coz je standardem v czfre, jak se zda). O vtun jsem se snazil nekolikrat, ale vzdycky me to dohanelo k silenstvi. Ale jakozto clen czfree nutne potrebuju tyhle tunely umet.

Zdenek

No, clanek jiste nebyl zamyslen tak, aby byl uzitecny kazdemu. Roota jiste cte mnoho lidi, kteri s tunelovanim nemaji prazadnou zkusenost a ani ji mit nechteji. Ja osobne jsem potesen tim, ze se nekdo do nepochybne zajimave problematiky tunelu pustil a dobre ji osvetlil. IPSec je v podstate nejperspektivnejsi (nejen) tunelovy protokol a proto nevidim duvod, proc ho vylucovat jen proto, ze na CFN se pouzivaji nejaka necista reseni typu openvpn ci vtun. Navic pochybuji, ze by radovy clen CFN musel o techto vecech neco vedet.

Zdravim

Ja nesnizuji uzitecnost toho clanku, ale OSOBNE si myslim, ze dnes se pouzivaji spis ty dva programy co jsem napsal. Vysvetli mi prosim proc je povazujes za neciste? Me tenhle IPSec pripada podobny jako sed (alespon podle toho jak jsem cetl ten serial). Je to sice skvely program, ale pouzitelny pouze pro skutecne guru. Bezni uzivatele podobnych programu sahnou radsi ko komplexnejsim a jednodussim baliku.

Radovy clen to opravdu vedet nemusi, ja jsem koordinator okresu decin a mam prsty ve dvou metropolitnich sitich.

http://dcfreenet.rokaglass.com
http://zstepanek.rokaglass.com

Zdenek

IPsec je nejperspektivnější zejména proto, že je součástí IPv6. Takže si na něj budete muset dříve či později zvyknout. Ostatní řešení jsou "nečistá" proto, že jsou proprietární - vtun funguje jen proti vtun, openvpn jen proti openvpn. Použijete-li IPsec, je (až na drobné problémy s interoperabilitou) jedno, kterou konkrétní implementaci (a jakou platformu) použijete na kterém konci. A to je obrovský rozdíl.

No dobra, dejme tomu ze to bude standard. Mam ale ejdnu otazku. Funguje to jako peer-to-peer nebo jako client-server? Z clanku jsem pochopil ze jako PtP (Alice vs. Bob). Jenze ja potrebuju CS, abych mohl pripojit male lokalni site s neverejnymi IP na nejaky centralni verejny uzel. Todle ma zase pekne udelane vtun, primo se mu urci kde je klient a kde server.

diky za radu.
Zdenek

Tak takovy clanek bude muset napsat nekdo jiny, nebot ja s timto nemam prazadne zkusenosti (a pochybuji, ze se v okoli meho bydliste v dohledne dobe objevi bod CZFree :-).

Zkousel jsem rozjet IPSec na Mdk9.1 a pri loadovani prislusneho kerneloveho modulu jsem dostal hlaseni, ze modul byl prelozen gcc v.2 zatimco kernel gcc v.3. Podarilo se nekomu IPSec pod Mdk 9.1 rozchodit?

Takze, mozna to bude pusobit zmatene, ale delam co mohu. Nekolik veci:
1. Stahnout zdrojaky z freeswan.org, rozbalit dle navodu, jsou to sice RPMka pro RH, ale narval jsem je uspesne i do Slacku.
2. Rekompilovat kernel vcetne IPSecu.
No a je to.
Mimochodem, zkusil bych zkontrolovat skripty, a pokud je volani knihoven ze skriptu, nedival jsem se zda ano ci ne, zkusit loadovani modulu volat s direktivou -f.

Snad to pomuze.

Da se to vyresit i bez rekompilace kernelu, a sice:
1) cd /lib/modules/verze-kernelu/kernel/net/ipsec/
2) gunzip ipsec.o.gz
3) vi -b ipsec.o, najit gcc2_compiled a nahradit za gcc3_compiled, pak soubor ulozit.
4) gzip ipsec.o
To je vse, ipsec pak chodi bez problemu (testovano jak na normalnim tak secure kernelu).

Dobrý den,
musíte udělat určitou úpravu souboru
/lib/modules/2.4.21.-0.13mdk/kernel/net/ipsec/ipsec.o.gz
ten soibor odzipujte, nalezte v soiboru řetězec gcc2 a nahraďtě gcc3 a zase zazipujte a ipsec by měl začít fungovat. Alespoň mě se rozjel.

Mam palma a ipaq 3870 s linuxem. ipsec byl pro mne pred timto serialem spanelska vesnice. Na palmovi mam rozjete pptp do firemni site (pres mobil, GPRS eurotel i paegas). Stojim pred rozhodnutim rozjizdet na ipaqu v linuxu ipsec (numusim kompilovat jadro ale nerozumim tomu a nevim jestli to bude v praxi fungovat) nebo pptp (je treba prekompilorat pppd a moduly do jadra ale zase tomu trosku vic rozumim a vim ze to funguje). Co byste poradili? Ja bych asi jako prvni zkousel pptp. Jsou u ipsec vetsi problemy s dialupem a dynamickymi adresami? Muzu cekat ze s ipsec budou vetsi problemy co se tyce otevrenych portu a kompatibilitou s nasimi mobilnimi operatory a jejich gprs konfiguracemi? Pptp s palmem jede v pohode. Je realne rozjet ipsec pres mobil do firemni site? Server je nepochybne nejake windows. Kolegove spravci se dusujou ze s widows klientem se dovnitr pres ipsec dostanou.

Dik za tipy.

F

Vlastní přenosové protokoly AH a ESP žádné porty nepoužívají, běží přímo nad IP. V tom ale je také hlavní kámen úrazu, pokud provider provádí nějakou (byť třeba transparentní) formu NAT. Pokud máte skutečnou IP konektivitu bez dalších obezliček (typu NAT), neměl by být s IPsec problém.

1) Pekny clanek
2) Nejsem zadny odbornik, ale jednou jsem narazil na jednoduchy tunel Zebedee http://www.winton.org.uk/zebedee/ - je to rychle, jednoduche, chodi to take mimojine pod Windows a da se s tim uzit spousty legrace :-)

Potřebuji udělat tunel mezi Ciscem a linuxem. nevíte někdo jak se nastavuje linux?
Dik