Pomalé VPN - IPSec

p_l_

Ahoj, řeším pomalý přenos souborů přes VPN - GRE over IPSec. Mám propojené různé RB na různě rychlých linkách a v některých případech není kapacita linky využita. Když zkusím Bandwidth test mezi routery na privátních adresách, tak výsledek odpovídá rychlosti linek, pokud ale přenáším soubory a nebo třeba data z SQL databáze, tak je rychlost výrazně nižší.

Nejvíc mě překvapuje rychlost mezi CCR1009 (1Gbit linka) a RB1100AHx (asymetrická linka 120/20Mbit). Bandwidth ukazuje bez omezovaní 70Mbit, nastavil jsem přes SQ omezení na 50Mbit, ale rychlost přenosu souborů je rychlejším směrem 600-800kByte, výjimečně to vyleze na 1MByte. Zajímavé je, že pomalejší směr, tedy z RB100AHx na CCR je rychlost vyšší, kolem 1.3MByte

Přitom RB1100AHx s jinou lokalitou, kde je RB1100Hx2 (100Mbit linka) dosahuje rychlost 1.7MByte. CCR<->RB1100Hx2 je na tom podobně jako CCR<->RB1100AHx, ale například CCR<->RB433AH je na tom tak o 20% lépe.

CPU v CCR se vyloženě fláká, RB1100AHx je vytížené trochu víc, ale ma do 40% a u RB1100Hx2 se dostanu až na 80%. Verze ROS jsou všude 6.27.

Nemáte někdo tip, jak dosáhnout lepších rychlostí?

Díky

majklik

Vítej v klubu. Ano, souhlas. Realita je taková, že IPsec v CCR je nějaký rozbitý a nadává na něj řada lidí. Respektive jede v GRE/IPsec dobře, pokud ty CCR jsou těsně vedle sebe na stole propojené kabelem, tak to vypadá OK. Pokud je vzdálíš od sebe ze reální linky, tak jde výkon totálně do kopřiv, jak uvádíš. Pokud jsou tam identicky nastavené RB1100AHx2, tak na 100 Mbps lince přes půlku Česka jedu uvnitř GRE/IPsec trvale na jejím stropu (replikace dat mezi servery).

Jaké používáš nastavení proposals? U CCR jsme si všimnul, že se to zlepší, pokud se nastaví tak, aby nedocházelo k využívání hardwarové podpory pro IPsec, když to musí drtit ten CPU v sobě, tak to výrazně ožije (za cenu zatížení CPU). Takže zkus použít např 3DES/SHA1.

Strategie omezit pomocí SQ tok vstupující do GRE tunelu o něco méně, než je neslabší článek v řetězci je správná. Dále se nesmí zpaomenout pomocí firewall mangle měnit MSS u TCP spojení jdoucích do GRE tunelů tak, aby nemuselo docházet případně k fragmentaci paketů. U novějších ROSů je na to volba přímo u definice GRE tunelu, aby to dělal automaticky (clamp TCP MSS).

p_l_

Dík za přivítání, i když některé kluby bych radši vynechal :-) Všiml jsem si ve fórech hromady problémů s CCR a IPSec, ale měl jsem dojem, že se řešily výrazně vyšší rychlosti než co potřebuju a také, že u jedné verze ROS byla zmínka, že je problém vyřešený.

Zkoušel jsem měnit MSS i pátral po významu zaškrtávátka u GRE, ale změny rychlost nijak neovlivnily. Teď jsem zkusil i sha1/3des a rychlost je pořád stejná. Co mi je divné je, že test rychlosti jak udp, tak i tcp tu linku využít dokáže, ale reálná data ne. Změna z sha256/aes 256, které jsem měl nastavené, na sha1/3des trochu zrychlila směr RB1100AHx->CCR1109, ale rychlejším směre, kde je omezení 120Mbit uploadem na straně RB1100AHx, zůstala rychlost na původních hodnotách :-( Prostě směrem od CCR je to pomalejší než když tam zkusím dát místo něj třeba RB493G, jen tu 493 provoz zatíží na 100% a má problémy s dalším provozem mimo VPN.

p_l_

Tak přeci jen změna, po těch pokusech jsem zapomněl zpět zaškrtnout clamp TCP MSS. Po zaškrtnutí se při sha1/3des zvýšila rychlost na 3MB. Je to sice polovina kapacity, ale znatelné zrychlení.

Díky

ales_lednej

Btw.. Kdyz das 3des a preneses vice nez 10GB, tak tam uz zrovna muzes nechat jenom gre :-)

p_l_

Aleši, díky za připomínku. Já jsem si přenastavením ověřil, že linkou proteče šifrovaně víc než při použití aes-cbc. Teď je otázkou co s tím. Jestli zavrhnout CCR nebo jestli je třeba nějaký způsob jak zakázat HW akceleraci a bude to lepší a nebo... Zkusil jsem aes-ctr, které by podle mě nemělo používat akceleraci, a to pošle Mikrotik spolehlivě do kolen. Prostě to nezvládne a rebootuje. Jiné šifrování jsem zatím nezkusil. CCR se tím bádáním pěkně prodražilo :(

majklik

Cooo? On je u CCR rozbitej i režim AES-CTR? To jsem ani nepostřehl, ale nikde jen nepoužívám. Vím, že byl rozbitý režim AES-GCM, který vede při dekódování prvního paketu k rebootu CCRka, ale cca od 6.20 by to mělo být opraveno, takže pokud se ti 3DES zdá slabší, tak můžeš šáhnou po AES-GCM, který je na šifrování v CPU i rychlejší než 3DES/SHA1 a není v případě CCR také akcelerován v HW (to mi i potvrzovali na supportu).

Je snad jasné, že každý ten algoritmus má omezenou velikost dat, kterou může zašifrovat, než dojde k opakování, ale že při jeho překročení se stane tunel automaticky nechráněn, to bych si tvrdit nedovolil. Jen začne být relativněji možný úspěšný útok na klíč kvůli opakování. V případě AES128-GCM to je po použití jednoho klíče na 64GiB dat. Proto je v definici proposals i doba platnosti jednoho klíče, takže je třeba si nastavit platnost takovou, aby nedošlo k přešvihnutí "bezpečného limitu". Je jen smutné, že u ROS v proposals jde definovat doba platnosti klíče jen časem, běžné je i limit podle počtu přenesených bajtů (lifebytes jde nastavit jen pro IKE fázi1).

p_l_

Zkusil jsem i GCM a i když mám verzi 6.27, tak se RB úspěšně restartuje :(

Jen tak mimochodem, narazil jsem pro změnu na problém s RB1100AHx. Zkusil jsem Metarouter a skončil jsem opět na fórech a zjistil jsem, že se i toto pár let řeší. Jestli to s CCR bude podobné... Propagovat železo, že jako jedno z mála podporuje HW šifrování a skutečnost je ve výsledku k horšímu....

majklik

To jsou šašci. GCM jsme reportoval v době 6.18, někdy kolem 6.20 psali, že má být opraveno, takže buď ne nebo to zase rozbili i s tím CTR. Ale čemu se divit, i co výkonosti týká, tak psali, že od ROS6.12 má CCR v IPsec dát víc než RB1100AHx2 - ha, ha.

Ohledně metarouteru a CCR, ano situace stejná jak s RB1100AHx2 - ná vícejadrových CPU PPC a tilera stále nejede. Proto mám, kde to potřebuji, obvykle v páru RB1100AHx2+RB1100AH, kde Metarouter mám na té AH, které přes VRRP dělá i backup pro AHx2.