VPN siete s OpenVPN (2)

VPN siete s OpenVPN (2)
28.10.2008 09:45 | Články | Jaroslav Imrich
Teoretické poznatky o VPN sieťach z minulého dielu dnes rozšírime o prvú praktickú skúsenosť. Názorne si predvedieme nasadenie OpenVPN v najjednoduchšej forme t.j. vo forme VPN serveru pre jediného klienta s využitím statického šifrovacieho kľúča.

1. Statický kľúč vs. certifikáty

Jednou z kľúčových vlastností každého VPN riešenia je šifrovanie, ktoré zabraňuje nielen odpočúvaniu prenosov ale aj neoprávnenému pozmeneniu prenášaných údajov. Šifry môžeme vo všeobecnosti rozdeliť na symetrické a asymetrické.

Symetrické šifry zväčša využívajú na šifrovanie údajov i na ich dešifrovanie jedno tajomstvo - v prevažnej väčšine implementácií je to heslo. Dáta zašifrované nejakým heslom je možné dešifrovať len tým istým heslom. Hlavným problémom tohto spôsobu šifrovania sa teda logicky stáva bezpečná výmena hesla medzi zúčastnenými stranami.

Asymetrické šifry narozdiel od symetrických, používajú kľúčový pár (napr. RSA) pozostávajúci z privátnej a verejnej časti. Dáta zašifrované verejným kľúčom je možné dešifrovať len privátnym kľúčom a naopak. Preto verejná časť kľúčového páru môže byť distribuovaná aj po nezabezpečenom kanáli. Viac o používaní asymetrických šifier sa môžete dozvedieť z článku Sila GnuPG.

OpenVPN podporuje obidva uvedené spôsoby šifrovania. Symetrické šifrovanie sa využíva v móde s tzv. statickým kľúčom a asymetrické šifrovanie v móde využívajúcom certifikáty. Základný zoznam vlastností oboch riešení som zámerne nerozdelil na výhody a nevýhody, pretože vždy závisí od konkrétneho prípadu a našich požiadaviek, či je daná vlastnosť výhodná alebo nevýhodná.

Riešenie so statickým kľúčom:

   -využíva symetrické šifrovanie
-jednoduchá konfigurácia
-nemusíte prevádzkovať certifikačnú autoritu
-na server sa môže pripojiť len jeden klient
-kľúč musí byť uložený v textovej podobe na oboch systémoch (klient a server), kde je vystavený riziku, že bude odcudzený

Riešenie s certifikátmi:

   -využíva asymetrické šifrovanie
-zložitejšia konfigurácia
-musíte prevádzkovať certifikačnú autoritu
-na server sa môže pripojiť viac ako jeden klient
-kľúč môže byť bezpečne uložený na čipovej karte chránený PIN kódom

Ako už bolo spomenuté v úvode, tento diel seriálu sa zaoberá nasadením OpenVPN so statickým kľúčom. Využitie certifikátov bude témou niektorého z ďalších dielov.

2. Modelová situácia

Predpokladajme, že máme k dispozícii dva počítače A a B, medzi ktorými chceme vytvoriť VPN sieť. Prostredie oddeľujúce tieto dva systémy nie je vôbec podstatné, môže to byť napríklad krížený sieťový kábel alebo aj internet. Jediná podmienka je, že systém B musí mať možnosť pripojiť sa na port 1194/UDP systému A.

V ďalšom texte predpokladajme počítače prepojené kríženým káblom. Oba počítače majú k dispozícii jediné sieťové rozhranie a je na nich nainštalovaný operačný systém Ubuntu 6.06 Server. Systém A bude na reálnom sieťovom rozhraní používať IP adresu 192.168.1.1 a systém B IP adresu 192.168.1.2.

Našou úlohou je medzi týmito počítačmi vytvoriť VPN sieť 10.1.1.0/255.255.255.252. Virtuálne sieťové rozhranie systému A v nej bude používať IP adresu 10.1.1.1 a virtuálne sieťové rozhranie systému B IP adresu 10.1.1.2.

