IPSec vs OpenVPN

Hálózatok egyéb

Sziasztok!

PPPoE kapcsolaton keresztül csinálnék tunnelt két RouterBoard 1100AH között.

Dinamikus routingot szeretnék rátenni, hogyha megállna a bérelt vonal, akkor átálljon erre.

Első körben azt a megoldást próbáltam, hogy létrehozok egy IPSec tunnelt, amin összekapcsolom a két eszközt EoIP tunnel segítségével. (erre azért van szükség, mert a dinamikus routinghoz interfész kell)

Az IPSec előnye, hogy a Routerboard 1100AH hardware gyorsítással bír. Úgy tűnik, az a hátránya, hogy még EoIP segítségével SEM tudok 1500byte-os frameket fragmentáció nélkül megfelelően tunnelezni.
Talán ez az oka annak, hogyha "local" kapcsolódok, akkor ~100% átviteli kapacitást tudok realizáni, ha
másik site-ról kapcsolódok ezen a vonalon keresztül (szimulálva a bérelt vonali szakadást) maximum ~30-50%-t attól függően, hogy sok (10) vagy nagyon sok (50) szálon indítom a letöltést.

Ha az IPSec-et lekapcsolom és helyette OpenVPN-t használok (Mikrotik féle implementációval) akkor minden rendben működik, mennek a full frame-ek, távoli site-on is megy a teljes sebesség, egy apró gond van:
Mivel OpenVPN AES-t nem gyorsítja a hardware (csak IPSec-t), ezért képes teljesen lezabálni a procit.

Van esetleg tippetek, mi lehet az orvosság?

Nyitottam egy threadet OpenVPN átviteli sebességgel kapcsolatosan is.

  • 7309 megtekintés

( kroozo v | 2013. 12. 30., h – 11:01 )

Microticket nem ismerem, de IPsecnél a fejlécezés miatt le kell venni az mss-t (max segment size) az aktuális MTU alá. A juniper ökölszámnak 1350-et javasol a példa doksikban, de ha jól látom, te még pppoe vagy hasonló keretezést is csinálsz, lehet kicsit lejebb is kell menni (bár szerintem az 1350 eleve alálövés)

Gyors google-fu ezt dobta: http://forum.mikrotik.com/viewtopic.php?f=2&t=65733 , és ha azt csinálja a nyitóban levő code, mint amit úgy kb. ki lehet olvasni belőle, akkor szerintem neked jó is lesz.

( akoscomp | 2014. 07. 02., sze – 16:11 )

Találtál valami megoldást a problémára?
Én is össze kell kössek két telephelyet titkosítva. Eddig OpenVPN-el volt összekötve, de a jelenlegi internetbérlet 100 Mbps-t tesz lehetővé, és jó lenne kihasználni.
Két RB1100x2 között (direkt kötve) OpenVPN-el egy irányba kb. 50 Mbps-t tudtam kihozni, sima IPSec tunnel-el 500-600 Mbps-t.

Nagyon látszik az IPSec hardware támogatás előnye, csak kérdés, hogy lehet jól implementálni.

Ha sima IPSec tunnelt implementálok, nem hiszem, hogy gondom lenne az MTU-val, de észrevettem, hogy néha elég nagyok a kiesések (kiesnek ping-ek, csak többszöri próbálkozásra tudja felvenni a kapcsolatot távoli szolgáltatással, stb).
Tesztelted esetleg valamilyen tunnel megoldásal kombinálva (GRE, EoIP)

AES128, 192 és 256-ot próbáltam, mert kritikus a titkosítás. Az eredmény kb ugyanaz volt, AES128-al felment 650 Mbps köré a sebesség.
Lehet, hogy ront még egy réteg, de az IPSec 500-600 Mbps sebességéből bőven ronthat. Nekem a funkcionalitás számít.
IPSec esetében úgy viselkedik, mintha egy bizonyos timeout után szétkapcsolna, és ha megint jön adat akkor visszakapcsolna. Ugyanis ha elkezdem pingelni a másikat és közben csinálok valamit, akkor az átmegy egyből, de ha 1-2 perc után próbálok másolni vagy sebességet tesztelni, akkor időbe telik amire megint van kapcsolat.
Ez elég érdekes, mert az IPSec amennyire tudom, nem függ az állandó kapcoslattól, bár a Remote Peers alatt mint kapcsolat jelenik meg a másik oldal, de az uptime, az nem esik le.

szerint a célhardwarenek (majdnem)mindegy h milyen AES kódolás...
Azon mondjuk csodálkoznék, ha az AES128-at is feltörnék (főleg, ha havonta váltasz jelszót, mert ugye :-)
fura, nekem sosem "szakadt meg" magától. Az igaz, ha nem volt UP, akkor kellett a csatornába request, hogy kapcsolódjon.

ha elolvasod, amit leírtam, akkor láthatod, hogy nekem interfészre van szükségem (nem csak tunnelre) ez pedig IPSec-el ugye nincs... próbáltam EoIP-t is, az átvitel frankó volt, de - mint írtam - a fragmentációval akadtak gondok, ezért maradtam végülis az OpenVPN-nél, mert ugyan jóval CPU igényesebb, de sikerül vele a rendelkezésre álló csövet kitömni (így nagyon nem izgatom magam).

Ami nagyon sokat segített az az volt, hogy megnéztem milyen queue jön létre az OpenVPN dinamikus interfészhez (default?) ennek a paramétereit megváltoztattam. Alapba talán 5-20 packet fér be a queue-ba, ezt nagyságrendileg 400 packet-re emeltem, így már bőven tud mit optimalizálni az OpenVPN.
(most kipróbáltam, h levettem 400-ról 40-re, uazt mutatta, szóval lehet, h mindössze annyi volt a diff, h SFQ helyett pfifo a scheduler?)

Azt még ki fogom próbálni, hogyha RB helyett PC van mindkét oldalon, akkor mi az eredmény, mert az OpenVPN nagyon mostohán van kezelve Mikrotik oldalról.
A PC implementáció ugye tud menni UDP-vel is és tud LZO tömörítést (a Mikrotik a kettő közül egyiket sem)