IPSEC/IKE2 VPN, MikroTik RouterOS alapokon

Figyelem! Ez egyelőre csak egy vázlat! Még számos korrekcióra szorul.

• Bevezetés
• VPN típus és hardver kiválasztása
• IPSEC/IKE2 VPN elmélet
• Alapfogalmak
• IKE - a kulcs csere alapjai
• MTU és fragmentáció
• Site-to-site VPN
• A feladat
• Meglevő hálózat ellenőrzése
• Site-to-site VPN beállítása (gyakorlat)
• Tűzfal beállítások
• Összefoglaló
• További site-ok hozzáadása
• Összes forgalom átirányítása
• Road Warrior VPN
• Bevezetés
• Beállítás (gyakorlat)
• Kapcsolódás Windows 10-ből
• Server-To-Site VPN (menedzselt szerver)

Bevezetés

Ez a könyv eredetileg úgy indult, hogy szükségem volt két vállalati telephely biztonságos összeköttetésére. Az interneten sok helyen próbáltam megkeresni a megfelelő megoldást. A föllelhető információkból sok helytelennek/tévesnek bizonyult. Egy részük számomra első olvasásra érthetetlen volt. Egy idő után a sok összegyűjtött információból kezdett körvonalazódni az optimális megoldás. Mivel ez a munka sokáig tartott, ezért hatékonyság növelés céljából elkezdtem magamnak jegyzeteket írni. Vettem néhány router-t, pusztán tesztelési célból. Különféle konfigurációban összekötöttem őket. Ahogy telt az idő, egyre nehézkesebbé vált a tesztelés fizikai eszközökkel. Ekkor kezdtem el használni a GNS3 nevű hálózat szimulációs szoftvert. Ezzel virtuális hálózatokat lehet felépíteni, és ebben virtuális router-eket és számítógépeket elindítani. Ez nagyon felgyorsította a tesztelést és a saját kérdéseim megválaszolását. Munkám során sok esetben hiányos volt a tudásom, amit pótolnom kellett. Most sem gondolom azt, hogy mindent tudok a témában. Ugyanakkor úgy láttam, hogy ebben a témában még nem született olyan magyar nyelvű leírás, ami MikroTik/RouterOS eszközökre specializáltan, lépésről lépésre magyarázza el a lehetséges megoldásokat, valamit ismerteti a buktatókat. Ezért úgy döntöttem, hogy ebből egy cikket készítek. Egy olyan leírást akartam készíteni, ami tartalmaz némi elméletet. Így azok számára is érthető, akik valamennyire értenek a hálózatokhoz, de kezdők az IPSEC/ VPN témában. Egy példán keresztül a gyakorlatban is használható tudást akartam átadni. Csak remélem, hogy az ebbe fektetett munka nem vész kárba, és mások számára is hasznosak lesznek az alább leírtak.

A könyvben a következő feladatokra keresünk megoldást:

Telephelyek összekötése VPN alagúton

Egy képzeletbeli vállalat két telephelyén külön alhálózatokon vannak számítógépek és más eszközök. Azt szeretnénk elérni, hogy a két telephelyen levő eszközök korlátozás nélkül tudjanak egymással kommunikálni úgy, hogy az interneten titkosított, biztonságos csatornán közlekedjenek az adatok.

Ezt később kiterjesztjük három- és még több telephely összekötésére.

Road warrior kliensek

A képzeletbeli vállalatunk utazó ügynökei egy szál laptoppal járják az utakat, látogatják az ügyfeleket stb. Számukra olyan hozzáférést szeretnénk biztosítani, ahol pusztán a laptop segítségével el tudják érni a vállalat összes telephelyét. A laptopot különféle (nem biztonságos) környezetben használják. Sok esetben más vállalatok tűzfalai mögül kell csatlakozniuk.

 

VPN típus és hardver kiválasztása

VPN típusok összehasonlítása

Fölmerülhet benned a kérdés, hogy miért pont IPSEC/IKEv2 protokollt kellene használnod? Sokféle VPN megoldás létezik. Ennek a leírásnak az elkészítésében sokat segített Nikita Tarikin előadásának megtekintése. Az általa előkészített ábrák nagyon kifejezőek. Az egyik ilyen ábra ami azt mutatja, hogy melyik VPN protokol milyen előnyökkel és hátrányokkal rendelkezik.

Az látható, hogy a "biztonságos" és az "alacsony CPU igény" egymást kizáró dolgok. Ami biztonságos ahhoz erős CPU kell. Amihez nem kell erős CPU, az nem biztonságos. Ebből a dilemmából a kiutat az jelenti, hogy bizonyos eszközökben külön hardver van a titkosításra. Cél hardver alkalmazásával viszonylag alacsony költségen nagy teljesítményt lehet elérni. Erről alább még írok.

A táblázatot áttekintve elég egyértelműen látszódik, hogy ha az erős titkosítás és a megbízhatóság a célunk, és mindezt viszonylag nagy sebességgel szeretnénk elérni, akkor az IPSEC + IKEv2 a legjobb megoldás. Manapság nagyon elterjedt és favorizált az OpenVPN. A fenti táblázatban ez azért van lassúnak jelölve, mert a MikroTik/RouterOS OpenVPN megoldása nem mondható optimálisnak. Más rendszereken az OpenVPN egész gyors tud lenni, legalábbis ami az adatforgalmat illeti. (A csatlakozás sebessége ott is elég lassú.) Mivel mi itt MikroTik/RouterOS eszközökkel szeretnénk megoldani a kapcsolatot, ezért az OpenVPN-t nem tudjuk használni. Plusz az OpenVPN-ről tudni kell, hogy alapból layer 3 protokoll fölött, layer 4-ben van implementálva. Az IPSEC-hez képest egyel magasabb szinten van, és ebből fakad néhány hátránya.

Néhány további dolog ami a táblázatból nem látszódik:

• A régi számítógépek és operációs rendszerek nem, vagy nem teljesen jól támogatják az IPSEC/IKEv2 VPN-t.
• Az IPSEC/IKEv2 beállítása általában nagyobb szakértelmet igényel, mint mondjuk egy L2TP szerver beállítása. Ez a cikk azért íródott, hogy átsegítsen a beállítás nehézségein. Ezért remélhetőleg ez sem okoz majd problémát.

Hardver kiválasztása

Ahogy föntebb említettem, nem mindegy hogy milyen eszközt használunk. Ilyen célra kizárólag olyan típust érdemes használni, amibe bele van építve a titkosítási algoritmusok hardveres támogatása. A specifikációk áttanulmányozása után bárki ki tudja választani a neki megfelelőt.

A MikroTik router-ek esetében erről van egy nagy táblázat itt: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Hardware_acceleration

Íme néhány általam favorizált típus.

HAP AC2

Az általam javasolt legkisebb/legolcsóbb MikroTik router a HAP AC2 típus. Ajánlott fogyasztói ára e cikk írásakor 69 USD. Ez nagyon alacsony ár a tudásához képest.

RB750Gr3

Ha nincsen szükség WiFi-re, vagy ha a Wifi-t külön eszközökkel szeretnéd megoldani, akkor esetleg szóba jöhet az RB750Gr3 is. CPU teljesítményben ez egy kicsit alulmarad a HAP AC2-höz képest, és várhatóan a HAP AC2 által alkalmazott arm architektúra a jövőben nagyobb támogatásra számíthat. (A memóriája több, de IPSEC site-to-site alagutazásnál ez nem igazán számít.) Minimálisan olcsóbb (59 USD). Én személy szerint akkor is inkább a HAP AC2-őt venném, ha a wifi részére nincsen szükségem.

HAP AC3

A HAP AC3 típus pontosan ugyan azt az IPQ-4019 processzort használja mint a HAP AC2. Bár a memóriája több, de VPN kapcsolat kiépítéshez erre nincs szükség. Ha csak a VPN alagút kiépítését nézzük, akkor nem jobb mint a HAP AC2, viszont drágább (99 USD). A Wifi képességei sokkal jobbak 5Ghz-en a specifikáció szerint, de erről én inkább itt nem mondanék véleményt mivel sosem próbáltam.

A fenti eszközök megfelelő beállítás esetén akár 300-400Mbps sebességel képesek IPSEC titkosításra. (Az IPSEC teljesítményt a hivatalos honlapon a "test results" fülön lehet megtalálni.) Kis céges és otthoni felhasználásra azért érdemes MikroTik-et használni, mert ezt a teljesítményt ilyen konfigurálhatóság és felügyelet mellett más cég termékeivel nem nagyon lehet elérni. (Hasonló tudású Cisco termékek többszörösébe kerülnek. Bár az igaz hogy ott a támogatás is jobb.)

RB4011

Ha ennél is nagyobb teljesítményre van szükség, akkor a RB4011 lehet jó megoldás. Ez nagyobb csomagméretnél 2Gbps IPSEC átvitelre képes, de még 512byte csomagméret esetén is kb. 800Mbps-t tud. Ennek van egy Wifi-vel ellátott változata is.

x86

Ha még ennél is nagyobb teljesítményre van szükséged, akkor sem kell lemondani a RouterOS-ről. A RouterOS elérhető x86 platformon. Egy gyors géppel és QSFP kártyákkal jóval nagyobb teljesítmény is elérhető. Bár az az igazság, hogy ha 1Gbp fölötti IPSEC teljesítményre van szükséged, akkor nem biztos, hogy ebből a cikkből kellene tájékozódnod, és akkor egyáltalán nem biztos, hogy a MikroTik lesz a megfelelő megoldás. :-)

 

IPSEC/IKE2 VPN elmélet

Alapfogalmak

Most egy kis elméleti rész következik. Ahol lehet, ott be fogom írni hogy RouterOs-ben az adott rész beállításai melyik menüpont alatt érhetők el. Ezen felül gyakorlati, konkrét javaslatokat teszek az egyes beállításokra a mi konkrét példáinkra (két telephely folyamatos összeköttetése VPN alagúton, illetve road warrior setup).

Ez a protokoll több fő részre bontható:

• Az IKE felelős azért, hogy a kommunikációs csatorna két oldalán levő felek közösen és biztonságosan megegyezzenek olyan kriptografikus kulcsokban, amiket később a kommunikáció során föl lehet használni az adatforgalom titkosítására. Az IKE az Internet Key Exchange rövidítése. Két fő verziója van. Az egyes verziót már nem nagyon használjuk. A kettes verziót úgy alakították ki, hogy kiküszöbölje az első verzió használata közben tapasztalt hibákat és hiányosságokat. Az IKEv2 normál UDP csomagokat és alapértelmezésben az 500-as portot használja.
• A titkosított adatforgalom úgy zajlik, hogy a tunnel két végén levő eszközök az egymás irányába küldött csomagokat a küldés előtt enkapszulálják (azaz beágyazzák) IPSEC csomagok belsejébe, a beérkező csomagokat pedig dekapszulálják (kicsomagolják).
• Az enkapszulációra kétféle szabvány terjedt el: az Authentication Header (AH) és az Encapsulating Security Payload (ESP). Az AH arra alkalmas, hogy garantálja a csomagok eredetét. (Harmadik fél nem képes meghamisítani őket.) Az ESP ezen felül titkosítást is végez - harmadik fél nem képes hozzájutni az eredeti csomagok adattartalmához akkor sem, ha a két fél közötti csatorna összes IPSEC csomagját el tudja olvasni.

Bár erről később még részletesen írok, de elöljáróban megemlítek két fogalmat. Ezek szükségesek ahhoz, hogy elkerüljük az előre hivatkozásokat, és úgy előre-hátra ugrálás nélkül lehessen olvasni ezt a cikket.

IPSEC Peer

Az IPSEC protokoll használatakor mindig van két kitüntetett csomópont. Az egyik a csomagok beágyazását (enkapszuláció) és titkosítását végzi. A másik a csomagok kicsomagolását (dekapszuláció), a titkosítás feloldását és az eredetiség vizsgálatot végzi. A gyakorlatban a kommunikáció kétirányú szokott lenni, ezért mindkét fél párhuzamosan végzi mindkét feladatot. Ezeknek a feleknek a neve ipsec peer. Fontos látni, hogy az enkapszulációt és dekapszulációt végző felek nem feltétlenül ugyan azok, mint akik a csomagokat eredetileg küldik vagy fogadják. A mi site-to-site példánkban az internet és a telephely (branch01 és office) határán álló router-ek a peer-ek, mivel ők végzik a csomagok be- és kicsomagolását. Ugyanakkor a csomagok feladói és címzettjei a telephelyen belül található gépek. A gyakorlatban előfordulhatnak olyan hálózati topológiák is, ahol a csomagok  olyan útvonalon utaznak, ahol az út egyes szakaszait IPSEC csomagokba ágyazva, egy másik részét normál módon teszik meg. Mi most csak a feladatleírásban szereplő problémára koncentrálunk.

RouterOS esetén az ehhez tartozó menüpont a /ip ipsec peer. Itt lehet megadni az IPSEC kommunikációhoz a távoli peer-eket. A helyi peer-t nem kell külön megadni, mert az maga a router.

IPSEC Policy

A másik fogalom az ipsec policy. Amikor egy csomagot továbbítani kell egy forrás címről egy cél címre, akkor a router elsősorban forgalomirányítási táblázatokat (routing table) használ annak megállapítására, hogy melyik csomagot melyik interface-en keresztül küldje ki. A csomagokat tűzfal szabályokkal tudjuk szűrni és manipulálni. A szűrés azt jelenti, hogy bizonyos csomagokat eldobunk ahelyett, hogy továbbítanánk őket. A manipuláció azt jelenti, hogy módosítjuk őket a továbbítás előtt. Ilyen manipuláció lehet például a forrás- vagy célcím megváltoztatása (srcnat és dstnat), a csomagok sorba állítása, várakoztatás és priorizálás stb. Bizonyos módosítások automatikusak, minden router a rajta áthaladó összes csomagot módosítja az IP protokoll szabályainak megfelelően. (Pl. TTL csökkentése) Az IPSEC protokoll a csomagok feldolgozását a fentiektől jól elkülöníthető rétegben végzi. A csomagok feldolgozása ebben a rétegben úgynevezett ipsec szabályok, szakszóval ipsec policy-k segítségével történik. Egy ilyen policy kicsit hasonlít egy tűzfal szabályra:

• IP csomagokon működik
• Minden szabályban feltételeket adunk meg. Ezek a feltételek vonatkozhatnak a csomag cél címére, forrás címére, az csomag típusára (TCP, UDP) stb.
• A feltételeken felül meg van adva egy művelet (action) is. Ez RouterOS esetén lehet discard (csomag eldobása) encrypt (csomag enkapszulálása és titkosítása) vagy none (ne csináljon vele semmit). Megjegyzés: az encrypt művelet egy kicsit megtévesztő lehet, mivel AH esetében nem történik titkosítás. Ami mindig megtörténik az az enkapszuláció.
• Amikor egy csomag illeszkedik a policy-ben megadott szabályokra, akkor a policy-ben megadott művelet végrehajtódik. Az encrypt művelet a csomagot beágyazza (enkapszulálja) egy IPSEC csomag belsejébe. Ennek során titkosíthat és ellenőrző összegeket írhat be az így előállított új csomagba.
• Fontos látni, hogy a beágyazás során az eredeti csomag "elhasználódik". Helyette egy teljesen új csomag képződik. Ez az új csomag szintén egy rendes IP csomag, de a protokoll száma már nem az eredeti (pl. UDP vagy TCP) hanem IPSEC AH vagy IPSEC ESP. Van rendes forrás- és célcíme, és a router az eredeti csomag helyett ezt a csomagot továbbítja. A fogadó oldal a nála megtalálható kulcs segítségével tudja kicsomagolni az eredeti csomagot. A kicsomagoláskor szükség lehet a titkosítás feloldására és az ellenőrző összeg ellenőrzésére. Az AH és ESP csomagok működés szempontjából datagram típusúak. A továbbítás nem feltétlenül sorrendhelyes. Ha a csomag valami miatt elveszik, akkor az IPSEC nem biztosít erről visszajelzést, és nem próbálja meg az újraküldést. Az eredeti feladó és címzett számára az IPSEC transzparens, nem látható. Ha az eredeti csomag kapcsolatállapot alapú (TCP) volt, akkor az esetleges csomag újraküldéseket is az erdeti (pl. TCP) protokoll valósítja meg függetlenül attól, hogy a csomagok az út egyrészében IPSEC csomagokba vannak ágyazva.
• Nem létezik decrypt művelet. A bejövő csomagok esetén a RouterOS automatikusan felismeri az IPSEC csomagokat, és megpróbálja kicsomagolni őket. Más szóval a bejövő csomagokra nem kell külön policy-kat megadni.
• Több ilyen szabályt (ipsec policy) meg lehet adni. Ezek egymás után lefutnak, és ha van olyan ami illeszkedik, akkor a később következő szabályok már nem futnak le.
• A tűzfal szabályokkal ellentétben az ipsec policy-nál nincsenek chain-ek.

RouterOS esetében a policy-k az /ip ipsec policy menüpont alatt találhatók.

Enkapszuláció és dekapszuláció

A ki- és becsomagolási folyamatot jobban nyomon lehet követni ezen az ábrán:

Forrás: https://wiki.mikrotik.com/wiki/Manual:Packet_Flow

A három nagy szürke doboz balról jobbra sorrendben:

• Switch (layer 2 routing), ebben vannak az A,B,C,D virtuális portok
• MPLS, ebben vannak az E,F,G,H virtuális portok
• Router (layer 3 routing), ebben vannak az I,J,K,L virtuális portok
• Belső RouterOS folyamatok (local in, local out, router processes)

Látható, hogy a decapsulate? és encapsulate? döntést jelképzeő dobozok a switching és routing részeken kívül helyezkednek el. A kimenő csomagok közvetlenül a fizikai interfész elérése előtt érik el az encapsulate? dobozt. Tehát az enkapszuláció a switching és routing után történik. Ennek során az eredeti (enkapszulált) csomag "elhasználódik". Helyette egy új csomag jön létre, ami a local out belső processzben képződik, és innen keződik a feldolgozása. Hasonlóan, a dekapszulációról való döntés is a switching és routing után történik. Ha dekapszulációra van szükség, akkor ezt a local in belső RouterOS processz végzi el. Ennek hatására az eredeti IPSEC csomag "elhasználódik", helyette megjelenik az eredeti (dekapszulált) csomag a local out processz kimenetén. Ezután megkezdődik a feldolgozása. Az IPSEC csomag és a dekapszulált csomag is áteshet routing/switching műveleteken. Sőt, ha többszörös beágyazás van, akkor ezek többször is megismétlődhetnek. Ha például az internet kapcsolat PPPoE protokollt használ, és ezen keresztül érkezik be egy IPSEC csomag, akkor az eredeti csomagot két dekapszuláció után kapjuk meg.

Policy template és generált policy-k

A legegyszerűbb esetben mindkét peer-en kézzel adjuk meg a policy-kat. Tehát kézzel írjuk elő hogy mik azok a csomagok, amiket IPSEC csomagokba kell ágyazni, és biztonságosan továbbítani a másik peer-hez. Ezt a módszert akkor lehet használni, ha kevés számú, előre megismerhető peer-t használunk, és kevés számú policy-t. Van azonban egy másik módja is a policy-k előállításának, ez pedig a policy template ("szabály sablon") megadása. RouterOS-ben úgy tudunk ilyeneket létrehozni, hogy policy template attribútumát yes értékre állítjuk. RouterOS-ben ezek a policy-k úgy jelennek meg a /ip ipsec policy menü alatt, hogy egy T betű van a státusz oszlopban. Egyelőre ezekről elegendő tudni annyit, hogy a rendszer a policy template-ek alapján konkrét dinamikus policy-kat generál a kapcsolat létrehozásakor. Ezeket automatikusan kitörli akkor, amikor a kapcsolat befejeződik. Ezek működését égy másik cikkben (road warrior VPN) fogom elmagyarázni.

 

