Virtuális privát hálózat (Virtuális magánhálózat, a továbbiakban VPN) lehetővé teszi a létrehozását az interneten egy biztonságos virtuális alagút egyik eszközről a másikra. Ha egy ilyen alagúton keresztül éri el a hálózatot, akkor mindenki más – beleértve az internetszolgáltatót is – Nagyon nehéz lesz figyelemmel kísérni a tetteit.

A VPN-szolgáltatások a fizikai tartózkodási helyére vonatkozó adatok bármely mással való helyettesítését is segítik, ami lehetővé teszi olyan szolgáltatások elérését, amelyek földrajzi elhelyezkedés alapján bizonyos régiók felhasználói számára blokkolva vannak. A VPN használata segít megvédeni a hálózaton keresztül továbbított üzenetek titkosságát (az adatok privátak maradnak) és integritását (az adatok változatlanok maradnak).

A VPN-hez való csatlakozás meglehetősen egyszerű. Először a felhasználó online lép fel, csatlakozik a szolgáltató szervereihez, majd VPN-kapcsolatot hoz létre a VPN-kiszolgálóval a kliens segítségével ( speciális program telepítve van a felhasználó számítógépére). A VPN-szolgáltatás ezután megkapja a felhasználó által kért oldalakat, és biztonságos alagúton keresztül továbbítja azokat neki. Ez biztosítja a felhasználói adatok és a magánélet védelmét az online munkavégzés során.

Hogyan működik a VPN-szolgáltatás titkosítása?

A VPN-protokoll az adatok továbbítására és titkosítására vonatkozó szabályok összessége. A legtöbb VPN-szolgáltatás több VPN-protokoll közül választhat ügyfelei számára, amelyek közül a leggyakoribbak: Pont-pont Tunneling Protocol (PPTP), Layer Two Tunneling Protocol (L2TP), Internet Protocol Security (IPSec) és OpenVPN (SSL/TLS). ) ).

Nem tudja megmagyarázni, hogy a VPN-szolgáltatások hogyan védik a felhasználók adatait anélkül, hogy a titkosításról beszélnénk. A VPN-szolgáltatások speciális adatfeldolgozási módszert (titkosítást) használnak, hogy az olvasott adatokat (sima szöveg) teljesen olvashatatlanná (titkosított szöveg) tegyék bárki számára, aki el tudja fogadni azokat. Az algoritmus (rejtjel) pontosan meghatározza, hogy egy adott VPN-protokoll keretein belül hogyan történik az adatok titkosítása és visszafejtése. A VPN-protokollok ezeket a kriptográfiai algoritmusokat használják az adatok titkosításához és titkosítására.

Ezen VPN-protokollok mindegyikének megvannak a maga erősségei és gyengeségei, a megfelelő kriptográfiai algoritmustól függően. Egyes VPN-szolgáltatások lehetővé teszik a felhasználók számára, hogy válasszon egyet az elérhető titkosítások közül. Háromféle titkosítás létezik: szimmetrikus, aszimmetrikus és hash.

A szimmetrikus titkosítás egyetlen kulcsot használ az adatok titkosításához és visszafejtéséhez. Az aszimmetrikus titkosítás két kulcsot használ: egyet a titkosításhoz és egyet a visszafejtéshez. Az alábbi táblázat összehasonlítja ezeket a titkosítási típusokat egymással.

Paraméter	Szimmetrikus titkosítás	Aszimmetrikus titkosítás
Kulcsok	Egy kulcs több entitáshoz	Az egyik entitás nyilvános kulccsal, a másik pedig privát kulccsal rendelkezik
Kulcscsere	Kívánt biztonságos út kulcsok küldése és fogadása	A privát kulcsot a tulajdonos őrzi, a nyilvános kulcs mindenki más számára elérhető
Sebesség	Könnyebb és gyorsabb	Nehezebb és lassabb
Megbízhatóság	Könnyebb feltörni	Nehezebb feltörni
Skálázhatóság	jó	Még jobb
Használat	Bármit titkosítani	Csak kulcsok és digitális aláírások
Biztonsági beállítások	A titoktartás biztosítása	Titoktartás, hitelesítés és megtagadás-megelőzés biztosítása
Példák	DES, Tipple DES, AES, Blowfish, IDEA, RC4, RC5 és RC6	RSA, ECC, DSA és Diffie-Hellman algoritmus

Az aszimmetrikus kriptográfia segít azokban az esetekben, amikor le kell küzdeni a szimmetrikus kriptográfiában rejlő korlátokat (amint azt a fenti táblázat mutatja). Whitfield Diffie és Martin Hellman része volt az első kutatócsoportnak, amely a szimmetrikus titkosítás fejlesztésén dolgozott, és kifejlesztették az aszimmetrikus titkosítási algoritmust, Diffie-Hellman algoritmus.

Ez egy népszerű kriptográfiai algoritmus, amely számos VPN-protokoll alapját képezi, beleértve a HTTPS-t, az SSH-t, az IPsec-et és az OpenVPN-t. Ezzel az algoritmussal két olyan fél, akik még soha nem találkoztak, megbeszélheti a privát kulcsot, még akkor is, ha a kommunikáció nem biztonságos nyilvános hálózaton (például interneten) keresztül történik.

A kivonatolás egyirányú (visszafordíthatatlan) titkosítás, amelyet a továbbított adatok integritásának védelmére használnak. Sok VPN-protokoll hash-algoritmusokat használ a VPN-en keresztül küldött üzenetek valódiságának ellenőrzésére. Ilyen például az MD5, SHA-1 és SHA-2. Az MD5 és az SHA-1 azonban már nem tekinthető biztonságosnak.

A VPN-szolgáltatásokat fel lehet törni, de ez nagyon-nagyon nehéz. Ha nem használ VPN-szolgáltatást, akkor lényegesen nagyobb az esélye annak, hogy a hackerek megkárosítsák.

