Myslím, že je teď správný čas, abys to vyzkousel a pripadne jim napsal dokud je to jeste beta:
https://forum.mikrotik.com/viewforum.php?f=1&sid=012154b9c0c1daf0c9e6a2b235ec7161
On je celý OpenVPN totální fail. V době setkilobitových linek to bylo příjemné řešení. Postupem doby se stal k ničemu, bez ohledu na TCP nebo UDP. TCP varianta má ovšem jistou výhodu. Na vyhnilých linkách, kde nejde o rychlost ani latenci, dokáže aspoň zvýšit spolehlivost. Někdy se to pekelně hodí. (Kdysi, blahé paměti, jsem na toto měl raději daleko jednodušší vtun, ale ten skončil v propadlišti dějin.
Mikrotik si s verzí 7 dá pěkně na ústa. Už verzi 6 ohýbali až za hranice flexibility. Advanced konfigurace se dělají spíš metodou pokus-omyl, některé operace dokonce vyžadují reboot (ačkoliv se tváří, že ne). Přechod na sedmičku bude velmi bolestivý. (Ale ti, co na ní budou rovnou začínat, pro ně to bude určitě lepší).
Jsem zvědavý, jestli dokáží něco provést s akcelerací v případě použití VRF. To je pro bezpečnost důležité, ale zabiják výkonu. V šestce a na všech HW musí jít veškerý provoz přes CPU. Pokud s tímto nepohnou, zůstane to dál jen hračkou :(. Doba hraje proti nim, průtoky linek se zvyšují, bezpečnost se stále více akcentuje a mikrotiky nestíhají.
Mam sice jen 300/100Mbps ale skvele mi chodi MIkrotik hEX S za cca 1500 Kc.
https://www.abctech.cz/mikrotik-routerboard-rb760igs-hex-s-5xglan-sfp-usb-l4-psu_d36297.html
Kouknete na vysledky testu https://mikrotik.com/product/hex_s#fndtn-testresults
Jedina nevyhoda toho routeru je, ze nema WiFi.
Jinak jsem koukal a mistni ISP pouziva dokonce starsi verzei, nez hEX S pro cele panelaky.
Ono je to trochu klamavé. Speedtesty posílají velké packety a na nich výkon jde. Zkuste si nastavit MTU a MSS clamping na něco malého (100 bajtů třeba) a už to uvidíte. Jakmile zapnete VRF a třeba ještě přidáte bridge, spadne to ještě o dramatický kus - podle toho, co za funkce využíváte, tak Mikrotik dokáže nebo nedokáže využívat hardwarové akcelerace a od toho se to pak odvíjí.
Taky mlží, jen při jejich cílení už musí dávat aspoň některé informace.
Např. se bez vlastních znalostí nedovíte, že ta jejich tabulka platí v případě, že je možné použít FastPath a FastTrack. FastPath ještě jde, pokud nepotřebujete filtrovat na bridgi. FastTrack je ale nepoužitelný ve chvíli, kdy potřebujete VRF nebo packet scheduler. V tu chvíli se z jejich tabulky nedozvíte nic kloudného a reálný průtok je čtvrtinový.
Hodně přínosné by bylo, kdyby zveřejňovali výkon skrz CPU na jednom jádru a na více jádrech (některé operace jdou jen přes jedno jádro). Tyto dva údaje by daly už daleko lepší přehled o výkonu. Jenže zrovna tyto by byly dost nepříznivé.
Dle mého názoru 20 let už ne - rozšíření IPv6 se blíží hranici překlopení, po které začne rychle klesat vytížení NATu, takže 1. jeho rychlost už nikoho nebude zajímat (když to nedořešili doteď, tak už to řešit nebudou), 2. poskytovatelé se o to nebudou chtít starat, takže se to začne řešit pomocí NAT64.
No Mikrotik nemá ani tak problémy s IPSecem jako takovým, ale spíš s tím, jak se s tím packetem pracuje. On na jednu stranu přichází šifrovaný a router Vám chce dát možnost s ním i tak pracovat. Pak se odšifruje a router Vám chce dát znovu šanci s ním pracovat (resp. toto není potřeba, ale nutnost). A oni strašně bojují (ostatně stejně jako čistý Linux) s tím, že pak je ten flow packetu docela zapeklitý. Už jen to, aby Vám skrz bridge a IMQ/HTB neprošel dvakrát apod. Pokud používáte VRF, musí se nejprve odšifrovat a pak teprve otagovat a zařadit do správné tabulky.., .... Velmi často se IPSec používá s GRE - další klička navíc...
Takže v praxi to je opravdu peklo. Peklo, které pramení z absolutní univerzálnosti Linuxu.
Wireguard by to opravdu usnadnit mohl a ztráta univerzálnosti by mohla být jen minimální.
I když je to dost smutné, pár komerčních produktů co uměj ipsec má pod kapotou Linux taky a až tolik problémů nevykazují.
Vždycky se říkalo, že nejvyšším standardem jsou chyby Cisca :). Myslím, že je to přiléhavé a situaci vysvětlující rčení. Každý vendor dá svému zařízení do vínku určité možnosti a v rámci nich pak nastavujete. Mikrotik se snaží o tak moc velkou univerzálnost, že se komplikacím nemůže vyhnout. Osobně raději VPN terminuju na jiném Mikrotiku, než na kterém routuji. Značně to pak usnadňuje pravidla a po započtení stráveného času to vyjde i levněji.
Další kouzelná kapitola je třeba BGP. Když máte navíc rozchozené VRF, tak se BGP používá pro injektování cest mezi jednotlivými VRF. To zkombinovat dohromady do něčeho rozumného taky vytvoří prakticky nečitelnou (= nepoužitelnou) konfiguraci.
HTB/IMQ je v ROS6 jen jedno centrální, takže nelze oddělit toky ven (do internetu) od toků dovnitř (z internetu) pomocí dvou odlišných HTB. Takže se to musí řešit pomocí markování. Pokud potřebujete řídit např. přípojky (plus jeden uplink), jsou to čtyři třídy. To celé krát dva směry = osm tříd. Pokud přidáte TOS/DSCP - třeba jen rozlišený na další čtyři pásma, už jste na dvaatřiceti třídách. ... Potřebujete connmark pro odlišení VRF (zejména pro vystavení interních služeb ven) a teprve po connmarku můžete provést packetmark. Celé Vám to pak vyjde třeba na víc než 100 různých connmarků, které musíte použít, abyste provoz nastrkal do HTB. Na to už si musíte udělat script, který toto všechno nageneruje (ručně to konfigurovat je nemyslitelné), který pak vytvoří v bratru 400 řádků pravidel do mangle. ...a teď se podívejte do testů výkonu, co s Mikrotikem dělá i blbých 25 pravidel, na kterých to testují.
Myslím, že např. v této oblasti si strašně nechali ujet vlak. Linux opravdu umí jeden connmark na spojení a jeden packet mark na paket. Pokud ale něco od routeru očekávám je, že mi poskytne k těmto low level funkcím (omezením) rozhraní, kde budu moci např. pracovat s více značkami na packet (a router si to interně převede do značek, které vyžaduje jádro).
Chápu, že 99,9% uživatelů nic takového nepotřebuje a nikdy potřebovat nebude. Jen mi to celé nesedí do strategie. Na jedné straně chtějí podprovat opravdu advanced funkce, na druhé straně je přinášejí tak nesmírně blbě, že jsou až na hranici použitelnosti.
Na druhou stranu, nemít NDA tak o tom jak různé i o několik řádů dražší produkty řeší různé feature requesty stylem pejsek a kočička pečou dort a jak si krásně naběhnete když třeba jen část z toho opravdu potřebujete použít by se daly vyprávět mnohé nekonečné příběhy, takže konkrétně Mikrotiku bych už s ohledem na cenové relace dost odpustil - jak říkáte je to snadno řešítelné dedikovanou VPN gatewayí (což by i bez chyb byl velmi dobrý nápad, už i s ohledem na jednodušší správu a míň zavlečených chyb) a když se navíc pohybujete v tísícovkách korun za box, tak jste na tom mnohem lépe než u desetitsíců euro za applianci u většiny konkurence.
@J ouda
Pravdu díte.
Mikrotiku vyčítám bídnou dokumentaci - právě tyto nuance musíte nalézt metodou pokus-omyl a v syntéze se znalostmi, jak funguje linuxový netfilter.
To, o tom ujetém vlaku, to bylo spíš povzdychnutí, protože si myslím, že měli nakročeno na víc. Teď ztrácejí půdu pod nohama, bezdrátové sítě ve stejném segmentu jim vypaluje Ubiquity.