OpenVPN + TUN/TAP lassú

A mai napon az OpenVPN és a TUN/TAP megoldása meggyűlöltette velem az életet. A lényeg az lett volna, hogy összefűzzek néhány gépet egy virtuális hálózatra interneten keresztül. Minden gép nagysebességű kapcsolattal rendelkezik (20-30 Mbit) és fontos, hogy a munkaállomások közötti kommunikáció legalább annyira gyors legyen, mint azok internetkapcsolata. Másik érv ami miatt az OpenVPN -t választottam erre a feladatra az, hogy megfelelő titkosítással biztonságos.

A konfiguráció során minden rendben volt, a hálózatot gond nélkül sikerült felépíteni. A második kritérium, hogy gyors legyen viszont nem teljesült. Mivel a TUN/TAP interfészek valaki zseniális ötletének köszönhetően csak 10Mbit half duplexek, ezért a szokásos átlag 2.8MB/s átviteli sebesség helyett csak 430 kB/s -ot sikerült kihozni belőle. Ott tartok, hogy szétvet az ideg, mert természetesen ez is egy olyan rohadt, retkes, mocskos, szar MEGOLDHATATLAN probléma, amire semmi használhatót nem ad ki a Google és a rendszert alkotó komponensek manual-jaiban (pl. tun kernel modul) sincs semmi. Körül-belül másfél óra keresgetés után feladtam.

Természetesen megpróbáltam ezt is:


ethtool -s tap0 speed 100
ethtool -s tap0 duplex full

Mindkettőre Operation not supported hibaüzenet. Jobb ötletem nincs. Abba meg már bele se merek gondolni, mennyi szenvedés lesz a Windows-os gépeken megoldani a sebességproblémát.

Ígyhát marad az insecure, macerás FTP-zgetés, mert képtelenek voltak normálisan megcsinálni valamit és egy ilyen apró problémán csúszik el minden. Ezeket gyűlölöm a legjobban, az ilyen kicsi apró, de ugyanakkor igen jelentős marhaságokat. Bezzeg a titkosszolgálatoknak, a nagyoknak mindent lehet, ők meg tudják írni maguknak, őnekik lehet biztonságosan csinálni, csak nekem kell ilyen szarságokon fennakadnom.

Hozzászólások

Ennek a beállításnak szerintem semmi jelentőssége nincs a valódi elérhető sebesség szempontjából, ez csak egy flag, ami azért van ott, mert az ethernet interfésznél van egy ilyen attribútum ami null értéket nem vehet fel. Az openvpn egy SSL alapú VPN megoldás, aminek a jellegzetessége, hogy a csomag újraszegmentálás miatt növeli a latency-t. Különösen, ha TCP felett csinálod, érdemesebb emiatt inkább UDP-re beállítani. Vannak protokollok, elsősorban az SMB, ami nagyon érzékeny a latencyre, jól sejtem, hogy te éppen ezzel probálkozol?

PPTP, bár biztonsági szempontból nem kifejezetten tökéletes, de közvetlen csomag encapsulation alapú, tehát nem szegmentál újra. Viszont elég spéci tűzfalbeállításokat igényel, hogy pl. NAT-on átjusson. Hasonló képpen az IPSec is, viszont azt még nagyobb rémálom beállítani és a NAT traversal is egy teljesen külön tudomány hozzá. Viszont ezek a megoldások az SMB-t elég jó sebességgel viszik át.
---
Linux is bad juju.

Es a jo oreg PPTP? Azt meg a windows is nativan tamogatja. Van server (poptop), linuxos kliens is. Igaz, a jo oreg ppp demmon kell hozza, de istenem...
--


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

a problema allitolag az, hogy tcpn a congestion control miatt fos a teljesitmeny. :) udpt nezd meg.

Azért elég abszurdnak tartom (ha igaz), hogy az OpenVPN tényleg nem képes nagyobb sebességgel átvinni, ~400 kB/s-nél megáll a móka és viszlát, amikor lassan már házhoz viszik a 100Mbit-et.

scp is lassan masol? nekem upc 20csomaggal letoltes:


bandi@xxx:~$ scp bandi@10.10.10.1:turbodelphi_en.iso.zip .
turbodelphi_en.iso.zip                    3%   20MB   1.9MB/s   05:17 ETA

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Szerencsés ember vagy, hogy Neked nem jönnek elő ilyen hülyeségek. A nem találtam lassúnak alatt mit értesz? Próbáltál már 10 Mbit/s-nál magasabb átviteli sebességet kihozni belőle?

MTU-s dolgot ki tudnád fejteni bővebben?

A FAQ-ban egy mukk nincs sebességproblémákról.

Köszi.

hello! régi már a bejegyzés, ezét reménykedem hogy találtál megoldást:)
sajnos nálam is hasonló a helyzet, nem megy gyorsabban mint 10mbit:(
tele van ezzel a net, sokan szenvednek vele, de megoldás sehol...