Tud valaki feltörni egy VPN szolgáltatást?

A VPN-szolgáltatások továbbra is az egyik legmegbízhatóbb védelmi módszer felhasználói adatvédelem amikor a hálózaton dolgozik. Fontos azonban észben tartani, hogy bármit fel lehet törni, különösen, ha nagy értékű célpont vagy, és ellenségeidnek elegendő munkaerő, idő és erőforrás áll rendelkezésre. Szerencsére a VPN-szolgáltatások legtöbb hétköznapi felhasználója nem ilyen célpont, ezért nem valószínű, hogy túl sok figyelmet vonna magára.

A VPN-kapcsolat feltöréséhez meg kell szakítani a titkosítást, amihez vagy a rendszer vagy az algoritmus sebezhetőségeinek kihasználása, vagy a titkosítási kulcs valamilyen módon történő ellopása szükséges. A kriptográfiai támadásokat hackerek és kriptoanalitikusok használják arra, hogy titkosítási kulcs hiányában egyszerű szöveget nyerjenek ki a titkosított változatból. A titkosítás feltörése azonban rengeteg számítási erőforrást és időt igényel – egy ilyen probléma megoldása szó szerint évekig is eltarthat.

Sokkal gyakrabban próbálják ellopni a titkosítási kulcsot, és ez érthető is: sokkal egyszerűbb, mint a titkosítás megoldása. Ez az a módszer, amelyhez a hackerek először folyamodnak. Itt minden nemcsak a matematikán múlik, hanem számos tényező kombinációján, beleértve a technikai trükköket, a számítási teljesítményt, a megtévesztést, a bírósági végzéseket és a hátsó ajtók használatát, a vesztegetést és más piszkos módszereket. És mindezt azért, mert a rejtjelek megfejtése nagyon összetett és erőforrás-igényes feladat.

Ismert VPN biztonsági rések

Az ismert Edward Snowden és a számítógép-biztonsági szakértők nem egyszer nyilatkoztak arról, hogy az NSA (US Nemzetbiztonsági Ügynökség) feltörte a legtöbb internetes forgalom, így a VPN-szolgáltatások forgalmának védelmére használt titkosítást. Snowden anyagai szerint az NSA a VPN-forgalmat úgy fejti vissza, hogy elfogja a titkosított forgalmat, és továbbítja az adatokat nagy teljesítményű számítógépeknek, amelyek aztán visszaadják a kulcsot.

Alex Halderman és Nadia Heninger számítógép-biztonsági kutatók meggyőző jelentést nyújtottak be, amely azt mutatja, hogy az NSA valóban képes nagy mennyiségű HTTPS-, SSH- és VPN-forgalom visszafejtésére egy Logjam-támadás segítségével, amely a Diffie-algoritmus kulcsfontosságú felhasználásait célozza meg.

Az NSA sikerét a Diffie-Hellman algoritmus megvalósításának sérülékenységének köszönheti. Ennek a sérülékenységnek az a lényege, hogy a titkosító programok szabványos prímszámokat használnak. Halderman és Heninger azzal érvelnek, hogy több száz millió dollárért lehet olyan számítógépet létrehozni, amely elég erős ahhoz, hogy visszafejtse egyetlen 1024 bites Diffie-Hellman titkosítást. Egy ilyen számítógép elkészítése körülbelül egy évig tart, és ami az ehhez szükséges összeget illeti, az NSA éves költségvetése szempontjából nincs benne lehetetlen.

Sajnos előfordul, hogy általában nem minden prímszámot (1024 bitnél kisebb) használnak a mindennapi használat amelyek titkosítást használnak – beleértve a VPN-szolgáltatásokat is. Ennek eredményeként az ilyen algoritmusok feltörése még könnyebbé válik. Ahogy Bruce Schneier kijelentette: „A matematika jó, de nem lehet feltörni. De a kód más kérdés.”

Érdemes folytatni a VPN-szolgáltatások használatát?

Halderman és Heninger azt tanácsolja a VPN-szolgáltatásoknak, hogy térjenek át a 2048 bites vagy még bonyolultabb Diffie-Hellman titkosítási kulcsokra, valamint útmutatókat készítettek ezek használatára a TLS protokollal. Az Internet Engineering Task Force (IETF) a protokollok újabb verzióinak használatát is javasolja, amelyek hosszabb prímszámsorozatokat igényelnek.

A hackerek feltörhetik a Diffie-Hellman titkosítási kulcsokat, ha azok legfeljebb 1024 bit hosszúak (körülbelül 309 karakter). A 2048 bites kulcsok feltörése valódi problémát jelent majd a hackerek számára! Más szóval, nagyon sokáig nem tudják majd visszafejteni az ilyen kulcsokkal védett adatokat.

Ami a felhasználókat illeti, meg kell jegyezni, hogy a hackerek valóban tudnak a VPN-szolgáltatások és a titkosítási protokollok sebezhetőségeiről, amelyek segítségével titkosított adatokat lopnak és hozzáférnek. Azonban sokkal jobban védett a VPN-szolgáltatásokkal, mint azok nélkül.. A számítógépét feltörhetik, de ez nagyon drága és időigényes lesz.És igen, minél kevésbé vagy látható, annál jobban védett.

Ahogy Snowden kijelenti: „A titkosítás valóban segít. A megbízható és jól konfigurált adattitkosítási rendszerekben valóban megbízhat.” Ennek megfelelően kerülje azokat a VPN-szolgáltatásokat, amelyek elsősorban SHA-1 vagy MD5 kivonatolási algoritmusokat, valamint PPTP vagy L2TP/IPSec protokollokat használnak. Érdemes olyan VPN-szolgáltatást választani, amely az OpenVPN legújabb verzióját használja(kizárólag biztonságos opció) vagy SHA-2. Ha nem tudja biztosan meghatározni, hogy a szolgáltatás melyik titkosítási algoritmust használja, keresse meg ezt az információt a felhasználói kézikönyvben, vagy lépjen kapcsolatba a szolgáltatás ügyfélszolgálatával.