Systém A bude plniť úlohu VPN servera, čo znamená, že bude na porte 1194/UDP počúvať na prichádzajúce spojenie od systému B, ktorý bude v úlohe VPN klienta.

3. Inštalácia OpenVPN

Aplikácia OpenVPN pozostáva z jediného rovnomenného spustiteľného binárneho súboru. Tento súbor sa používa na spustenie serveru i klienta, a preto je nutné rovnakú aplikáciu nainštalovať na oba systémy. Rozdiel medzi klientom a serverom je len v konfigurácii.

Ak ste zvyknutí pracovať s viacerými operačnými systémami určite oceníte multiplatformovosť, pretože OpenVPN je podľa oficiálnej dokumentácie možné prevádzkovať na platformách Linux 2.2+, Solaris, OpenBSD 3.0+, Mac OS X, FreeBSD, NetBSD a v neposlednej rade aj Microsoft Windows. Osobne mám skúsenosti s prevádzkovaním na Linuxe, OpenBSD a MS Windows a môžem potvrdiť, že OpenVPN na týchto platformách funguje naozaj bez najmenších problémov.

OpenVPN odporúčam inštalovať z oficiálnych repozitárov vami používanej distribúcie. Ak používate distribúciu Ubuntu, môžete balík "openvpn" zo skupiny "universe" nainštalovať príkazom:

# sudo apt-get install openvpn

Pokiaľ používate inú distribúciu a balík OpenVPN sa v nej nenachádza, môžete ho zostaviť zo zdrojových kódov, ktoré sú k dispozícii na domovskej stránke projektu. Budete na to potrebovať v systéme nainštalované knižnice LZO a OpenSSL. Inštaláciu zo zdrojových kódov môžete vykonať napríklad spustením nasledovných príkazov:

# wget http://openvpn.net/release/openvpn-2.0.9.tar.gz
# tar xfz openvpn-2.0.9.tar.gz
# cd openvpn-2.0.9
# ./configure --prefix=/usr/local
# make
# make install

V tomto prípade bude výsledný binárny súbor "openvpn" umiestnený do adresára "/usr/local/sbin".

4. Virtuálne sieťové rozhrania

OpenVPN pracuje s virtuálnymi sieťovými rozhraniami TUN/TAP, ktoré softvérovo emulujú sieťové zariadenia a musia mať podporu v jadre operačného systému.

Väčšina distribučných jadier TUN/TAP ovládač obsahuje, no pokiaľ si zostavujete jadro sami, mali by ste sa uistiť, že ste tento ovládač pridali. Nachádza sa v sekcii ovládačov sieťových rozhraní pod názvom "Universal TUN/TAP device driver support" a jeho prítomnosť vo vašom jadre môžete overiť prítomnosťou riadku

CONFIG_TUN=m

alebo

CONFIG_TUN=y

v config súbore vytvorenom pri zostavovaní jadra.

Kým bežné sieťové rozhrania ako eth0 priamo zastupujú hardvér, čo môže byť napríklad sieťová karta v PCI slote, tak pakety prechádzajúce rozhraniami TUN/TAP sú preposielané používateľskému programu. Táto vlastnosť sa v prípade OpenVPN využíva o.i. na šifrovanie a dešifrovanie paketov pred ich odoslaním cez reálne sieťové rozhranie.

Rozhranie TAP simuluje klasické zariadenie typu Ethernet pracujúce s rámcami na druhej (linkovej) vrstve OSI modelu a rozhranie TUN simuluje point-to-point zariadenie pracujúce s paketmi na tretej (sieťovej) vrstve rovnakého modelu. Zjednodušene sa dá povedať, že TAP sa primárne používa na vytvorenie bridge-ovanej VPN siete a TUN na vytvorenie route-ovanej VPN siete.

5. Spustenie VPN servera a klienta

