S tim, ze je intalace jednoducha musim souhlasit. Po zkusenostech s IPSEC pred nekolika lety (kernel 2.4, FreeS/WAN), kdy jse me nepodarilo rozchodit Woknous stranu, jsem byl pripraven na nejhorsi. Intalace v rezimu sdileneho klice je tak snadna, az primitivni. Odolnost spojeni na mizerne lince me taky uvadi v uzas.
Pouzivam OpenVPN vyse pol roka a mozem len suhlasit s chvalami, jedinou chybyckou krasy s ktorou som sa stretol je ze sa linuxovy server po preruseni spojenia nevrati do listen modu (skonci) ale na to staci banalny skript.
Divne ze sa o nom nepisalo aj skor, tento softver ma skvelu interoperabilitu aku len tak nenajdete. Fajn vecou je moznost fungovat cez TCP, zvlast ked na hop od klienta nie je moznost nastavit NAT (alebo mate ISP pridelujuceho neroutovatelne IP).
Este dolezita vec: http://secunia.com/product/3952/
(samozrejme SSL treba mat zaplatane)
PS: Spomenul niekto ze to na *nixoch vie pouzivat ethernet bridging cez TAP (tunelovat aj broadcasty)?
Tunelovat IP přez TCP a ješte přez proxy je zoufalost. Uznávám ale, když to jinak nejde (zdravíme koleje ZČU Plzeň), tonoucí se rád stébla chytne.
Jinak pro ostré nasazení snad jen přez UDP, ale ja bych asi vždy radši zvolil IPSEC.
Je prudce stabilni, konfigurace de taky zvládnout, asi před půlrokem tu vyšli výborné články, nakonfigurujete ho i proti "proprietárním řešením" na proprietárním hardwaru či operačním systému.
Osobně bych za proprietární označil spíš OpenVPN
'Tunelovat IP přez TCP a ješte přez proxy je zoufalost.' - suhlasim, ale kazdopadne je to velka vyhoda... zvlast, ked sa niekto ocitne v desne paranoidnej korporacii, kde je mozny pristup na internet iba cez http proxy.
IPSec ma, ako je zname, problemy s NAT (zmeni sa jedna z adries packetu a potom nesedi checksum). Samozrejme existuju rozne NAT traversal finty, ale to je len zaobalenie AH/ESP protokolu do UDP.
Ku kompresii: IPSec zvycajne pouziva na svojej vrstve podstatne vacsie packety (16384 B aj s hlavickami) co umoznouje lepsi kompresny pomer; OpenVPN ma adaptivnu kompresiu, t.j. to co nevie dobre zbalit, vobec nebali.
TUN/TAP ifc je mozne dat do bridge spolu s vnutornym eth ifc firewallu a pridelovat klientom IP cez DHCP + cez to prelezu vsetky mozne windozove broadcasty, takze klient to tak ako by bol vo vnutornej lan.
Moj rezultat: IPSec na budovanie NET <-> NET VPN; OpenVPN jednoznacne pre roadwarriorov...
Btw neviem ako inde a ako to je teraz, ale na Slovensku napr. cez chello su povolene iba protokoly ICMP, UDP a TCP, takze IPSec no-way... skusal som to dost davno, mozno to je uz inak.
Zdravim
Taky jsem pred par mesici pouzival OpenVPN. Server v multi klient modu bezel na linuxu, klienti na win 2K/XP. Bez jedinyho problemu.
Akorat jeste musim podotknout ze podpora multi klient serveru je zatim v beta fazi, nicmene me to fungovalo bez potizi. V posledni stable verzi to jeste neni.
Zdenek
Nu, autor by mel poznamenat jednu vec. A to, ze pokud se je klient na windozich, tak je nutne, aby klientska adresa a serverova adresa byla z jedne site s maskou 255.255.255.252, coz neni principielne omezujici, nicmene to vcelku zvysuje "rozsah" ruznych IP adres na serveru a vypis rozhrani pak vypada "nepekne".
maskarada NENI specialni pripad snatu.
shoduji se v tim, ze obe prekladaji zdrojovou adresu
lisi se v tom, ze se SNAT neni problem restartovat masinu ktera SNAT provadi - tcp konexe drzi az po regulerni timeouty.
zkuste to udelat se strojem co dela MASQUERADE a pak vas to mozna donuti podivat se v cem se lisi... - mozna uz tusite - tcp konexe proste pokud existuje pred "zprovoznenim" maskarady, tak se neprelozi.
Na tunelovani pouzivam (prozatim) CIPE a tam jsem si zvykl na jednu moc peknou vlastnost. Novy virtualni interface muze mit stejnou IP jako v systemu jiz exitujici fyzicky adapter. Vypada to treba takto:
eth0
Link encap:Ethernet HWaddr 00:12:34:56:78:90
inet addr:10.1.106.64 Bcast:10.1.106.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
cipcb0
Link encap:IPIP Tunnel HWaddr
inet addr:10.1.106.64 P-t-P:10.1.108.16 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MTU:1442 Metric:1
Prislusna route pak vypada:
10.1.108.0 * 255.255.255.192 U 0 0 0 cipcb0
Jde tohle i s OpenVPN (TUN/TAP)?
hlavne bych rekl, ze je to v prve rade "nebezpecny" kdyz vypadnou oba konce porad to funguje, ale data kazdy vidi.
s openvpn to teoreticky fungovat musi taky, protoze to je vec nastaveni smerovacich tabulek jadra a cipu i openvpn to je suma fuk, jak se to nastavi.
btw co delate kdyz vypadne jeden konec? to pak nemuze fungovat...
S tim stretem filozofii souhlasim. Taky jsem na to docela ziral, kdyz jsem na to v dokumentaci narazil. Dobre je to videt tady: http://sites.inka.de/bigred/devel/cipe-doc/cipe_5.html#SEC30
Jen ze zvedavosti, pokud by ta "spojka" byl klasicky PPP spoj, jake IP adresy byste pro koncove body PPP pouzil? Oba body by spolecne patrily do jedne ze siti, kazdy bod by patril do sve site (na svem konci) a nebo byste udelal samostatnou sit? :-)
How-to:
1. Na klienta nainstalujes OpenVPN
2. nastavis spojeni podle tohodle clanku
3. zkusis ping, jesli se to spolu bavi
4. overis, jesli tap0 je rozhrani, kde samba ma dovoleno komunikovat (smb.conf)
5. jesli mas nastaven ipsec firewall, povol pruchod pres tap* rozhrani na porty samby
Jak proste
Jak mam docilit, aby pocitace "za" serverem s OPENVPN na interni siti interniho sit. rozhranni "videly" pocitac na Internetu, ktery je pripojen se serverem pres OpenVPN v SAMBE pres druhe(externi) sitove rozhranni ? Vidim jen prazdnou pracovni skupinu. ;o(
Na serveru se pingnu na adresu druheho rozhranni, stejne tak na vzdalenem pocitaci se pingnu na IP adresu serveru nastavenou v OpenVPN, takze tunel je propojen.
Poradite ?
Jestli jsem spravne pochopil dotaz, tak na to se pouziva parametr samby "remote announce", ktery urcuje, kam jeste se maji posilat broadcasty pro "network neighbourhood".... Alespon ja takhle v nasi domene vidim pocitac z hostingoveho centra, ktery je pristupny pres OpenVPN.
Onedlho budem nuteny pristupovat do firemnej siete cez VPN/IPsec. Chcel by som, aby som na to mohol pouzivat moj pocitac, na ktorom bezi Debian (Linux kernel 2.6.x). Na serveri (vo firemnej sieti) nebudem moct menit ziadne nastavenie. Na klientskej strane by sa mal pouzivat VPN klient pre Win (tusim nejaky Conectivity VPN, alebo ako sa vola).
Otazka znie: je mozne rozchodit doma VPN, ktore budem moct pri danych podmienkach pouzit, a ak ano ako-na-to, kde ziskat informacie...
Ak by sa mi to podarilo, nebudem nuteny instalovat doma Win, resp. nosit domov firemny notebook.
Ja teda doted pouzivam pro tyto ucely SSLtunnel:
http://www.hsc.fr/ressources/outils/ssltunnel/
coz umi pouze tunel pres SSL a pripadne pres proxy. Konfigurace je celkem jednoducha a nepouziva to tun interface ale ppp. Hlavni nevyhodou je to, ze to existuje pouze na Linux a unixy, ne na Widle.
Takze asi vyzkousim tu OpenVPN. Pokud to umi SSL tunel s pouzitim SSL certifikatu, je to prese to co potrebuju na prochazeni firewallem :)
pouzivam ovpn s ssl certifikaty pro pripojeni pres 3 ne moc spolehlive wifi spoje.
konfigurace ssl (tvorba vlastni cert. autority a klicu pro obe stany) i obnovy tunelu po vypadku (pingani, nahazovani spadleho tunelu) je dobre popsana v HOWTO:
http://openvpn.sourceforge.net/howto.html
funguje k plne spokojenosti z linuxu i windows.
Mam takuto situaciu:
Jedna strana:
Skola ma linux server, ktory je pripojeny do sveta cez ADSL, ale nema verejnu IP, iba privatnu IP (10.1.2.1), takze je zrejme, ze je to este providerom NAT-ovane. Ale neviem, kolko takych NAT-ov v ceste od providera do Internetu este je. A nepoznam ani verejnu adresu providera (ale slo by to isto zistit, napr. traceroute.)
Druha strana:
Moj server s Linuxom na WI-FI sieti providera, zase s privatnou adresou (10.1.2.x), ani tu neviem, kolko je este v ceste roznych firewallov a nepoznam verejnu IP adresu.
Potrebujem z mojho linux servera sa spojit na skolsky server a spravovat ho aj z domu.
Ako tu sprevadzkovat VPN? Co musim po provideroch pozadovat? Musi mi provider "otvorit" prislusny port?
(Priznavam, ze s teorii VPN niesom este doma...)
Vdaka.
Je potreba, aby se oba pocitace "videli" alespon na jednom portu (ne nutne stejnem). Nejlepsi by bylo mit nejaky pocitac s verejnou adresou a rychlou linkou, ktery by fungoval jako prostrednik.
Pokud to neni k dispozici, tak je potreba umluvit providery, aby oba pocitace byly pod nejakou kombinaci (a pevne danou) IP a portu zvenku pristupne.
neni nezbytne, aby byly oba pocitace viditelne a dostupne pres verejnou IP. Nutne je pouze jeden konec dostupny pres verejnou adresu a port. Adresa muze byt i dynamicky podle DNS. Port muze byt klidne forwardovan na cilovy stroj s naslouchajicim OpenVPN. Pokud oba stroje nemaji verejne dostupny aspon jeden port na nejake IP, tak musis bud nekoho umluvit, nebo ti nekdo musi delat server a ty se tam pripojis pres VPN k nemu a k nemu se pripoji i server ve skole. Proste jeden konec musi jit kontaktovat (logicky), potom neni problem. Pokud je odchozi adresa promenna, tak doporucuju pouzit certifikat, aby se tam nekonektil kde kdo.
Ty dva stroje na sebe nemusí nutně přímo vidět. Pokud jsou všechny NATy po cestě dostatečně "rozumné" a zachovají číslo UDP portu, tak stačí nastavit jako remote stranu veřejnou adresu posledního NATu protistrany a taky dostatečně malý ping, aby v některém NATu nestihnul vypršet timeout. Obě strany vlastně kopou tunel a potkají se někde uprostřed.
Použil jsem GUI 1.0 beta 22 v kombinaci s VPN2.0beta15
Když zadám cestu před .p12 a nezdám cesutu před dh soubor tvrdí že nemůže najít openVPN, dh je zkontrolován v pořádku.
V případě že nezadám, žádné cesty a oba soubory umístím do adresáře, kde je umístěn openvpn proběhne jako by inicializace, ale pak nahlásí, že nemůže nalézt dh soubor.
Vím že článek je starší, ale třeba mi někdo poradí:
měl jsem Motorolu Droid 4, rootlou, kde mi bez problému běželo Open VPN, tedy při využití připojení od mobilního operátora jsem se dokázal dostat na naší vnitřní sítě.
S novým telefonem, kde je rootnutí trochu problém, nejde Open VPN spustit. Je na to nějaké řešení?
Díky předem