A VPN-szolgáltatások az Ön barátai. Bízzon a titkosításban, ne kételkedjen a matematikában. Használja a VPN-szolgáltatásokat a lehető leggyakrabban, és próbáljon meg meggyőződni arról, hogy a kilépési pontjai is biztonságosak. Így még akkor is biztonságban maradhat, ha titkosított alagútját feltörik.

Oszd meg és uralkodj: MS-CHAPv2 garantált feltörés

Alekszandr Antipov

A huszadik Defcon konferencián David Hultonnal előadást tartottunk az MS-CHAPv2 feltöréséről. Ez a bejegyzés hozzávetőleges áttekintést nyújt arról, hogy miről beszéltünk.

A huszadik Defcon konferencián mi David Hulton előadást tartott az MS-CHAPv2 feltöréséről. Ez a bejegyzés hozzávetőleges áttekintést nyújt arról, hogy miről beszéltünk.

Miért MS-CHAPv2?

Az első kézenfekvő kérdés az, hogy miért vágtunk bele az MS-CHAPv2-be, tekintettel arra a régóta fennálló érzésre, hogy az internetnek nem szabad erre a protokollra hagyatkoznia. Sajnos annak ellenére, hogy ez egy elavult protokoll és széles körű kritika célpontja, továbbra is mindenhol használják. A legfigyelemreméltóbb az MS-CHAPv2 használata a PPTP VPN-ben. A WPA2 Enterprise konfigurációkban is meglehetősen gyakran használják, különösen azokban, amelyek kölcsönös hitelesítési tulajdonságaira támaszkodnak. Előadásunkhoz összeállítottunk egy listát több száz VPN-szolgáltatóról, amelyek PPTP-től függenek. Olyan figyelemre méltó példákat tartalmaz, mint az iPredator, a The Pirate Bay VPN-szolgáltatása, amelyet állítólag arra terveztek, hogy megvédje az információcserét a kormányzati felügyelettől.

Úgy gondoljuk, hogy az MS-CHAPv2 továbbra is annyira elterjedt, mert a protokoll lehetséges gyengeségeit vizsgáló korábbi tanulmányok elsősorban a szótári támadásokra összpontosítottak. Ha ezt a korlátozott kutatást kombináljuk a protokollt és annak operációs rendszerrel való kompatibilitását támogató kliensek rendkívül széles számával, akkor világossá válik, hogy ez a legkevesebb felhasználói mozgást igénylő megoldás miért olyan csábító.

Most mi?

1) A PPTP VPN megoldások minden felhasználójának és szolgáltatójának azonnal el kell kezdenie az átállást egy másik VPN protokollra. A PPTP-forgalmat titkosítatlannak kell tekinteni.

2) Azoknak a vállalatoknak, amelyek az MS-CHAPv2 kölcsönös hitelesítési tulajdonságaitól függenek a WPA2 RADIUS szervereikhez való csatlakozáshoz, azonnal el kell kezdeniük az átállást egy alternatív megoldásra.

A nagyvállalatok sok esetben az IPSEC-PSK használatát választották a PPTP helyett. Míg a PPTP jelenleg nyilvánvalóan megszakadt, az IPSEC-PSK valószínűleg még sebezhetőbb a szótári támadásokkal szemben, mint a PPTP valaha volt. A PPTP legalább megköveteli, hogy a támadó elfogja az aktív hálózati forgalmat, hogy offline szótári támadást indítson, míg az IPSEC-PSK VPN agresszív módban lényegében kivonatokat ad ki minden támadónak, aki csatlakozik.

Tekintettel a ma elérhető megoldásokra, bárminek biztonságos telepítéséhez bizonyos fokú tanúsítványok ellenőrzésére van szükség. Ez az OpenVPN konfigurációra vagy az IPSEC tanúsítványmódban történő használatára vonatkozik a PSK helyett.

@SooLFaa:
Habozás nélkül úgy döntöttem, hogy szó szerint veszem az ajánlást.

A program bemutatása és elindítása.

A routerek elleni támadást nem a helyi gépemről hajtják végre, hanem egy speciálisan bérelt távoli VDS-ről Windows vezérlés. A bal egérgomb dupla kattintásával Hollandiába kerültem.

Ahogy a címben is szerepel, a támadóeszköz szerepét a RouterScan program látja el. A program letöltéséhez látogasson el az Antichat fórumra. A szerző szerint csak onnan kell letölteni a programot.

A program hordozható, telepítése a letöltött archívum meghatározott mappába való kicsomagolásából áll.

Alapértelmezés szerint a program a 80-as, 8080-as, 1080-as portokon támadja meg a routereket. Ezt a listát teljesen indokoltnak tartom, nem igényel kiegészítést, változtatást.
Ezenkívül a program további modulokat is csatlakoztathat

• Router Scan (fő)
• Proxy szerverek észlelése
• Használja a HNAP 1.0-t
• SQLite Manager RCE
• Hudson Java Servlet
• phpMyAdmin RCE

és a routerek elleni támadással együtt egy adott tartományban lévő összes IP-t „megvizsgálja”.
De egy ilyen elfoglalt program jelentősen lelassítja a működését, ezért ebben az ablakban nem érintünk semmit. elvégre a támadás célja egy véletlenszerű router WEB felületének elérése cikk írásához.

Nincs más hátra, mint a támadás IP-tartományának kiválasztása, és már futhat is a program.
Elmegyünk egy oldalra, amely országonként megadja az IP-tartományokat, és véletlenszerűen kiválasztjuk Lengyelországot áldozatként (az ország kiválasztása véletlenszerű).

