VPN 500Mbit/s internetre

 ( unregistered | 2019. szeptember 19., csütörtök - 15:52 )

Sziasztok!

Segítséget szeretnék kérni hogy milyen routert/hardvert ajánlotok OVPN-hez?
ExpressVPN-hez csatlakozna a router, de eddigi tesztjem során harmatgyenge minden:
1. megpróbáltam mikrotiken (3011, de inkább hagyjuk csinált a netből egy 70Mbit-et és ráadásul az OVPN-t be sem lehetett lőni mert a drága jó ROS még egy 1000 éves LZO-t sem támogat)
2. volt synology RS815 szintén lassú
3. mivel a laptopomban egy 6 magos i7 van kipróbáltam és simán hozz a 400Mbit-et kb 10% CPU terhelés mellett
4. próbáltam utánanézni hogy ki mit használ, de igazából nem nagyon vannak ezen rajta a userek/adminok (most vagy én vagy ilyen hülye és valami triviális dolgot elrontok, vagy nem használják így) a legtöbb amire jutottam az egy mikrotik CCR (ami l2tp/IPsec-et tud 700-800Mbit-et) de az OVPN rendes támogatása miatt ez kiesik (a VPN szolgáltatók nem is nagyon támogatják már), illetve találtam egy olyan eszközt hogy PICO PC, de itt is az OVPN csak max 100Mbit

A végső konklúzióm eddig az hogy most tényleg építenem kell egy linux-os gépet két porttal az egyiket a netre dugva a másikat meg a routerre hogy működjön rendesen, vagy Ti oldottak már meg ilyen problémát és van valami jótanács mit rontok el?

Előre is köszönöm!

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

v7 betaban van udp+lzo

Troll-e vagy..

Szerintem arra gondolt hogy a v7 4(!) éve fejlesztés alatt van és még mindig beta :)

2 hettel ezelottig meg beta SEM volt....

+1

Akkor már csak fél év :)
Félreértés ne essék a mikrotik az egyik kedvenc gyártóm, de ez a v7 fejleszétéis ütem...

a v7-ben nincs instant pénz, ezért több erőforrás megy el a jelenlegi vasak támogatására. Lásd pl NV2 -vel való szívás ARM cpu esetén - ez a szopóroller kb 2 év alatt lett elhárítva...

Én azt olvastam, hogy az egyik legnagyobb gond, hogy minden újításhoz amit betennének, frissebb kernelre kellene váltani a mostani 3.x-től.
De ez problémás a Tile processzorokon (kikerült valamikor a Linux kernel által támogatott CPU-k listájából, de állításuk szerint a RouterOS kód nem azt a Tile kódbázist használta és így őket állítólag nem érinti ez rosszul), és ugye az meg nem lehet, hogy mindenre van új RouterOS, de a top kategóriás CCR-ekre meg nincs...

Szerintem rengeteg egyedi fejlesztés került abba a régi Linux kernelbe amit használnak, és irtó soká tart, hogy újabb kernelre is portolják azokat. Tippem az, hogy a v7 fejlesztés akkor lassult be, mikor belefutottak valami olyan új Linux kernel kódba (vagy új kernelre épülő csomagba), ami kellene a v7-hez, de nem lehet backportolni a régi kernelbe.

Az meg a másik baj, hogy ha ki is jön a v7, muszáj lesz megvárni vele jó pár iterációt, mire a gyerekbetegségek java része elmúlik belőle. Mert ahogy kinéz, ez túl nagy váltás lesz.

a latest kernelen van a v7 ami tilet tamogat - tan 4.x LTS

Szerintem rengeteg egyedi fejlesztés került abba a régi Linux kernelbe amit használnak, és irtó soká tart, hogy újabb kernelre is portolják azokat

Levonom a konzekvenciát (bár a mikrotik-fanoknak fájni fog): ez a fejlesztési modell nem működőképes. Ha a linux kernelbe belefejlesztenek egy valag egyedi valamit, amit aztán nem pusholnak az upstreambe akármilyen okból kifolyólag, akkor egyszer, előbb vagy utóbb eljön az ítélet napja, amikor az orbitálissá nőtt szopás maguk alá temeti őket. Így ugyanis nem lehet linux kernelre terméket építeni.

