❗️Toto je původní verze internetového fóra ISPforum.cz do února 2020 bez možnosti registrace nových uživatelů. Aktivní verzi fóra naleznete na adrese https://telekomunikace.cz
Pomalý IPsec spoj mezi RB1100ahx2 a CCR
Pomalý IPsec spoj mezi RB1100ahx2 a CCR
Ahoj, už nějakou dobu řeším pomalý spoj mezi RB1100ahx2 a CCR v IPSec tunelu, AES 128, SHA1. Mezi RB je RR spoj na UBNT. V bandwidth testu bez IPSecu se dostanu na 80Mbit/s, jakmile to ženu v IPSecu, nedostanu se nad 12Mbit/s. Kudy dál? Díky.
0 x
Ok, zeptám se jinak. Co byste doporučili za nejlepší konfiguraci pro vysokou bezpečnost a zároveň s co nejvyšším výkonem?
0 x
Pokud ti to dává takto málo, tak bych si tipnul, že jedna strana nepodporuje HW akceleraci ... tedy nejspíš v případě CCR verze ROS bude "divná". Ale nemám zkušenosti ani s CCR, ani s ipsecem. Ale akceleraci by měly podporovat oba boxy.
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Ale i softwarově by ti to mělo dát o dost víc ... teoreticky:
http://wiki.mikrotik.com/wiki/Manual:IP ... encryption
http://wiki.mikrotik.com/wiki/Manual:IP ... encryption
0 x
Jelikož je zde zakázáno se negativně vyjadřovat k provozním záležitostem, tak se holt musím vyjádřit takto: nové fórum tak jak je připravováno považuji za cestu do pekel. Nepřehledný maglajz z toho bude. Do podpisu se mi pozitiva již nevejdou.
Aktuálně jsem všude nandal v6.24, fyzicky chyba v CCR nebude, zkouším to oproti dvěma dalším. Předělal jsem čistý IPSec do GRE tunelu. Taky nic.
Zkusím ještě vyhodit tu RB1100 a dát místo ní CCR.
Zkusím ještě vyhodit tu RB1100 a dát místo ní CCR.
0 x
proč se nekoukneš na kolik běží jádra když pouštíš šifrovanej trafik? pak uvidíš jaký zařízení to dělá... Nicméně ano, mělo by to podporovat hardwarový šifrování nicméně nikdo nikde neříká že ho mikrotik umí používat u konkrétních zařízeních protože všude kde to uvádí většinou nefunguje.
0 x
Supermicro + Mikrotik = SuperTik
high speed routery podle požadavků
high speed routery podle požadavků
-
sub_zero
- Příspěvky: 1741
- Registrován: 19 years ago
- antispam: Ano
- Bydliště: Olomouc
- Kontaktovat uživatele:
to je nesmysl. Máme dvě RB433AH, spojený přes tupou L2 a dává nám to na IPsecu cca 30Mbps. Hledal bych prolém jinde.
0 x
Říkáš-li, že něco nejde, znamená to, že to neumíš.
Jirka Lazorčák
PS: Ta fotka je stará, už mám +15kilo..
Jirka Lazorčák
PS: Ta fotka je stará, už mám +15kilo..
RB433AH a 30 Mbps IPsec? S jakým proposal to je použité? S paranoidnějším jsme tak na polovičce.
Spousta lidí, co zkoušeli IPsec na CCR, si myslí opak, zvláště když na naléhání stále z Mikrotiku nevypadla ta konfigurace v které to má ušifrovat ty slibované gigabity.
Ano, CCR má podporu pro HW akceleraci, ale jen pro některé konfigurace (a některé konfigurace vyvolají zhroucení CCR po prvním přeneseném paketu).
Řešíš nějak MTU? Pokud ne, tak ti klasický IPsec tunel bude muset dělat postfragmentaci, když do něj budeš posílat pakety s MTU1500. Postfragmentace/defragmentace srazí výkonost dosti dolů. Ale ještě hůře se srazí v případě, že v cestě máš linku, která není full duplex (takže pokud ten "RR spoj na UBNT" je něco jako wifina, tak jsi na tom).
Pro IPsec tunel pak musíš třeba pro TCP šahat na MSS, aby to rozumně jelo. Něco jako (pokud na jedné straně je 10.1.1.0/24 a na druhé 10.1.2.0/24):
R1:
/ip firewall mangle add
chain=forward action=change-mss new-mss=1380 passthrough=yes tcp-flags=syn protocol=tcp dst-address=10.1.2.0/24 tcp-mss=!0-1380
R2:
/ip firewall mangle add
chain=forward action=change-mss new-mss=1380 passthrough=yes tcp-flags=syn protocol=tcp dst-address=10.1.1.0/24 tcp-mss=!0-1380
Při tom pokusu s GRE, tak pokud ho obaluješ pomocí IPsec transportu, tak MTU na tom GRE tunelu by nemělo být větší jak 1432 (pokud to balíš do IPsec tunelu, tak je to ještě cca o 20 bajtů horší), aby nemusela IPsec vrstva fragmentovat. A je opět vhodné patřičně regulovat MSS v tom GRE tunelu.
Kolik ti to dá, pokud zkusíš dát bandwith test mezi těma Mikrotiky skrz ten GRE tunel na přímo? To jede podstatně rychleji, že? Pokud ano, tak jsi ve stejné situaci, v jaké tu je těch X vláken na téma "pomalá rychlost na jedno TCP spojení", ten IPsec tunel to ještě zhoršuje, pokud ztrátuje. Jestli se ti to při TCP přenosu chová tak (např přes FTP), že pilovitě stoupá, pak se to sekne, spadne a znova postupně stoupá a takto pořád dokola s tím, že dlouhodobější průměr máš těch 12 Mbps, tak aplikuj na to, co posíláš do toho GRE tunelu, shaping třeba pomocí SQ a řízni to někam, kde nedojde k zahlcení toho RR spoje, pak ti to pojede třeba spokojeně 50 Mbps...
forevercz píše:fyzicky chyba v CCR nebude
Spousta lidí, co zkoušeli IPsec na CCR, si myslí opak, zvláště když na naléhání stále z Mikrotiku nevypadla ta konfigurace v které to má ušifrovat ty slibované gigabity.
Ano, CCR má podporu pro HW akceleraci, ale jen pro některé konfigurace (a některé konfigurace vyvolají zhroucení CCR po prvním přeneseném paketu).
Řešíš nějak MTU? Pokud ne, tak ti klasický IPsec tunel bude muset dělat postfragmentaci, když do něj budeš posílat pakety s MTU1500. Postfragmentace/defragmentace srazí výkonost dosti dolů. Ale ještě hůře se srazí v případě, že v cestě máš linku, která není full duplex (takže pokud ten "RR spoj na UBNT" je něco jako wifina, tak jsi na tom).
Pro IPsec tunel pak musíš třeba pro TCP šahat na MSS, aby to rozumně jelo. Něco jako (pokud na jedné straně je 10.1.1.0/24 a na druhé 10.1.2.0/24):
R1:
/ip firewall mangle add
chain=forward action=change-mss new-mss=1380 passthrough=yes tcp-flags=syn protocol=tcp dst-address=10.1.2.0/24 tcp-mss=!0-1380
R2:
/ip firewall mangle add
chain=forward action=change-mss new-mss=1380 passthrough=yes tcp-flags=syn protocol=tcp dst-address=10.1.1.0/24 tcp-mss=!0-1380
Při tom pokusu s GRE, tak pokud ho obaluješ pomocí IPsec transportu, tak MTU na tom GRE tunelu by nemělo být větší jak 1432 (pokud to balíš do IPsec tunelu, tak je to ještě cca o 20 bajtů horší), aby nemusela IPsec vrstva fragmentovat. A je opět vhodné patřičně regulovat MSS v tom GRE tunelu.
Kolik ti to dá, pokud zkusíš dát bandwith test mezi těma Mikrotiky skrz ten GRE tunel na přímo? To jede podstatně rychleji, že? Pokud ano, tak jsi ve stejné situaci, v jaké tu je těch X vláken na téma "pomalá rychlost na jedno TCP spojení", ten IPsec tunel to ještě zhoršuje, pokud ztrátuje. Jestli se ti to při TCP přenosu chová tak (např přes FTP), že pilovitě stoupá, pak se to sekne, spadne a znova postupně stoupá a takto pořád dokola s tím, že dlouhodobější průměr máš těch 12 Mbps, tak aplikuj na to, co posíláš do toho GRE tunelu, shaping třeba pomocí SQ a řízni to někam, kde nedojde k zahlcení toho RR spoje, pak ti to pojede třeba spokojeně 50 Mbps...
0 x
Zdravím,
potřeboval bych poradit jaké náležitosti šifrování zvolit v Proposals a Peers pro největší datovou propustnost IPsec tunelu (na zabezpečení se klade nejmenší důraz - největší na rychlost a propustnost)
Děkuji za odpověď
potřeboval bych poradit jaké náležitosti šifrování zvolit v Proposals a Peers pro největší datovou propustnost IPsec tunelu (na zabezpečení se klade nejmenší důraz - největší na rychlost a propustnost)
Děkuji za odpověď
0 x
Nu, pokud na bezpečnost kašleš zcela a chceš jen výkon, tak použiješ proposal, který máš předdefinován pod jménem null - vypnuté šifrování i podepisování. 
Nicméně pak je možná jendodušší použít přímo GRE nebo IPIP tunel. 
Nejrychlejší na nějakém tupém RouterBoardu bude proposal používající jen holý DES typu:
/ip ipsec proposal
add name=velkadira auth-algorithms=null enc-algorithms=des pfs-group=none
Pokud máš na obou stranách RB1100AHx2 nebo CCR, tak se dá použít AES-CBC+SHA, které to umí dělat v hardware.
Pokud by na obou koncích byly relativně nové PC, tak možná zkusit použít AES-GCM, pro který mají novější Intel CPU podporu v hardware (automaticky obsahují vedle šifrování i podepisování) a ROS to snad už také podporuje.
Co použiješ v Peers, tak tam se můžeš trochu rozšoupnout, protože se to používá/vyjendává jen občas, tak i celkem slabší RBčko přežije (pokud nemáš tuny tunelů) SHA256+AES256+MODP2048.
Nicméně pak je možná jendodušší použít přímo GRE nebo IPIP tunel. Nejrychlejší na nějakém tupém RouterBoardu bude proposal používající jen holý DES typu:
/ip ipsec proposal
add name=velkadira auth-algorithms=null enc-algorithms=des pfs-group=none
Pokud máš na obou stranách RB1100AHx2 nebo CCR, tak se dá použít AES-CBC+SHA, které to umí dělat v hardware.
Pokud by na obou koncích byly relativně nové PC, tak možná zkusit použít AES-GCM, pro který mají novější Intel CPU podporu v hardware (automaticky obsahují vedle šifrování i podepisování) a ROS to snad už také podporuje.
Co použiješ v Peers, tak tam se můžeš trochu rozšoupnout, protože se to používá/vyjendává jen občas, tak i celkem slabší RBčko přežije (pokud nemáš tuny tunelů) SHA256+AES256+MODP2048.
0 x