Miután a kívánt tartományokat beszúrta a megfelelő programablakba, elindíthatja a programot.
Az útválasztók feltörésére fordított idő a kiválasztott tartományban lévő IP-k számától függ, és meglehetősen hosszú ideig tarthat.
De egy cikk megírásához nem kell más, mint egy feltört router, amelyen VPN szervert lehet beállítani. Ezek a modellek lehetnek ASUS routerek, Mikrotik vagy bármely más modell DD-WRT firmware-rel. Gyorsan áttekintve a „Jó eredmények” lapon megjelenő útválasztók listáját, nem nehéz megállapítani, hogy a megadott útválasztók modelljei szerepelnek a listában.

VPN szervert telepítünk az útválasztóra.

Ebben a cikkben az áldozat szerepére egy DD-WRT-t futtató útválasztót választottam.

Választásomat az magyarázza, hogy az említett firmware lehetővé teszi a router VPN-kiszolgálóként való használatát PPTP protokoll segítségével, és legutóbb ennek a protokollnak szenteltem magam.

Másolja a kívánt útválasztó URL-jét ide címsor böngésző és az oldal betöltése után annak WEB-es felületén találjuk magunkat adminisztrátori jogokkal.

Ahhoz, hogy az útválasztó VPN-kiszolgálóként működjön, lépjen a Szolgáltatások - PPTP fülre.

Tekintse át a cikket a modern magánalagutak használatáról egy népszerű lett márka útválasztóiban. Beszélni fogok arról, hogyan állíthatok be vpn-szervert a mikrotikban olyan technológiák alapján, mint az l2tp, ipsec, openvpn, pptp, gre és eoip. Útközben röviden beszélek arról, hogy mik ezek a technológiák, hogyan különböznek egymástól, és összehasonlítom a Mikrotik teljesítményét az összes megadott alagúttal.

Ez a cikk egyetlen cikksorozat része, amely erről szól.

Bevezetés

Azonnal szeretném felhívni a figyelmet arra, hogy ez a cikk inkább áttekintés lesz, nem pedig valós tapasztalat átadása, mivel én magam is leggyakrabban úgy használom. vpn szerverek. Ennek ellenére a VPN-sel is meg kellett küzdenem a Mikrotikban. Mind a pptp szervereket beállítottam a távoli kliensek csatlakoztatására, mind az l2tp-t két vagy több Mikrotik hálózat egy közös magánhálózatba való kombinálására. Főleg alapértelmezés szerint, anélkül, hogy belemerülnénk a beállítások bonyolultságába.

Azok számára, akik szeretnék jól átlátni a hálózatokat, de valamiért még nem tudják, hogyan kell ezt megtenni, azoknak ajánlom ezt a cikksorozatot - hálózatok a kicsiknek.

VPN szerver opciók a Mikrotikban

A Mikrotikban minden bonyolult a vpn szerver opciókkal :) Abban az értelemben, hogy sok vpn implementáció létezik, amit nem olyan könnyű kiválasztani, ha nem érted részletesen hálózati technológiák. Nem nagyon értem őket, de úgy tűnik, egy kicsit értem a lényeget. Megpróbálom a saját szavaimmal elmagyarázni, hogy mik a különbségek.

Két alapvetően eltérő megoldás létezik két Mikrotik és külső előfizető közötti kapcsolatok megszervezésére:

1. L2 helyek közötti alagút létrehozása a használatával EOIP alagút. A legegyszerűbb és gyors út kombinálni két Mikrotik. Ha nem használ titkosítást, akkor a leggyorsabb VPN-kapcsolatot kapja. Dedikált fehér IP-cím szükséges mindkét eszközön. Az ilyen kapcsolatokat az irodák vagy fióktelepek VPN-en keresztüli egyesítésére használják. Általában NAT-on keresztül nem működik. Ide is hozzáteszem GRE alagút, bár működik l3-ban, és útválasztást használ, ugyanúgy működik a helyek között.
2. VPN kapcsolati szint l3 a kliens-szerver technológián, mint pl PPTP, L2TP, SSTP, OpenVPN. Az ilyen kapcsolatokat az irodák egyesítésére és a távoli alkalmazottak összekapcsolására is használják. Csak egy fehér IP-cím elég a szerver oldalon vpn létrehozása kapcsolatokat. NAT-on keresztül működik.

A VPN-kapcsolatok mindegyik típusáról külön mesélek egy kicsit.