IKE - a kulcs csere alapjai

Az IKE protokoll célja, hogy két egymással kommunikálni kívánó fél számára biztonságos módon meghatározzon olyan kriptografikus kulcsokat, amikkel a biztonságos kommunikáció elvégezhető. Az IKE protokoll nem csak a kulcsokat határozza meg, hanem a kulcsokhoz tartozó titkosítási algoritmusokat és egyéb olyan paramétereket is, amik szükségesek a kommunikáció lebonyolításához. Ezeket a dolgokat összefoglaló néven Security Association-nak vagy röviden SA-nak nevezzük. Egy SA mindig két konkrét félhez (peer) tartozik. Ha ez első olvasásra nem teljesen világos akkor gondolj úgy az SA-ra, mint egy olyan titkosító kulcsra ("jelszóra"), amit csak az egy mással kommunikáló felek ismernek. Fontos látni, hogy az IKE mindig két fél között egyezteti az algoritmusokat és a kulcsokat. Emiatt az SA-k mindig párban jönnek létre (a kommunikációs csatorna két oldalán.) Ennek hiányában az IPSEC kommunikáció nem lehetséges.

Az IKE protokoll egy démont (folyamatosan a háttérben futó programot) használ. Ez a démon az idő nagy részében nem csinál semmit, inaktív. Alapvetően kétféle módon lehet aktiválni:

• Ha van olyan adatforgalom ami illeszkedik egy ipsec policy-re, akkor az enkapszuláció elvégzéséhez szükség van egy megfelelő SA-ra. Ha ez az SA még nem áll rendelkezésre, akkor ez felébreszti az IKE démont. Ez az IKE démon fölveszi a kapcsolatot a másik oldalon levő IKE démonnal.
• A másik oldalon levő IKE démon fogadja ezt a kapcsolatot. Ez a másik mód amin keresztül egy IKE démont aktiválni lehet (távolról egy másik IKE démon által).
• A RouterOS-ben van egy olyan beállítás is (send-initial-contact), amivel elő lehet írni, hogy a két oldalon konfigurált peer akkor is fölvegye egymással a kapcsolatot, ha épp nincsen olyan továbbítandó csomag, amit enkapszulálni kellene. Az SA előre kiépítése felgyorsítja a válaszidőt az első csomagok elküldésénél.

Miután felébredtek, a két oldalon levő két démon elkezdi egyeztetni az algoritmusokat és a kulcsokat. Ezt UDP üzenetek segítségével valósítják meg. Az egyeztetés végeredménye (szerencsés esetben) az lesz, hogy mindkét félnél létrejön egy-egy SA, amivel már le lehet bonyolítani a kommunikációt. A kulcsok meghatározásához a Diffie-Hellman néven ismert kulcs csere algoritmust használják. Ez az algoritmus képes előállítani ugyan azt a titkos és véletlenszerű kulcsot a kommunikációs csatorna két oldalán úgy, hogy közben a csatornát potenciálisan figyelő többi fél nem képes hozzájutni ezekhez a kulcsokhoz (annak ellenére, hogy a kommunikáció nincs titkosítva). Az algoritmus rövid neve a továbbiakban DH algoritmus, vagy egyszerűen csak DH. A DH algoritmusnak több változata ismert, amelyek különböző bonyolultsági fokkal rendelkeznek. A magasabb bitszámot használó, erősebb titkosítást biztosító algoritmusok magától értetődően magasabb számítási igénnyel rendelkeznek. A különböző változatait a kulcs bitek számának megfelelően szokás csoportosítani. Ezek a csoportok az úgynevezett DH csoportok.

Az IKE démon az UDP/500 -as portot használja a kulcsok egyeztetésére. Ha szeretnél IPSEC/IKEv2 kommunikációt, akkor ezt a portot nyitva kell hagynod. Ez a kommunikáció normál UDP csomagokat használ, amelyek adattartalma nincs titkosítva vagy aláírva. (Ezen felül a 4500-as portot is ha NAT mögött van valamelyik fél, erről alább írok.)

Az IKEv2 protokoll az SA-t két fázisban hozza létre.

IKE első fázis

Az első fázisban a két fél megegyezik azokban az algoritmusokban, amiket használni fognak a kommunikációra a következő fázisban. Ezen felül meghatározásra kerül néhány olyan kulcs is, ami majd a második fázis összes kommunikációját védi. Ezeket a kulcsokat a fent említett DH algoritmussal határozzák meg. Ha gyakran és sok alagutat kell fölépíteni, akkor a DH algoritmus egy korlátozó tényező lehet (mivel számításigényes). Ebben az írásban az a célunk, hogy két fix címmel rendelkező router között permanens kapcsolatot alakítsunk ki. Itt nem lehet számítani nagy számú kapcsolat gyakori felépítésére, ezért érdemes magasabb (biztonságosabb) DH csoportot választani. A magas számítási igény miatt az első fázisban meghatározott kulcsok általában hosszú lejáratúak (több óra). Az első fázisban a sikeres egyeztetéshez a következőkben kell megegyezniük a feleknek:

• autentikációs módszer (pl. előre megadott titkos jelszó vagy tanúsítvány)
• DH csoport
• titkosítási algoritmus
• kulcs csere algoritmus
• hash algoritmus
• NAT-T
• DPD és leárati idő (opcionális)

Ezeket alább részletezem.

Authetikációs (azonosítási) módszer

A felek valamilyen módon igazolják azt, hogy tényleg azok, akinek mondják magukat. Ez a felek azonosítása, vagy szakszóval autentikáció. A legegyszerűbb esetben erre egy egymás között megosztott titkos kulcsot használnak. Egy egyszerű jelszó, angolul "pre shared key" vagy röviden PSK. Egy másik, nagyon elterjedt módszer az X.509 tanúsítványok használata. Ez utóbbit nehezebb beállítani, de jóval biztonságosabb. Ha nagy biztonságra törekedünk, akkor az előre megosztott kulcsok (PSK) használatát kerülni kell.

Keress rá arra hogy psk ike vulnerability és találni fogsz egy csomó cikket ami arról szól, hogy a PSK azonosítás mennyire sebezhető.

A PSK használata mégis indokolt lehet némely esetben:

• Ha a végfelhasználónak nincs elég szakértelme a tanúsítvány alapú azonosítás beállításához.
• Ha a távoli csomópont nem támogatja a tanúsítvány alapú azonosítást (pl. régi szoftver verzió).
• Ha alacsonyabbak a biztonsággal kapcsolatos elvárásaink.

Vannak egyéb más azonosítási módszerek is, erre most nem térek ki. Mi ebben az írásban alhálózatok összekötését akarjuk megvalósítani. Teljes telephelyek közötti mindenféle kommunikációt kívánunk titkosítani, ezért itt érdemes erősebb, tanúsítvány alapú azonosítást használni.

RouterOS-ben az azonosításhoz tartozó beállítások a /ip ipsec identity menüpont alatt találhatók. Ezen belül az auth-method attribútum határozza meg az azonosítási módszert.

DH csoport

Ez a már föntebb említett Diffie-Hellman algoritmus bonyolultsági fokát adja meg. A magasabb bitszámú algoritmus magasabb biztonságot ígér, de számításigényesebb.

Titkosítási algoritmus

Ez egy titkos kulcsú, szimmetrikus titkosítási algoritmus kiválasztását jelenti. Mi ebben a példában az AES256-CBC algoritmust választjuk, mert ez hardver támogatással rendelkezik, és elég biztonságos.

Kulcs csere algoritmus

Itt IKE2-őt választunk. (Akit érdekel az utánanézhet a többi típusnak, ez a cikk az IKEv2-ről szól.)

Hash algoritmus

Ez az algoritmus egy kriptografikus hasítófüggvény aminek az a legfontosabb jellemzője, hogy az invertálása túl nagy bonyolultságú ahhoz, hogy értelmes keretek között megvalósítható legyen. Mi ebben a példában az SHA2-256 algoritmust választjuk, mert ez hardver támogatással rendelkezik, és elég biztonságos. Ezt a hash algoritmust használjuk többek között a fent említett ellenőrző összegek számításához. Közvetve ez garantálja az enkapszulált csomagok integritását. (Az ellenőrző összeget általában nem direkt módon a hash függvény határozza meg, hanem az ebből származtatott MAC kód.)

Néhány szó a NAT-T-ről

Az IPSEC protokollhoz külön módszert kellett kidolgozni a NAT mögött levő végpontok elérésére. Az IKE protkoll első és második fázisát nem befolyásolja az, ha a peer-ek közötti útvonalon áthaladó csomagok NAT-on esnek át. Ez azért van, mert az alap IKE protokoll normál UDP csomagokat használ, és ezek forrás- és célcíme szabadon módosítható. Azonban az IPSEC által titkosított adatforgalomnál ez már problémát okoz.

Az egyik probléma a csomagok módosításával kapcsolatos:

• ESP csomagok esetén azért nem lehet NAT-ot végezni, mert a beágyazott eredeti csomag tartalmazhatja a forrás- és célcímet. Ezekhez a NAT-ot elvégezni kívánó router nem fér hozzá, mert az eredeti csomag titkosítva van.
• AH csomagok esetén az eredeti címek hozzáférhetőek, nincsenek titkosítva. Viszont a csomag integritását egy olyan hash érték biztosítja, ami érvénytelenné válik akkor, ha a csomagban levő forrás vagy célcím módosításra kerül. Így tehát az AH csomagokon elvégezhető a NAT, de a célállomásra való beérkezés után a célállomás ezeket a csomagokat eldobja, mert észreveszi hogy a csomagot valaki módosította.

A másik probléma azzal kapcsolatos, hogy a két fél közötti kommunikáció olyan útvonalon haladhat végig, amiben részt vesznek olyan router-ek, amik szintén futtatnak IKE démont és tartalmaznak IPSEC policy-ket. Ha egy ilyen router-re beérkezik egy IPSEC csomag, akkor a router esetleg elkezdheti feldolgozni (megpróbálja kicsomagolni). Valahogy el kell érni azt, hogy ezek a csomagok csak a cél csomóponton legyenek dekapszulálva.

Ezen problémák elkerülésére lefoglalták a 4500-as portot és kialakítottak egy plusz protokollt arra, hogy az IPSEC csomagok át tudjanak haladni NAT-olt hálózatokon. Az eredeti ESP=50 illetve AH=51 protokoll mezőt lecserélik UDP=17-re, és beszúrnak egy érvényes UDP header-t az IP header és az ESP/AH header közé, valamit módosítják a cél portszámot 4500-ra. Ezekkel a változtatásokkal ezek a csomagok normál UDP csomagként továbbíthatók. A hozzáadott extra UDP header miatt elvégezhető rajtuk a NAT anélkül, hogy az enkapszulált csomag integritása megsérülne.

Mivel ez a módosítás csökkenti a hasznos payload méretét (azonos MTU mellett), ezért ezt csak akkor szokás használni, ha arra lehet számítani hogy a felek között NAT történik. Ha a felek között biztosan nem történik NAT, akkor érdemes kikapcsolni ezt a funkciót, ezzel növelve az egy csomagban kiküldhető (hasznos) adat mennyiségét.

Bár ezek a problémák a kulcs csere (IKE) használatakor nem jelentkeznek, de mégis az IKE protokoll az, ami előre megegyezik abban, hogy a felek használjanak-e NAT-T módot vagy ne. Így amikor a csomagok enkapszulációja szükségessé válik, akkor a router már előre tudja, hogy el kell-e végezni a NAT-T csomag transzformációt.

Az algoritmusok egyeztetésének módja

RouterOS-ben (és általában más szoftverekben is) megadható több algoritmus. A két oldalon levő IKE démon a megadott lehetséges algoritmusok közül olyan választ, ami mindkét oldal számára megfelelő. Ezen belül a sorrend is lényeges - ha több lehetséges algoritmust adunk meg, akkor azoknak magasabb a prioritása, amelyeket előrébb sorolunk a listában.

RouterOS-ben az ehhez tartozó menüpont az /ip ipsec profile és az /ip ipsec proposal . A profile az első fázishoz tartozik, a proposal a második fázishoz.

Ha nem található olyan algoritmus amit mindkét fél megadott a listájában, akkor a kulcscsere nem hajtható végre, és az IPSEC kapcsolat nem hozható létre.

Az algoritmusok kiválasztásánál nem csak azt kell figyelembe venni, hogy mennyire biztonságos kapcsolatot szeretnénk. Figyelembe kell venni az elérhető számítási teljesítményt (ami az adatforgalom sebességétől is függ!), valamint a távoli peer lehetőségeit. Ha például megnézzük a Windows 10 kliensek lehetőségeit akkor azt látjuk, hogy a kettes fázisban kizárólag az SHA1 hasító függvényt támogatja. Így például ha azt szeretnénk hogy Windows 10 kliens tudjon csatlakozni, akkor kénytelenek leszünk engedélyezni az SHA1 hasító függvényt. (Megjegyzés: bár maga az SHA1 már rég nem tekinthető biztonságosnak, de az SHA1 alapú MAC kódok igen.)

A mi esetünkben site-to-site kapcsolatot akarunk kialakítani két MikroTik Router között, így előre ismerjük a peer-ek képességeit, és biztonságosnak mondott algoritmusokat tudunk használni.

IKE második fázis

A második fázisban a felek (peers) létrehoznak egy vagy több SA párt. Ezek lesznek később használva az IPSEC csomag enkapszulációhoz (titkosításra és MAC generálásra). Minden IKE démon által előállított SA-nak van egy maximális életkora (lifetime). Az életkor lehet megadva lejárati időben, maximális adatforgalomban, illetve lehet akár mindkettő is. Az életkor elérése után az SA nem használható tovább a kommunikációhoz, új SA-t kell kiépíteni.

Kétféle életkor létezik. egy "soft" és egy "hard". Amikor az SA eléri a "soft" életkort, akkor az IKE démon kap egy értesítést, és újra elkezdi futtatni a második fázist. Ennek az a célja, hogy az életkor végén a kommunikáció folytatásához szükséges "friss" SA azonnal rendelkezésre álljon. Így a kommunikáció nem lesz várakoztatva a kulcsok egyeztetése miatt (az IPSEC forgalomnak nem kell várakoznia az IKE-re).

A második fázisban a feleknek a következőkben kell megegyeznie:

• Mód (alagút vagy transzport)
• IPSEC protokoll (ESP vagy AH)
• Azonosítás (autentikáció) módja
• PFS (DH) csoport
• Életkor

Ezeket alább részletezem.

Mi az a transzport és alagút mód?

A csomagok enkapszulációja során az eredeti IP csomagnak van egy forrás- és egy célcíme. Transzport mód esetében a forrás- és célcím nem kerül beágyazásra. Ezt a módot akkor lehet jól használni, ha egy olyan biztonságos kapcsolatot akarunk kiépíteni, aminél a titkosítandó csomagok forrás- és célcíme ugyan az, mint a peer-ek címe. (A mi esetünkben ez azt jelenti, hogy az egyik router az eredeti csomag küldője, a másik az eredeti csomag végleges címzettje.)

Azokban az esetekben, amikor az eredeti csomagok feladója és/vagy címzettje nem egyezik meg az enkapszulációt/dekapszulációt végző peer-ekkel, alagút módot kell használni. A mi példa feladatunk ilyen! A kapcsolatot két alhálózat között kell megvalósítanunk. Az egyik alhálózatból induló csomagok valahol beérkeznek egy router-be, ami enkapszulálja őket. Ezután az adatok titkosított IPSEC csomagok belsejében haladnak tovább egy másik router-hez. Ez a másik router elvégi a dekapszulációt, és innentől kezdve a csomagok újra titkosítatlan módon haladnak tovább az eredeti célcím irányába. Tehát az eredeti csomagok forrás- és célcíme nem egyezik meg azoknak a router-eknek a címével, amelyek az enkapszulációt/dekapszulációt végzik. Egy ilyen típusú összeköttetés kialakításához a transzport mód nyilván nem használható, mivel az eredeti csomagok forrás- és célcímeit nem lehet használni az összeköttetés kialakításához. Az IPSEC csomag célba juttatásához az kell, hogy a célcíme a távoli peer címe legyen, és ez nem egyezik meg az eredeti címzettel. Az eredeti címek általában olyan belső/foglalt hálózati címek amikhez az interneten nem lehet útvonalat választani. Ugyanakkor az eredeti forrás- és célcímek megőrzése szükséges ahhoz, hogy kicsomagolás után a távoli alhálózaton belül továbbíthatóak legyenek az eredeti csomagok az eredeti (végleges) célcímre. Tehát az IPSEC csomagok forrás- és célcíme a peer-ek címeivel egyezik meg, de valahol el kell tárolni az eredeti forrás- és célcímet is. Tunnel módban pontosan ez történik. Az eredeti csomag teljes egészében, az eredeti forrás- és célcímekkel együtt enkapszulálásra kerül. Az új IPSEC csomag forrás és célcímei eltérhetnek az eredeti csomag forrás- és célcímeitől. Így az IPSEC csomag forrás- és célcíme olyan publikus címeket tartalmazhat, amikhez az interneten lehet útvonalat választani, a kicsomagolás után pedig újra elérhetőek lesznek azok a (belső privát) címek, ami alapján az útvonalválasztás a helyi/belső alhálózaton belül elvégezhető.

A tunnel mód bármikor használható a transzport mód helyett. Azonban fontos megjegyezni azt, hogy a tunnel mód további header-ek hozzáadását igényli, és így csökkenti az egy csomagban továbbítható hasznos adat (payload) maximális méretét, és fölösleges csomag fragmentációt okozat. Ezért ha biztosan nincs rá szükség, akkor ne használjunk tunnel módot.

IPSEC csomag formátumok: AH és ESP

Az AH csomag formátum arra alkalmas, hogy garantálja a küldő fél eredetiségét. (Azt, hogy valóban a másik fél küldte a csomagot.) Más szóval ezt a csomag integritásának nevezik. Az AH nem titkosítja az adatokat! Ez úgy működik, hogy az eredeti csomag egyes részeire kiszámítunk egy ellenőrző összeget. Az összeg kiszámításához felhasználjuk a választott hash algoritmust és az SA-ban található titkos kulcsot. Hogy a csomag mely részeiből számítjuk ki ezt az összeget, az függ attól is, hogy transzport vagy alagút módot használunk.

• Transzport módnál az AH header-t az IP header után szúrjuk be. Az IP adat és IP header is részt vesz az ellenőrző összeg számításában. Azok az IP mezők amik megváltozhatnak a továbbítás során (pl. TTL) nullára vannak állítva az összeg kiszámítása előtt. Ez csökkenti a header-ek méretét, és növeli a hasznos payload méretét. Ugyanakkor ez azzal jár, hogy az IP header-ben levő címek nem módosíthatók.
• Alagút módnál a teljes IP csomagot enkapszuláljuk. Az eredeti IP csomag teljes egésze (ide értve az forrás és célcímet valamint a TTL mezőket is) részt vesz az ellenőrző összeg számításában. Ez garantálja az eredeti csomag forrás és célcímének integritását, de növeli a header-ek méretét, és csökkenti a hasznos payload méretét. Az IP header-ben levő címek módosíthatók.

Bővebb infó: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Authentication_Header_.28AH.29

Az ESP csomag formátum garantálja a csomagok integritását, és titkosítja a bennük levő adatokat. Teljesen más mezőket használ mint az AH. Ezeket a mezőket három csoportba lehet osztani:

• ESP Header - ez a titkosított adat előtt van. A helye attól függ, hogy transzport vagy alagút módot használunk.
• ESP Trailer - Ez a titkosított adatok után következik. Ez tartalmaz egy padding-ot ami szükséges ahhoz, hogy a titkosítandó adat mérete a titkosító algoritmus blokk méretének egész számú többszöröse legyen.
• ESP Authentication data - Ez tartalmaz egy Integrity Check Value (ICV) értéket. Ez az AH protokollhoz hasonló módon van kiszámítva.

Bővebb infó: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Encapsulating_Security_Payload_.28ESP.29

Az AH használata akkor indokolt, ha az átvinni kívánt adatok nem titkosak (nyilvánosak) és csak annyi a célunk, hogy kívülálló/közbeékelődő támadók ne legyenek képesek más nevében adatokat küldeni. A mi példánkban a célok között szerepel az, hogy a két site közötti kommunikációt mások ne tudják lehallgatni. Emiatt ESP-t kell használunk.

Második fázis, azonosítás (autentikáció) módja

Itt pont ugyan azok igazak, mint az első fázisnál. (Az azonosítás módja az első és második fázisnál azonos.)

PFS (DH) csoport

Ennek megértéshez vissza kell térnünk az első fázishoz. Az első fázisban csak azokat a kezdeti kulcsokat határozzuk meg DH algoritmussal, amik a második fázis biztonságos lebonyolításához szükségesek. A második fázisban létrehozott kulcsok nem tartanak örökké. Ahogy azt korábban írtam, a második fázisban létrehozott SA-knak van egy soft és egy hard lifetime limit-je, és időnként meg kell őket újítani. A második fázisban létrehozott SA nem ugyanazokat a kulcsokat tartalmazza, mint amiket az első fázis használt. Minden második fázisban létrehozott SA saját, egyedi titkos kulcsokat tartalmaz, amik előre nem kitalálhatóak. Tehát valójában kétféle SA van: egy szülő SA ami az első fázishoz tartozik, és ehhez kapcsolódó további "gyermek" SA-k, amik a második fázishoz tartoznak. Az első fázis rendszerint egyszer játszódik le, ezért az ehhez tartozó kulcsot szokás állandó kulcsnak is nevezni. A második fázis sokszor lejátszódhat, mivel a kommunkikáció hosszú ideig eltarthat, és ezalatt többször szükség lehet a (korlátos életidővel rendelkező), második fázis által generált SA-k megújítására.

Ahogy korábban említettem, a DH algoritmus nagyon számításigényes. Ezért a második fázisban létrehozott SA-k titkos kulcsait alapesetben az első fázisban létrehozott SA kulcsaiból származtatják. Mivel az első fázisban DH algoritmussal létrehozott titkos kulcsok közvetlenül semminek a titkosítására nincsenek fölhasználva, ezért szinte semmi esély nincs arra, hogy ezt a kezdeti kulcsot bárki brute force módszerrel (a kommunikáció rögzítésével és annak próbálkozásos visszafejtésével) meghatározza. Ez a működés pfs-group=none beállításnak felel meg RouterOS-ben. Ennél a beállításnál a második fázis egyáltalán nem használ DH algoritmust. Emiatt gyors, kisebb CPU igényű. Mégis viszonylag biztonságos.

Előfordulhat azonban az, hogy az első fázisban meghatározott állandó kulcshoz valaki valamilyen más módon hozzáfér. Ha ez bekövetkezik, akkor az ebből származtott összes második fázisban használt kulcs meghatározása nagyon egyszerűvé válik. Mivel az első fázisban meghatározott kulcs nagyon hosszú ideig használatban lehet (nincs lejárata!), ezért az állandó kulcs feltörése után visszamenőleg megfejthetővé válik az összes kommunikáció, amit korábban a támdó rögzített. Ez különösen akkor veszélyes, ha az első fázis által meghatározott kulcsok megbízhatóan, leállás nélkül működő csomópontok között, határozatlan ideig kiépített alagút kiépítésére vannak használva. Ennek a problémának kivédésre szolgál a Perfect Forward Secrecy vagy röviden PFS. Ennek az a lényege, hogy a második fázishoz használt kulcsot nem az első fázisban meghatározott első kulcsból származtatjuk, hanem egy külön DH algoritmussal határozzuk meg. Ez csökkentheti az átviteli sebességet, és a válaszidőket is növelheti. Főleg akkor, ha a második fázis lejárati ideje rövid, és egyetlen eszközön párhuzamosan egyszerre sok VPN alagutat kell működtetni. Ugyanakkor ez a módszer garantálja azt, hogy a korábban rögzített kommunikáció ne legyen teljes egészében visszafejthető akkor, ha valaki megszerzi az első fázisban meghatározott állandó kulcsot. PFS group használata esetén minden IPSEC SA kulcsát egy külön DH algoritmus futtatással határozzuk meg, aminek semmi köze nincsen az IKE első fázisában használt állandó kulcshoz. Ha bármelyik kulcs feltörésre kerül (például brute force módszerrel), akkor csak a kommunikációnak azon része lesz hozzáférhető, aminek titkosításához a feltört/megtalált kulcsot használták.

Van itt erről egy jó kérdés: https://security.stackexchange.com/questions/196832/which-pfs-group-is-recommended-for-ipsec-configuration

Mi ebben a példában modp2048 beállítást fogunk használni az első és a második fázishoz is. Ez egy viszonylag erőforrás igényes beállítás. A választást azzal indokoljuk, hogy itt egy site-to-site kapcsolatról van szó. Egyetlen alagutat építünk ki két alhálózat összekötésére, és csak ezt az egy alagutat kell működtetnünk. Ezek a peer-ek megbízhatóan, hosszú időn keresztül működnek. A két alhálózatban levő gépek ugyan ezt az egy alagutat használják megosztva. Így a felépítendő SA-t száma alacsony, viszont az egy SA-n keresztül nagyobb adatmennyiség van lebonyolítva. Ez indokolja a magasabb PFS DH csoport használatát.

 

MTU és fragmentáció

Amikor az eredeti IP csomagokat IPSEC csomagokba enkapszuláljuk, akkor természetesen az IPSEC csomagok mérete nagyobb lesz, mint az eredeti IP csomagok mérete. Hogy pontosan mennyivel nagyobb, azt ismét Nikita Tarikin előadásáról származó ábrával mutatom be. Az alábbi ábra egy rendes IP csomag illetve egy IPSec ESP csomag felépítését mutatja (tunnel módban):

Ha a tunnel módon felül még NAT-T beállítást is használunk, akkor további 8 byte-ot elvesz az IP fejléc és az IPSEC adat blokk közé beszúrt extra UDP fejléc:

Ethernet (layer 2) szinten a maximális csomagméret általában 1500 byte. Egy normál IPv4 csomag esetében az IPv4 header 20 byte-ot foglal el. (Ebben van verziószám, TTL érték, al-protokol száma, forrás- és célcím stb. Részletek itt találhatók. Emiatt egy ethernet-en keresztül küldött normál IP csomagban a hasznos adat (payload) mérete legfeljebb 1492 byte lehet.

Ha megnézzük az alagút módban használt IPSEC/ESP csomagot akkor azt látjuk, hogy az eredeti (teljes) beágyazott és titkosított IP csomagon felül még el kell tárolnunk az ESP fejlécet, az ESP tail-t (amiben pl. a csomag integritását biztosító ellenőrző összeg szerepel). Ezen felül egy új IP header is bekerül az elejére (amiben az sa-src-address és az sa-dst-address közötti forgalmazáshoz szükséges). Ha pedig még NAT-T módot is használunk, akkor még újabb 8 byte-ot föl kell használunk.

Ha az eredeti ethernet csomag mérete 1500 byte volt, és az IPSEC/ESP csomag (ethernet) mérete is legfeljebb 1500 byte lehet, akkor az enkapszulációt természetesen nem lehet elvégezni. Egyszerűen azért, mert az eredeti csomag nem fér bele a legnagyobb méretű IPSEC csomagba sem. IPv6 esetében még rosszabb a helyzet, az IPv6 header mérete ugyanis 40 byte.

Amikor a router ilyen feladattal szembesül, akkor az eredeti IP csomagot töredékekre bontja (idegen szóval fragmentálja), és ezeket a töredékeket külön IPSEC csomagokban továbbítja. A távoli peer ezeket a töredékeket fogadja, egyesével kicsomagolja, és ezekből állítja elő az eredeti csomagot. A távoli peer addig nem tudja helyreállítani az eredeti csomagot, amíg az összes töredék meg nem érkezik. Ezért tárolnia kell őket egy ideig. Előfordulhat, hogy nem érkezik meg minden töredék. (Az IPSEC csomagok datagram típusúak, nincs arra garancia hogy megérkeznek.) Ilyenkor a távoli peer eldobja a használhatatlan töredékeket. De ezt csak egy idő után teszi meg, és addig is fölöslegesen tárolja őket. A fragmentálás jelentősen rontja a továbbított és a hasznos adatmennyiség arányát. A helyzet tovább romlik akkor, ha egy adott útvonalon több helyen kell fragmentálni. A többszörös fragmentáció hatására a kapcsolat átviteli sebessége jelentősen csökkenhet, a válaszidők jelentősen növekedhetnek, és az átvitelben résztvevő eszközök terhelése növekedik. Többszörös fragmentáció előfordulhat például akkor, ha az útvonalon van egy PPPoE alagút, vagy ha egy nem optimális router az IPSEC csomagokat újabb IPSEC csomagokba enkapszulálja stb.

MTU Path Discovery

A fenti okokból a fragmentációt lehetőség szerint el kell kerülni! Ebből a célból használják a Path MTU Discovery (rövidítve MTUPD) nevű eljárást. Ez máshogy működik IPv4 és IPv6 esetén. Azonban mindkettőre igaz, hogy kizárólag kapcsolatállapot alapú protokollokkal működik. Az ilyen protokollok a kommunikációt úgy végzik el, hogy először kiépítenek egy utat (path), és az adatokat ezen az úton át küldik el egymásnak. A csomagkapcsolt (datagram) protokollok esetén az MTU Path discovery nem működik.

• IPv4 esetében úgy működik az MTUPD, hogy a kiküldött IP csomagnál a küldő fél beállítja a DF (don't fragment) bitet. Bármely eszköz ami egy ilyen csomagot nem tud fragmentálás nélkül továbbítani, eldobja a csomagot és visszaküld egy "Fragmentation eeded" ICMP csomagot a feladónak. Ebben az üzenetben szerepel az elérhető legnagyobb MTU is. A küldő fél ezzel az új MTU-val próbálja újra a csomag küldését. Ez a folyamat addig ismétlődik, amíg a csomag el nem jut (fragmentálás nélkül) a célcímhez.
• Az IPv6 router-ek nem támogatják a fragmentálást, és az IPv6 fejlécben nincsen DF bit. Az IPv6 protokoll esetében az MTU Path discovery úgy működik, hogy eredetileg azt feltételezzük, hogy az útvonal MTU-ja ugyan az, mint a link MTU-ja. (A link MTU-ját az a helyi interface adja meg, amin keresztül a küldő fél kiküldi a csomagot.) Ezután az IPv4 protokollhoz hasonlóan, bármely eszköz ami a túl nagy méret miatt nem tudja továbbítani a csomagot, visszaküld egy ICMPv6 "túl nagy csomag" üzenetet a feladónak.
• Ha egy korábban kialakított kapcsolatban csökken az MTU értéke, akkor az első túl nagy csomag ICMP hibát okoz, és a küldő fél automatikusan ennek megfelelően csökkenti az kiküldött csomagméreteket. Tehát az MTUPD képes dinamikusan alkalmazkodni a path MTU megváltozásához.
• Hasonlóan, ha a kialakított kapcsolatban növekedik az MTU értéke, akkor az operációs rendszer ezt felismeri, és módosítja a kapcsolat MTU-ját. Ezt az OS úgy éri el, hogy időnként újrapróbálkozik nagyobb méretű ICMP DF csomagokkal. Az újrapróbálás ideje Linux és Windows operációs rendszerek esetében 10 perc.

Sajnálatos módon az MTUPD algoritmus nem mindig működik megfelelően. Ennek az az oka, hogy egyes eszközök letiltják az ICMP csomagok fogadását és/vagy továbbítását. (Általában biztonsági megfontolásokból.) Nem lehet előre megmondani, hogy a két telephelyet összekötő útvonalon van-e (vagy lesz-e a jövőben) olyan eszköz, ami megakadályozza az ICMP csomagok átjutását, és ezzel ellehetetleníti az MTU automatikus meghatározását.

TCP MSS Clamping

A TCP kapcsolatok esetében elterjedt megoldás a fenti probléma kiküszöbölésére a TCP maximális szegmens méret csökkentése vagy más néven MSS Clamping. A TCP MSS csökkentése közvetve csökkenti a TCP csomagok maximális méretét, ezáltal képes csökkenteni a fragmentációt. Ez a következő módon működik. A TCP protokoll a kapcsolat kialakítását az úgynevezett SYN csomagok elküldésével kezdi. Ezek tartalmazzák az egy TCP csomagban elküldhető maximális adat méretet, más néven MSS-t. Amikor egy TCP SYN csomag áthalad egy olyan eszközön, ami tudja magáról hogy nem képes az alapértelmezett 1500 byte -os ethernet frame fragmentálás nélküli továbbítására, akkor módosítja a továbbítandó TCP SYN csomagban található MSS értéket egy alacsonyabb értékre. (Hogy pontosan mi a megfelelő érték, arról később írok). Ezzel a módszerrel TCP kapcsolatok esetén az adott eszközön egész biztosan el lehet kerülni a fragmentációt. Ez a módszer az MTUPD-től teljesen független módon működik, és bármely TCP kapcsolatra alkalmazható.

Az MTU érték magasan tartása növeli a hatékonyságot. Emiatt sok szabályt dolgoztak ki, amivel az overhead-et (header/adat arányt) alacsonyan lehet tartani. Az IPSEC/ESP csomagok overhead-je függ az átviteli módtól (transzport/alagút), a NAT-T beállítástól (kell-e extra UDP header-t beszúrni), a használt titkosítási algoritmustól (például a cipher blokk méretétől) stb. Ráadásul a használt titkosítási algoritmust nem lehet mindig előre rögzíteni. Ha például sok különböző kliens kapcsolódik és különböző proposal-okat használnak, akkor az IKE démon számos különböző algoritmus kombinációt elfogadhat. Ennek bonyolultságával kapcsolatban némi támpontot adhat ez a weblap. Itt látható, hogy például a paddig értéke egy byte-tal kevesebb mint a cipher blokk mérete (legrosszabb eset). Illetve első pillantásra furcsának tűnhet az SHA1 HMAC értékhez beírt 96 bit, de jobban utánanézve kiderül, hogy bizonyos algoritmus kombinációknál nem a teljes HMAC ellenőrző összeget írják be a csomagba, hanem annak csak egy részét.  Az utólag hozzáadott újabb típusú algoritmusokra (SHA256+) további RFC-k használhatók. Lehet találni a neten mindenféle MTU kalkulátorokat, azonban ezek nem mindig képesek kiszámítani a megfelelő MTU értéket az általad használt algoritmusokra (feltéve hogy előre ismered őket!), és kétséges a megbízhatóságuk.

Sokkal célravezetőbb az empirikus módszer. Az empirikus módszerhez az szükséges, hogy legyen az alagút mindkét oldalán egy elérhető, ping-elésre képes gép, valamint hogy a ping üzenetek átmenjenek az egyik oldalról a másikra. Windows operációs rendszer alatt erre a a ping parancs a -f és -l kapcsolókkal használható. A -f kapcsoló jelentése: do not fragment. A -l kapcsolóval lehet megadni (növelni) a csomag méretét.

Az empirikus módszert a feladatként meghatározott site-to-site VPN kapcsolat teszt hálózatán végezzük el.

Először egy olyan útvonalon ping-elünk, ahol nincsenek alagutak. Például a branch01 -ben levő Windows10-1 gépről pingeljük az ISP router-ének 10.2.2.2 címét. Kezdetben 1472 byte mérettel próbálkozunk. Az 1472 úgy jön ki, hogy egy ICMP ping csomagban 20 byte IP header és 8 byte ICMP header van. A teljes (alapértelmezett) 1500 byte-os ethernet keretből így 1472 byte marad:

Ahogy látható, az 1472 byte méret átment, az 1473 byte méretre "packet needs to be fragmented but DF set" ICMP hibaüzenetet kaptunk. Ezzel megtudtuk azt, hogy az internet felé menő normál (nem alagutazott) útvonal milyen MTU értékkel rendelkezik. Jelen esetben ez ethernet (layer 2) szinten 1500. Ezután elkezdjük ping-elni az alagút másik oldalán levő valamelyik (bármelyik) gépet egy olyan csomagmérettel, amiről még úgy gondoljuk, hogy fragmentáció nélkül átmegy az alagúton:

Tehát most már tudjuk, hogy az MTU érték valahol 1472 és 1400 között van. A pontos értéket felező módszerrel viszonylag gyorsan meg tudjuk határozni:

Alagúton legfeljebb 1410 byte adat ment át, alagút nélkül pedig 1472 byte. A kettő között a különbség 1472-1410 = 62 byte. Tehát ennyivel kell csökkenteni az MSS értékét ahhoz, hogy elkerüljük a TCP csomagok fragmentációját.

Egy normál 1500 byte-os TCP/IP csomag felépítése olyan, hogy az IP fejléc elvesz 20 byte-ot, és a TCP fejléc elvesz még 20 byte-ot. Ezért a teljes 1500 byte-os ethernet keretben az MSS értéke nem haladhatja meg az 1460 byte-ot. Az általunk felépített konkrét alagút ennél 62 byte-tal kisebb helyet biztosít. Ezért a fragmentáció nélkül továbbítható legnagyobb MSS érték 1460 - 62 = 1398 byte.

Ezt a számítás egy sorba kiírva:

TCP MSS = 1460 - (1472 - <mért ICMP MTU>) = <mért ICMP MTU> - 12

Mindig az 1472 byte-os alap értékhez viszonyítunk. Ha például az internet kapcsolatod PPPoE-t használ, akkor az első tesztben azt fogod tapasztalni, hogy az ICMP MTU a VPN alagút nélkül 1472 alatt van. Ettől függetlenül a TCP MSS mindig 12 byte-tal kevesebb lesz, mint az általad mért maximuális ICMP ping méret. Ez azért van így, mert a TCP csomag elméleti maximális 1460-as értéke is az 1500 byte-os full ethernet frame-re vonatkozik.

Bár ez a módszer egy kicsit fáradságos, viszont sokkal megbízhatóbban meghatározza a valós MTU értéket, mint egy elméleti számítás.

A fent leírt módszer akkor is célra tud vezetni, ha az útvonalon található router-ek közül valamelyik blokkolja az ICMP üzenetek visszaküldését. Ha a visszajövő ICMP üzenetek blokkolva vannak, akkor az MTUPD biztosan nem működik. Azonban ICMP alapú ping helyett lehet használni UDP vagy TCP alapú pinget. (Erre vannak programok.) Ha nem érkezik vissza válasz a TCP vagy UDP alapú, megnövelt méretű pingre (timeout) akkor ez feltételezhetően azért azért van, mert fragmentáció nélkül nem lehetett átküldeni a csomagot. Tehát a "packet needs to be fragmented but DF set" üzenetet ilyenkor a timeout helyettesítheti (de persze csak akkor, ha van olyan csomagméret, aminél jön vissza ping válasz!)

Ha sokféle algoritmus engedélyezel, és nem vagy biztos abban, hogy az enkapszuláció és az alagutazás pontosan mekkora overhead-et okoz, akkor viszonylag biztonságosan használhatod az 1360 byte-os MSS értéket. Ebbe bőven belefér a NAT-T mód által beszúrt extra 8 byte-os UDP header, és a legerősebb titkosítási algoritmusok overhead-je is. Bár az igaz, hogy ez így nem mindig optimális, de egész biztosan nem okoz fragmentációt. (Annál minden jobb.)

TCP MSS Clamping RouterOS-ben

Tehát olyan szabályt veszünk föl, ami képes lecsökkenteni a TCP SYN csomagok 1360 byte-nál nagyobb MSS értékét 1360-ra. Nagyon fontos hogy olyan szabályt vegyünk föl, ami nem képes növelni az MSS értékét. Ha a csomag már eleve 1360 -nál kisebb MSS értékkel érkezik be, és ezt felülírjuk 1360-ra, akkor ezzel megnöveljük azt, és így végül pont az ellenkezőjét érjük el annak, mint amit szeretnénk (növeljük a fragmentációt ahelyett hogy csökkentenénk).

A megfelelő szabály az office gépen így néz ki:

/ip firewall mangle add action=change-mss chain=forward new-mss=1360 src-address=172.16.1.0/24 protocol=tcp tcp-flags=syn tcp-mss=!0-1360 ipsec-policy=in,ipsec passthrough=yes comment="IKE2: Clamp TCP MSS from 172.16.1.0/24 to ANY"

A branch01 gépen pedig így:

/ip firewall mangle add action=change-mss chain=forward new-mss=1360 src-address=172.16.2.0/24 protocol=tcp tcp-flags=syn tcp-mss=!0-1360 ipsec-policy=in,ipsec passthrough=yes comment="IKE2: Clamp TCP MSS from 172.16.2.0/24 to ANY"

Egy kis magyarázat hozzá:

• Az src-address, ipsec-policy, protocol=tcp és tcp-flags=syn együttes használatával kiszűrjük azokat a TCP SYN csomagokat, amik már átjöttek az alagúton. (Az src-address szűrőben az office router szabályánál ezért szerepel a branch oldal alhálózata.) Ez a szabály így azért jó, mert garantáltan csak azokra a TCP kapcsolatokra módosítja az MSS-t, amik már átjöttek az alagúton. (Azokra nem szeretnénk módosítani, ami nem megy át alagúton!)
• A tcp-mss=!0-1360 szabály szó szerint azt jelenti, hogy "a tcp mss értéke nem nulla és 1360 között van". Ez könnyebben értelmezhető formában annyit tesz, hogy nagyobb mint 1360.
• A passthrough=yes azért került oda, mert az MSS megváltoztatása után nem szeretnénk átugrani a többi mangle szabályt. (Bár a jelenlegi példában nincsen több mangle szabály, de ha lennének akkor valószínűleg nem akarnánk átugrani őket.)

 

Site-to-site VPN

Ebben a fejezetben bemutatom, hogyan lehet összekapcsolni két telephely lokális hálózatát egy biztonságos VPN kapcsolaton keresztül

A feladat

Ebben a példában egy olyan hálózatot veszünk alapul, ahol két külön site (telephely) van. Mindkettő külön internet kapcsolattal rendelkezik. Mindkét site egy MikroTik router-en keresztül kapcsolódik az internetre. Az a célunk, hogy a router-ek mögötti két LAN-t összekapcsoljuk egymással, a következő módon:

• A broadcast üzenetek ne menjenek át egyik LAN-ból a másikba.
• Az egyik LAN-ból elérhető legyen a másik, és fordítva.
• A két LAN egy olyan alagúton keresztül legyen összekötve, ami a lehető legnagyobb biztonságot nyújtja, lehetőleg hatékonyan (nagy sebességgel).

Ez a felállás gyakran előfordul például olyan cégeknél, amik több telephellyel rendelkeznek. Az egyik site lehet például a központi iroda, a másik egy raktár vagy egy gyár/üzem stb. Ez a modell később könnyen kiegészíthető három vagy még több site összekapcsolására.

Példa hálózat

A példa hálózatban a két site neve branch01 és office. Ezek egy vállalat két telephelyét jelképezik. Az office a központi iroda.

Internet kapcsolat

Az internetet egy olyan routerrel szimuláltam, ami különböző alhálózatokat ad az összes portjára. Az ether2 portjára 100.2.2.2/24, az ether3 portjára 100.3.3.3/24 az ether4 portjára 100.4.4.4/24 stb. Ezekre a portokra DHCP szervereket is beállítottam. (Az igazi internet felé az ether1-internet nevű porttal csatlakozik egy VMWare NAT adapterhez, ez az ábrán egy felhőként jelenik meg.) Ez a router úgy van beállítva, hogy az alhálózatok között korlátozás nélkül minden csomagot továbbít. Felfoghatjuk ezt a router-t úgy, mint az internet szolgáltató (ISP) távoli elérési pontja.

Tehát bármely hozzá csatlakozó eszköz másik címet kap, ráadásul másik alhálózatban. Ez nagyon hasonló ahhoz, mint amikor az egyes site-ok különböző ISP-n keresztül különböző címtartományban levő "nyilvános" címeket kapnak. Ezek "nyilvánosak" olyan értelemben, hogy az internetet reprezentáló router korlátozás nélkül továbbítja a csomagokat minden ilyen nyilvános cím között. Ez a felépítés azért is jó, mert így bármelyik "internet" felé menő illetve onnan érkező csomagot egyszerűen meg lehet vizsgálni (pl. wireshark-kal), ez könnyűvé teszi a tesztelést.

Az "internet router"-nek ez a kezdeti konfigurációja:

/interface ethernet
set [ find default-name=ether1 ] name=ether1-internet
/interface list
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=pool-2 ranges=100.2.2.100-100.2.2.200
add name=pool-3 ranges=100.3.3.100-100.3.3.200
add name=pool-4 ranges=100.4.4.100-100.4.4.200
add name=pool-5 ranges=100.5.5.100-100.5.5.200
/ip dhcp-server
add address-pool=pool-2 disabled=no interface=ether2 name=dhcp-eth2
add address-pool=pool-3 disabled=no interface=ether3 name=dhcp-eth3
add address-pool=pool-4 disabled=no interface=ether4 name=dhcp-eth4
add address-pool=pool-5 disabled=no interface=ether5 name=dhcp-eth5
/interface list member
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
/ip address
add address=100.2.2.2/24 interface=ether2 network=100.2.2.0
add address=100.3.3.3/24 interface=ether3 network=100.3.3.0
add address=100.4.4.4/24 interface=ether4 network=100.4.4.0
add address=100.5.5.5/24 interface=ether5 network=100.5.5.0
/ip dhcp-client
add disabled=no interface=ether1-internet
/ip dhcp-server network
add address=100.2.2.0/24 dns-server=100.2.2.2 gateway=100.2.2.2
add address=100.3.3.0/24 dns-server=100.3.3.3 gateway=100.3.3.3
add address=100.4.4.0/24 dns-server=100.4.4.4 gateway=100.4.4.4
add address=100.5.5.0/24 dns-server=100.5.5.5 gateway=100.5.5.5
/ip dns
set allow-remote-requests=yes servers=1.1.1.1,1.0.0.1
/ip firewall nat
add action=accept chain=srcnat disabled=yes out-interface-list=LAN
add action=masquerade chain=srcnat out-interface=ether1-internet
/system identity
set name=internet-routeros

Site-ok kezdeti állapota

A két darab site neve branch01 és office. Az első példában azt feltételezzük, hogy a site-ok tetején levő router-ek fix, statikus címeket kapnak. Egy későbbi példában be fogom mutatni azt is, hogy hogyan lehet ezt megoldani dinamikusan változó címek esetén.

Teszt branch01

A "nyilvános" címe az "internet" felé 100.2.2.10. A belső LAN hálózat címe 172.16.1.0/24, ezen belül a router címe 172.16.1.1.

A branch01 kezdeti konfigurációja a következő:

/interface bridge
add name=bridge-branch01
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=pool-branch ranges=172.16.1.100-172.16.1.200
/ip dhcp-server
add address-pool=pool-branch disabled=no interface=bridge-branch01 name=dhcp-branch01
/interface bridge port
add bridge=bridge-branch01 interface=ether2
add bridge=bridge-branch01 interface=ether3
/ip address
add address=172.16.1.1/24 interface=bridge-branch01 network=172.16.1.0
add address=100.2.2.10/24 interface=ether1 network=100.2.2.0
/ip dhcp-server network
add address=172.16.1.0/24 dns-server=172.16.1.1 gateway=172.16.1.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add distance=1 gateway=100.2.2.2
/system identity
set name=routeros-branch01

Fontos látni, hogy ez a teszt router a masquerade-on kívül semmiféle tűzfal szabályt nem tartalmaz. Ez a tesztelés alatt megfelelő. Éles környezetben be kell állítani tűzfal szabályokat. Egy példa beállítást a cikkben később közzéteszek.

A branch01 hálózaton belülre tettem egy Windows 10 és egy virtuális teszt PC gépet. Ezek címei:

• 172.16.1.200 a windows gépnek, dinamikus címmel
• 172.16.1.10 a virtual PC-nek, statikus címmel

Az alagutat elsősorban a virtual pc-vel teszteltem. Ennek oka, hogy egyszerre sok Windows 10 VM indítása annyira leterhelte a host gépet, hogy ez sok esetben csomagvesztéshez vezetett, és elérhetetlennek látszódtak olyan kapcsolatok, amik normál esetben működtek volna. A Windows 10 gépeket általában csak a router-ek konfigurálásának idejére kapcsoltam be.

Teszt office

Ez nagyon hasonló a branch01-hez, csak az alhálózatok címei térnek el:

A "nyilvános" címe az "internet" felé 100.3.3.10. A belső LAN hálózat címe 172.16.2.0/24, ezen belül a router címe 172.16.2.1.

Itt a teljes (kezdeti) konfigurációja, alig több mint 20 sor:

/interface bridge
add name=bridge-office
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=pool-office ranges=172.16.2.100-172.16.2.200
/ip dhcp-server
add address-pool=pool-office disabled=no interface=bridge-office name=dhcp-office
/interface bridge port
add bridge=bridge-office interface=ether2
add bridge=bridge-office interface=ether3
/ip address
add address=172.16.2.1/24 interface=bridge-office network=172.16.2.0
add address=100.3.3.10/24 interface=ether1 network=100.3.3.0
/ip dhcp-server network
add address=172.16.2.0/24 dns-server=172.16.2.1 gateway=172.16.2.1
/ip dns
set allow-remote-requests=yes servers=1.1.1.1
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1
/ip route
add distance=1 gateway=100.3.3.3
/system identity
set name=routeros-office

Az office hálózaton belülre is tettem egy Windows 10 és egy teszt PC gépet. Ezek címei:

• 172.16.2.199 a windows gépnek, dinamikus címmel
• 172.16.2.10 a virtual PC-nek, statikus címmel

 

Meglevő hálózat ellenőrzése

VPN kapcsolat kialakítása előtt feltétlenül teszteld le, hogy a kezdeti (VPN nélküli) állapotban minden gép lát minden másikat az alhálózatokon belül, plusz azt is hogy minden gép lát minden nyilvános címmel rendelkező gépet.

Ha ezeket a teszteket nem végzed el, akkor lehet hogy egy olyan környezetben kezded el kialakítani a VPN hálózatot, ahol az nem is lehetséges. Ez nagyon meg tudja nehezíteni a hibák lokalizálását és elhárítását.

branch01 -en belül tesztek

A kezdeti állapotban a branch01-en belül mindenki lát mindenkit. Az alábbi képen a PC1 gépről a következőket próbálom elérni:

• Saját LAN oldali router 172.16.1.1
• Saját branch01 router WAN publikus címe 100.2.2.10
• Az internetet szimuláló router-en több cím: 100.2.2.2, 100.3.3.3 és 100.4.4.4
• Az office router WAN publikus címe 100.3.3.10

Ezek ICMP ping tesztek. (Ha nem vagy benne biztos hogy mi az az ICMP, akkor olvasd el ezt.) Sok esetben a TCP illetve UDP kapcsolatokat korlátozzák az úton levő tűzfalak, miközben az ICMP csomagokat átengedik. Ha van rá lehetőséged, akkor végezd el ezeket a teszteket TCP és UDP protokollal is. Itt nem másolom be az összes tesztet, de a branch01 router-jéről is látni a Windows10-1 és PC1 gépeket, plusz a Windows10-1 gépről is látni a PC1 és branch01 router gépeket, ezen felül az "interneten" levő összes "nyilvános" címet is.

office -on belüli tesztek

Nem győzőm hangsúlyozni a tesztek fontosságát. Nagyon hasonlókat tesztelünk a PC2 gépről is:

• Saját LAN oldali router 172.16.2.1
• Saját branch01 router WAN publikus címe 100.3.3.10
• Az internetet szimuláló router-en több cím: 100.2.2.2, 100.3.3.3 és 100.4.4.4
• Az branch01 router WAN publikus címe 100.2.2.10

branch01 és office közötti tesztek

Ami nyilvánvalóan nem működik, az az office1 és a branch01 hálózat közötti kapcsolat. A branch01 router-je nem tud az office belső hálózatáról és fordítva. Az internetet jelképező router pedig nem tud egyik belső céges hálózatról se.

A hibát ("elérhetetlen hálózat") mindig az internetet jelképező router küldi vissza. Mivel a helyi (branch01 vagy office) router nem tudja hogy hol van a cél cím, ezért a default route (internet) felé továbbítja a csomagokat. Az internetet jelképező router se tudja hogy ezek hol vannak (privát LAN-ok belső címei), ezért visszaküldi hogy a célhálózat nem elérhető.

A VPN kapcsolat kialakításának pont ez az egyik célja. Azt szeretnénk elérni, hogy a két telephely gépei lássák egymást. A másik célja természetesen az, hogy ez a kapcsolat biztonságos legyen. Az interneten keresztül utazó adatokat ne tudja bárki megnézni, visszafejteni és bizalmas adatokhoz hozzájutni.

Site-to-site VPN beállítása (gyakorlat)

Előkészületek

NTP beállítása

Az IKE és az IPSEC protokoll nagyon érzékeny a rendszeridő beállításaira. Mielőtt hozzákezdenél a VPN beállításához, győződj meg róla, hogy a router-ek NTP kliense jól van beállítva, és pontos rajtuk a rendszeridő. A saját országodnak megfelelő nyilvános NTP szervereket például itt is megtalálhatod.

/system clock set time-zone-autodetect=yes time-zone-name=Europe/Budapest
/system ntp client set server-dns-name=0.hu.pool.ntp.org,1.hu.pool.ntp.org primary-ntp=[/resolve 2.hu.pool.ntp.org] secondary-ntp=[/resolve 3.hu.pool.ntp.org]

FQDN (teljes host nevek) beállítása

A továbbiakban sok kényelmetlenségtől megkímélheted magadat akkor, ha rendes host neveket hozol létre a peer-ekhez. Ennek különösen akkor lesz jelentősége, ha később nem csak site-to-site, hanem road warrior típusú VPN klienseket is támogatni szeretnél. Ebben a példában az office-hoz az office.myserver.hu, a branch01-hez a branch01.myserver.hu host neveket fogjuk használni.

Ezen felül elvégzünk pár beállítást amivel elérjük, hogy ez a két név a megfelelő IP címekre oldódjon föl.

Az "ISP" internet router-én adjuk meg az IP címeket a host nevekhez, statikus DNS bejegyzések formájában:

/ip dns static
add address=100.3.3.10 name=office.myserver.hu
add address=100.2.2.10 name=branch01.myserver.hu
# Ez már be volt állítva korábban, csak a teljesség kedvéért
/ip dns set allow-remote-requests=yes

Az office router-en beállítjuk az "ISP" által adott DNS szervert és a router teljes nevét.

/ip dns set servers=100.3.3.3
/system identity set name=office.myserver.hu

Ugyan ez a branch01 router-en:

/ip dns set servers=100.2.2.2
/system identity set name=branch01.myserver.hu

Mindkettőn teszteld le, hogy működik-e:

Tanúsítványok generálása

Ahogy korábban jeleztem, tanúsítványokat fogunk használni az azonosításra. Arra készülünk, hogy a fő irodához (office) tovább telephelyeket fogunk csatlakoztatni. Ezért az azonosításhoz szükséges tanúsítványokat és kulcsokat az office router-jén fogjuk előállítani.

Ennél sokkal egyszerűbb megoldás a szimmetrikus kulcsok (pre shared key) használata. Ha egyszerűsíteni szeretnéd a dolgokat, akkor ugorj a következő részre.

Három tanúsítványt fogunk előállítani:

• Certificate Authority
• Központi iroda (office)
• branch01

Főbb különbségek:

• A CA lejárati ideje nagyon hosszú. A key-usage részben jó sok dolog szerepel.
• A szervernél a key-usage részben tls-server szerepel.
• A kliensnél a key-usage részben tls-client szerepel.

Ha érdekel hogy ezek pontosan mit jelentenek, akkor az X.509 szabványt kell tanulmányoznod. Ennek bemutatása bőven túlmutat egy ilyen egyszerű iromány keretein.

CA tanúsítvány generálása

/certificate add name=ca.myserver.hu \
	country=HU state=Heves locality=Eger \
    organization=myserver.hu \
    common-name=ca.myserver.hu \
    subject-alt-name=DNS:ca.myserver.hu \
    key-size=4096 days-valid=3650 trusted=yes \
    key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign

Nagyon fontos, hogy a name, common-name és subject-alt-name ugyan azt a  nevet tartalmazza, és ez az egyértelműség kedvéért valami "ca." kezdetű legyen. Ennek nem feltétlenül kell létező fqdn-nek lenni, mert a CA cert-et megbízható CA cert-ként fogjuk importálni mindenhová.

Hozzárendelünk egy privát kulcsot, és aláírjuk saját magával. Ez elég sokáig eltarthat, számításigényes.

/certificate sign ca.myserver.hu

Végül exportáljuk egy állományba. Erre azért van szükség, hogy a másik peer-en importálni tudjuk.

/certificate export-certificate ca.myserver.hu

office peer kulcs és tanúsítvány generálása

/certificate add \
	name=office.myserver.hu \
    country=HU state=Heves locality=Eger \
    organization=myserver.hu \
    common-name=office.myserver.hu \
    subject-alt-name=DNS:office.myserver.hu \
    key-size=4096 days-valid=1095 \
    trusted=yes key-usage=tls-server

Nagyon fontos, hogy a name, common-name és subject-alt-name részben azonos fqdn-ek legyenek. És persze nem árt, ha ez egy valós létező fqdn.

Ezt is a CA-val írjuk alá. Eltarthat egy ideig...

/certificate sign office.myserver.hu ca=ca.myserver.hu

Ezt a tanúsítványt nem exportáljuk, mert már azon a router-en van, ahol szükség lesz rá.

branch01 peer kulcs és tanúsítvány generálása

/certificate add \
	name=branch01.myserver.hu \
    country=HU state=Heves locality=Eger \
    organization=myserver.hu \
    common-name=branch01.myserver.hu \
    subject-alt-name=DNS:branch01.myserver.hu \
    key-size=4096 days-valid=1095 trusted=yes key-usage=tls-client
    

Ezt is a CA-val írjuk alá:

/certificate sign branch01.myserver.hu ca=ca.myserver.hu

A branch01-nél szükséges exportálnunk a tanúsítványt a titkos kulccsal együtt. Erre majd a branch01 router-en lesz szükség.

/certificate export-certificate branch01.myserver.hu type=pkcs12 export-passphrase=abcd1234

Export állományok másolása branch01-re és importálása

A két exportált állományt át kell másolnod a branch01 router-re. A másolást én a példában úgy oldottam meg, hogy WinBox -szal csatlakoztam az office router-hez, és a files menüpont alól letöltöttem őket a saját gépemre. Ezután csatlakoztam a branch01 router-hez is, és ott feltöltöttem őket (szintén WinBox-szal).

Ezután a branch01 router-en így importáltam őket:

/certificate import file-name=cert_export_ca.myserver.hu.crt
/certificate import file-name=cert_export_branch01.myserver.hu.p12

Ezután még át kellett írni a neveiket, hogy ne "cert_export" nevűek legyenek. Ennek nincs túl nagy jelentősége. Amikor majd az azonosításhoz meg kell adnod őket, akkor "cert_export_branch01.myserver.hu.p12_0" helyett egyszerűen "branch01.myserver.hu" néven lehet rá hivatkozni. Valahogy így:

    [admin@branch01.myserver.hu] /certificate> print detail 
    Flags: K - private-key, L - crl, C - smart-card-key, A - authority, I - issued, R - revoked, E - expired, 
    T - trusted 
    0    A  T name="cert_export_ca.myserver.hu.crt_0" issuer=C=HU,ST=Heves,L=Eger,O=myserver.hu,CN=myserver.hu digest-algorithm=sha256 key-type=rsa country="HU" state="Heves" locality="Eger" organization="myserver.hu" common-name="myserver.hu" key-size=4096 subject-alt-name=DNS:ca.myserver.hu days-valid=3650 trusted=yes key-usage=digital-signature,key-encipherment,data-encipherment,key-cert-sign,crl-sign serial-number="4723FDDFBA4C0EE7" fingerprint="d478806e903a39ab9c247fee055913d7b359bf599519edc59ca32ebf10764b3d" invalid-before=dec/29/2020 20:12:56 invalid-after=dec/27/2030 20:12:56 expires-after=521w2d9h51m36s

    1 K     T name="cert_export_branch01.myserver.hu.p12_0" issuer=C=HU,ST=Heves,L=Eger,O=myserver.hu,CN=myserver.hu digest-algorithm=sha256 key-type=rsa country="HU" state="Heves" locality="Eger" organization="myserver.hu" common-name="branch01.myserver.hu" key-size=4096 subject-alt-name=DNS:branch01.myserver.hu days-valid=1095 trusted=yes key-usage=tls-client serial-number="6E4BF36124495358" fingerprint="623f9943980a8bd320d1b8c250d6061fb8fee8de0c6d924144e5df6f4e1398b4" invalid-before=dec/29/2020 20:18:21 invalid-after=dec/29/2023 20:18:21 expires-after=156w2d9h57m1s
    
    [admin@branch01.myserver.hu] /certificate> set 0 name="ca.myserver.hu"
    [admin@branch01.myserver.hu] /certificate> set 1 name="branch01.myserver.hu"

Végül töröltem őket a branch01 router-ről és az office routerről is:

/file remove [find where name=cert_export_ca.myserver.hu.crt]
/file remove [find where name=cert_export_branch01.myserver.hu.p12]

Ezen felül a saját gépemről is.

Figyelem! A fentieket csak a példa kedvéért csináltam ennyire egyszerű módon. A valóságban sokkal erősebb jelszót kellene használnod, és biztonságos módon megoldani az export állományok átmásolását. Sőt ha nagyon szigorúak akarunk lenni, akkor a branch01 privát kulcsát a branch01 router-en kellene előállítanod, és onnan soha nem szabadna kikerülnie. A példa kedvéért (és általános felhasználásra) a fent leírt módszer, a megfelelő elővigyázatosság mellett megfelelő lehet.

Phase 1 proposal beállítás (ipsec profile)

Ezt mindkét router-en meg kell tenni. A mi konkrét példánkban előre meghatároztuk azokat a konkrét algoritmusokat, amiket használni fogunk. Ezért itt nem fogunk algoritmus listákat megadni, csak konkrét algoritmusokat. Ezt azért tehetjük meg, mert előre ismerjük az összes peer minden képességét, és tudjuk hogy mit akarunk.

Az IKEv2 első fázisához tartozó algoritmusokat egy külön menüpontban, a /ip ipsec profile alatt kell fölvennünk. Ezt mindkét router-en megtesszük:

/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name="myserver.hu" nat-traversal=no proposal-check=strict

Természetesen, ha a Te esetedben valamelyik peer egy NAT-olt hálózaton van, akkor állítsd be a nat-traversal=yes attribútumot. A mi példánkban erre nincs szükség.

Érdekes az elnevezés. Bár ez is egy proposal, de ennek profile a neve. Ennek megvan a maga magyarázata. Elméletileg minden egyes peer -hez külön algoritmus beállításokat lehet megadni. A gyakorlatban azonban ez egyáltalán nem jellemző. A gyakorlatban az összes lehetséges peer-re, vagy legalábbis a peer-ek nagy számosságú csoportjaira azonos algoritmusokat szoktunk használni. Emiatt az algoritmusok beállítása egy külön ipsec profile entitásba került, és névvel van ellátva. A peer-ek létrehozásakor nem a konkrét algoritmus neveket adjuk meg, hanem csak hivatkozunk arra a profile-ra ami meghatározza az algoritmusokat. Ez egyébként azért is jó, mert a profile módosításával egy lépésben át lehet konfigurálni az összes peer-t, ami hozzá van rendelve.

Természetesen nincs annak semmi akadálya, hogy minden egyes peer-hez egy külön profile-t hozz létre, és így peer-enként egyedileg tudd beállítani az algoritmusokat. De ez általában kontraproduktív. A mi konkrét példánkban egyetlen egy peer lesz, de mivel RouterOS-ben a konfigurációnak ilyen a szerkezete, ezért ehhez kell igazodnunk.

A proposal-check=strict beállítással azt írjuk elő, hogy a második fázisban létrehozott SA-k milyen maximális életkorral rendelkezhetnek. (Az első fázisban az életkort is egyeztetjük.) A strict beállítás szigorú, a responder csak akkor fogadja el az initiator által kínált max. életkort, ha az nem nagyobb, mint ami a responder oldalon alapértelmezésként meg van adva.

Phase 2 proposal beállítás (Ipsec proposal)

A második fázishoz külön be kell állítanunk a lehetséges algoritmusokat (amiket korábban tárgyaltunk). Ez RouterOS-ben az /ip ipsec proposal menüpont alatt található.

Ezt mindkét router-en futtatni kell:

/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048 name="proposal-myserver.hu" lifetime=30m

Az alapértelmezett lejárati idő 30 perc, ezt az igényeknek megfelelően módosítani lehet.

Peer-ek létrehozása

Először a teljes verziót írom le, amikor mindkét oldalon mindkét címet megadod.

Az office router-en:

/ip ipsec peer
add exchange-mode=ike2 address=100.2.2.10/32 local-address=100.3.3.10 name="peer-branch01" passive=yes send-initial-contact=yes profile="myserver.hu"

A branch01 router-en:

/ip ipsec peer
add exchange-mode=ike2 address=100.3.3.10/32 local-address=100.2.2.10 name="peer-office" passive=no send-initial-contact=yes profile="myserver.hu"

Egyszerűsített verzió

A responder oldalon (passive=yes) nem szükséges megadni az address paramétert. Ha ezt elhagyod, akkor az 0.0.0.0/0 -nak felel meg. A responder oldalon a peer address paramétere arra való, hogy ezen keresztül korlátozni és/vagy azonosítani tudjuk az initiator-okat az IP címük alapján. Azoknál a konfigurációknál, ahol nem ismered előre az initiator IP címét, az address paramétert elhagyhatod. Ezen felül a local-address -t se kötelező megadni. De ha ez nincs megadva, akkor az adott peer minden interface-en és minden címen keresztül használható lesz. A responder oldalon az address paraméter kizárólag ip cím prefix lehet. (Konkrét IP cím /32 prefixnek felel meg.) A responder oldalon általában nem szükséges minden klienshez külön peer-t létrehozni.

Az initiator oldalon (passive=no) az address paramétert minden esetben kötelező megadni. Ez mondja meg, hogy hol van a responder, amivel föl kell venni a kapcsolatot. Az initator oldalon az address paraméter értéke nem csak IP cím lehet, hanem fqdn is.  Ha a kapcsolat megszakad, akkor az újrakapcsolódás előtt a RouterOS resolve-ozza az ott megadott host nevet. (A helyi DNS cache TTL figyelmen kívül hagyásával.) Ez lehetőséget ad arra, hogy olyan VPN szerverrel alakíts ki kapcsolatot, aminek a címe dinamikusan változik.

A problémák akkor jelentkeznek, amikor különböző phase1 proposal-t (/ip ipsec profile) szeretnél megadni a különböző peer-ekhez a responder oldalon. Ilyenkor muszáj megadnod az address paramétert. (Mert ha azt nem adod meg, akkor a RouterOS számára az első illeszkedő peer-t fogja felhasználni, a többi elérhetetlen lesz.) Ez a probléma csak akkor fordulhat elő, ha a responder oldalon több peer is van. Erről a problémáról egy későbbi fejezetben lesz szó. ( Lásd még: https://forum.mikrotik.com/viewtopic.php?f=2&t=172945&p=845929#p845929 )

Érdekességek:

• A local-address azt a címet adja meg, amelyiken az IKE démon várja a bejövő kapcsolatokat. (Ezt nem kötelező megadni, ha nem adod meg, akkor a peer bármely címre beérkező kulcs-csere kéréshez használható.)
• A passive azt jelenti, hogy az IKE démon másik oldalon levő peer-re vár a kapcsolat felépüléséhez. Ha a passzív mód ki van kapcsolva, akkor a peer megpróbálja automatikusan végrehajtani nem csak az első fázist, hanem a másodikat is (feltéve hogy az első fázis után vannak létrehozva a peer-nek megfelelő policy-k). RouterOS-ben mindkét oldal lehet initator és responder is.
• A send-initial-contact beállítás hatására a egy "initial contact" csomagot küld a peer-nek. Ennek hatására a (távoli) peer kitörli az összes korábban létrehozott SA-t, ami a helyi peer forráscíméhez tartozik.

Bővebb leírás itt: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Peers

Identity hozzáadása

Ahogy korábban írtuk, ez szolgál a peer-ek kölcsönös azonosítására. Az azonosítást a korábban létrehozott kulcsokkal és tanúsítványokkal valósítjuk meg.

x509 tanúsítvány alapú identity hozzáadása

Az office router-en:

/ip ipsec identity
add auth-method=digital-signature certificate=office.myserver.hu match-by=certificate my-id=fqdn:office.myserver.hu peer=peer-branch01 remote-certificate=branch01.myserver.hu remote-id=fqdn:branch01.myserver.hu

A branch01 router-en:

/ip ipsec identity
add auth-method=digital-signature certificate=branch01.myserver.hu mode-config=modeconf-branch01 my-id=fqdn:branch01.myserver.hu peer=peer-office remote-id=fqdn:office.myserver.hu

Egy kis magyarázat hozzá:

• Az office router esetében megvan mindkét certificate. Az office.myserver.hu és a branch01.myserver.hu nevű is. Mivel a branch01 tanúsítványait a jövőben is az office router-en kívánjuk kiállítani, ezért ez a jövőben is mindig rendelkezésre fog állni. Emiatt az azonosításnál a match-by=certificate értéket adtuk meg. Ez azt jelenti, hogy az azonosítást a teljes certificate pontos egyezése alapján végzi el. Ha ezt megadod, akkor persze kötelező megadni a remote-certificate értékét is (tudnia kell, hogy a távoli peer tanúsítványát mivel hasonlítsa össze).
• A branch01 router esetében nem rendelkezünk az office tanúsítványával. Bár elméletileg ezt az office routeren kiexportálhattuk volna (privát kulcs nélkül!), és a branch01 router-en importálhattuk volna. Ebben az esetben ott is használhatnánk a match-by=certificate beállítást. De ha így tennénk, akkor ez azt jelentené, hogy minden alkalommal amikor az office gép tanúsítványa lejár, azt újra kellene exportálni és újra föl kellene másolni a branch01 routerre is. Ez ebben a példában nem tűnik problémásnak. De képzeljük el azt a helyzetet, amikor az office router-hez már 20 különböző branch-et csatlakoztattunk. Könnyen abban a helyzetben találhatjuk magunkat, hogy a VPN responder tanúsítványának megújítása után 20 különböző gépre kell fölmásolni és beállítani az új tanúsítványt. Ez elég kényelmetlen lenne. Ehelyett használhatjuk a match-by=remote-id és a remote-id=fqdn: beállítást. Ez a beállítás a következőt teszi:
  • Először természetesen (mint mindig) ellenőrzi a távoli peer tanúsítványának digitális aláírását és lejárati idejét. Itt használjuk ki a PKI nyújtotta előnyt: ellenőrizni tudjuk a távoli peer megbízhatóságát egy harmadik fél (a CA) segítségével. (Bár a mi példánkban a CA -t is mi valósítjuk meg, de a CA cert lejárata 10 év.)
  • Ha ezt rendben találja, akkor a common-name mezőjében megkeresi, hogy milyen fqdn-re szól a tanúsítvány
  • Ezt hasonlítja össze a remote-id:fqdn: mezőben megadott fqdn értékkel.

Az egyeztetést sok más módon el lehet végezni. Ezeket nem sorolom föl itt, mert a mi példánkhoz nem szükségesek, és tényleg nagyon sok lehetőség van. Bővebb leírást itt találsz: https://wiki.mikrotik.com/wiki/Manual:IP/IPsec#Identities

Előre megosztott kulcs alapú identity hozzáadása

office oldalon:

/ip ipsec identity
add auth-method=pre-shared-key secret="****your_shared_key******" my-id=fqdn:office.myserver.hu remote-id=fqdn:branch01.myserver.hu peer=peer-branch01

branch01 oldalon:

/ip ipsec identity
add auth-method=pre-shared-key secret="****your_shared_key******" my-id=fqdn:branch01.myserver.hu remote-id=fqdn:office.myserver.hu peer=peer-office

IKE működésének ellenőrzése (első fázis)

Ezen a ponton a két router IKE démonjainak tudni kell azonosítani egymást, és SA-kat készíteni.

Ha megnézed a naplót (/log print) akkor az office oldalon valami ilyesmit kell látnod:

10:58:30 ipsec,info new ike2 SA (R): 100.3.3.10[4500]-100.2.2.10[4500] spi:7d0560af36a26da3:4caa053a4ee2453e 
10:58:30 ipsec,info,account peer authorized: 100.3.3.10[4500]-100.2.2.10[4500] spi:7d0560af36a26da3:4caa053a4ee2453e 
10:58:30 ipsec,error no policy found/generated 

A branch01 oldalon pedig ilyet:

10:58:31 ipsec,info new ike2 SA (I): 100.2.2.10[4500]-100.3.3.10[4500] spi:4caa053a4ee2453e:7d0560af36a26da3 
10:58:31 ipsec,info,account peer authorized: 10.2.2.10[4500]-100.3.3.10[4500] spi:4caa053a4ee2453e:7d0560af36a26da3

Ha nem ezt látod, akkor ne menj tovább. Nincs értelme további dolgokat beállítani addig, amíg ez nem működik.

Policy-k létrehozása manuálisan

A responder oldalon a napló utolsó sorában látható egy hibaüzenet: no policy found/generated. Ez azért számít hibának, mert policy megadása nélkül az IKE démon csak az első fázist tudja befejezni. A második fázishoz azért szükséges a policy-k megadása, mert az IKE démon minden policy-hoz külön SA-t generál. Mivel mi az identity -nél mindkét router-nél a generate-policy=no beállítást adtuk meg, ezért a rendszer nem generál dinamikusan policy-ket. Helyette csak azokat tudja használni, amiket előre (kézzel) fölvettünk. De mivel ilyeneket még nem vettünk föl, ezért nincsen egyetlen egy policy se, amihez a második fázis lefuttatásával SA-t tudna generálni. Így tehát egyetlen egy SA se jön létre. Ez pedig nyilvánvalóan hiba (hiszen SA-k hiányában semmiféle IPSEC kommunikáció nem lehetséges).

Az office oldalon a következő policy-t vesszük föl:

/ip ipsec policy
add dst-address=172.16.1.0/24 peer=peer-branch01 proposal=proposal-myserver.hu src-address=172.16.2.0/24 tunnel=yes

A branch01 oldalon ennek a párját:

/ip ipsec policy
add dst-address=172.16.2.0/24 peer=peer-office proposal=proposal-myserver.hu src-address=172.16.1.0/24

Egy kis magyarázat a beállításokhoz:

• Az src-address és a dst-address mondja meg azt, hogy milyen csomagokat szeretnénk enkapszulálni. Ez az eredeti csomag forrás- és célcímére vonatkozó feltétel. Itt nem csak konkrét címeket, hanem címtartományokat is meg lehet adni.
• Lehetne megadni feltételt src-port és dst-port -ra is, illetve protocol-ra (tcp, udp) is. Ezt mi most nem tesszük meg, mert a két telephely közötti kapcsolatot nem szeretnénk korlátozni. De jó ha tudod: a megfelelő policy-k és feltételek megadásával el tudod érni például azt, a titkosítást szelektíven, csak bizonyos szolgáltatásokhoz tartozó adatforgalomra korlátozd.
• A peer mondja meg, hogy melyik peer felé kell küldeni az enkapszuláció után létrejött új IPSEC csomagot.
• A tunnel=yes beállítással írjuk elő az alagút módot.

Ha beírod hogy /ip ipsec policy export akkor azt fogod látni, hogy az exportba beleírja az sa-src-address és sa-dst-address attribútomokat is.

Ezek valójában ready-only attribútumok, és a policy-hez rendelt peer alapján automatikusan vannak meghatározva. Az egy RouterOS bug, hogy ezt is beleteszi az exportba. Amikor a policy-k módosításán dolgozol, akkor ez ne tévesszen meg.

IKE működésének ellenőrzése (második fázis)

A fenti két policy létrehozása után ezeknél a policy-knél meg kell hogy jelenjen az A flag, ami azt jelzi hogy aktív.

Az office router-en:

[admin@office.myserver.hu] /ip ipsec policy> print detail 
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes 

1  A  peer=peer-branch01 tunnel=yes src-address=172.16.2.0/24 src-port=any dst-address=172.16.1.0/24 dst-port=any protocol=all        action=encrypt level=require ipsec-protocols=esp sa-src-address=10.3.3.10 sa-dst-address=10.2.2.10        proposal=proposal-myserver.hu ph2-count=1 
[admin@office.myserver.hu] /ip ipsec policy> 

A branch01 router-en:

[admin@branch01.myserver.hu] /ip ipsec policy> print detail 
Flags: T - template, X - disabled, D - dynamic, I - invalid, A - active, * - default 
0 T * group=default src-address=::/0 dst-address=::/0 protocol=all proposal=default template=yes 

1  A  peer=peer-office tunnel=yes src-address=172.16.1.0/24 src-port=any dst-address=172.16.2.0/24 dst-port=any        protocol=all action=encrypt level=require ipsec-protocols=esp sa-src-address=10.2.2.10        sa-dst-address=10.3.3.10 proposal=proposal-myserver.hu ph2-count=1 
[admin@branch01.myserver.hu] /ip ipsec policy> 

A default nevű nullás policy template mindkét oldalon megjelenik, ezzel most nem kell foglalkozni.

Ezen felül, a /ip ipsec installed-sa menüpont alatt meg tudod nézni az IKE második fázisában generált SA-kat. Ez az office router-en például valahogy így néz ki:

[admin@office.myserver.hu] /ip ipsec installed-sa> print 
Flags: H - hw-aead, A - AH, E - ESP 
0  E spi=0x798ACAD src-address=100.2.2.10 dst-address=100.3.3.10 state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc         enc-key-size=256 auth-key="c2c879d6e7db7221df2ddb3e14b139e7a614ea54a85cabbe672cc0f8a6942d67"         enc-key="3f87e644e9d5085bb2f19c55cb111f4662ab4140187d898d6eddedd5989211b6" add-lifetime=24m6s/30m8s replay=128 

1  E spi=0x40A1E9 src-address=100.3.3.10 dst-address=100.2.2.10 state=mature auth-algorithm=sha256 enc-algorithm=aes-cbc         enc-key-size=256 auth-key="72819bd20e06f814859e44bd35e47b848e05c9230ca0d0006e56962bf89e71e5"         enc-key="6900d551d05d522263402c7231e7de154c3c08d58bca850d9aa31f75cbf5f333" add-lifetime=24m6s/30m8s replay=128 
[admin@office.myserver.hu] /ip ipsec installed-sa> 

Itt látható, hogy a két peer között két SA jött létre (a küldésre és a fogadásra). Ezen felül látszódnak a választott algoritmusok, a titkosító kulcsok, és az életkor.

Ha megfelelő hardvert és megfelelő algoritmus beállításokat használtál, akkor itt az E betű mellett megjelenik egy H betű is. Ez jelzi azt, hogy az SA-hoz elérhető a hardveres gyorsítás. A mi példánkban ez azért nincs kiírva, mert a teszt során egy virtuális gépen futtattam egy demo router-t, és abban nincsen ilyen támogatás.

Hiányzó NAT bypass szabályok

Ha ezek után megpróbáljuk mondjuk az office telephelyen levő PC2 gépről elérni a branch01 gépen levő PC1 gépet, akkor a következőt fogjuk látni:

Ez elsőre érthetetlennek tűnhet. Az az ICMP csomag ami a 172.16.2.10 gépről indult el a 172.16.1.10 irányába, elvileg illeszkedik az általunk létrehozott policy-ra, és becsomagolás után az alagúton kellene hogy átmenjen. De láthatóan nem ez történik. Helyette az office router ezt a csomagot továbbküldte az "internet" irányába, és az "ISP" fő routere (10.3.3.3) azt a választ küldte rá, hogy ezt erre a privát címre ő nem tud útvonalat választani. Ha az ICMP hiba a 10.3.3.3 -tól jött vissza akkor a csomag egyértelműen kiment az internetre, méghozzá titkosítatlanul.

Mi történik itt? A magyarázathoz ismét a packet flow diagramhoz kell visszatérnünk.

Ahogy korábban írtuk, a csomagok enkapszulációja (a policy szabályok futtatása) az egyik legutolsó lépés. A switching és a routing jóval hamarabb fut le, mint az enkapszuláció. Az office router tűzfalában be volt állítva egy ilyen NAT szabály:

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-internet

Ez a címfordítás szükséges ahhoz, hogy az office és branch01-en belül található, privát címmel rendelkező gépek el tudják érni az interneten található nyilvános szolgáltatásokat. De mi történik akkor, amikor nem az internetet, hanem a másik privát LAN-on belül található címet akarjuk elérni? Az az ICMP ping csomag aminek a forráscíme 172.16.2.10 és a célcíme 172.16.1.10, illeszkedik erre a NAT szabályra. Ez azért van, mert az illeszkedés egyetlen feltétele az, hogy a kimenő interface az ether1-internet interface legyen.

Hogy pontosan miért illeszkedik, azt alább még bővebben kifejtem. A layer 3 routing akkor kezdődik el, amikor a csomag áthalad a fenti ábrán az I vagy K betűvel jelölt csomópontok valamelyikén. Ez belül így néz ki:

A layer 3 routing során a routing decision doboz az a művelet, ahol a router az útvonalválasztást elvégzi. Ezen a ponton már eldőlt hogy mi a csomag célcíme. Ekkor a RouterOS átnézi az éppen aktuális routing táblázatot. Választ egy route-ot, amin keresztül a célcím elérhető. Így dönti el, hogy a távozó csomag melyik interface-re lesz kiírva. A dst-nat feldolgozása a prerouting részben van. (Logikus, hogy a célcím módosítása megelőzi az útvonal választását.) Az src-nat (forrás cím módosítása) a postrouting-ban van. A fenti layer 3 routing diagramban szereplő alprocesszek részletesebb kibontása alább látható.

Az IPSec policy-k jóval az útvonalválasztás után futnak le. A mi példánkban a 172.16.1.0/24 célcímhez keresünk útvonalat. Az office router saját routing táblázatában a 172.16.1.0/24 alhálózathoz nincsen megadva külön route. A layer 3 routing szempontjából nézve az a megfelelő route amin keresztül ez a célcím elérhető, a default gateway. Ehhez az ether1-internet interface tartozik. Ez egy WAN interface! A masquerade NAT szabály pedig erre illeszkedik:

/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-internet

Mivel ez a NAT szabály illeszkedik, ezért a router lecseréli a forráscímét arra a címre, ami az ether1-internet interface-en van. Mire a csomag eléri az IPSEC policy-kat, addigra a forráscíme 10.3.3.10 lett. Erre nem illeszkedik egyik policy sem, ezért akadály nélkül távozik az ether1-internet interface-en. Beérkezik az ISP routeréhez, és ez egyből ICMP hibát küld vissza (nincs hozzá útvonal).

Ezt azért magyaráztam el ennyire részletesen, hogy belássuk: a probléma nem csak annyiból áll, hogy a csomag nem jut el a céljához. A csomag távozik az internet irányába, ráadásul titkosítatlanul! Ez TCP kapcsolatok esetén még talán nem túl nagy probléma, mert ott csak TCP SYN csomagok tudnak kimenni (a kapcsolat nem épül föl). De UDP csomagok esetében ez azt jelenti, hogy a rosszul beállított routing és NAT szabályok miatt pont az ellenkezőjét értük el annak, amit akartunk: önként küldjük a potenciálisan bizalmas adatokat a nagyközönség felé. Ahogy azt később látni fogjuk, ez a probléma fokozottan jelentkezhet azokban az esetekben, amikor a VPN (kliens) oldalon nem kézzel fölvett, statikus policy-kat használunk, hanem egy template-ből generáljuk őket. Ha egy hiba miatt a VPN kapcsolat nem épül föl, akkor a dinamikus policy-k nem jönnek létre, és ennek hatására az internet irányába titkosítatlan csomagok hagyhatják el a csomópontot. Ezt esetleg nehezebb lehet észrevenni, mert csak VPN kapcsolat hiba esetén jelenik meg.

Azt a jelenséget, melynek során a router a hiányzó vagy hibás beállításából fakadóan rossz helyre küldi a csomagokat, szokás úgy nevezni hogy package leaking.

Ezen problémák megszüntetéséhez két dolgot kell tennünk.

NAT bypass

Az egyik megoldás az, hogy úgy módosítjuk az src-nat szabályokat, hogy ezeknek a csomagoknak a forrás címét nem írjuk át. Ezt persze mindkét telephelyen meg kell tenni ahhoz, hogy oda- és vissza is illeszkedjenek az ipsec policy-k.

Például az office route-en ezt megtehetjük így:

/ip firewall nat
add chain=srcnat src-address=172.16.2.0/24 dst-address=172.16.1.0/24 action=accept place-before=0

Ennek az eredménye egy ilyen NAT táblázat:

[admin@office.myserver.hu] /ip firewall nat> print detail 
Flags: X - disabled, I - invalid, D - dynamic 
 0    chain=srcnat action=accept src-address=172.16.2.0/24 dst-address=172.16.1.0/24 
 1    chain=srcnat action=masquerade out-interface=ether1-internet 

Azok a csomagok amikre később illeszkedik az ipsec policy, illeszkednek a legelső NAT szabályra is. Mivel ott action=accept van, ezért ezekre a csomagokra a NAT feldolgozás befejeződik, a második action=masquerade szabály sosem fut le rájuk.

Ha ezt így próbáljuk meg kezelni, akkor előre ismernünk kell, hogy milyen cél alhálózatok esetében nem akarunk masqurade/srcnat címfordítást végezni. (A mi site-to-site példánkban ez a helyzet.)

Ha sok ilyen cél alhálózat van, akkor az összes ilyen szabály felsorolása és a policy-kkal való szinkronban tartása fáradságos munka lehet, ráadásul könnyű hibázni. Ha az összes IPSEC policy-re illeszkedő csomagnál el akarjuk kerülni a címfordítást, akkor egyszerűbb ha egy plusz feltételt adunk hozzá, az alábbi módon:

[admin@branch01.myserver.hu] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade out-interface=ether1-internet log=yes
[admin@branch01.myserver.hu] /ip firewall nat> set 0 ipsec-policy=out,none
[admin@branch01.myserver.hu] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
0 chain=srcnat action=masquerade out-interface=ether1-internet log=yes ipsec-policy=out,none
[admin@branch01.myserver.hu]

Ez a plusz feltétel az ipsec-policy, ami mindig két, vesszővel elválasztott értéket tartalmaz: irány és policy.

Az irány (első) érték lehet in vagy out.  Az in érték csak a prerouting, input és forward chain-ekben használható. Az out érték csak a postrouting, output és forward chain-ekben használható. Azt már korábban bemutattam, hogy az srcnat chain a postrouting-ban van. Tehát kizárásos alapon itt az out -ot kell használnunk. (Az egyedüli chain ahol az in és az out érték is használható, az a forward chain.)

A policy (második) érték lehet ipsec vagy none. Az ipsec érték azt jelenti, hogy a van olyan ipsec policy, ami illeszkedik a csomagra, ezért ez alapján a csomaggal később ipsec műveletet (enkapszuláció vagy dekapszuláció) kell végezni. A none pedig ennek az ellenkezőjét jelenti: nincs olyan ipsec policy, ami illeszkedik a csomagra.

Tehát az ipsec-policy=out,none feltétel hozzáadásával azt írjuk elő, hogy az action=masquerade művelet csak azokra a csomagokra fusson le, amikhez nincsen megfelelő ipsec policy.

Ha ezek után megpróbáljuk az egyik alhálózatban levő gépről elérni a másik alhálózatban levő gépet akkor azt látjuk, hogy a VPN alagút működik, és a két alhálózat gépei látják egymást.

Ezzel azonban csak a probléma egyik felét oldottuk meg. Egyrészt elképzelhető, hogy a VPN peer vagy policy kikapcsolása/törlése után titkosítatlan csomagok szöknek ki az internetre. Másrészt ha megpróbáljuk magáról a router-ről elérni a távoli telephely egy gépét, akkor azt fogjuk látni, hogy ez nem működik:

Ennek a magyarázata az következő. Az egyetlen olyan route, ami alapján a 172.16.2.0/24 célhálózat elérhető, a default route (ISP-n keresztül). Ne feledjük: az ipsec policy egy külön réteg. Van policy-nk a a 172.16.2.0/24 célhálózathoz, de route-unk nincsen! A RouterOS ping parancsa ezért olyan ICMP csomagokat hoz létre, aminek a forráscíme megegyezik a default route-hoz tartozó címmel. Tehát a ping csomagok forráscíme a 10.2.2.10 cím lesz, és nem a 172.16.1.1 cím.

Ez a probléma akkor is megjelenik, amikor traceroute-ot akarsz futtatni a telephelyek közötti, alagúton keresztül haladó útvonalra:

A második hop címe azért nem látszódik, mert a VPN alagúton való átjutáshoz az enkapszuláció után a RouterOS egy "logical out-interface" nevű logikai (belső) interface-t használ. Ez látszódik a packet flow ábrán is. Ez a belső interface nem érhető el a RouterOS /interface menüjéből. Nincsen neve és nincsen címe sem. Bár az igaz, hogy amikor ezt az interface-t eléri az ICMP ping csomag, akkor csökkentjük a TTL értékét, és ha nullára csökkent akkor eldobjuk a csomagot. Azonban a RouterOS nem küld vissza "ICMP Time Exceeded" üzenetet, mivel ehhez szükség lennne a forráscím megadására. Tehát a VPN alagúton való áthaladás csökkenti a TTL értékét, de az ICMP alapú traceroute-ban nem látszódik ennek az állomásnak a címe, mert az a belső interface ami a TTL-t csökkenti az alagúton való áthaladáskor, nem rendelkezik olyan forrás címmel, amit föl lehetne használni az ICMP válasz visszaküldésére.

A traceroute-ban így csak annyit látunk, hogy interneten való (potenciálisan sok router-en keresztüli) áthaladás helyett az alagút egyetlen (ismeretlen című) hop-ként látszódik.

Csomag szökések megakadályozása

A fenti példák szemléltetik, hogy szükséges megakadályozni a privát hálózati címekhez tartozó csomagok "szökését" az internet felé. Ezt több lépésbben tesszük meg.

Az első lépésben explicit "elérhetetlen" route-okat hozunk létre az összes privát címtartományhoz.

/ip route
add comment="Prevent package leak RFC1918 class A" distance=1 dst-address=10.0.0.0/8 type=unreachable
add comment="Prevent package leak RFC1918 class B" distance=1 dst-address=172.16.0.0/12 type=unreachable
add comment="Prevent package leak RFC1918 class C" distance=1 dst-address=192.168.0.0/16 type=unreachable

Ez biztosan megakadályozza a csomagok megszökését, mert ezek a route-ok mindig specifikusabbak, mint a 0.0.0.0/0 default route. De az IPSEC szempontjából ez problémás. Ahhoz, hogy az ipsec policy működőképes maradjon, szükség van valamilyen aktív, elérhető route-ra a cél címek irányában.

Az office router-en ezt így adjuk hozzá:

/interface bridge
add name=ipsec protocol-mode=none
/ip route
add dst-address=172.16.1.0/24 gateway=ipsec pref-src=172.16.2.1 comment="VPN to branch01"

A branch01 router-en pedig így:

/interface bridge
add name=ipsec protocol-mode=none
/ip route
add dst-address=172.16.2.0/24 gateway=ipsec pref-src=172.16.1.1 comment="VPN to office"

A pref-src megadása miatt az összes router-ről a távoli privát hálózatba indított forgalom (például ping) automatikusan az ott megadott címet fogja használni. Ezen felül, a pref-src hatására a traceroute is elkezd "jól" működni:

Amikor a TTL értéket nullára csökkenti a távoli router, akkor képes lesz visszaküldeni ICMP "time exceeded" üzenetet, mert a pref-src beállítás alapján képes lesz forráscímet meghatározni az ICMP válaszhoz.

Ha teljesen perfekcionista akarsz lenni, akkor még ezt a tűzfal szabályt is hozzáadhatod a megfelelő pozícióba:

/ip firewall filter
add action=reject chain=forward out-interface=ipsec reject-with=icmp-network-unreachable comment="Reply with network-unreachable when IPSEC tunnel is down"

Ha valami miatt a VPN nem működik (pl. letiltottad a policy-t), akkor a router az alapértelmezett "host is unreachable" helyett egy kicsit korrektebb "network is unreachable" ICMP választ küld majd vissza.

MTU, TCP MSS Clamping

Az elméleti fejezetben már részletesen beszámoltam arról, hogy mi az az MTU, és mi az a TCP MSS Clamping. Most csak a gyakorlati beállítást mutatom be. Egy olyan szabályt veszünk föl, ami képes lecsökkenteni a TCP SYN csomagok 1360 byte-nál nagyobb MSS értékét 1360-ra. Nagyon fontos hogy olyan szabályt vegyünk föl, ami nem képes növelni az MSS értékét. Ha a csomag már eleve 1360 -nál kisebb MSS értékkel érkezik be, és ezt felülírjuk 1360-ra, akkor ezzel megnöveljük azt, és így végül pont az ellenkezőjét érjük el annak, mint amit szeretnénk (növeljük a fragmentációt ahelyett hogy csökkentenénk).

A megfelelő szabály az office gépen így néz ki:

/ip firewall mangle add action=change-mss chain=forward new-mss=1360 src-address=172.16.1.0/24 protocol=tcp tcp-flags=syn tcp-mss=!0-1360 ipsec-policy=in,ipsec passthrough=yes comment="IKE2: Clamp TCP MSS from 172.16.1.0/24 to ANY"

A branch01 gépen pedig így:

/ip firewall mangle add action=change-mss chain=forward new-mss=1360 src-address=172.16.2.0/24 protocol=tcp tcp-flags=syn tcp-mss=!0-1360 ipsec-policy=in,ipsec passthrough=yes comment="IKE2: Clamp TCP MSS from 172.16.2.0/24 to ANY"

Egy kis magyarázat hozzá:

• Az src-address, ipsec-policy, protocol=tcp és tcp-flags=syn együttes használatával kiszűrjük azokat a TCP SYN csomagokat, amik már átjöttek az alagúton. (Az src-address szűrőben az office router szabályánál ezért szerepel a branch oldal alhálózata.) Ez a szabály így azért jó, mert garantáltan csak azokra a TCP kapcsolatokra módosítja az MSS-t, amik már átjöttek az alagúton. (Azokra nem szeretnénk módosítani, ami nem megy át alagúton!)
• A tcp-mss=!0-1360 szabály szó szerint azt jelenti, hogy "a tcp mss értéke nem nulla és 1360 között van". Ez könnyebben értelmezhető formában annyit tesz, hogy nagyobb mint 1360.
• A passthrough=yes azért került oda, mert az MSS megváltoztatása után nem szeretnénk átugrani a többi mangle szabályt. (Bár a jelenlegi példában nincsen több mangle szabály, de ha lennének akkor valószínűleg nem akarnánk átugrani őket.)

 

Tűzfal beállítások

Szeretném fölhívni a figyelmet arra, hogy a korábbi szakaszokban leírt példa hálózatban az office és branch01 router-ek semmiféle tűzfal szabályt nem tartalmaznak az internet felől érkező támadások kivédésére. Ha például egy támadó képes IP Spoofing felhasználásával kívülről az internet irányából küldeni olyan csomagokat, amiknek a forrás- és célcíme az office illetve branch01 címtartományában van, akkor azzal rá tudja venni a router-eket, hogy ezeket a csomagokat is enkapszulálják, titkosítsák és küldjék át az alagúton. Mivel a támadó ismeri az eredeti (később enkapszulált) csomagok tartalmát, ezért az adatforgalom megfigyelésével lehetősége van egy olyan támadás végrehajtására, ahol tetszőleges titkosítatlan adathoz meg tudja határozni a titkosított párját. Ez az úgynevezett Known-Plaintext attack, ami nagyságrendekkel egyszerűbben visszafejthetővé teszi a kulcsokat, ezáltal magas biztonsági kockázatot jelent.

Alább leírok egy minimális konfigurációt ami megmutatja, hogy a példában leírt site-to-site kapcsolatnál milyen szabályokat kell hozzáadni ahhoz, hogy a VPN alagút védett és működőképes legyen.

Az alábbiakat semmiképp ne alkalmazd vakon! A Te konkrét feladatodnak megfelelően kell módosítani ezeket a szabályokat. Szinte biztos, hogy Te konkrét esetedben ez a minta változtatás nélkül nem alkalmazható. Figyelmeztetve lettél.

Először listába szervezzük a WAN és LAN interface-eket. Midkét router-en az ether1 interface kapcsolódik az ISP-hez. Ezt hangsúlyozandó, átnevezzük ether1-internet -re:

/interface
set name=ether1-internet [find name=ether1]
/interface list
add name=LAN
add name=WAN
/interface list member
add list=WAN interface=ether1-internet
add list=LAN interface=ether2
add list=LAN interface=ether3
add list=LAN interface=ether4
add list=LAN interface=ether5

Az office router-en ezen felül a következőket állítjuk be:

/ip firewall filter

add action=accept chain=input comment="Allow UPD 500,4500 for IKEv2" dst-address=100.3.3.10 dst-port=500,4500 in-interface=ether1-internet protocol=udp
add action=accept chain=input comment="Allow IPSEC/ESP" dst-address=100.3.3.10 in-interface=ether1-internet protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

add action=accept chain=forward ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=forward in-interface-list=LAN src-address=172.16.2.0/24
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-internet

A branch01 oldalon ennek teljesen a tükörképe van. Csak a WAN cím módosul, és a privát alhálózatok címe cserélődik föl:

/ip firewall filter

add action=accept chain=input comment="Allow UPD 500,4500 for IKEv2" dst-address=100.2.2.10 dst-port=500,4500 in-interface=ether1-internet protocol=udp
add action=accept chain=input comment="Allow IPSEC/ESP" dst-address=100.2.2.10 in-interface=ether1-internet protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN

add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=accept chain=forward in-interface-list=LAN src-address=172.16.1.0/24
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
/ip firewall nat
add action=masquerade chain=srcnat out-interface=ether1-internet

A beállítások után ne felejts el újra tesztelni! Nézd meg, hogy az egyes alhálózaton levő gépekből ki mit lát: azonos alhálózatban, másik alhálózatban, interneten stb.

Néhány érdekesség:

• Rögtön az input chain legelején engedélyezzük a bejövő csomagokat az UDP/500 és UDP/4500 portokon. Ez szükséges ahhoz, hogy az IKE démonok végre tudják hajtani az első és második fázist. Ezen keresztül azért nehéz támadást véghezvinni, mert az azonosításhoz szükség van a tanúsítványokra.
• Az input és forward chain-ek legelején elfogadjuk az összes, internet irányából érkező ipsec-esp csomagot. Ez azért nem jelent biztonsági kockázatot, mert ezeknek a csomagoknak a kicsomagolása közben az érvénytelen ellenőrző összeggel rendelkező csomagok automatikusan eldobásra kerülnek.
• Ami ezután van az csak a szokásos: engedjük az ICMP-t, eldobjuk az érvénytelen csomagokat, eldobunk minden más bejövőt ami nem a LAN irányából érkezik, eldobunk minden továbbítandó csomagot (kivéve a port forward-hoz használt dsnat-on átesetteket) stb. Igazából a maradék szabályok kb. ugyan azok, mint amiket egy alapértelmezett RouterOS konfiguráció reset után megtalálsz bármelyik MikroTik eszközben.

 

Összefoglaló

Zanzásított verzió

A konkrét IP címek és hálózat címek helyett olyanokat írok mint "local.sub.net" vagy "remote.public.ip". Ahol a két oldal konfigurációja azonos vagy nagyon hasonló, ott csak az egyik oldalt írom ki.

; 1. NTP beállítása
/system clock set time-zone-autodetect=yes time-zone-name=Europe/Budapest
/system ntp client set \
    server-dns-name=0.hu.pool.ntp.org,1.hu.pool.ntp.org \
    primary-ntp=[/resolve 2.hu.pool.ntp.org] \
    secondary-ntp=[/resolve 3.hu.pool.ntp.org]
    
; 2. FQDN beállítása - készíts DNS neveket a router-jeidhez
; ...

; 3. Tanúsítványok generálása és aláírása
; /certificate add name=ca.myserver.hu ... key-usage=digital-signature,....
; /certificate add name=office.myserver.hu ... key-usage=tls-server
; /certificate add name=branch01.myserver.hu ... key-usage=tls-server
; /certificate sign ca.myserver.hu
; /certificate sign office.myserver.hu ca=ca.myserver.hu
; /certificate sign branch01.myserver.hu ca=ca.myserver.hu

; 4. peer tanúsítványok fölmásolása és importálása
; ...

; 5. IKE phase1 proposal beállítása
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 \
    name="myserver.hu" nat-traversal=no proposal-check=strict


; 5. IKE phase2 proposal beállítása
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048 \
    name="proposal-myserver.hu" lifetime=30m

; 6. ipsec peer-ek létrehozása

/ip ipsec peer
add exchange-mode=ike2 name="peer-remote" \
    address=remote.public.ip/32 \
    local-address=local.public.ip \
	passive=yes send-initial-contact=yes \
    profile="myserver.hu"

; 7. identity létrehozása

; teljes cert azonosítással
/ip ipsec identity
add auth-method=digital-signature peer=peer-branch01 \
    certificate=office.myserver.hu  my-id=fqdn:office.myserver.hu  \
    match-by=certificate remote-certificate=branch01.myserver.hu remote-id=fqdn:branch01.myserver.hu

; remote-id azonosítással
/ip ipsec identity
add auth-method=digital-signature peer=peer-office \
    certificate=branch01.myserver.hu  my-id=fqdn:branch01.myserver.hu  \
    match-by=remote-id remote-id=fqdn:office.myserver.hu

; 8. policy létrehozása

/ip ipsec policy
add peer=peer-branch01 proposal=proposal-myserver.hu 
	dst-address=remote.subnet/24 src-address=local.subnet/24
    tunnel=yes

; 9. NAT bypass

/ip firewall nat
set [find where action=masquerade] ipsec-policy=out,none

; 10. Prevent package leak

/ip route
add comment="Prevent package leak RFC1918 class A" distance=1 dst-address=10.0.0.0/8 type=unreachable
add comment="Prevent package leak RFC1918 class B" distance=1 dst-address=172.16.0.0/12 type=unreachable
add comment="Prevent package leak RFC1918 class C" distance=1 dst-address=192.168.0.0/16 type=unreachable

; 11. Add active route to remote subnet

/interface bridge
add name=ipsec protocol-mode=none
/ip route
add dst-address=remote.subnet/24 gateway=ipsec pref-src=local.lan.ip comment="VPN to branch01"

; 12. replace host unreachable with network unreachable

/ip firewall filter
add action=reject chain=forward out-interface=ipsec \
	reject-with=icmp-network-unreachable \
    comment="Reply with network-unreachable when IPSEC tunnel is down"
    place-before=<???>
    
; 13. MTU, TCP MSS Clamping

/ip firewall mangle add action=change-mss chain=forward new-mss=1360 \
    src-address=remote.sub.net/24 protocol=tcp tcp-flags=syn tcp-mss=!0-1360 \
    ipsec-policy=in,ipsec passthrough=yes \
    comment="IKE2: Clamp TCP MSS from remote.sub.net/24 to ANY"
    

Itt további magyarázat nélkül közlöm az office és branch01 router-ek teljes konfigurációját.

office

/interface bridge
add name=bridge-office
add name=ipsec protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] name=ether1-internet
/interface list
add name=LAN
add name=WAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=myserver.hu proposal-check=strict
/ip ipsec peer
add exchange-mode=ike2 local-address=100.3.3.10 name=peer-branch01 passive=yes profile=myserver.hu
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=proposal-myserver.hu pfs-group=modp2048
/ip pool
add name=pool-office ranges=172.16.2.100-172.16.2.200
/ip dhcp-server
add address-pool=pool-office disabled=no interface=bridge-office name=dhcp-office
/interface bridge port
add bridge=bridge-office interface=ether2
add bridge=bridge-office interface=ether3
/interface list member
add interface=ether1-internet list=WAN
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
/ip address
add address=172.16.2.1/24 interface=bridge-office network=172.16.2.0
add address=100.3.3.10/24 interface=ether1-internet network=100.3.3.0
/ip dhcp-server network
add address=172.16.2.0/24 dns-server=172.16.2.1 gateway=172.16.2.1
/ip dns
set allow-remote-requests=yes servers=100.3.3.3
/ip firewall filter
add action=accept chain=input comment="Allow UPD 500,4500 for IKEv2" dst-address=100.3.3.10 dst-port=500,4500 in-interface=ether1-internet protocol=udp
add action=accept chain=input comment="Allow IPSEC/ESP" dst-address=100.3.3.10 in-interface=ether1-internet protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=reject chain=forward comment="Reply with network-unreachable when IPSEC tunnel is down" out-interface=ipsec reject-with=icmp-network-unreachable
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
/ip firewall mangle
add action=change-mss chain=forward comment="IKE2: Clamp TCP MSS from 172.16.1.0/24 to ANY" ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp src-address=172.16.1.0/24 \
    tcp-flags=syn tcp-mss=!0-1360
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface=ether1-internet
/ip ipsec identity
add auth-method=digital-signature certificate=office.myserver.hu match-by=certificate my-id=fqdn:office.myserver.hu peer=peer-branch01 policy-template-group=branch01.myserver.hu \
    remote-certificate=branch01.myserver.hu remote-id=fqdn:branch01.myserver.hu
/ip ipsec policy
add dst-address=172.16.1.0/24 peer=peer-branch01 proposal=proposal-myserver.hu sa-dst-address=100.2.2.10 sa-src-address=100.3.3.10 src-address=172.16.2.0/24 tunnel=yes
/ip route
add distance=1 gateway=100.3.3.3
add comment="Prevent package leak RFC1918 class A" distance=1 dst-address=10.0.0.0/8 type=unreachable
add comment="Prevent package leak RFC1918 class B" distance=1 dst-address=172.16.0.0/12 type=unreachable
add comment="VPN to branch01" distance=1 dst-address=172.16.1.0/24 gateway=ipsec pref-src=172.16.2.1
add comment="Prevent package leak RFC1918 class C" distance=1 dst-address=192.168.0.0/16 type=unreachable
/system identity
set name=office.myserver.hu

branch01

/interface bridge
add name=bridge-branch01
add name=ipsec protocol-mode=none
/interface ethernet
set [ find default-name=ether1 ] name=ether1-internet
/interface list
add name=LAN
add name=WAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name=myserver.hu proposal-check=strict
/ip ipsec peer
add address=100.3.3.10/32 exchange-mode=ike2 local-address=100.2.2.10 name=peer-office profile=myserver.hu
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=proposal-myserver.hu pfs-group=modp2048
/ip pool
add name=pool-branch ranges=172.16.1.100-172.16.1.200
/ip dhcp-server
add address-pool=pool-branch disabled=no interface=bridge-branch01 name=dhcp-branch01
/interface bridge port
add bridge=bridge-branch01 interface=ether2
add bridge=bridge-branch01 interface=ether3
add bridge=ipsec interface=ether5
/interface list member
add interface=ether1-internet list=WAN
add interface=ether2 list=LAN
add interface=ether3 list=LAN
add interface=ether4 list=LAN
add interface=ether5 list=LAN
/ip address
add address=172.16.1.1/24 interface=bridge-branch01 network=172.16.1.0
add address=100.2.2.10/24 interface=ether1-internet network=100.2.2.0
/ip dhcp-server network
add address=172.16.1.0/24 dns-server=172.16.1.1 gateway=172.16.1.1
/ip dns
set allow-remote-requests=yes servers=100.2.2.2
/ip firewall filter
add action=accept chain=input comment="Allow UPD 500,4500 for IKEv2" dst-address=100.2.2.10 dst-port=500,4500 in-interface=ether1-internet protocol=udp
add action=accept chain=input comment="Allow IPSEC/ESP" dst-address=100.2.2.10 in-interface=ether1-internet protocol=ipsec-esp
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=reject chain=forward comment="Reply with network-unreachable when IPSEC tunnel is down" out-interface=ipsec reject-with=icmp-network-unreachable
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
/ip firewall mangle
add action=change-mss chain=forward comment="IKE2: Clamp TCP MSS from 172.16.2.0/24 to ANY" ipsec-policy=in,ipsec new-mss=1360 passthrough=yes protocol=tcp src-address=172.16.2.0/24 tcp-flags=syn tcp-mss=\
    !0-1360
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none log=yes out-interface=ether1-internet
/ip ipsec identity
add auth-method=digital-signature certificate=branch01.myserver.hu my-id=fqdn:branch01.myserver.hu peer=peer-office remote-id=fqdn:office.myserver.hu
/ip ipsec policy
add dst-address=172.16.2.0/24 peer=peer-office proposal=proposal-myserver.hu sa-dst-address=100.3.3.10 sa-src-address=100.2.2.10 src-address=172.16.1.0/24 tunnel=yes
/ip route
add distance=1 gateway=100.2.2.2
add comment="Prevent package leak RFC1918 class A" distance=1 dst-address=10.0.0.0/8 type=unreachable
add comment="Prevent package leak RFC1918 class B" distance=1 dst-address=172.16.0.0/12 type=unreachable
add comment="VPN to office" distance=1 dst-address=172.16.2.0/24 gateway=ipsec pref-src=172.16.1.1
add comment="Prevent package leak RFC1918 class C" distance=1 dst-address=192.168.0.0/16 type=unreachable
/system identity
set name=branch01.myserver.hu

További site-ok hozzáadása

Az alábbi leírásban már nem konkrét ip címeket használok, hanem olyan beszédes neveket mint branch01.lan.subnet/24 vagy branch02.router.lan.ip. Ez elősegíti a megértést azáltal, hogy a parancsok is beszédesek lesznek (5-6 különböző hálózat számszerű címeinek észben tartása már nem egyszerű feladat.)

Új site hozzáadása

Ez egy zanzásított verzió lesz. Felsoroljuk azokat a lépéseket, amikkel egy további site-ot lehet hozzákapcsolni a központi, office site-hoz. Legyen az új site neve branch02.

; 1. Új kliens certificate készítése

/certificate add name=branch02.myserver.hu \
	country=HU state=Heves locality=Eger \
    organization=myserver.hu common-name=branch02.myserver.hu \
    subject-alt-name=DNS:branch02.myserver.hu \
    key-size=4096 days-valid=1095 trusted=yes key-usage=tls-client
/certificate sign branch02.myserver.hu ca=ca.myserver.hu
/certificate export-certificate branch02.myserver.hu type=pkcs12 export-passphrase="not_telling"

; 2. Certificate fölmásolása az új VPN branch router-jére, utána importálás
/certificate import file-name=cert_export_ca.myserver.hu.crt name="ca.myserver.hu"
/certificate import file-name=cert_export_branch02.myserver.hu.crt name="branch02.myserver.hu"
/file remove [find where name=cert_export_ca.myserver.hu.crt]
/file remove [find where name=cert_export_branch02.myserver.hu.p12]

; 3. ipsec phase1 proposal (profile)
/ip ipsec profile
add dh-group=modp2048 enc-algorithm=aes-256 hash-algorithm=sha256 name="myserver.hu" nat-traversal=no proposal-check=strict

; 4. ipsec phase2 proposal (proposal)
/ip ipsec proposal
add auth-algorithms=sha256 enc-algorithms=aes-256-cbc pfs-group=modp2048 name="proposal-myserver.hu" lifetime=30m

; 5. ipsec peer
; branch02 router-en:
/ip ipsec peer
add exchange-mode=ike2 name="peer-office" \
   address=[/resolve office.myserver.hu] \
   profile="myserver.hu" \
   passive=yes send-initial-contact=yes 
; office router-en:
add exchange-mode=ike2 name="peer-branch02" \
   address=[/resolve branch02.myserver.hu] \
   profile="myserver.hu" \
   passive=yes send-initial-contact=yes 

; 6. identity
; branch02 router-n
add auth-method=digital-signature certificate=branch02.myserver.hu \
    my-id=fqdn:branch02.myserver.hu \
    peer=peer-office \
    remote-id=fqdn:office.myserver.hu
; office router-en:
add auth-method=digital-signature certificate=office.myserver.hu \
    my-id=fqdn:office.myserver.hu \
    peer=peer-branch02 \
    match-by=certificate \
    remote-certificate=branch02.myserver.hu \
    remote-id=fqdn:branch02.myserver.hu
    
; 7. policy
; branch02 router-en
add src-address=branch02.lan.subnet/24 dst-address=office.lan.subnet/24 \
  peer=peer-office proposal="proposal-myserver.hu" tunnel=yes
; office router-en
add src-address=office.lan.subnet/24 dst-address=branch02.lan.subnet/24 \
  peer=peer-branch02 proposal="proposal-myserver.hu" tunnel=yes

; 8. routing

; branch02 routing
/interface bridge
add name=ipsec protocol-mode=none
/ip route
add comment="Prevent package leak RFC1918 class A" distance=1 dst-address=10.0.0.0/8 type=unreachable
add comment="Prevent package leak RFC1918 class B" distance=1 dst-address=172.16.0.0/12 type=unreachable
add comment="Prevent package leak RFC1918 class C" distance=1 dst-address=192.168.0.0/16 type=unreachable
add commend="VPN to office" distance=1 dst-address=office.lan.subnet/24 gateway=ipec pref-src=branch02.router.ip

; office routing
add commend="VPN to branch02" distance=1 dst-address=branch02.lan.subnet/24 gateway=ipec pref-src=office.router.ip

; correct ICMP branch02
add action=reject chain=forward comment="Reply with network-unreachable when IPSEC tunnel is down" out-interface=ipsec reject-with=\
    icmp-network-unreachable place-before=<????>

; 9. MTU TCP MSS

; branch02 mtu tcp mss clamping
/ip firewall mangle 
add action=change-mss chain=forward new-mss=1360 \
   src-address=office.lan.subnet/24 \
   protocol=tcp tcp-flags=syn tcp-mss=!0-1360 \
   ipsec-policy=in,ipsec passthrough=yes comment="IKE2: Clamp TCP MSS from office.lan.subnet/24 to ANY"

Teljesen összekapcsolt hálózatok

A korábban leírt módszerrel bármikor hozzá tudsz adni több site-ot, és a különböző site-ok között VPN kapcsolatokat kialakítani. Három site esetén akár még előnyös is lehet az, hogy minden site minden site-tal kapcsolatban van. ("Fully connected network"). Ennek az az előnye, hogy bármely site elérhetetlensége esetén az összes többi kommunikálni tud egymással. A gondok akkor kezdődnek, amikor a site-ok száma elkezd növekedni. Egy 10 site-ból álló hálózatnál már 45 alagutat kellene kiépíteni ahhoz, hogy minden site mindegyik másikat lássa.

Csillag topológia

Helyette választhatunk egy csillag topológiát: minden site az office -hoz csatlakozik, és a branch-ek közöti forgalmat az office továbbítja. Ennek van egy olyan előnye is, hogy a telephelyek közötti forgalmat egyetlen egy helyen, az office tűzfalával meg lehet szűrni. A nyilvánvaló hátránya az, hogy a csillag közepe egy SPOF,  és természetesen az összes hálózati forgalom áthalad rajta, ezért nagyobb a hálózat terhelése.

Ezt a fajta összekötést úgy érjük el, hogy újabb ipsec policy-k hozzáadásával rávesszük a telephelyeket arra, hogy a "többi" telephely irányába menő forgalmat is az alagúton küldjék át.

branch02 gépen

/ip route
add comment="VPN to branch01 through office" distance=1 \
  dst-address=branch01.lan.subnet/24 \
  gateway=ipsec \
  pref-src=branch02.router.lan.ip
  
/ip ipsec policy
add peer=peer-office proprosal=proposal-myserver \
  src-address=branch02.lan.subnet/24 \
  dst-address=branch01.lan.subnet/24 \
  tunnel=yes

branch01 gépen:

/ip route
add comment="VPN to branch02 through office" distance=1 \
  dst-address=branch02.lan.subnet/24 \
  gateway=ipsec \
  pref-src=branch01.router.lan.ip
  
/ip ipsec policy
add peer=peer-office proprosal=proposal-myserver \
  src-address=branch01.lan.subnet/24 \
  dst-address=branch02.lan.subnet/24 \
  tunnel=yes

office01 gépen:

/ip ipsec policy
add peer=peer-branch01 proprosal=proposal-myserver dst-address=branch01.lan.subnet/24 src-address=branch01.lan.subnet/24 tunnel=yes
add peer=peer-branch02 proprosal=proposal-myserver dst-address=branch02.lan.subnet/24 src-address=branch01.lan.subnet/24 tunnel=yes

Egyéb más topológiák

A fent leírtak alapján bárki kialakíthat magának más topológiákat. Például csillagok csillagokba kötve stb. Általában véve igaz, hogy ilyen nagy számú telephely összekötésére másfajta megoldást érdemes választani. Például lehet telepíteni szerver terembe magas rendelkezésre állású, gyors hálózati kapcsolattal rendelkező StrongSwan VPN szervereket, és ezeken keresztül redundáns módon összekötni a telephelyeket. Ez azonban már túlmutat ennek a leírásnak a keretein.

Összes forgalom átirányítása

TODO!

https://forum.mikrotik.com/viewtopic.php?f=2&t=171863

Road Warrior VPN

Bevezetés

Ebben a fejezetben bemutatjuk, hogyan lehet road warrior kliensekkel kapcsolódni MikroTik RouterOS VPN szerverhez, IPSEC/IKEv2 alapokon. A "road warrior" egy olyan mobil dolgozó, aki folyamatosan úton van. Van nála egy mobil eszköz (pl. laptop, telefon, tablet) és különböző helyekről kapcsolódik a céges hálózathoz.

Ennek a fejezetnek a megértéséhez szükséges az előző fejezetek megértése. Sok olyan fogalom és beállítás szerepel majd benne, amit ott magyaráztunk el.

Beállítás (gyakorlat)

Előkészületek

Ennél a példánál a site-to-site példában megadott VPN környezetet feltételezzük. Ide értve az ott létrehozott tanúsítványokat is.

Az office router-en fogunk kialakítani egy olyan VPN szerver beállítást, road warrior kliensek csatlakozását is fogadni tudja. Ahogy ott, itt is nagyon fontos az NTP kliens helyes beállítása.

Tanúsítványok

Arra készülünk, hogy sok road warrior kliens fog csatlakozni. Ezért egy úgynevezet tanúsítvány sablont hozunk létre. Ebből később könnyebb lesz származtatni az egyes kliens tanúsítványokat.

/certificate
add name="~client-template@office.myserver.hu"  \
    country="HU" state="Heves" locality="Eger" \
    organization="office.myserver.hu"  \
    key-size=4096 days-valid=1095 \
    common-name="~client-template@office.myserver.hu" \
    subject-alt-name="email:~client-template@office.myserver.hu" \
    trusted=yes key-usage=tls-client
 

A template-et nem írjuk alá! Minden klienshez külön kliens tanúsítványt generálunk. Kliens alatt nem felhasználót kell érteni, hanem VPN kliens eszközt. Ha egy felhasználó több számítógépről is be akar jelentkezni (pl. a telefonjáról és a laptopjáról), akkor ezekhez külön tanúsítványt kell létrehozni. Mi most egy gandalf nevű felhasználóhoz és egy vivobook laptophoz tartozó tanúsítványt generálunk a template-ből:

/certificate 
add copy-from=~client-template@office.myserver.hu \
    name="gandalf-vivobook@office.myserver.hu" \
    common-name="gandalf-vivobook@office.myserver.hu" \
    subject-alt-name=email:gandalf-vivobook@office.myserver.hu
sign gandalf-vivobook@office.myserver.hu ca=ca.office.myserver.hu

Ezután exportáljuk a kliens és a CA cert-et. A kliens cert-hez a privát kulcsot is.

/certificate
export-certificate gandalf-vivobook@myserver.hu type=pkcs12 export-passphrase="not_telling_you"
export-certificate ca.office.myserver.hu

VPN kliensek alhálózata

A VPN klienseknek egy saját címtartományt adunk. A router-en fölveszünk egy hidat, és adunk neki egy címet ezen az alhálózaton belül. A kapcsolódó kliensek ebből a tartományból fognak címeket kapni.

/interface bridge
add name=bridge-vpn-rw comment="VPN Road Warrior"
/ip address
add address=10.10.10.254/24 comment="VPN Road-Warrior" name=pool-vpn-rw

mode-config

Az IKE/ISAKMP  protokoll nem csak kulcsok és titkosítási algoritmusok egyeztetésére használható. Ezen keresztül lehet IP címet beállítani, közölni a másik féllel az elérhető alhálózatokat ("route push") stb. Ezen paraméterek megadására való a mode-config.

/ip ipsec mode-config
add address-pool=pool-vpn-rw address-prefix-length=32 \
    name=modeconf-vpn-rw split-include=172.16.1.0/24,172.16.2.0/24 \
    static-dns=172.16.1.1 system-dns=no responder=yes
    

• Az address-pool mondja meg, hogy melyik IP pool-ból osztunk címeket
• Az address-prefix-length mondha meg, hogy mennyi címet osztunk. (Nem csak egyedi címet lehet átadni, hanem teljes címtartományokat is.)
• A split-include segítségével lehet megadni egy vagy több helyi alhálózatot. A másik peer megkapja ezeket a hálózatokat. Értesül arról, hogy ezen a peer-en keresztül milyen hálózati címtartományok érhetők el. Ennek a policy generálásnál lesz szerepe (erről később írok)
• A static-dns megadásával lehet átküldeni azt a DNS szervert, ami a helyi hálózat címeit tudja feloldani.
• A system-dns=no beállítás akadályozza meg azt, hogy a helyi router DNS-t (/ip dns és /ip dns static) adja át a másik félnek
• A responder=yes beállítás hatására ez a peer küldi át a mode-config beállításokat a távoli peer-nek. Ha ez no-ra van állítva, akkor ez az initiator oldal.

IKE Phase 1 (ipsec profile) és phase 2 (ipsec proposal)

Hogy ez pontosan mit jelent, azt a site-to-site VPN résznél már leírtam. Ami ahhoz képest eltérés, az az algoritmusok megválasztása. Itt többféle kliensre számítunk: Windows 10, Linux, iOS, különböző android verziók stb. Próbálunk beállítani biztonságos algoritmusokat. De figyelembe kell vennünk azt, hogy várhatóan milyen típusú klienseket szeretnénk támogatni, és hogy ezek a kliensek milyen algoritmusokat támogatnak, plusz még azt is, hogy milyen algoritmusokhoz van hardveres gyorsítás a router-ben.

/ip ipsec profile
add dh-group=modp2048,modp1536,modp1024 \
    enc-algorithm=aes-256,aes-192,aes-128 \
    hash-algorithm=sha256 \
    name=profile-vpn-rw \
    nat-traversal=yes proposal-check=claim

/ip ipsec proposal
add auth-algorithms=sha512,sha256,sha1 \
    enc-algorithms=aes-256-cbc,aes-256-ctr,aes-192-cbc,aes-192-ctr,aes-128-cbc,aes-128-ctr \
    lifetime=8h name=proposal-vpn-rw pfs-group=none

Hogy melyik OS milyen algoritmusokat támogat, arról például itt is tájékozódhatsz:

• Windows
• macOS
• IOS
• Android (StrongSwan)
• Linux (StrongSwan)

Érdekes, hogy például a Windows 10 kliensek az első IKE fázisban támogatják a modp1024 + SHA256 beállítást, de a második fázisban hash algoritmusnak kizárólag az SHA1-et támogatja, pfs-t pedig egyáltalán nem tud használni. (Ezért engedélyeztem az SHA1-et, máskülönben Windows-ból nem lehetne csatlakozni.)

Figyelem! Ha mégis megpróbálod beállítani a pfs-group értéket valami none-tól különböző értékre, akkor először azt fogod tapasztalni hogy működik. De amint letelt a megadott lejárati idő, a MikroTik oldal meg fogja követelni a kulcs lecserélését. Azonban a Windows ezt nem fogja megtenni (mert ezt nem támogatja). Ha például 4 óra a lejárat, akkor 4 óra folyamatos kapcsolat után fog "megszakadni" a kapcsolat. Ráadásul úgy, hogy MikroTik-ből connected-nek látszódik, csak épp elérhetetlen lesz a másik oldal. Ilyenkor egy gyors megoldás a kapcsolat újraépítésére az, hogy az identity-t disabled-re állítod, majd újra enabled-re. Ez a MikroTik oldalon törli a phase1 -et is, és így a kapcsolat újra ki tud épülni.

Policy group

A policy group  egy névvel ellátott csoportot határoz meg. A nevén kívül semmit nem lehet itt megadni. Ennek az a jelentősége, hogy ezzel lehet később összekapcsolni az identity-t és a policy template-eket. (Hogy ez miért fontos, azt később fogom leírni.)

/ip ipsec policy group
add name=group-vpn-rw

Policy template

A site-to-site VPN példában kézzel, statikus policy -kat adtunk hozzá. Ezt azért tehettük meg, mert előre ismertük az alhálózatok címeit, és ezeket néhány telephelyen meg tudtuk adni kézzel. Ez az út nem járható a road warrior kliensek esetén, sok okból:

1. Ha ezeket kézzel akarnánk fölvenni a klienseken, akkor a kliensek nagy száma miatt ez túl nagy munka lenne.
2. Ráadásul a VPN-en keresztül elérhető alhálózatok listája bármikor megváltozhat a VPN szerveren, és ilyenkor nem szeretnénk, ha az összes road warrior klienst kézzel újra kellene konfigurálni.
3. Ráadásul a kliensek általában erre nincsenek fölkészülve. Egy Windows 10 vagy egy macOS kliens alapértelmezésben a szervertől kéri le a split-include -ban megadott alhálózatok listáját, és ezekhez automatikusan generálja a policy-ket. Bár elvileg lehetséges ezeket kézzel előre hozzáadni, de ezek a kliensek alapvetően nem erre vannak kitalálva, és ez nem véletlen.

A VPN szerver oldalán hasonló a helyzet. Bár megadhatnánk kézzel a policy-ket, de akkor duplán végeznénk el a munkát. Ha a mode-config -ban már megadtuk a split-include direktívával a kliensek számára elérhető alhálózatokat, akkor ez alapján automatikusan generálhatunk policy-ket a szerver oldalon is. (A kapcsolat sikeres felépülésekor.)

/ip ipsec policy
add dst-address=10.10.10.0/24 \
	group=group-vpn-rw proposal=proposal-vpn-rw \
    src-address=0.0.0.0/0 template=yes \
    ipsec-protocols=esp level=require \
    protocol=all action=encrypt

Ipsec peer

/ip ipsec peer
add exchange-mode=ike2 \
    address=0.0.0.0/0 \
	local-address=89.134.227.161 \
    name=peer-vpn-rw \
    passive=yes send-initial-contact=yes \
    profile=profile-vpn-rw

Részletek:

• az address=0.0.0.0/0 miatt bármilyen címről fogadunk beérkező kapcsolatokat (nem tudjuk előre megmondani, hogy a road warrior honnan fog kapcsolódni)
• a local-address adja meg azt a címet, ahol az IKE démon figyel (ehhez a peer-hez!)
• a passive=yes, send-initial-contact=yes beállítás az ami miatt ebből egy olyan responder lesz, ami várja a bejövő kapcsolatokat
• a profile az nyilván az IKE kulcs-csere első fázisának beállításait tartalmazza.

Ipsec indentity

Ez szolgál a kliensek azonosítására. Minden klienshez külön identity-t kell létrehozni!

/ip ipsec identity
add auth-method=digital-signature \
    certificate=ca.myserver.hu \
    remote-certificate=gandalf-vivobook@myserver.hu \
    generate-policy=port-strict \
    match-by=certificate \
    mode-config=modeconf-vpn-rw \
    peer=peer-vpn-rw \
    policy-template-group=group-vpn-rw \
    remote-id=user-fqdn:gandalf-vivobook@myserver.hu

Itt most csak a site-to-site VPN -hez képesti eltéréseket írom le:

• meg van adva a mode-config, ez tartalmazza a split-include beállítást, a VPN szerver ezt veszi alapul
• meg van adva a generate-policy=port-strict - ezt használjuk a policy generáláshoz.

A policy generálás folyamata:

• A kliens csatlakozik, azonosítja magát az identity-ben megadott certificate-tel.
• Elküldi az általa elfogadhatónak ítélt címtartományokat, amik erre a kapcsolatra vonatkoznak. (Ez egyébként a kliens oldali policy template-nek felel meg!)
• A szerver ezt összeveti azokkal a policy template-ekkel, amik ahhoz a policy template group-hoz tartoznak, amiket az identity-ben megadtunk. (Ez a szerver oldali policy template.)
• A kettő összevetése után határozza meg azokat a tartományokat amiket mindkét oldal elfogadhatónak talál.
• Ha nincsen közös rész, akkor abból kapcsolódási hiba lesz.
• Ha van közös rész, akkor a helyi policy template-ek alapján konkrét, dinamikus policy-ket generál.
• Ezek a dinamikus policy-k csak addig élnek, amíg a kapcsolat él. A kapcsolat megszakadásakor ezek a policy-k automatikusan törlésre kerülnek.

Ezek alapján most már jobban érthető az, amit a site-to-site kapcsolatnál a package leaking-ről írtunk. A kapcsolat bármikor megszakadhat, és emiatt a policy-k egy része bármikor eltűnhet. Fokozottan fontos hogy a router-t úgy konfiguráljuk, hogy titkosítatlan, privát címtartományhoz tartozó csomagok véletlenül se kerüljenek ki az internetre.

Tűzfal beállítások

Az IKE és IPSEC -hez itt is szükség van az 500 és 4500 -as UDP port megnyitására, valamint az esp csomagok fogadására.

/ip firewall filter
add place-before=0 \
    protocol=udp dst-port=500,4500 \
    dst-address=myserver.hu.public.ip \
    action=accept \ 
    chain=input \
    comment="Allow UDP 500,4500 IPSec for myserver.hu.public.ip"
add action=accept chain=input comment="Allow IPSEC/ESP" \
    dst-address=myserver.hu.public.ip \
	protocol=ipsec-esp \
    place-before=1

Ezután engedélyezünk minden forgalmat a VPN klienseknek kiosztott IP címtartomány felől mindenhová.

/ip firewall filter 
add chain=input src-address=10.10.10.0/24 \
    ipsec-policy=in,ipsec action=accept \
    place-before=[ find where comment~"defconf: drop all not coming from LAN" ] \
    disabled=no \
    comment="IKE2: Allow ALL incoming traffic from vpn-rw client to this router"

add chain=forward \
    src-address=10.10.10.0/24 \
    ipsec-policy=in,ipsec action=accept \
    place-before=[ find where comment~"defconf:  drop all from WAN not DSTNATed" ] \
    disabled=no \
    comment="IKE2: Allow ALL incoming traffic from vpn-rw client to ANY"
 

Ha nem szeretnéd, hogy a kliensek ezen keresztül internetezzenek, akkor a második szabály helyett beírhatsz egy olyat, ahol a dst-address -ben a helyi office privát LAN szerepel. Illetve természetesen ha akarod, akkor hozzáadhatod az összes többi branch címét is.

add chain=forward \
    src-address=10.10.10.0/24 \
    dst-address=office.lan.subnet/24 \
    ipsec-policy=in,ipsec action=accept \
    place-before=[ find where comment~"defconf:  drop all from WAN not DSTNATed" ] \
    disabled=no \
    comment="IKE2: Allow ALL incoming traffic from vpn-rw client to office LAN"
 
 add chain=forward \
    src-address=10.10.10.0/24 \
    dst-address=branch01.lan.subnet/24 \
    ipsec-policy=in,ipsec action=accept \
    place-before=[ find where comment~"defconf:  drop all from WAN not DSTNATed" ] \
    disabled=no \
    comment="IKE2: Allow ALL incoming traffic from vpn-rw client to branch01 LAN"
 
  add chain=forward \
    src-address=10.10.10.0/24 \
    dst-address=branch02.lan.subnet/24 \
    ipsec-policy=in,ipsec action=accept \
    place-before=[ find where comment~"defconf:  drop all from WAN not DSTNATed" ] \
    disabled=no \
    comment="IKE2: Allow ALL incoming traffic from vpn-rw client to branch02 LAN"
 

A mi példánkban az office router már tartalmaz egy általános masquerade szabályt, ami átírja az internet irányába menő összes csomag forráscímét az office rotuer WAN címére. Ide értve azokat is, amik a VPN kliensek felől érkeznek az alagúton át.

Általános esetben, ha nincsen beállítva ilyen szabály, akkor azt pluszban kézzel hozzá kell adni. (A mi példánkban erre nincs szükség, csak a teljesség kedvéért írtam ki.)

/ip firewall nat
add place-before=0 chain=srcnat src-address=10.10.10.0/24 \
	out-interface-list=WAN \
    ipsec-policy=out,none \
    action=masquerade \
    comment="Masquerade vpn-rw clients --> WAN traffic"

Ezen felül van arra is lehetőség, hogy a VPN kliensek felől az office LAN (illetve bármely más branch) irányába menő csomagok címét is  átfordítsuk.

/ip firewall nat
add place-before=0 chain=srcnat \
	src-address=10.10.10.0/24 \
    dst-address=office.lan.subnet/24 \
    ipsec-policy=out,none action=masquerade \
    comment="SRC-NAT vpn-rw client -> office LAN "
add place-before=0 chain=srcnat \
	src-address=10.10.10.0/24 \
    dst-address=branch01.lan.subnet/24 \
    ipsec-policy=out,none action=masquerade \
    comment="SRC-NAT vpn-rw client -> branch01 LAN "
add place-before=0 chain=srcnat \
	src-address=10.10.10.0/24 \
    dst-address=branch02.lan.subnet/24 \
    ipsec-policy=out,none action=masquerade \
    comment="SRC-NAT vpn-rw client -> branch02 LAN "

Ezek közül az első opcionális, mert az office LAN-ján belülről a default route arra a router-re vezet, amelyikre a road warrior kliensek is csatlakoznak. A több branch esetében ez nem opcionális, mivel a branch01 LAN-ján belülről a road warrior kliensek 10.10.10.0/24 címéhez nincs statikus route megadva, a default route-on keresztül pedig kimegy az internetre titkosítatlanul a válasz, és ott elakad... Alternatív megoldásként kézzel hozzá lehet adni route-okat és ipsec policy-ket a vpn-rw alhálózatra a branch-eken is, de ez elég fáradságos munka (minden branch-en +1 route és +1 policy, és az office-ban is...)

MTU TCP MSS

Ez szinte ugyan az mint ami a site-to-site leírásban volt, csak a szabályban a forráscím más.

add action=change-mss chain=forward \
	comment="Clamp TCP MSS from vpn-rw clients to ANY" \
	ipsec-policy=in,ipsec new-mss=1360 \
	passthrough=yes protocol=tcp \
	src-address=10.10.10.0/24 \
	tcp-flags=syn tcp-mss=!0-1360

 

Kapcsolódás Windows 10-ből

Ez egészen jól, képekkel illusztrálva le van írva itt. Az előző oldalon leírtak szerint exportált p12 és cert állományokat kell fölmásolni a kliens gépre, és importálni őket.

A következőkre kell figyelni:

• Importálni kell a CA cert-et és a klienshez készített pkcs12 kulcspárt.
• Importálás célja: Local Machine (helyi gép)
•  

Server-To-Site VPN (menedzselt szerver)

Ez egy újabb forgatókönyv ez olyan szerverhez, ami egy távoli hálózaton (akár több NAT és tűzfal mögött) található, és az üzemeltetése a saját cég feladata.

• Ennek a szervernek nincsen nyilvános címe, és Linux vagy Windows operációs rendszer futtat. Ebből a szempontból a road warrior felálláshoz hasonlít. 
• Ugyanakkor az is igaz, hogy ezt  a szervert távolról szeretnénk kezelni. Tehát az office LAN-on belülről szeretnénk elérni.

folyt köv...