Takmer všetky konfiguračné nastavenia OpenVPN je možné uviesť priamo cez parametre pri spustení, alebo ich aplikácia môže čítať z konfiguračného súboru. Osobne uprednostňujem druhú možnosť kvôli jednoduchšej údržbe, no v nasledujúcom príklade bude kvôli väčšej názornosti konfigurácia vykonaná prostredníctvom parametrov z príkazového riadka. Použitie konfiguračných súborov bude popísané v nasledujúcom článku.

Pred prvým spustením OpenVPN v móde so statickým kľúčom je nutné tento kľúč vygenerovať. Používa sa na to príkaz:

root@A:~# openvpn --genkey --secret static.key

V aktuálnom adresári bude po spustení tohto príkazu vytvorený súbor "static.key" s obsahom podobným tomuto:

#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
05bf51aad90ff49c8807ca92bdc8c350
20cc270e6b46e040864dd5b07fd10a73
8c5452590947cd2a37bc558cd58aa8fd
d78321cc02bb2e7c8db20a677bbab592
00fdedce367674c47d595eb40a410593
568854d77e3128154dbca4f993e5c9da
d16716246fb7be6f9affb3598978afa8
83ce6b6e88ae02767e8257f80ffcca5a
3dc2aae37475fb379514866f83a25fba
8f2fae44583074646b7a5144f129ed28
a46a0569bf9e50f46d1f300fcc8d15d3
9ccce1ec108ad53f79d2dfce55dd4733
7372702f96afa683558d804304723126
18aaeb039085c8f1fb693dd670b2d2ca
915966e7bbc174ebacbec4c718a169d2
2d0a6ebf481a8bae37437c0625784ba0
-----END OpenVPN Static key V1-----

OpenVPN server na systéme A môžeme následne spustiť príkazom:

root@A:~# openvpn --dev tun --ifconfig 10.1.1.1 10.1.1.2 --secret static.key

Parameter "--dev tun" určuje, že má byť použité virtuálne sieťové rozhranie typu TUN. Parameter "--ifconfig 10.1.1.1 10.1.1.2" hovorí, že bude vytvorený tunel medzi IP adresou 10.1.1.1 a 10.1.1.2. OpenVPN vďaka tomuto parametru automaticky nastaví na vytvorené virtuálne sieťové rozhranie adresu 10.1.1.1 a bude očakávať, že sa pripojí klient s IP adresou 10.1.1.2. Parameter "--secret static.key" určuje názov súboru, ktorý obsahuje statický kľúč.

Výstupom tohto príkazu by mal byť text podobný tomuto:

root@A:~# openvpn --dev tun --ifconfig 10.1.1.1 10.1.1.2 --secret static.key
Sat Jan 5 17:16:18 2008 OpenVPN 2.0.6 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Apr 10 2006
Sat Jan 5 17:16:18 2008 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Sat Jan 5 17:16:18 2008 TUN/TAP device tun0 opened
Sat Jan 5 17:16:18 2008 ifconfig tun0 10.1.1.1 pointopoint 10.1.1.2 mtu 1500
Sat Jan 5 17:16:18 2008 UDPv4 link local (bound): [undef]:1194
Sat Jan 5 17:16:18 2008 UDPv4 link remote: [undef]

Z výpisu je pre nás podstatná iba informácia o názve vytvoreného virtuálneho sieťového rozhrania, čo je v tomto prípade "tun0".

Príkaz po spustení ostane blokovať konzolu a ďalší výpis textu uvidíme až pri pripájaní klienta. Samozrejme OpenVPN sa dá používať aj ako daemon (systémová služba), ktorý neblokuje terminál. Postup priameho spúšťania z konzoly sa však používa najmä pri prvotnom testovaní spojenia, pretože prípadnú chybu v konfigurácii okamžite vidíme na obrazovke.

V ďalšom kroku musíme súbor so statickým kľúčom zo systému A bezpečne (ideálne na USB kľúči alebo pomocou SSH spojenia) preniesť na systém B. Ak by niekto tento kľúč pri prenose odcudzil, mohol by dešifrovať všetky údaje prenášané VPN sieťou.