• GRE Tunnel – az egyszerű gre protokollt használja egy alapvető, nem biztonságos helyek közötti VPN felépítéséhez. A CISCO fejlesztette. Lehetővé teszi a csomagok kapszulázását különféle típusok IP alagutak belsejében. Egyszerű szavakkal ezt csinálja. Elveszi az adataidat az összes fejléccel együtt, csomagba csomagolja, interneten keresztül továbbítja a másik végére, ahol ezt a csomagot visszaelemzi az eredeti adatokká. A hálózat végfelhasználói számára mindez úgy néz ki, mintha helyi hálózaton keresztül kommunikálnának.
• EOIP alagút - Ethernet át Az IP egy szabadalmaztatott MikroTik RouterOS protokoll, amely Ethernet alagutat hoz létre két router között IP-kapcsolaton keresztül. Az adatátvitelhez a GRE protokollt használja. Alapvető különbség Az eoip tunnel az l2-ben működik és közvetlenül továbbítja a kereteket, míg a gre tunnel csomagokon működik és útválasztást használ. Remélem jól magyaráztam és nem hazudtam. Nem tudom, miért döntött úgy a mikrotik, hogy létrehozza a saját alagút megvalósítását a gre protokollon keresztül. Talán egyszerűen nincsenek hasonló megoldások, ezért kitalálták a saját megvalósításukat.
• A PPTP egy pont-pont alagútkezelési protokoll. Működéséhez a GRE protokollt használja, és támogatja a titkosítást. A pptp valamikor nagy népszerűségre tett szert, mivel a 95-ös verziótól kezdve a Windows már eleve támogatta. Ma már nem ajánlott a pptp használata, mivel nagyon könnyen feltörhető. A titkosítási kulcsot rövid időn belül (több óra) lekérjük a forgalmi dump-ból, és az összes forgalmat visszafejtjük. Talán ez ellen valahogy fel lehet küzdeni különböző titkosítási protokollok használatával, de ezt a témát nem vizsgáltam részletesen. Úgy döntöttem, hogy a pptp a legegyszerűbb megoldás, ahol nincsenek fokozott biztonsági követelmények, és a forgalom visszafejtése, ha megtörténik, nem okoz gondot. A PPTP nem csak a Windows-t támogatja, hanem az Androidot is, ami nagyon kényelmes. Nagyon könnyű beállítani.
• L2TP – Layer 2 Tunneling Protocol. Annak ellenére, hogy a név azt mondja, hogy l2, a valóságban egy IP hálózatban munkamenet szinten működik, azaz l3. 1701-es UDP-portot használ. Nem csak IP-hálózatokban működik. A pptp-hez hasonlóan már készen is támogatja a felhasználói hitelesítést. Önmagában nem biztosít titkosítást. Az ipsec segítségével titkosítja a forgalmat, ami nagyon biztonságosnak számít, és nincs benne komoly sebezhetőség. Jelenleg szinte minden eszköz és rendszer támogatja, akárcsak a pptp. Nem sokkal nehezebb beállítani. Általában ezt a típusú titkosított alagutat javaslom a VPN szervezéséhez.
• Az OpenVPN a titkosított kapcsolatok nagyon népszerű megvalósítása. A fő előny a beállítások rugalmassága. Például az openvnp egyik nagyon klassz funkciója, hogy csatlakozáskor az útvonalakat közvetlenül a klienshez küldi. én hosszú ideje Openvpn szervereket használtam. Amikor először kellett pptp útvonalat átadnom egy kliensnek, nem tudtam rájönni, hogyan állítsam be. Kiderült, hogy nincs rá mód, egyszerűen nem tudta megtenni. Harmadik féltől származó eszközöket kellett használnom. Sajnos a mikrotik openvpn ismeretlen okokból nem támogatja az udp protokollt, ami nagymértékben korlátozza a vpn szerver használatának lehetőségeit. Tcp-n sokkal lassabban működik, mint udp-n. A csomagfejléc-tömörítés sem működik. Tehát általában nincs értelme openvpn szervert használni a Mikrotikban, hacsak nincs rá valami konkrét ok.
• Az SSTP - Secure Socket Tunneling Protocol - protokollt a Microsoft vezette be ben Windows Vista SP1. A fő előnye, hogy integrálva van a Windowsba, és a 443-as portot tudja használni, ami néha segít a tűzfalak megkerülésében. Nagyon biztonságosnak tekinthető, SSL 3.0-t használ. A hátránya tudtommal az, hogy a Mikrotik nagyon igényes a processzor erőforrásokra. Gyenge hardveren ez biztosítja a legalacsonyabb sebességet az összes többi VPN-kapcsolathoz képest. Emiatt a felülvizsgálatomban egyáltalán nem veszem figyelembe.

A leírtakból a következő következtetést vonhatjuk le. Általában a legjobb az l2tp + ipsec alapú VPN használata a Mikrotikban. Fő ok:

1. Egyszerűség és könnyű beállítás.
2. Erős titkosítás.
3. Szinte minden modern eszköz és rendszer támogatja az l2tp kapcsolatokat. Nincs szükség további szoftver telepítésére.
4. Alkalmas az irodák és a távoli dolgozók egyesítésére is – telephely-telephely és ügyfél-telephely kapcsolat.

Ha szükséged van maximális teljesítmény titkosítás nélkül, majd kapcsolatokat építhet ki hálózatok vagy irodák között az EOIP Tunnel segítségével – a Mikrotik szabadalmaztatott fejlesztésével.

Kezdjük a VPN-kapcsolatok beállításával és tesztelésével a mikrotikban.

L2tp alagút felállítása mikrotikban

Először is állítsunk fel egy egyszerű l2tp alagutat titkosítás nélkül, és mérjük meg a sebességet. Az l2tp vpn konfigurálásához a mikrotikban kövesse az alábbi lépések sorozatát.

Menjünk a szakaszra IP -> Poolés adjon hozzá egy IP-címkészletet a VPN-alagúthoz.

Hozzon létre egy profilt az alagúthoz PPP -> Profilok.

A többi lapon a beállítások az alapértelmezettek. Ezután hozzon létre egy felhasználót PPP -> Titkok.

Most indítsuk el az l2tp szervert. Menjünk-hoz PPPés nyomja meg a gombot L2TP szerver.

Beállítjuk az l2tp szerver beállításait. Még nem engedélyeztük az ipsec-et.

A VPN-kiszolgáló konfigurálva van. Most készítsünk neki egy állandó felületet, hogy ez alapján statikus útvonalakat készíthessünk. Menjünk-hoz Interfészekés létrehozni.

Befejező simítás. Statikus útvonalat hozunk létre, amelyen keresztül az előfizetők helyi hálózat A szerverek VPN-en keresztül képesek lesznek csatlakozni egy távoli útválasztó mögött lévő helyi hálózati előfizetőhöz. Menjünk-hoz IP -> Útvonalakés adjunk hozzá egy útvonalat.

Statikus útvonalat adunk hozzá, hogy az útválasztó ügyfelei tudják, hol léphetnek kapcsolatba a távoli helyi hálózat VPN-előfizetőivel.

Ez minden. Az l2tp-t egy távoli Mikrotik-on konfiguráltuk, és így kombináltunk 2 helyi hálózatot VPN használatával. Az IP-címek listájában aktív l2tp kapcsolat esetén a szerveren és a kliensen a kiszolgálón a VPN-hálózathoz megadott tartományba tartozó IP-címeket kell látnia - 10.10.5.1-10.10.5.100. Mostantól mindkét hálózatról pingelhet ellentétes hálózatokat.

