Otázka je, co je to definice ideální tunel, z jakého úhlu pohledu?
Co se týše porovnání zatěže ni routeru při L2TP/PPTP kontra IPsec, je to dáno naročností algoritmu. PPTP/L2TP (a pokud nevypnu u SSTP, tak i vnitřní SSTP přenos) používá proudovou RC4 šifru, ta se nepovažuje za nejlepší, ale pro běžné použití dostatečná. Má výhodu, že je snadno implementovaltená a rychlá, za cenu menší bezpečnosti (ale dostatečné u běžného použití).Průser je ta handshake stránka věci, kdy se domlouvá daný symetrický klíč, to MS zprasil a už se to veze.
IPsec s 3DES, AES a spol blokovými šiframi je mnohem náročnější na CPU. Navíc, pokud si zapnete i podepisování, tka to ještě przní MD5 nebo SHA1. Ale vhondým nastavením řpi ještě rozumném zabezpečení se dá vyrazit slušný výkon. Nicméně pro větší toky to chce něco s HW akcelerací, bez akcelerace pro větší rychlosti připadá tak RB800 pro 50 Mbps a RB1100AH pro 100 Mbps, aby tomělo ještě výkonovou rezervu pro další blbosti (RB4xxAH se hodí tak do 10 Mbps s rezervou výkonu).
EoIP, GRE, IPIP, SIT jsou jen tunely bez zabezpečení, to musím něčím obalit. Navíc, zda často raděná varianta, že mám vzít EoIP a obalit to PPTP je blbost, když PPTP umí samo o sobě L2 bridgie.
K té síle hesla u PPTP a spol - je to úplně jedno. Respektive, pokud vezmu nejprofláknutější službu cloudcracker (jsou výkonější a levnější), tak když jim strčíte uvodní sekvenci, tak do 20 minut vám projdou to proti 300.000.000 nejěžnějších hesel (za 17 USD - hodně předraženo, je i slovník 800 mega hesel za 2 eura). Pokud najdou, víte jméno a může směle dešifrovat. Pokud heslo nebude ve slovníku, tak za 20 USD (je vidět tlak konkurence, nedávno ještě chtěli nelidských 100 USD) projdou do max 24 hod celý DES prostor a dodají hash hesla, takže vím jméno(jméno) a tento hash už je vlastní šifrovaíc klíč, s ním můžu dešifrovat jakoukoliv komunikaci součansou nebo minulou zachycenou (není implementován princip perfect-forward-secret), stejně tak úspěšně nasimulovat přihlášneí, kde se používá MS-CHAP.
Co se SSTP týče, to je v pohodě. Protože je to celé obaleno TLS obálkou (pokud ji nevypnu, Mirkotik tuhle blbost umí) a provádím ověřování certifikátů. Problém je v tom MS-CHAP (a je jedno, zda v1 nebo v2). Mikrosoft to ví tak 15 let, proto nahrazoval PPTP pomocí L2TP/IPsec, který ten omyl schová, později SSTP. Pokud by Mikrotik podporoval EAP protokol s vatriantpou PEAPv1, kdy je ta MS-CHAP sekvence zabalena do TLS obálky, tak by to bylo v pohodě, pasivní odposlech není možný a PPTP i L2TP bez IPsec obalu by byly v pohodě. Bohužel toto neumí v režimu klient, umí to jen jako server ve spolupráci s Radius serverem.
Nicméně problém SSTP je třeba to, že je to TCP, a to občas při přenosu TCP v TCP dává divné výsledky. Podobně blbě je na tom i OpenVPN. Kdyby měli i podporu pro UDP variantu, byla by to dobrá varianta na ROSu... Jiná věc je třeba efektivita. Pokud mám třeba MTU1500, tak PPTP efektivně přenese cca 1480 bajtů vnořeného MTU, L2TP cca 1460, kdežto SSTP jen cca 1370. Všichni 3 umí zachovat MTU1500 uvnitř tunelu za cenu fragmentace/reasemblace paketů.
Já používám pro pevné bof-bod tunely nejčastěji GRE tunel obaleny IPsec transportem, kde neí problém se zkráceným MTU. Kde musím mít L2 nebo MTU1500, tak EoIP/IPsec (už by s emohl ROS naučit MPLS over GRE a VPLS tunel by to řešil v jendom). Pro mobilní klienty IPsec v IKEv2 (ROS neumí) nebo L2TP/IPsec. Pro něco SSTP jako záloha, když IPsec bude neprůchozí nebo to není kritické na přenosový výkon.
Navíc SSTP implementace v ROS má v sobě nějakou chybu. Mám na RB1100AHx2 SSTP koncentrátor pro cca 50 tunelů a RBčko se pravidelně resetuje, když spadne za den jen 5x, je to úspěch (je tam pár RBček v backup režimu, padá vždy to aktivní a i na fóru je dost pláče na téma SSTP v ROSu).