OpenVPN klienta na systéme B môžeme spustiť príkazom:

root@B:~# openvpn –remote 192.168.1.1 --dev tun --ifconfig 10.1.1.2 10.1.1.1 --secret static.key

Parameter "--remote 192.168.1.1" určuje reálnu IP adresu VPN servera, na ktorý sa má klient pripojiť. V tomto prípade sa teda systém B pripojí na adresu 192.168.1.1 a predvolený port 1194/UDP. Význam ostatných parametrov je rovnaký ako pri VPN serveri. Všimnite si však opačné poradie adries určených parametrom "--ifconfig 10.1.1.2 10.1.1.1". OpenVPN vďaka tomuto parametru automaticky nastaví na vytvorené virtuálne sieťové rozhranie adresu 10.1.1.2 a na druhej strane tunela bude očakávať server s adresou 10.1.1.1.

Výstupom tohto príkazu by mal byť text podobný tomuto:

root@B:~# openvpn --remote 192.168.1.1 --dev tun --ifconfig 10.1.1.2 10.1.1.1 --secret static.key
Sat Jan 5 17:17:24 2008 OpenVPN 2.0.6 i486-pc-linux-gnu [SSL] [LZO] [EPOLL] built on Apr 10 2006
Sat Jan 5 17:17:24 2008 IMPORTANT: OpenVPN's default port number is now 1194, based on an official port number assignment by IANA. OpenVPN 2.0-beta16 and earlier used 5000 as the default port.
Sat Jan 5 17:17:25 2008 TUN/TAP device tun0 opened
Sat Jan 5 17:17:25 2008 ifconfig tun0 10.1.1.2 pointopoint 10.1.1.1 mtu 1500
Sat Jan 5 17:17:25 2008 UDPv4 link local (bound): [undef]:1194
Sat Jan 5 17:17:25 2008 UDPv4 link remote: 192.168.1.1:1194
Sat Jan 5 17:17:35 2008 Peer Connection Initiated with 192.168.1.1:1194
Sat Jan 5 17:17:36 2008 Initialization Sequence Completed

Na termináli systému A by mali pribudnúť dva riadky informujúce o pripojení klienta:

Sat Jan 5 17:17:36 2008 Peer Connection Initiated with 192.168.1.2:1194
Sat Jan 5 17:17:36 2008 Initialization Sequence Completed

Po úspešnom nadviazaní spojenia medzi klientom a serverom je medzi systémom A a systémom B vytvorená VPN sieť 10.1.1.0/30.

6. Overenie funkčnosti VPN siete

Medzi používanými sieťovými rozhraniami by na oboch systémoch malo pribudnúť jedno rozhranie typu TUN. Konfiguráciu sieťových rozhraní systému A môžeme zobraziť príkazom ifconfig:

root@A:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:34:A4:D1
inet addr:192.168.1.1 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe34:a4d1/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:134 errors:0 dropped:0 overruns:0 frame:0
TX packets:107 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13968 (13.6 KiB) TX bytes:15070 (14.7 KiB)
Interrupt:185 Base address:0x1400

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:281 errors:0 dropped:0 overruns:0 frame:0
TX packets:281 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:27988 (27.3 KiB) TX bytes:27988 (27.3 KiB)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.1.1.1 P-t-P:10.1.1.2 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Z výpisu je vidieť, že systém A používa rozhranie tun0 s IP adresou 10.1.1.1. Na systéme B je výstup príkazu ifconfig analogický, a teda je z neho vidieť, že tento systém používa rozhranie tun0 s IP adresou 10.1.1.2:

root@B:~# ifconfig
eth0 Link encap:Ethernet HWaddr 00:0C:29:53:E8:F9
inet addr:192.168.1.2 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::20c:29ff:fe53:e8f9/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:138 errors:0 dropped:0 overruns:0 frame:0
TX packets:126 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:14196 (13.8 KiB) TX bytes:20008 (19.5 KiB)
Interrupt:185 Base address:0x1400

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2 errors:0 dropped:0 overruns:0 frame:0
TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:100 (100.0 b) TX bytes:100 (100.0 b)

tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
inet addr:10.1.1.2 P-t-P:10.1.1.1 Mask:255.255.255.255
UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)

Ak ani jeden zo systémov nepoužíva firewall, malo by byť možné príkazom ping overiť konektivitu medzi virtuálnymi rozhraniami. Z počítača A by sa nám malo podariť "pingnúť" virtuálnu IP adresu počítača B:

root@A:~# ping 10.1.1.2 -c 4
PING 10.1.1.2 (10.1.1.2) 56(84) bytes of data.
64 bytes from 10.1.1.2: icmp_seq=1 ttl=64 time=1.79 ms
64 bytes from 10.1.1.2: icmp_seq=2 ttl=64 time=0.740 ms
64 bytes from 10.1.1.2: icmp_seq=3 ttl=64 time=0.553 ms
64 bytes from 10.1.1.2: icmp_seq=4 ttl=64 time=0.782 ms

--- 10.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3013ms
rtt min/avg/max/mdev = 0.553/0.966/1.790/0.483 ms

Ak by sme počas pingovania z počítača A pustili na virtuálnom rozhraní počítača B analyzátor sieťovej prevádzky tzv. sniffer, mali by sme vidieť ICMP echo pakety vysielané programom ping a zároveň ICMP reply pakety, ktoré odosiela systém B ako odpoveď:

root@B:~# tcpdump -i tun0
tcpdump: WARNING: arptype 65534 not supported by libpcap - falling back to cooked socket
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type LINUX_SLL (Linux cooked), capture size 96 bytes
17:41:02.803616 IP 10.1.1.1 > 10.1.1.2: ICMP echo request, id 62222, seq 1, length 64
17:41:02.804933 IP 10.1.1.2 > 10.1.1.1: ICMP echo reply, id 62222, seq 1, length 64
17:41:03.808143 IP 10.1.1.1 > 10.1.1.2: ICMP echo request, id 62222, seq 2, length 64
17:41:03.808165 IP 10.1.1.2 > 10.1.1.1: ICMP echo reply, id 62222, seq 2, length 64
17:41:04.793097 IP 10.1.1.1 > 10.1.1.2: ICMP echo request, id 62222, seq 3, length 64
17:41:04.793120 IP 10.1.1.2 > 10.1.1.1: ICMP echo reply, id 62222, seq 3, length 64
17:41:05.848259 IP 10.1.1.1 > 10.1.1.2: ICMP echo request, id 62222, seq 4, length 64
17:41:05.848280 IP 10.1.1.2 > 10.1.1.1: ICMP echo reply, id 62222, seq 4, length 64

8 packets captured
16 packets received by filter
0 packets dropped by kernel

Na reálnom sieťovom rozhraní systému B by však sniffer v tomto momente zachytil len VPN pakety prichádzajúce na port 1194/UDP, ktorý je v nasledujúcom výpise označený slovom "opevpn":

root@B:~# tcpdump -i eth0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
17:41:02.803616 IP 192.168.1.1.openvpn > 192.168.1.2.openvpn: UDP, length 124
17:41:02.804933 IP 192.168.1.2.openvpn > 192.168.1.1.openvpn: UDP, length 124
17:41:03.808143 IP 192.168.1.1.openvpn > 192.168.1.2.openvpn: UDP, length 124
17:41:03.808165 IP 192.168.1.2.openvpn > 192.168.1.1.openvpn: UDP, length 124
17:41:04.793097 IP 192.168.1.1.openvpn > 192.168.1.2.openvpn: UDP, length 124
17:41:04.793120 IP 192.168.1.2.openvpn > 192.168.1.1.openvpn: UDP, length 124
17:41:05.848259 IP 192.168.1.1.openvpn > 192.168.1.2.openvpn: UDP, length 124
17:41:05.848280 IP 192.168.1.2.openvpn > 192.168.1.1.openvpn: UDP, length 124