Mindkét Mikrotikhoz csatlakoztatott laptopom van tesztelésre. Most megmérem a kapcsolat sebességét az iperf3 segítségével. A router mögött m-távirányító A kiszolgálót a 10.30.1.254-es laptopon futtatom, az ügynököt pedig a 10.20.1.3-on. Sebességteszt futtatása vpn kapcsolatok:

átlagsebesség 194 Mbit/sec. Őszintén szólva nem értettem, miért olyan alacsony a sebesség. Az én próbapad két Mikrotik routeren és egy gigabites Mikrotik switchen van összeszerelve. Valami 500 Mbit/sec körüli sebességre számítottam. Hadd emlékeztesselek arra, hogy az alagút még nincs titkosítva. A routerek processzorterhelése ugyanakkor 90-95% körül alakult. Ez tulajdonképpen ezeknek a vasdaraboknak a mennyezete.

Most próbáljuk meg engedélyezni az ipsec titkosítást és mérjük vele a sebességet.

Az ipsec beállítása

Egy ideig elakadtam az ipsec beállításánál l2tp-hez. Az interneten sok utasítás található, de mindegyik elavult. Mint kiderült, be legújabb verziói firmware, az ipsec futtatása alapértelmezett beállításokban nem egyszerű, de nagyon egyszerű. Ehhez csak meg kell adnia az l2tp szerver tulajdonságait Használja az IPsec-et– igen, és állítson be egy jelszót.

Minden szükséges beállításokat Az ipsec automatikusan létrejön. Az ügynökön tegye ugyanezt - engedélyezze az ipsec titkosítást, és adjon meg egy jelszót.

Az l2tp kliens csatlakoztatása után hasonló sorokat fog látni a naplóban:

19:17:00 l2tp,ppp,info l2tp-out1: inicializálás... 19:17:00 l2tp,ppp,info l2tp-out1: csatlakozás... 19:17:03 ipsec,info új 1. fázis kezdeményezése (Identity Védettség): 192.168.13.197<=>192.168.13.1 19:17:04 ipsec,info Az ISAKMP-SA létrehozva: 192.168.13.197-192.168.13.1 spi:407844c0ceb5d2ab:46ce7ffb25495efd:46ce7ffb25495efd:17ppp,25495infot7ppp19:19 hitelesített 19:17:07 l2tp, ppp ,info l2tp-out1: csatlakoztatva

Ha meg szeretné győződni arról, hogy az ipsec titkosítás működik, lépjen a szakaszra IP -> Ipsec -> Telepített SA-kés nézd meg a titkosított csomagszámlálót. Ha nő, akkor minden rendben van, a forgalom titkosított.

Ott a szekcióban Távoli Peers Megtekintheti azon távoli ügyfelek listáját, amelyeknél működik az ipsec titkosítás, és megtekintheti a használt algoritmusokat. Az összes alapértelmezett ipsec-beállítás megtalálható ebben a részben. Megtekintheti őket, módosíthatja vagy új profilokat adhat hozzá. Alapértelmezés szerint az sha1 engedélyezési algoritmus és az AES titkosítás használatos. Ezeket a paramétereket módosíthatja, ha érti a témát. Nem leszek okos, nem mélyedtem el a titkosítás témájában. Nem tudom, melyik algoritmus a leggyorsabb és legbiztonságosabb.

Teszteljük egy vpn kapcsolat sebességét l2tp + ipsec.

én így kaptam... 26 Mbit/secátlagos. Ugyanakkor a processzor terhelése 100%. Nem sok. Ezek a hardverelemek nagyon rosszul alkalmasak titkosított csatornákhoz. Ezekben a tesztekben magán a teszten kívül semmi mást nem töltenek be. Valós körülmények között a sebesség még alacsonyabb lesz.

VAL VEL VPN beállítások l2tp + ipsec alapján kész. Folytassuk a fennmaradó VPN-alagutak beállítását, és hasonlítsuk össze a sebességüket.

Ppptp szerver beállítása a mikrotikban

A pptp szerver beállítása alapvetően nem különbözik az l2tp-től. A műveletek logikája és sorrendje megegyezik. Először létrehozunk egy címkészletet IP -> Pool vpn hálózathoz. Ugyanazt a medencét fogom használni, amelyet korábban létrehoztunk.

Ez a profil tartalmazza az alapértelmezett titkosítási beállításokat, amelyekben le van tiltva. Először nézzük meg a VPN-csatorna sebességét nélkülük. Hozzon létre egy új felhasználót egy távoli pptp kapcsolathoz.

A PPP részben engedélyezzük a pptp szervert.

Most hozzuk létre az Interfész listában PPTP szerver kötés hasonló az előző részhez.

És végül adjon hozzá egy statikus útvonalat a távoli hálózathoz pptp kapcsolaton keresztül.

A pptp szerver beállítása kész. A tűzfalon a következő dolgokat kell megnyitnia a külső interfészről érkező kapcsolatokhoz:

• TCP 1723-as port
• GRE protokoll

Állítsuk be a pptp klienst.

pptp kliens

Megyünk a távoli útválasztóhoz, és konfiguráljuk a kapcsolatot a pptp kliensen keresztül. Menjünk, mint általában, a szakaszra PPPés add hozzá PPTP kliens. Az Általános fülön nem érintünk semmit, a Dial Out-on viszont feltüntetjük a pptp szerver címét és a csatlakozáshoz szükséges felhasználónevet.

Statikus útvonal hozzáadása egy távoli irodához VPN-alagúton keresztül.

Minden készen áll. Aktiváljuk a pptp kapcsolatot, és megpróbáljuk pingelni a helyi hálózat címeit. Győződjön meg arról, hogy a titkosítás le van tiltva a kliens pptp kapcsolati állapotában.

Most nézzük meg a VPN-kapcsolat sebességét pptp-n keresztül.

