Chtěl bych propojit jinou část sítě se stávající sítí. Problém je ale, že ta nová část je v jiném městě, takže to chci udělat VPNkou. Říkal jsem si, že bych použil OpenVPN, ale zas nevím, jak je to s náročností na CPU. Jaké používáte VPNky pro trvalé spojení vy?
Moje představa je taková, že by přes to žádná velká extra data nešla, spíš jen dohled zařízení a sem tam se bude hodit i možnost moct tu druhou část sítě moct managovat.
Díky.
❗️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
Jakou VPN pro trvalé spojení sítí
-
klobasanet
- Příspěvky: 57
- Registrován: 12 years ago
- Bydliště: Údírna
Já používam gre tunel, maximálně by to šlo prohnat ještě přes pptp a na tom gre
0 x
Pokud mikrotik na oba konce, tak EoIP.. Provozovani na cca 100 zarizenich vic jak 3 roky.. Bez problemu.. 
0 x
Používáme OVPN server na RB450, připojených je kolem 200 zařízení (MKT, Linux, Win) a load cca 10 %. Drobnou vadou je, že pokud i na krátký okamžik vypadne přípojka do netu u tohoto RB, dostane se do stavu, kdy load vyskočí na 100 %, MKT se pak snaží obsloužit a navázat všechna spadlá připojení najednou, ale nenaváže se nic. Musí se restartovat, pak opět funguje, neboť pak proces navazování spojení probíhá maximálně u 5 klientů najednou.
0 x
Nick_xx píše:Používáme OVPN server na RB450, připojených je kolem 200 zařízení (MKT, Linux, Win) a load cca 10 %. Drobnou vadou je, že pokud i na krátký okamžik vypadne přípojka do netu u tohoto RB, dostane se do stavu, kdy load vyskočí na 100 %, MKT se pak snaží obsloužit a navázat všechna spadlá připojení najednou, ale nenaváže se nic. Musí se restartovat, pak opět funguje, neboť pak proces navazování spojení probíhá maximálně u 5 klientů najednou.
Tam máš pak nastavený nějaký watchdog nebo jak to řešíš? Počítám, že asi nejezdíš MK restartovat manuálně a asi se na něj ani vzdáleně nedostaneš ne?
0 x
..:: DobraSit.cz ::..
RB1100AHx2 jako server, také nějaká stovka SSTP tunelů, po rebootu se klienti připojují hbitě a OK, bez výtuhu. Aspoň na ROS6.0rc14, v ROS5 měli bug, kdy RB zahučelo čas od času u SSTP serveru. U SSTP klienta je zase bug, že se zapomene čas od času připojovat (probere ho disable/enable).
Jimak k tomu poptávanému účelu je ais podstatné, zda se mají data nějak chránit nebo jen tunelovat, od toho bych volil, co použít. Pro takovýto management bez nutnosti zabezpečení normálně používám GRE, při požadavku na zabezpečení ho obalím pomocí IPsec teransportu. Pokud je požadavke, že se musí zachovat MTU1500 uvnitř tunelu, tak třeba to EoIP.
Jimak k tomu poptávanému účelu je ais podstatné, zda se mají data nějak chránit nebo jen tunelovat, od toho bych volil, co použít. Pro takovýto management bez nutnosti zabezpečení normálně používám GRE, při požadavku na zabezpečení ho obalím pomocí IPsec teransportu. Pokud je požadavke, že se musí zachovat MTU1500 uvnitř tunelu, tak třeba to EoIP.
0 x
Petr S. píše:Tam máš pak nastavený nějaký watchdog nebo jak to řešíš? Počítám, že asi nejezdíš MK restartovat manuálně a asi se na něj ani vzdáleně nedostaneš ne?
Po VPN se tam sice dostat nedá, ale přes veřejnou IP nebo z jiného mikrotika v téže síti se na něj dostat dá. O výpadcích se většinou dozvídám, takže RB automaticky restartuji. Pokud je to mikrovýpadek, kdy vyhnije jen VPN a ostatní služby nic nezaregistrují, přijdu na to sám, až se budu chtít na nějakého klienta připojit. Watchdog ať už v mikrotiku, nebo ze serveru přes API, zatím nebylo potřeba řešit.
0 x
po vypadku konektu po vyprseni keepalive timeout killne postupne vsecny tunely, kdyz se konekt obnovi, normalne se zacnou ovpn klienti pripojovat, je pravda ze max 5 najednou, musi jim vypocitat nejake rsa klice ci co a to je pomerne narocne na cpu, postupne pripoji vsechny. U rb s mipsem na 800mhz trva pripojeni 100 vpn asi 3 minuty.
0 x
TTcko píše:Pokud mikrotik na oba konce, tak EoIP.. Provozovani na cca 100 zarizenich vic jak 3 roky.. Bez problemu..
Není EoIP nešifrovaná?
0 x
..:: DobraSit.cz ::..
akurat si mi zobral otazku 
podla mna ten eoip nie je sifrovany... tak ja pouzivam zatial na vsetko pptp a v pohode akurat co sa trapim s maklikom ale to uz pri inej teme ked to chcem prehodit na iny eth...
podla mna ten eoip nie je sifrovany... tak ja pouzivam zatial na vsetko pptp a v pohode akurat co sa trapim s maklikom ale to uz pri inej teme ked to chcem prehodit na iny eth...
0 x
EoIP šifrované není, stejně jako ostatní normální IP tunely (GRE, IPIP, GRE6, IPIPv6). Taktéž PPPoE není normálně šifrován, jde v MK zapnout, ale platí pro něj následující odstavec..
Co se tyká odolnosti L2TP (bez IPsec) a PPTP, tak jejich doba potřebná k zlomení je v mikrotik implemetnaci cca 20 minut, pokud uslyším úvodní sekvenci navazování protokolu. PPTP jde požádat na dálku posláním vhodného bordelu řadě NAT bran s PPTP helperem (chyba v PPTP helperech, možná je by design, aby to vůbec skrz NAT fungovalo), aby PPTP navazované spojení poslala ke mně místo požadovanému PPTP serveru, takže nemusím být ani v cestě komunikace. Pro L2TP se musím dostat do cesty toho spojení a poslouchat. Pokud je někdo echt kteativní v generování hesel (zcela náhodný řetězec), tak maximálně 24 hodin. PPTP a L2TP neodolá tak ani pasivnímu odposlechu, abych získal potřebné autorizační údaje na to, aby se dokázal přihlásil nebo zpětně dešifroval jakoukoliv komunikaci šifrovanou danými ověřovacími údaji. Podobně blbě je na tom IPsec používající Auth method=pre shared keys s exchange mode=aggressive (to je chyba v IPsec protokolu by design). Chyba v řadě implementací IPsec pak je, že odpovídají na agressive mód i když nemají (takže o potřebné hashe jde pěkně požádat na dálku a pak sei je v klíku za den/dva přežvýkat, pokud takový režim používám bez omezení adres protistran)...
Problém šifrovaného PPTP, L2TP a případně i PPPoE celkem efektivně by řešilo použití EAP, nejlépe EAP-TTLS a v něm teprve vložený ten MSCHAP, případně pak PEAPv0/EAP-MSCHAPv2, který je podporován asi o dob Windows 2000. Mikrotik pro VPN připojení EAP nepodporuje.
Pokud L2TP/PPTP/PPPoE používáte s ověřováním pomocí CHAP a PAP, tak se spojení vůbec nešifruje (šifrování funguje pouze v kombinaci s MSCHAPv1/2). Je to velice efektivní způsob útoku, pokud můžu aktivně zasáhnout. Když nemá klient vysloveně zakázáno použití PAP, CHAP a přikázáno šifrovat, tak mu odopovím s nabídkou pouze PAP autorizace a přihlašovací údaje dostávám v čitelné formě v následujícím paketu.
Pak je nějaký průser v OpenVPN, ale jen pro ROS6. Nepochopil jsem z dané demonstrace, zda problém je, když OpenVPN na MKčku je klient, server nebo oboje. Daný útok nefunguje v ROS5 (má fungovat i na MS Windows systémy, pokud se používá TCP režim spojení).
Edit: Máme rok 2013... Už od roku 2000 řve Microsoft, že používat PPTP (a L2TP bez IPsec obálky) v kombinaci s holým MSCHAPv1/2 je průser a říká nepoužívat...
Co se tyká odolnosti L2TP (bez IPsec) a PPTP, tak jejich doba potřebná k zlomení je v mikrotik implemetnaci cca 20 minut, pokud uslyším úvodní sekvenci navazování protokolu. PPTP jde požádat na dálku posláním vhodného bordelu řadě NAT bran s PPTP helperem (chyba v PPTP helperech, možná je by design, aby to vůbec skrz NAT fungovalo), aby PPTP navazované spojení poslala ke mně místo požadovanému PPTP serveru, takže nemusím být ani v cestě komunikace. Pro L2TP se musím dostat do cesty toho spojení a poslouchat. Pokud je někdo echt kteativní v generování hesel (zcela náhodný řetězec), tak maximálně 24 hodin. PPTP a L2TP neodolá tak ani pasivnímu odposlechu, abych získal potřebné autorizační údaje na to, aby se dokázal přihlásil nebo zpětně dešifroval jakoukoliv komunikaci šifrovanou danými ověřovacími údaji. Podobně blbě je na tom IPsec používající Auth method=pre shared keys s exchange mode=aggressive (to je chyba v IPsec protokolu by design). Chyba v řadě implementací IPsec pak je, že odpovídají na agressive mód i když nemají (takže o potřebné hashe jde pěkně požádat na dálku a pak sei je v klíku za den/dva přežvýkat, pokud takový režim používám bez omezení adres protistran)...
Problém šifrovaného PPTP, L2TP a případně i PPPoE celkem efektivně by řešilo použití EAP, nejlépe EAP-TTLS a v něm teprve vložený ten MSCHAP, případně pak PEAPv0/EAP-MSCHAPv2, který je podporován asi o dob Windows 2000. Mikrotik pro VPN připojení EAP nepodporuje.
Pokud L2TP/PPTP/PPPoE používáte s ověřováním pomocí CHAP a PAP, tak se spojení vůbec nešifruje (šifrování funguje pouze v kombinaci s MSCHAPv1/2). Je to velice efektivní způsob útoku, pokud můžu aktivně zasáhnout. Když nemá klient vysloveně zakázáno použití PAP, CHAP a přikázáno šifrovat, tak mu odopovím s nabídkou pouze PAP autorizace a přihlašovací údaje dostávám v čitelné formě v následujícím paketu.
Pak je nějaký průser v OpenVPN, ale jen pro ROS6. Nepochopil jsem z dané demonstrace, zda problém je, když OpenVPN na MKčku je klient, server nebo oboje. Daný útok nefunguje v ROS5 (má fungovat i na MS Windows systémy, pokud se používá TCP režim spojení).
Edit: Máme rok 2013... Už od roku 2000 řve Microsoft, že používat PPTP (a L2TP bez IPsec obálky) v kombinaci s holým MSCHAPv1/2 je průser a říká nepoužívat...
0 x
Já teď konkrétně třeba stojím před problémem, jakým způsobem spojit dvě části sítě, obě v jiném městě, a to tak, aby z jedné sítě bylo možné mít přístup na management prvků v síti druhé. Jsou tam vytvořeny MGMT VLANy, takže by stačilo propojit jenom tu přes VPN. A tohle se mi bez šifrování nebo s chabým vůbec dělat nechce 
A jak se mi to tak jeví, tak pokud chci opravdu bezpečnou vpn tak si nevyberu
Jediná možnost je asi použít IPSec bez aggresive mode, že?
A jak se mi to tak jeví, tak pokud chci opravdu bezpečnou vpn tak si nevyberu
Jediná možnost je asi použít IPSec bez aggresive mode, že?
0 x
..:: DobraSit.cz ::..
Je to bída 100 let za opicema... Kde je třeba IKEv2 podpora pro IPsec, ať se můžou klienti s WIn Vista/7/8 připojovat trošku na úrovni (a ne L2TP/IPsec opičárny), natož SuiteB ECSDA kreyptografická podpora? Vždyť je to ostuda...
Buď IPsec s RSA klíči nebo SSTP s využitím povinných certifikátů oběma směry (hezké privátní rozšíření Mikrotiku, eliminující slepé pokusy o hádání hesel cizáky, pokud potřebuji řešit jen ROS-ROS spojení).
Pokud je to víc IP segmentů, pak se použití klasického IPsec tunelu komplikuje z pohledu složitých SPD. Také skrz klasický IPSec tunel nejde poslat rozumně nějaký dynamický routovaný protokol. Proto pro pro propojení větších síti se složitější sturkturou používám GRE (v ROS6 tím jde poslat i IPv6 v kombinaci s OSPFv3) a ten je obalen IPSec v transportním režimu Pokud je potřeba L2 propojení, tak je možno použít i EoIP tunel, opět vložený do IPsec transportu. Druhá možnost pro L2 tunel je i ten SSTP s aktivovaným BCP.
Pro připojení mobilních klientů je pak akceptovatelné L2TP/IPsec, kde IPsec vrstva používá X.509 certifikáty a nebo to SSTP.
Pro volbu zda GRE/IPsec nebo EoIP/IPsec může být i fakt, že v EoIP/IPsec bude zachován MTU 1500, kdyby to něčemu vadilo. V SSTP bude zachováno MTU1500 také. Samozřejmě to dělají díky automatické fragmentaci a skládání paketů dohromady, což občas brzdí. Klasický GRE/IPsec má MTU1432, pro TCP věci to řeší šáhnutí na MSS, což řeší 95% problémů.
MTU jde i zachovat v ROS6 pro GRE/IPsec s aktivovaným MPLS nad GRE. Ale MPLS/GRE/IPsec složenina je už pro drsnější nátury v podání Mikrotiku.
Buď IPsec s RSA klíči nebo SSTP s využitím povinných certifikátů oběma směry (hezké privátní rozšíření Mikrotiku, eliminující slepé pokusy o hádání hesel cizáky, pokud potřebuji řešit jen ROS-ROS spojení).
Pokud je to víc IP segmentů, pak se použití klasického IPsec tunelu komplikuje z pohledu složitých SPD. Také skrz klasický IPSec tunel nejde poslat rozumně nějaký dynamický routovaný protokol. Proto pro pro propojení větších síti se složitější sturkturou používám GRE (v ROS6 tím jde poslat i IPv6 v kombinaci s OSPFv3) a ten je obalen IPSec v transportním režimu Pokud je potřeba L2 propojení, tak je možno použít i EoIP tunel, opět vložený do IPsec transportu. Druhá možnost pro L2 tunel je i ten SSTP s aktivovaným BCP.
Pro připojení mobilních klientů je pak akceptovatelné L2TP/IPsec, kde IPsec vrstva používá X.509 certifikáty a nebo to SSTP.
Pro volbu zda GRE/IPsec nebo EoIP/IPsec může být i fakt, že v EoIP/IPsec bude zachován MTU 1500, kdyby to něčemu vadilo. V SSTP bude zachováno MTU1500 také. Samozřejmě to dělají díky automatické fragmentaci a skládání paketů dohromady, což občas brzdí. Klasický GRE/IPsec má MTU1432, pro TCP věci to řeší šáhnutí na MSS, což řeší 95% problémů.
MTU jde i zachovat v ROS6 pro GRE/IPsec s aktivovaným MPLS nad GRE. Ale MPLS/GRE/IPsec složenina je už pro drsnější nátury v podání Mikrotiku.
0 x
Nick_xx píše:Používáme OVPN server na RB450, připojených je kolem 200 zařízení (MKT, Linux, Win) a load cca 10 %. Drobnou vadou je, že pokud i na krátký okamžik vypadne přípojka do netu u tohoto RB, dostane se do stavu, kdy load vyskočí na 100 %, MKT se pak snaží obsloužit a navázat všechna spadlá připojení najednou, ale nenaváže se nic. Musí se restartovat, pak opět funguje, neboť pak proces navazování spojení probíhá maximálně u 5 klientů najednou.
Zdravím, mám RB2011, ver 6.6, ovpn, po restartu RB navazuje cca 20 klientů spojeni asi 4 min. Má vliv nastavení hodnoty keepalive na tuto dobu, příp. čím to zkusit zrychlit? Verze fw, nějaká hodnota v nastavení ...
Dík za odpovědi
Odesláno z mého HTC Desire S pomocí Tapatalk 2
0 x
Zdravim, dotaz k ovpn: Funguje na nekterem rb 1100Ah2x nebo ccr HW akcelerace pro sifrovani aes256 na ovpn ? Jak velky je prinos v prenosove kapacite a odezvach na tunelech ? Resp. za jak dlouho prihlasi treba 100 klientu ?
0 x