8 packets captured
16 packets received by filter
0 packets dropped by kernel

Tieto výpisy názorne potvrdzujú "Princíp šifrovaného tunelu" (vysvetlený v predchádzajúcom dieli tohto seriálu), ktorý spočíva v tom, že pakety pre privátnu sieť sú prenášané v zašifrovanej podobe v dátovej časti verejných paketov. V tomto konkrétnom prípade teda pakety vymieňané medzi verejnými rozhraniami s IP adresami 192.168.1.1 a 192.168.1.2 v sebe obsahujú ICMP komunikáciu medzi IP adresami 10.1.1.1 a 10.1.1.2.

7. Záver

V treťom dieli sa pokúsime vylepšiť konfiguráciu dnes vytvorenej VPN siete použitím konfiguračných súborov a daemonizáciou procesu. Pozrieme sa aj na prístup distribúcie Ubuntu, ktorá vhodne kombinuje konfiguračné parametre odovzdávané z príkazového riadka s parametrami načítavanými z konfiguračných súborov. No a aby nechýbal ani príklad z reálneho života, použijeme OpenVPN so statickým kľúčom na tunelovanie proxy servera.



    • ifconfig 28.10.2008 | 12:18
      kain   Návštevník
      vyhol by som sa pouzivaniu ifconfig. pri zlozitejsich konfiguraciach je matuci. lepsie je pouzivat nastroje z balika iproute.
      • Re: ifconfig 28.10.2008 | 12:27
        Avatar uid0 Debian  Používateľ
        nespravny dovod, pri zlozitejsich konfiguraciach je totiz nefunkcny
        Debian. apt-get into it…
        • Re: ifconfig 28.10.2008 | 12:28
          Avatar Samuel BWPOW Kupka CentOS, Mandriva  Používateľ
          Na druhu stranu, vystup je imho trochu citatelnejsi. Ale na konfiguraciu sa fakt ifconfig nehodi.
          Strach dát najevo své pocity a zjednat si u druhých respekt je jedním z problémů civilizovaného člověka, který se naučil zpochybňovat svou vlastní pravdu pro zdání objektivity
          • Re: ifconfig 28.10.2008 | 13:34
            Avatar partizan Arch  Používateľ
            Pokial nerobite nejake zlozitejsie konfiguracie ako viac IP na jednom rozhrani a podobne tak je to uplne nepodstatne a taktiez mimo linuxu si snim vecsinou budete musiet vystacit.
            Arch & Metal
            • Re: ifconfig 28.10.2008 | 15:44
              Avatar uid0 Debian  Používateľ
              presne ako hovoris, nefunkcnost ifconfig sa prejavuje uz pri velmi malej zlozitosti
              Debian. apt-get into it…
              • Re: ifconfig 28.10.2008 | 18:51
                kain   Návštevník
                otazka je co kto poklada za zlozitost ;)
    • datum 29.10.2008 | 10:10
      mich   Návštevník
      datum clanku 28.12.2008? :-)
      Ale inak pekny clanok. Snad pride coskoro dalsi diel.
      • Re: datum 29.10.2008 | 14:06
        Avatar partizan Arch  Používateľ
        no darmo je to clanok ktory predbehol svoju dobu :D
        Arch & Metal
        • Re: datum 29.10.2008 | 14:14
          Avatar Tomáš Srnka Barz čo, už asi všetko  Administrátor
          fixed, uklepol som sa :)
          Dlho som robil linuxos.sk, neskôr založil vpsFree.cz, posledných pár rokov ako tech. riaditeľ vo Websupporte
    • rychlost 03.11.2008 | 16:52
      mich   Návštevník
      Robil niekto z vas test rychlosti spojenia dvoch pc pomocou OpenVPN? Konfiguracia server-klient, pouzitie tun. S kompresiou / bez kompresie. Lebo mne vychadza polovicna rychlost prenosu v porovnani s prenosom bez OpenVPN. Nie ze by to bolo zle, ale mozno sa da este zvysit vykon prenosu, pretoze procesor je pri prenose zatazeny celkovo tak na nejakych 45% (maximalna zataz od openvpn-ka bola 36%) no a prenosova cesta zvladne dvojnasobok bez problemov, tak neviem, cim je to limitovane...
      Hladanie na nete moc nepomohlo, alebo neviem hladat :-)
      Trochu udajov o teste:
      OS -OpenBSD4.3, CPU pocitacov: 3GHz. Max. prenosova rychlost spojenia: 100Mbit/s a priemerna rychlost prenosu cez VPN bola 42Mbit/s. Pri teste bol posielany 700MB subor pomocou scp.
      • Re: rychlost 03.11.2008 | 17:32
        Avatar Jaroslav Imrich Ubuntu  Používateľ
        Pokial viem, tak scp tiez sifruje prenos a z vlastnej skusenosti ho povazujem za velmi pomale (a tiez velmi bezpecne). Podarilo sa ti niekedy prenasat s scp v plnej rychlosti spojenia? Aka je rychlost prenosu s SCP bez VPN a cim merias prenosovu rychlost?
        We can't solve problems by using the same kind of thinking we used when we created them - A. Einstein
        • Re: rychlost 04.11.2008 | 00:09
          mich   Návštevník
          Dakujem za odpoved, bez VPN cez scp bola rychlost 82Mbit/s. A merane to bolo iba pomocou scp. Teda tie udaje, ktore zobrazuje pri kopirovani. Prenesene data, rychlost a cas. Ale to s tym scp mas pravdu, mozem skusit aj nejaku inu metodu prenosu. Iked tiez neviem, cim je to limitovane pri pouziti scp... Lebo cpu nie je vytazena na maximum.
          • Re: rychlost 04.11.2008 | 17:50
            cezz   Návštevník
            Na testovanie priepustnosti by som skor pouzil nieco jednoduchsie, ako netcat, alebo nastroje na to urcene.

            Inak samozrejme vsetko zavisi od toho, ako rychlo dokaze stroj data sifrovat/komprimovat. Mal som jeden tunel na takom par Mhz routri a ten stihal iba par MB/s, vyrazne pomohlo vypnutie kompresie, ktora v zasade neprinasala vyraznu usporu dat a data nemalo zmysel setrit na ukor priepusnosti, zato uspora CPU bola velka.
    • staticky kluc = jeden klient 04.11.2008 | 17:53
      cezz   Návštevník
      Toto IMHO nemusi byt pravda, staci iba povolit pripojenie viacerych klientov s jednym klucom. Alebo sa mylim?
      • Re: staticky kluc = jeden klient 05.11.2008 | 21:28
        Avatar Jaroslav Imrich Ubuntu  Používateľ
        Konfiguracny parameter, ktory by povolil takuto moznost nepoznam. Mohol by si ho prosim uviest?
        We can't solve problems by using the same kind of thinking we used when we created them - A. Einstein
        • Re: staticky kluc = jeden klient 11.11.2008 | 14:43
          hmm..   Návštevník
          Asi som sa pomylil.. beriem spat :) Ibaze by to bolo --duplicate-cn
          • Re: staticky kluc = jeden klient 11.11.2008 | 17:28
            Avatar Jaroslav Imrich Ubuntu  Používateľ
            Parameter "duplicate-cn" sa pouziva v mode s certifikatmi a povoluje pripojenie viacerych klientov s rovnakym obsahom pola "commonName", ktore je sucastou subject-u certifikatu. Dovolim si vsak podotknut, ze ani tu sa vsak nemusi nutne jednat o rovnaky certifikat/kluc.
            We can't solve problems by using the same kind of thinking we used when we created them - A. Einstein