Azonos 194 Mbit/sec, amely titkosítatlan l2tp-n van, 100%-os processzorterhelés mellett. Általában egy kicsit furcsa volt pontosan ugyanazokat a számokat látni. Többször lefuttattam a tesztet, de mindig ugyanaz az eredmény. Titkosítás nélkül nincs különbség az l2tp és a pptp kapcsolatok sebességében.

Most engedélyezzük a titkosítást a pptp-ben a szerveren, és nézzük meg a sebességet. Ehhez a pptp profilban kifejezetten jelezzük, hogy titkosítást használunk. Menjünk-hoz PPP -> Profilokés szerkessze a profilunkat.

Győződjön meg arról, hogy az ügyfél állapota működik.

A VPN-kapcsolat sebességét tesztelem pptp-n keresztül, és a titkosítás engedélyezve van.

Átlagosan kiderült 71 Mbit/sec. Nem rossz eredmény az ipsec titkosításhoz képest l2tp-ben. Ahogy korábban mondtam, a pptp szerverek jól használhatók ott, ahol vagy egyáltalán nincs szükség titkosításra, vagy megengedett a titkosított forgalom visszafejtése. De ugyanakkor továbbra is titkosítással zárva van, és mindenki, aki arra jár, nem fog látni semmit. Legalább a forgalmat ki kell üríteni, és valahogyan ki kell választania egy kulcsot szótár vagy nyers erő segítségével. Nem tudom pontosan, hogy ez a gyakorlatban hogyan valósul meg. Nem tanulmányozta a kérdést.

Most térjünk át a Mikrotik openvpn szerverére. Nagyon érdekes megnézni az ilyen típusú VPN-kapcsolatok sebességtesztjeit.

Openvpn szerver beállítása Mikrotikban

Nincs semmi bonyolult az openvpn szerver beállításában a mikrotikon, kivéve a tanúsítványokkal kapcsolatos árnyalatokat. Aki még soha nem dolgozott velük, minden túl bonyolultnak tűnhet. Ezenkívül magának a Mikrotiknak nincs semmilyen eszköze szerver- és ügyféltanúsítványok létrehozására. Használata szükséges harmadik féltől származó segédprogramok. Ha Linuxos gépe van, használhatja az utasításaimat.

Ha nincs Linuxos gépe, de továbbra is eltökélt szándéka, hogy a Mikrotik openvpn használatával VPN-alagutat hozzon létre, akkor nézzük tovább a beállítást. Először is szükségünk van egy openvpn disztribúcióra a Windows számára. Letöltheti a linkről - https://openvpn.net/community-downloads/. Érdeklődni fogunk a Windows Installer iránt.

A telepítést rendszergazdaként végezzük, és a folyamatban megadunk egy komponenst, az úgynevezett EasyRSA 2 tanúsítványkezelő szkriptek.

Menjünk a könyvtárba C:\Program Files\OpenVPN. Helyezze át a mappát onnan könnyű-rsa valahol máshol, hogy ne kelljen állandóan az UAC-ban botorkálni, ami nem teszi lehetővé, hogy nyugodtan dolgozzon a Program fájlokban. oda költöztem D:\tmp\easy-rsa. Nevezze át a fájlt vars.bat.sample V vars.bat. Megnyitjuk szerkesztésre, és hozzávetőlegesen a következő formába hozzuk.

Azok számára, akik nem értik, ezek csak változók, amelyeket az igényeim szerint határoztam meg. Azt írhatsz oda, amit akarsz, ez a mi feladatunk szempontjából nem fontos. Semmin nem változtathatsz, hanem hagyd úgy, ahogy van. Hozzon létre egy mappát a könyvtárban kulcsok. Következő elindítjuk parancs sor a rendszergazdától, és lépjen a megadott könyvtárba D:\tmp\easy-rsa.

Megválaszoljuk a feltett kérdéseket és befejezzük az alkotást. gyökértanúsítvány. Megjelenik a mappában D:\tmp\easy-rsa\keys. Ezután létrehozunk egy openvpn szerver tanúsítványt a paranccsal - build-key-server szerver_neve.

Most generáljunk egy tanúsítványt az ügyfél számára. Csak egy kliensem van távoli Mikrotik formájában. Pontosan annyit alkotsz, amennyire szükséged van. A parancsot használjuk build-key tanúsítvány_neve.

Elkészültünk a tanúsítványok létrehozásával. Mindegyik megtalálható a kulcsok könyvtárában. A következő fájlokat kell átvinnie a Mikrotikba, amely openvpn szerverként fog működni:

• kb.crt
• ovpnserver.crt
• ovpnserver.key

Tanúsítványok importálása a hozzáadott fájlokból. Menjünk-hoz Rendszer -> Tanúsítványokés először importálni kb.crt, Akkor ovpnserver.crtÉs ovpnserver.key.

Valahogy így kell kinéznie. Most kezdjük el az openvpn szerver beállítását a mikrotikban. Készítsünk hozzá külön profilt PPP -> Profilok.

Minden beállítás alapértelmezett. Helyi és távoli címként az Ip Pool-ot használom, amelyet az l2tp beállításának legelején hoztam létre. Adjunk hozzá egy távoli felhasználót az openvpn számára PPP ->Titkok.

Menjünk a szakaszra PPPés kattintson OVPN szerver. Adja meg a beállításokat és a letöltött CA-tanúsítványt.

Ezzel befejeződik az openvpn szerver beállítása a Mikrotikban. Alapértelmezés szerint a rendszer a titkosítási protokollt használja BF-128-CBC. Módosítható az ügyfél tulajdonságaiban, és az összes támogatott titkosítás listája a VPN-kiszolgáló tulajdonságaiban.

Munkához meghatározott beállítás Az openvpn szervernek meg kell nyitnia a bejövő tcp 1194-es portját a tűzfalon. Most állítsuk be az openvpn klienst, és teszteljük a kapcsolat sebességét a vpn-n keresztül az openvpn alapján.