Részemről tipp ez a sok egyedi fejlesztés, azon infók alapján, amit az utóbbi években olvasni lehetett. És ha így van, akkor valószínű utolérte őket amit írsz, és ennyi év volt kimászni a helyzetből.

emellett közrejátszik az is, hogy rengeteg új termék van, ezekhez is kell fejleszteni ezt-azt. Bugfixek (nézd meg pl az NV2 vs ARM cpu problémát), új dolgok, WiGig (Wireless wire).
Ezek mind nagyobb prioritást élveznek, mint a v7 - amire viszont azért van szükség, mert a nagy vasak (32 ill 72 magos CCR) sok feladatban nem hozzák azt, ami kéne az embereknek (BGP pl).

LOL! Nem tudtam, hogy megszületett. Bocs :)

Az OVPN kliens a legtöbb célhardverben nem hardveresen gyorsított, hanem CPU-ból megy (a Mikrotik-en sem az, még a CCR sem lesz jó, mert ott is csak 1 magon fog futni szoftveresen, ami sovány ilyesmire). Emiatt jól látod, muszáj leszel építeni egy célgépet PC alapon, és vagy jó erős procit tenni bele, vagy olyan procit, ami AES-NI képes, mert azt a legtöbb disztrón az újabb OpenVPN szerverek tudják használni AES HW gyorsításra.

Egyébként az OVPN-től függetlenül a 3011 nagyjából 2.5 Gbit-et tud route-olni, szóval ha 70 Mbit ment át, akkor valami nagyon nagyon nem jó volt...

klasszikusan a fasttrack

fasttrack on-off, ugyanaz a sebesség

naja, simán elnatolná ha csak filtereket használsz, de mlg az IPSec is leesik 800Mbit-re az OVPN-be már bele sem merek gondolni

Plusz a mikrotik ovpn tcp-t használ, ami szintén nem tesz jót a sebességnek.

És még tömöríteni sem tudja.

FYI a 7beta1 már tud UDP-t :-)

mellesleg miert szopatod tomoritessel, amikor jellemzoen kb minden tomoritett?

nyilván nem ide szántad - de képes rádobni ~10-20%-t simán.

jahm, 1-el fele ment volna....
jellemzoen monden szart compressedben ker a browser eleve, lofaszx fileok compressedek...

Elég szépen tömörít azért a status fájlok alapján, és azért nincs mindenhol üvegszál. Ha kapok 10-20% extra sávszélt, miért ne használjam?

egyatalan er valamit a tomorites? most mar szinten minden ssl-ben megy, ott meg a random bajtokat nehez osszenyomni...

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

ip header compression?

"volt synology RS815 szintén lassú"

Pl. DS918+ már jó lenne, nekem 400Mbit-et simán kihajtott NordVPN-nel.

De alapvetően ahogy írták valami jobb x86 processzor kell neki.

--

"After successfully ignoring Google, FAQ's, the board search and leaving a undecipherable post in the wrong sub-forum don't expect an intelligent reply."

Én építettem x86ból mikrotikot 2 alaplapi + egy db pcie HP NICcel 300/300Mbit IPSec VPN 25-27%cpu load :)

Eddig még nem sikerült hwes limitbe ütközni.

Az egész fogyaszt 60Watt körül L5420 Xeon alapon. ha valami tönkremegy benne kicserélem, max akkor bukod a mikrotik licenszet, ha a szilárdtest meghajtó megy tönkre a gépben.

blogomban némi adalékanyag.

------------------------

Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)

Ha uezt virtualizáció alatt csinálod, még a háttértárat is cserélheted.
Arra azért figyelj, h Mikrotik alatt nincs lehetőséged kihasználni a CPU-ben lévő AES utasításkészletet, ellenben linux esetén igen.

Ellenben nem kell csomag meg mindenféle frissítéssel, egyébbel bíbelődnöm.

Meg a többi mikrotik eszközzel egy homogén szoftverkörnyezetet alkot...