openvpn kliens

Az openvpn kliens mikrotikon konfigurálásához át kell vinni az előző lépésben generált tanúsítványokat oda. Pontosabban ezek a fájlok:

• m-remote.crt
• m-távirányító.kulcs

Ezekből a fájlokból importáljuk a tanúsítványt, akárcsak a szerveren. Kérjük, vegye figyelembe, hogy a tanúsítvány neve mellett szerepelnie kell a KT karaktereknek.

Most konfigurálja az openvpn klienst. Menjünk-hoz PPPés add hozzá OVPN kliens.

Adjon hozzá egy statikus útvonalat az openvpn szerver mögötti távoli hálózati erőforrások eléréséhez.

Minden készen áll. Csatlakozhat és tesztelheti a VPN-kapcsolat sebességét az openvpn-n keresztül.

Átlagosan kiderült 24 Mbit/sec 100%-os processzorterhelés mellett. Az eredmény az l2tp + ipsec-hez hasonlítható. Az eredmény kissé meglepő volt. Azt hittem, hogy rosszabb lesz, mint az l2tp, de a valóságban ugyanaz. Én személy szerint általában jobban szeretem az openvpn opciót, bár a Mikrotik korlátozott openvpn beállításai miatt az openvpn előnyei nehezen realizálhatók. Hadd emlékeztesselek, hogy BF-128-CBC titkosítással, azaz blowfish-sel teszteltem.

Íme az eredmény az AES-128-CBC-vel - 23 Mbit/sec, kb.

A Mikrotik rendezte a VPN szerver kliens-szerver implementációit. Most nézzük meg az l2-vpn sebességét eoip alagút formájában.

Az EOIP Tunnel + Ipsec beállítása

Állítsuk be vpn hálózat EOIP alapján a Mikrotikban. Itt meg kell értenie egy fontos különbséget a korábban elvégzett összes korábbi beállításhoz képest. Az EOIP alagút l2 szinten működik, vagyis mindkét hálózati szegmens ugyanazon a fizikai hálózaton lévőnek tekinti magát. Mindkettő címtere azonos lesz. Az én példámban ez 10.20.1.0/24. Mindkét hálózathoz csak egy DHCP-szerver legyen. Az én esetemben megmarad m-szerver.

Hozzon létre egy EOIP alagutat az m-szerveren. Menjünk-hoz Interfész lista -> EoIP Tunnelés adjunk hozzá egy újat.

A beállításokból elég csak a második Mikrotik távoli címét megadni. Az új EoIP interfészt hozzá kell adni a helyi hídhoz a fizikai interfészekkel együtt.

A távoli Mikrotikhoz megyünk, és ott is ugyanezt csináljuk, csak más távoli címet adunk meg.

Ez elég ahhoz, hogy az EoIP alagút azonnal működjön. Állapota RS lesz.

A második Mikrotiknál ​​az EoIP interfészt is hozzá kell adni a helyi hídhoz más interfészekkel.

A legegyszerűbb módja annak, hogy ellenőrizzük, hogy minden rendben van-e, ha lekérjük a híd interfész m-slave IP-címét dhcp-n keresztül. IP címet kell kapnia tőle dhcp szerver m-szerveren, feltéve, hogy nincs más dhcp szerver a hálózaton. Ugyanez történik az m-slave mögötti hálózat helyi gépeivel. IP-címeket kapnak az m-szerveren lévő dhcp szervertől.

Most nézzük meg egy ilyen EoIP-alapú VPN-alagút teljesítményét.

Megmutatom a maximális eredményt, amit kaptam - 836 Mbit/sec. Valamiért a különböző tesztekben a sebesség 600-850 Mbit/sec tartományban ingadozott. A sebesség változásához szükséges volt az EoIP interfész letiltása és újraengedélyezése. A sebesség lenyűgöző. Ugyanakkor a processzor nincs 100%-ban betöltve. Vagyis nem ő a szűk keresztmetszet. Úgy tűnik, elakadtam a hálózati teljesítményben. Hadd emlékeztesselek arra, hogy itt nincs titkosítás vagy forgalomirányítás. Közvetlen l2 csatorna két Mikrotik között EoIP vpn-n keresztül.

Adjuk hozzá az Ipsec titkosítást az EoIP alagúthoz, és nézzük meg a sebességet. Ehhez módosítsa a csatornabeállításokat mindkét Mikrotikon. Adja hozzá az Ipsec-jelszót és a helyi címeket, tiltsa le a Fast Path-t.

Online tanfolyam "Hálózatmérnök"

Ha szeretné megtanulni, hogyan kell magasan elérhető és megbízható hálózatokat felépíteni és karbantartani, javasoljuk, hogy vegyen részt az OTUS Network Engineer online tanfolyamán. Ez egy eredeti program valódi berendezéseken való távgyakorlással és Cisco akadémiai bizonyítvánnyal kombinálva! A hallgatók gyakorlati készségeket szereznek a berendezések üzemeltetésében egy távoli online laboratórium segítségével, amely egy képzési partnerre épül - RTU MIREA: Cisco 1921, Cisco 2801, Cisco 2811 routerek; Cisco 2950, ​​​​Cisco 2960 kapcsolók. A tanfolyam jellemzői:

• A kurzus két projektmunkát tartalmaz.;
• A hallgatók beiratkoztak a hivatalos Cisco Akadémiára (OTUS, Cisco Academy, ID 400051208), és hozzáférést kapnak a CCNA Routing and Switching tanfolyam minden részéhez;
• A hallgatók vizsgát tehetnek, és az OTUS tanúsítvánnyal együtt bizonyítványt kaphatnak a „CCNA Routing and Switching: Scaling Networks” kurzusról;

Tesztelje magát a felvételi vizsgán, és további részletekért tekintse meg a programot.