egységes felületen érem el a hálózatban az eszközöket.

------------------------

Nincs a világon se jó, se rossz. A gondolkodás teszi azzá... (W. Shakespeare)

nem értem mit mondasz.
Van egy virtualizációs réteg (tapasztalatom szerint a ProxMox a leggyorsabb Mikrotik szempontjából), ezen fut a Mikrotik.
Az egész image-t tudod menteni, duplikálni, nem utolsó sorban tudsz használni igény szerint 10G (40G?) kártyákat, ellenben Mikrotik-kel (ami nagyon háklis erre tudtommal)

Valamint 1 dualsocket gépet ritkán tudsz kihasználni egyetlen Mikrotik-kel, viszont ha futtatsz rajta többet, 2-4 maggal...

1) kíváncsi volnék, mi az a forgalom, ahol 500mbps-t kell titkosítani (nem lehetne megoldani direkt L2-vel?)
2) Mikrotik-IPSec (esetleg EoIP over IPSec) tud 500mbps-t hw accel-el.
https://rickfreyconsulting.com/mikrotik-vpns/
3) linux ill BSD esetén használhatsz külön gyorsító kártyát vagy CPU-ban lévő AES utasításkészletet, megfelelő openssl libbel.

Ha openvpn-t kell használni, akkor én PC-t használnék, minél magasabb órajellel (és kevesebb maggal)

1. Semmi komolyra, csak egy plusz biztonsági lépcsőnek, hogy bármi ami bejön vagy kimegy az ISP kábelen az titkosítva legyen legalább így
2. Persze ha nem kellene külső szolgáltató akkor nagyon szép eredményeket lehet elérni
3 + 4. Akkor itt a gépépítés a megoldás mert ovpn kell, az oké hogy magas órajelűt de mennyire?

ha tudsz használni AES gyorsítást akkor kevéssé számit a CPU órajele. Ha nem, akkor minél gyorsabb, annál jobb. pl 3.5GHz

Én wireguard-dal oldottam ezt meg, ami az Orange Pi PC2 harmatgyenge ARMv8 processzorával is lazán viszi a gigabit körüli átvitelt.

Oooo. Ezt picit részletezed? Melyik image? Milyen titkosítást használva?

Nagyon jól hangzik.

ja. csak lofasz support nincs hozza a standard eszkozokben.... kb mint a ms fele sslvpnhez

Hát a következő nagyon érdekel:

Orange Pi PC2 harmatgyenge ARMv8 processzorával is lazán viszi a gigabit körüli átvitelt.

Az hogy milyen Windows támogatás van rá az nem érdekel, mert ilyen feladat nem Windows feladat. S2S vpn vagy vpn nem kliens helye, a client Access egyébként is nagyon komoly dolog manapság és ott a sebesség az egyik utolsó igény.

A fentiben nem kételkedem de szinte hihetetlen. Érdekelne hogyan.

Ez igaz, de ha szerverek, desktop/laptop gépek, esetleg telefonok között szeretnél VPN-t, arra szerintem kiváló választás.

A wireguard éppen az egyszerűségre törekvés miatt nem teszi konfigurálhatóvá a cryptot. Ha érdekelnek a részletek, a hivatalos doksiban találsz róla leírást.
Az image alatt mire gondolsz? Az eszközön milyen OS van? Armbian "next" image, 5.3-as kernellel.

Szia!

Jó kérdés az 500mbit OpenVPN :D

Az "ovearhead" okoz problémát (header + control-data), valamint a csomagdarabolás - egy tunnelen keresztűl.

Azt elképzelhető megoldásnak tartom, ha több openvpn tunnel-t használva csatalkozik a kliens és "round-robin" módon használja azokat - soha nem próbáltam ilyet - lehet működne és így el lehet érni 500mbit-et.

Használj másik VPN megoldást pl.: Ocserv (tcp+udp együtt használja - Cisco AnyConnect féle protokollt használ)
https://ocserv.gitlab.io/www/index.html

Szerintem amennyi az overhead, annyit pont javíthat a compression :-)