Informatika | Hálózatok » Fülöp Miklós - Virtuális magánhálózatok

NetAcademia-tudástár VPN – virtuális magánhálózatok Virtuális magánhálózat: nyilvános hálózaton (például Interneten) keresztül megvalósított, titkosított hálózati kapcsolat, amellyel az ügyfél számítógépe vagy akár egy teljes fiókirodai hálózat hozzáférhet a központi, belső vállalati intranetre csatlakozó erőforrásokhoz. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár Miért jó a VPN? Ha néhány évvel ezelőtt egy felhasználónak otthonról (vagy bárhonnan máshonnan, a cég területén kívülről) el kellett érnie a vállalati erőforrásokat, szinte gondolkodás nélkül mondtuk a választ: a megoldás egy RAS kiszolgáló telepítése, ahová a dolgozó betárcsázva, a modemes kapcsolaton keresztül szépen hozzáfér mindenhez, amire szüksége lehet. A dolognak mára jó néhány szépséghibája lett: • • • A RAS

kiszolgálóra telepített modemek, így az egyidejűleg kiszolgálható ügyfelek száma véges A hívás díja akár a csillagos égig is emelkedhet, hiszen bárhol is járunk a világban, mindig a céges számot kell hívnunk – külföldről ez bizony nem olcsó mulatság A modemek sebessége még akkor is csak 56kbit, ha a kiszolgálóban digitális kártyákkal kapcsolódunk a telefonos hálózathoz. Ez meg sem közelíti a felhasználók számára ma rendelkezésre álló hálózati kapcsolatok (ADSL, kábeltévé, mikró, stb.) sebességét A virtuális magánhálózat használata, ami nem más, mint egy, az Interneten keresztül kiépített titkosított csatorna, megoldja a problémát. Ha a cég rendelkezik egy állandó, nagy sebességű internetes kapcsolattal, a felhasználók a VPN kiszolgálón keresztül csatlakozhatnak a belső hálózatra.  Ügyfél-kiszolgáló VPN kapcsolat Ekkor: • • • Nincs szükség modemek használatára, a virtuális portok, azaz

az egyidejű hozzáférések számát csak az erőforrások korlátozzák (gyakorlatilag azonban csak a céges internetkapcsolat sávszélessége jön szóba, mint korlátozó tényező) A felhasználónak nem kell nemzetközi számot tárcsáznia, elég, ha bármelyik internetszolgáltatónál, helyi tarifával csatlakozik a világhálóhoz Modemek híján nincs sebességkorlát sem A VPN másik alkalmazási területe az alhálózatok összekapcsolásához kötődik. Gondoljunk egy cégre, ahol a központi hálózat mellett számos fiókiroda is működik, országszerte. Mit tehetünk, ha a fiókiroda hálózatát szeretnénk valamilyen szinten összekapcsolni a központi hálózattal? Ha megelégedtünk a modemes sebességgel, használhattuk a klasszikus telefonos megoldást. Ha azonban állandó kapcsolatra volt szükség, illetve számított a sebesség, a legjobban tettük, ha bérelt vonali kapcsolatot építettünk ki az irodák között. Mindkét megoldás méregdrága 

Kiszolgáló-kiszolgáló VPN kapcsolat Ekkor a központi hálózat folyamatosan elérhető, a VPN kiszolgáló állandó kapcsolattal csatlakozik az Internetre. A fiókiroda internetes kapcsolata lehet állandó vagy időszaki is, az igényektől függően továbbra is megelégedhetünk a modemes kapcsolattal, vagy használhatjuk a fiókiroda nagy sávszélességű hozzáférését. A fiókiroda átjárója pedig igény szerint automatikusan felépíti a VPN kapcsolatot, és elérhetővé teszi a vállalati hálózatot – mindezt gyorsan és olcsón. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár VPN protokollok A nyilvános hálózaton keresztüli biztonságos kommunikáció érdekében a hálózati forgalmat természetesen titkosítani kell. A forgalom titkosítására többféle megoldás, protokoll létezik. A Windows 2000 ügyfelek és kiszolgálók a következő két

protokoll használatát támogatják: • • Point-to-Point Tunneling Protocol (PPTP): Az RFC 2637-ben [1] definiált alagútprotokoll, amely MPPE (Microsoft Point-to-Point Encryption) titkosítással működik. A PPTP protokollt a korábbi Windows ügyfelek (Windows 9x-től napjainkig) is támogatják Layer 2 Tunneling Protocol (L2TP): Az L2TP protokoll specifikációját az RFC 2661-ben [2] találjuk. Maga az L2TP protokoll saját titkosítást nem tartalmaz, ezért a virtuális magánhálózatot az „L2TP over IPSec”, azaz az IPSec titkosítással segített L2TP kapcsolat valósítja meg. Az L2TP használatát a Windows 2000 és Windows XP kiszolgálók illetve ügyfelek támogatják. A protokollok részletes bemutatására később visszatérünk. VPN kiszolgáló a Windows 2000-ben: Routing and Remote Access Service A távelérés és útválasztás-szolgáltatás (Routing and Remote Access Service, RRAS) minden Windows 2000 Server beépített szolgáltatása. Telepítés

után letiltva marad, mi magunk indíthatjuk el – a szükséges beállítások létrehozása után–, vagy állíthatjuk le azt, de a rendszerből eltávolítani nem lehet. Az RRAS felügyeleti konzolját az Administrative Tools menüben találjuk, nem meglepő módon Routing and Remote Access néven. Az RRAS engedélyezése előtt varázsló segít a szolgáltatás beállításában. A szolgáltatást egyébként kézzel is testre szabhatjuk, de egyelőre fogadjuk el a varázsló segítségét: készítsünk VPN kiszolgálót! Nyissuk meg az RRAS konzolt, kattintsunk jobb gombbal a kiszolgáló nevére, és válasszuk a „Configure and Enable Routing and Remote Access” parancsot!  Varázsló segít az RRAS-ból VPN kiszolgálót faragni A varázsló (fenti ábrán is látható) első oldalán válasszuk a Virtual private network (VPN) server opciót. Továbbhaladva ki kell választanunk a VPN ügyfelek által használni kívánt protokollokat (ez lehet a TCP/IP mellett más

is, például a NetBEUI, de a Windows kommunikációhoz ma már bőven elég a TCP/IP is). Az „Internet Connection” oldalon a meglévő hálózati kapcsolatok közül válasszuk ki azt, amellyel a VPN kiszolgáló az Interneten „lóg”. Az RRAS ezen a kapcsolaton keresztül fogadja majd a beérkező VPN kéréseket Ez után el kell döntenünk, hogy milyen módon szeretnénk a beérkező ügyfeleknek IP címeket osztani. Erre két lehetőségünk van: • • DHCP kiszolgáló használatával – ekkor az RRAS szolgáltatás a belső DHCP kiszolgálótól „szerez” IP-címeket. Meghatározott címtartományból – ekkor mi magunk határozhatjuk meg a kiosztani kívánt IP-címeket Bárhonnan is származik a címtartomány, annak első eleme lesz majd a virtuális kiszolgáló IP címe, a többit pedig az RRAS szépen kiosztja majd a beérkező ügyfelek között. Figyeljünk arra, hogy a kiszolgálón legyen beállítva a DNS és a WINS kiszolgálók IP címe is, mert

ezeket az információkat az RRAS a bejelentkezés során továbbítja az ügyfelek irányába. Ez után azt kell eldöntenünk, hogy milyen módon szeretnénk azonosítani a bejelentkező felhasználókat. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár  Felhasználó-azonosítás: Windows vagy Radius? Ehhez a beépített Windows-módszer mellett immár a RADIUS protokoll segítségét is hívhatjuk. A RADIUS-ról később még lesz szó, egyelőre itt válasszuk a „No, I don’t want to” kezdetű sort, magyarul az azonosítást bízzuk a Windowsra. Miután ezzel elkészültünk, a varázsló elindítja az RRAS szolgáltatást. Az alapvető beállításokkal készen is vagyunk, egy híján Fontos! Ha az RRAS nem tartományvezérlőn, hanem tagkiszolgálón fut – ami egyébként a javasolt eljárás –, a tartományi felhasználók azonosítása csak akkor működik

helyesen, ha a kiszolgálót felvesszük a „RAS and IAS Servers” csoportba. A legtöbb esetben ez automatikusan megtörténik, de mindig nézzünk utána magunk is! Az RRAS konzol Miután a szolgáltatás elindult, ismerjük meg az RRAS felügyeleti modul tartalmát!  Az RRAS konzol közvetlenül telepítés után A „Ports” sorra kattintva láthatjuk, hogy a varázsló 128-128 PPTP és L2TP portot hozott létre. Ez minden bizonnyal elég lesz, de az elérhető portok számát magunk is beállíthatjuk, ha a fában megnyitjuk a „Ports” tulajdonságlapját. Ugyanitt a portokon kettőt kattintva szükség esetén beállíthatjuk, hogy az adott eszközt szeretnénk-e bejövő, illetve kimenő kapcsolatok felépítésére használni. Az alapértelmezés természetesen nekünk teljesen megfelel A konzolban látszik az is, ha valamelyik port éppen használatban van (Active/Inactive). Kattintsunk jobb gombbal a kiszolgálóra (itt SERVER (local)), és nyissuk meg a

tulajdonságlap IP oldalát! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár  Az RRAS kiszolgáló IP tulajdonságai Itt állítható be, hogy az ügyfelek IP-címe honnan származzon (DHCP vagy meghatározott IP-cím tartomány). Ezt a beállítást már a varázsló megtette helyettünk. Az oldal alján kiválaszthatjuk azt a hálózati csatolót (értelemszerűen azt, amelyik a céges hálózatra, befelé „néz”), amin keresztül az RRAS a DHCP kiszolgálót megszólítja. Az ügyfeleknek küldött DNS és WINS címek is azok lesznek, amelyek az itt kiválasztott hálózati csatolón érvényesek! Bár a betárcsázó ügyfél automatikusan kap IP-címet, az ő hálózatán található számítógépek is „kérhetnek” a VPN kapcsolaton keresztül. Ehhez meg kell szólítaniuk a vállalati hálózatban található DHCP kiszolgálót, ez azonban csak akkor fog

sikerülni, ha az RRAS kiszolgálón futó DHCP Relay Agent segít nekik, és kérésüket továbbítja a kiszolgáló felé.  A DHCP Relay Agent továbbítja a DHCP kéréseket a kiszolgáló felé A DHCP Relay Agent-nek azonban meg kell magyaráznunk, hogy merre találja a DHCP kiszolgálót. Ehhez a konzolfában nyissuk meg a DHCP Relay Agent tulajdonságlapját és adjuk meg a DHCP kiszolgálók IP-címét. Emlékezzünk, hogy a betárcsázó ügyfél mindenképpen kap IP címet, a Relay Agent használatára csak akkor van szükség, ha a csatlakoztatott hálózaton belülről valaki más is szeretne IP-címhez jutni. Ügyfél-kiszolgáló VPN kapcsolat létrehozása A virtuális magánhálózathoz való csatlakozásban segít nekünk az Internet Connection Wizard varázsló. Ezt a vezérlőpultból, a Network Connections ablakon belül taláható Create (Make) New Connection ikon segítségével csalogathatjuk elő. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás

nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár  A csatlakozástípus kiválasztása Windows XP alatt A csatlakozás típusánál válasszuk ki a VPN-re utaló opciót (Windows 2000-nél „Connect to a private network”, XP-nél „Connect to the network at my workspace”). XP esetén a következő oldalon még arról is nyilatkoznunk kell, hogy modemes vagy VPN kapcsolaton keresztül szeretnénk csatlakozni. A VPN csatorna kialakításához meglévő Internet-kapcsolatra van szükség. Ez a kapcsolat lehet állandó, de használhatunk klasszikus modemes, betárcsázós kapcsolatot is Ezt még kényelmesebbé tehetjük, ha a VPN kapcsolatnak is beállítjuk, hogy melyik – másik – kapcsolat segítségével hozhatja létre a kapcsolatot az Internet-szolgáltatóval.  Ha kell, a Windows automatikusan tárcsázza az Internet-szolgáltatót is Ha ezt megadjuk, a Windows szükség esetén tárcsázza majd az Internet-szolgáltatót,

és a felépült kapcsolaton keresztül fogja felépíteni majd a VPN kapcsolatot. Ezután meg kell adnunk a VPN kiszolgáló IP-címét (mint egy „telefonszámot”), és már készen is vagyunk. Csatlakozás a VPN kiszolgálóhoz Ha megnyitjuk a létrehozott csatlakozási ikon tulajdonságlapját, viszontlátjuk a varázslóban megadott beállításokat. Kattintsunk a Networking oldalra!  A VPN kapcsolat hálózati beállításai Látható, hogy a VPN kapcsolat típusa „Automatic”. Választhatnánk kifejezetten a PPTP vagy az L2TP használatát is, de első körben érdemesebb az automatikus üzemmódnál maradni. Ilyenkor a számítógépek először megpróbálkoznak az L2TP kapcsolat kialakításával, és ha az nem sikerül, végső esélyként megpróbálkoznak a PPTP-vel. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár Ha ezzel a beállítással csatlakoznánk a VPN

kiszolgálóhoz, a sikeres csatlakozás után minden hálózati forgalom (ideértve például az internetes böngészést is) a VPN kapcsolaton keresztül igyekezne az Internet felé, ugyanis a csatlakozás pillanatában az alapértelmezett átjáró a VPN kiszolgáló lesz. Ha ezt szeretnénk elkerülni, a VPN kapcsolat tulajdonságlapjának fent is látható Networking oldalán válasszuk ki az Internet Protocol (TCP/IP)-t és kattintsunk a Properties, az erre megjelenő dialógusablakban pedig az Advanced gombra. Ekkor a következő ablakot látjuk:  Ha nem akarjuk, hogy minden forgalom a VPN felé menjen, töröljük ezt a beállítást! Ha eltüntetjük a pipát a „Use default gateway on remote network” sor elől, a következő csatlakozáskor az alapértelmezett átjáró marad az, ami volt: az Internet-szolgáltatóé. Ilyenkor a VPN kapcsolat felé csak az a forgalom halad majd, ami kifejezetten oda való. Ezt ellenőrizhetjük is a route print parancs kiadásával.

Miután ezzel is elkészültünk, itt az ideje, hogy csatlakozzunk végre a kiszolgálóhoz. Kattintsunk duplán a csatlakozás ikonjára vagy válasszuk a Connect parancsot! Adjunk meg egy bejelentkezésre jogosult felhasználónevet és jelszót, és kattintsunk az OK gombra. A kapcsolat néhány másodperc alatt létrejön  A létrejött VPN kapcsolat paraméterei Ha létrejött kapcsolaton a Status parancsot választjuk, megjelenik a fent látható dialógusablak. Itt láthatjuk többek között a saját és a kiszolgáló IP-címét és a titkosítás típusát is. Ha a titkosítás típusa • • MPPE – akkor a VPN kapcsolat PPTP IPSec – akkor a VPN kapcsolat L2TP protokollon keresztül jött létre. Az ábrán a bal oldali (XP) PPTP, míg a jobb oldali (W2K Pro) L2TP kapcsolatot épített fel, de ez természetesen nem az operációs rendszer típusától függ. Ne ijedjünk meg, ha elsőre nem épül fel az L2TP kapcsolat, ez az IPSec miatt még további

beállításokat is igényel. Elégedjünk meg egyelőre a PPTP-vel, ami bár „gyengébb” titkosítást alkalmaz, mint az IPSec, de azért jóval több, mint a semmi. A következő alkalommal hálózatokat kapcsolunk majd össze VPN alagúton keresztül, és nem fog kimaradni a protokollok, a PPTP, L2TP, a RADIUS és a távelérési házirendek bemutatása sem. Addig is, jó szórakozást! folytatjuk Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár Fülöp Miklós mick@netacademia.net A cikkben szereplő URL-ek: [1] http://www.ietforg/rfc/rfc2637txt [2] http://www.ietforg/rfc/rfc2661txt Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 8 NetAcademia-tudástár VPN - Virtuális magánhálózatok, 2. rész, Az L2TP protokoll Az előző részben körüljártuk a VPN hálózatok „lényegét”, Windows

2000 kiszolgálónkon varázsoltunk egy VPN kiszolgálót és csatlakoztunk is hozzá – egyelőre csak egy munkaállomással, PPTP kapcsolaton keresztül. Ma terítékre kerül az új protokoll, az L2TP is. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 9 NetAcademia-tudástár Az L2TP protokoll a PPTP és a Cisco által fejlesztett L2F (Layer 2 Forwarding) protokollok összeházasításával született. Windows 2000-ben maga az L2TP protokolltitkosítást nem, csak az alagúthálózat kialakításához szükséges funkciókat tartalmazza, így a „csupasz” L2TP forgalom bár alagúton halad, de az alagút fala üvegből van. Szerencsére ezzel az „üvegalagúttal” nem találkozunk, ugyanis a Windows 2000 egy ügyes trükkel az L2TP tudomása nélkül titkosítja a hálózati forgalmat. A titkosítást a Windows IPSec motorja végzi, automatikusan generált szabályok alapján (amelyek kifejezetten

az L2TP forgalom titkosítására készültek). Kapcsolódó IPSec cikksorozatunkban a dolog működéséről részletesebben is fellebbentjük majd a fátylat, egyelőre elégedjünk meg annyival, hogy az L2TP kapcsolat létrehozásához mind a kiszolgálónak, mind az ügyfélnek (azaz az alagút mindkét oldalának, mégpedig nem a felhasználónak, hanem a számítógépeknek!) rendelkeznie kell egy-egy nyílt kulcsú tanúsítvánnyal. Lehetőség van egyébként arra is, hogy a tanúsítvány helyett a kommunikáló tagok jelszóval hitelesítsék egymást, erről később lesz majd szó.  Az RRAS minden induláskor ellenőrzi a számítógép tanúsítványát, és az eseménynaplóban jelzi, ha probléma van (esetünkben például nincs tanúsítvány) Alapértelmezésben, ha az RRAS kiszolgáló nem rendelkezik tanúsítvánnyal, az L2TP VPN kapcsolatokat meg sem kísérli felépíteni, úgysem sikerülne. Ilyenkor minden beérkező L2TP kapcsolatot azonnal elutasít

Erről a fenti ábrán is látható csinos kis eseménynapló-bejegyzéssel tájékoztat minket. Tanúsítványok a számítógépen A számítógépnek is lehet tanúsítványa? Lehet bizony! Indítsuk el a Start menü Run parancsa segítségével a Microsoft Management Console-t (mmc.exe), majd válasszuk a Console / Add/Remove snap-in parancsot A megjelenő ablakban kattintsunk az Add gombra, a telepíthető modulok listájában kattintsunk kétszer a Certificates sorra, majd válasszuk a Computer account, majd a Local Computer opciókat. Ezzel megnyitjuk a helyi számítógép tanúsítványtárát Ezt az MMC konzolt egyébként későbbi használatra érdemes elmenteni.  Ennek a számítógépnek van tanúsítványa. vajon honnan szerezte? A tanúsítványok kezelése-terjesztése Windows 2000 tartományban igazán nem nehéz dolog. Ha valamelyik tagkiszolgálóra telepítünk egy tanúsítványkiadó szolgáltatást (Enterprise, azaz vállalati üzemmódban), a Windows 2000

kiszolgálók és munkaállomások automatikusan beszerzik tőle a megfelelő tanúsítványokat (mint az a fenti ábrán is látható). Ehhez egyetlen Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 10 NetAcademia-tudástár Group Policy beállításra van szükség (amit a tartományvezérlőre telepített CA egyébként meg is tesz): a mindenkire érvényes alapértelmezett tartományi házirend (Default Domain Policy) Computer Configuration / Windows Settings / Public Key Policies / Automatic Certificate Request Settings pontja alatt – ha még nem létezik – hozzunk létre egy új Request objektumot. Az objektum típusa legyen Computer Ezután már csak a használni kívánt CA nevét kell megadnunk – a listában a tartományba telepített vállalati tanúsítványkiadók láthatók.  Automatikus tanúsítványkérés beállításai a tartományi alapértelmezett csoportos házirendben A

házirend érvényesítése után a Windows 2000 munkaállomások és kiszolgálók automatikusan beszerzik a nekik szükséges tanúsítványokat, sőt, idővel azok frissítésére is képesek lesznek. A rendszer Windows 2000 tartományon belül szinte teljesen automatikus. Emlékszünk az előző cikk végén bemutatott két ábrára? Ott, míg a tartományon kívüli Windows XP csak PPTP, a tartományi tag Windows 2000 automatikusan L2TP protokoll segítségével csatlakozott a kiszolgálóhoz. A magyarázat ez: a Windows 2000 Professional tartományi tag lévén hozzáfért a csoportos házirendhez, és az utasításoknak megfelelően telepítette a saját kis tanúsítványát. Tanúsítványok telepítése „kézzel” No igen, de mit tehetünk, ha a fenti feltételek bármelyike, nem áll fenn, azaz: • • Nincs vállalati tanúsítvány-kiszolgálónk, vagy nem a sajátunkat szeretnénk használni A számítógépek nincsenek tartományban, így automatikusan kérni sem

tudnak? Mindkét esetben kettős célunk van: az első, hogy valahogy tanúsítványhoz jussunk. Ehhez használhatunk bármely tanúsítvány-kiszolgálót, akár Windows 2000 CA-t is. A Windows 2000 tanúsítvány-kiszolgálótól a szolgáltatás webes felületén keresztül kérhetünk tanúsítványt, más szolgáltatások esetén érdeklődjünk a CA üzemeltetőjétől. A második cél pedig a megszerzett tanúsítvány telepítése. Ha a Windows 2000 CA-t használjuk (a webes felületen keresztül), ez automatikusan megtörténik, de ellenőrizhetjük a számítógép tanúsítványtárában. Ha a tanúsítványt más szolgáltatótól kapjuk, ugyanitt importálhatjuk a rendszerbe. Tanúsítványkérés weben keresztül Lássuk mi a teendő, ha a Windows 2000 CA webes felületén keresztül szeretnénk tanúsítványhoz jutni! Esetünkben a tartományon kívüli Windows XP-nek szeretnénk tanúsítványt szerezni. Ennek érdekében a böngésző segítségével megnyitjuk a CA

weboldalát a http://server.falatraxhu/certsrv címen (jelentkezzünk be egy, a CA-hoz megfelelő jogosultságokkal bíró tartományi rendszergazda nevével és jelszavával) Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 11 NetAcademia-tudástár  A Windows 2000 CA webes felülete Ez valójában egy varázsló, amely lépésről lépésre végigvezet a tanúsítványkérés folyamatán. Tartsunk vele! • • Válasszuk a „Request a certificate” opciót, majd Next! A következő oldalon válasszuk az „Advanced Request”, azután pedig a „Submit a certificate request to this CA using a form” lehetőséget!  A kért tanúsítvány paraméterei A fent látható „Advanced Certificate Request” oldalon a Certificate Template mezőben attól függően válasszunk tanúsítványtípust, hogy egyedülálló (stand-alone) vagy vállalati CA-hoz csatlakozunk. Stand-alone CA esetén a

„Client Authentication Certificate” vagy az „IPSec Certificate” közül válasszunk (előbbi „felhasználó”-azonosításhoz is, utóbbi csak az IPSec csatornák kiépítéséhez használható), vállalati CA esetén pedig – mint az ábrán is látható – az Administrator típusú tanúsítványra lesz szükségünk. Aki nem hiszi, járjon utána [1]! Fontos még az ábra alján látható másik bekeretezett rész: „Use local machine store”, azaz a tanúsítványt a helyi számítógép tanúsítványtárába telepítsük. Ha a hozzá tartozó privát kulcsot később exportálni is szeretnénk (például adatmentési célból), válasszuk ki az egy sorral feljebb látható „Mark keys as exportable” lehetőséget is.  A kész tanúsítványt egy kattintással telepíthetjük Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 12 NetAcademia-tudástár Miután a kérést elküldtük, a

vállalati CA – megfelelő jogok birtokában – azonnal elkészíti a tanúsítványt, és a következő oldalon egy kattintással telepíthetjük is azt. Ha a CA nem vállalati típus, várnunk kell addig, míg egy rendszergazda jóvá nem hagyja a kérésünket. Ezután visszatérhetünk a kiszolgáló weboldalára és hozzájutunk a hőn áhított tanúsítványhoz További feltételek a tanúsítványokkal kapcsolatban A sikeres L2TP kapcsolat kiépítéséhez tehát mindkét tagnak rendelkeznie kell érvényes tanúsítvánnyal, bár mint a mellékelt ábra mutatta, az nem feltétel hogy az a bizonyos tanúsítvány annak a „nevére” szóljon, aki azt használja (ettől persze ez még biztonságos, hiszen a privát kulcs csak nála található meg). A tanúsítvány érvényességét két tényező befolyásolhatja még: • • A tanúsítvány lejárati ideje (ellenőrizhetjük, ha a tanúsítványra kettőt kattintunk) és egyéb jellemzői, pl. a visszavonási

státusza A tanúsítványt kiadó szervezetbe vetett bizalmunk No ez utóbbi már érdekes kérdés. Hogy kikben bízunk? Nos, a Windows beépítve tartalmaz egy listát a „megbízható” tanúsítványkiadókról. Ezután minden olyan tanúsítványban megbízunk, amit olyan CA adott ki, aki ebben a listában szerepel, vagy legalábbis, ha a kiadó CA-nak van olyan saját tanúsítványa, ami végső soron egy ilyen listatagtól származik (azaz, a CA-k közti hierarchiában egy megbízott CA-nak „gyermeke”). Ez a lista a megbízott gyökérkiszolgálók listája, „magyarul” a „Trusted Root Certification Authorities”.  Ellenőrizzük, hogy a házi CA-nk szerepel-e a megbízott gyökérkiszolgálók listájában! Windows 2000 tartományi környezetben természetesen minden vállalati CA bekerül a bizalmi listába, és persze kézzel is vehetünk fel újabbakat. Tartományon kívül azonban érdemes figyelni, és ellenőrizni, hogy a saját CA-nk szerepel-e ebben a

listában. A webes tanúsítványtelepítés során ez a bejegyzés is létrejön, de ha mégsem, a tanúsítványkiadó weboldaláról letölthetjük az ő saját tanúsítványát, és kézzel importálhatjuk a listába. A lényeg, hogy meglegyen Visszatérve a számítógépek saját tanúsítványaira: egy gépnek több tanúsítványa is lehet, a sikeres csatlakozás feltétele az, hogy mindkét gép rendelkezzen legalább egy olyan tanúsítvánnyal, amely: • • ugyanattól a tanúsítványki-szolgálótól származik ráadásul ebben a közös tanúsítvány-kiszolgálóban mindketten megbíznak Ennyi. Pofonegyszerű, nemde? :-) Hálózatok összekapcsolása VPN-en keresztül Eddig (gondolhatnánk) arról volt szó, hogy mi módon csatlakoztathatunk egy-egy számítógépet, munkaállomást a vállalati hálózathoz virtuális magánhálózaton keresztül. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia

Kft 13 NetAcademia-tudástár  Alhálózatok összekapcsolása VPN-nel A valóság az, hogy ha nem egy számítógépet, hanem egy teljes alhálózatot csatlakoztatunk, a módszer teljesen hasonló, csak a virtuális magánhálózatot nem az egyes számítógépek, hanem az alhálózat „határán” álló RRAS kiszolgáló építi fel – a másik alhálózaton található másik RRAS kiszolgáló felé. Az RRAS kiszolgálók feladata, hogy a túloldali alhálózatokba haladó illetve onnan érkező csomagokat a megfelelő módon továbbítsák (routolják). Ezt a hálózati konfigurációt ezért router-torouter VPN kapcsolatnak is nevezik Létrehozhatunk „féloldalas” hálózatot is, amikor mindig csak az egyik oldal (általában a fiókiroda) kezdeményezi a kapcsolatot, amikor arra igény van. A fiókiroda RRAS szolgáltatása ilyenkor csak „ügyfélként” üzemel, a VPN szolgáltatást csak a központi RRAS-ra kell telepíteni (akit hívunk). Állandó

internetes kapcsolatra is csak a központi szolgáltatásnak van szüksége, a fiókiroda ugyanis azt saját magának képes igény szerint kiépíteni (pont ugyanúgy, mint az ügyfél, aki a VPN-re való csatlakozás előtt tárcsázza az Internet-szolgáltatóját). Ha az állandó kapcsolat mindkét oldalon megvan, létrehozhatjuk a szimmetrikus VPN-t is. Ebben az esetben mindkét RRAS kiszolgáló egyidejűleg VPN kiszolgáló és ügyfél is, a kapcsolat kiépítését pedig mindig az kezdeményezi, aki éppen szeretne „átlátni” a másik alhálózatba. Honnan tudja az RRAS, hogy VPN kapcsolatot kell (lehet) kiépíteni, kivel, milyen módon? Honnan tudja az RRAS hogy mi van a „másik” alhálózatban? Honnan tudja az RRAS, hogy a másik alhálózatot a VPN kapcsolaton keresztül érheti el? Ezekre a kérdésekre kell sorban választ adnunk néhány varázsló segítségével. Új demand-dial kapcsolat létrehozása Tegyük fel, hogy a feladat a fentebb látható két

alhálózat (a központi 10.11x és a vidéki 1022x) összekapcsolása Ehhez mindkét kiszolgálóra telepítettük és konfiguráltuk már az RRAS szolgáltatást, VPN kiszolgáló üzemmódban. Természetesen rendelkezésünkre állnak az L2TP használatához szükséges tanúsítványok is. A következő lépés, hogy létrehozzuk a VPN automatikus felépítéséhez szükséges elemeket mindkét kiszolgálón. Ezek: • Egy úgynevezett „demand-dial interface”, ami gyakorlatilag megfelel az ügyfélgépeken a telefonos hálózati kapcsolat ikonjának, csak ezt az RRAS képes automatikusan tárcsázni • Egy felhasználónév arra az esetre, ha a távoli RRAS szeretne bejelentkezni hozzánk • Egy bejegyzés az útválasztási táblában, ami jelzi, hogy a távoli alhálózat a demand-dial kapcsolat túloldalán található Először hozzuk létre a VPN interfészt. Üljünk le a vidéki számítógép elé, és az RRAS konzolban a Routing Interfaces sorra kattintva válasszuk

a „New demand-dial interface” parancsot!  Az új VPN interfészt létrehozó varázsló A varázsló első kérdése a létrehozandó kapcsolat nevére vonatkozik. Azt hihetnénk, hogy bátran választhatunk bármit, azonban vigyázzunk: ha nem csak kitárcsázni szeretnénk, hanem a behívást is engedélyezzük, a varázsló ezt a nevet fogja adni a túloldali eszköz számára létrehozott felhasználónak. Ezért érdemes olyan nevet választani, ami utal a túloldali eszközre, nem tartalmaz szóközt és ékezetes betűket. Miután mi a vidéki router előtt ülünk, a név most legyen: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 14 NetAcademia-tudástár „KozpontiRouter”. Ezután kiválaszthatjuk a kívánt VPN protokoll típusát: PPTP, L2TP vagy automatikus, majd meg kell adnunk a túloldali VPN kiszolgáló külső IP címét, ahova az alagutat építeni fogjuk.  Hozzunk-e létre

helyi felhasználói fiókot a betárcsázó router számára? Ezután az ábrán is látható oldal következik: kérhetjük az IP és IPX csomagok továbbítását a kapcsolaton keresztül, valamint megkérhetjük a varázslót, hogy hozzon létre helyi felhasználót a távoli routertől beérkező hívások számára. Figyeljünk rá, hogy ez a felhasználó tagkiszolgálók esetén nem az Active Directory-ba, hanem a számítógép saját felhasználói adatbázisába kerül! Erre akkor kell figyelnünk, amikor majd a túloldalon meg kell adnunk a betárcsázáshoz szükséges felhasználónevet, jelszót és tartományt: ez utóbbi ekkor nyilván nem a Windows tartomány, hanem a számítógép neve lesz. (Természetesen a behíváshoz nem feltétlenül kell az így létrehozott felhasználóneveket használni, bármilyen fiók – tartományi is – megfelel, ha rendelkezik a megfelelő behívási jogosultságokkal). A következő két oldalon meg kell adnunk először az

újonnan létrehozott felhasználó jelszavát, majd a kitárcsázáshoz szükséges adatokat: felhasználónevet, tartományt és jelszót. A VPN interfész ezzel elkészült Végezzük el ugyanezeket a műveleteket a másik kiszolgálón is (persze értelemszerűen az ellentétes neveket választva). Az interfész ettől a pillanattól kezdve – bár még nem automatikusan, de kézzel – már csatlakoztatható.  Az interfész kézzel máris használható A Connect parancs segítségével próbáljunk aktiválni a VPN kapcsolatot. Ha munkánkat jól végeztük, néhány másodperc alatt a kapcsolat bármelyik irányba (de nem egyszerre!) kezdeményezve kiépül. Ezt az interfész Connection State oszlopának „Connected” értéke jelzi. Ha a csatlakozás nem sikeres, az „Unreachability Reason” (és az eseménynapló) elárulja nekünk, hogy mi lehet a probléma. Ha a felhasználónév / tartomány / jelszó nem megfelelő (emlékezzünk, hogy a varázsló csak akkor hoz

létre tartományi felhasználót, ha az RRAS tartományvezérlőn fut), akkor a Set Credentials parancs segítségével újra megadhatjuk ezeket az adatokat. Végül a Properties hatására előbukkanó dialógusablakban ellenőrizhetjük és módosíthatjuk a varázslóban megadott és egyéb tulajdonságokat (például hogy mennyi idő múlva szakítsa meg a kapcsolatot, ha nincs forgalom rajta). Figyelem! A VPN kapcsolat mindig legyen demand-dial, de a várakozási időt kikapcsolhatjuk. Érdemes az újratárcsázási beállításokat is áttekinteni Ne ijedjünk meg, ha a sikeresnek tűnő csatlakozás után a Remote Access Clients továbbra is 0 kapcsolatot jelez, a router-torouter kapcsolatot az RRAS itt nem számolja. Ha viszont a Ports sorra kattintunk, láthatjuk, milyen portok aktívak (rendezzük sorba ezeket is állapot szerint). Itt rögtön látszik az is, hogy PPTP vagy L2TP kapcsolatot sikerült kiépíteni Az L2TP kapcsolat előfeltételei és megoldásai pontosan

megegyeznek a korábban leírtakkal. Csatlakozási probléma tartományi fiókok esetén A legjobb szakemberekkel is megesik néha, hogy átsiklanak egy-egy, szinte minden oldalon hangsúlyozott szabály felett. Ha az RRAS telepítése után a csatornák felépítése nem sikerül, mégpedig az eseménynapló szerint azért, mert „a hitelesítő Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 15 NetAcademia-tudástár kiszolgáló nem elérhető” – nos akkor első dolgunk legyen ellenőrizni, hogy az RRAS kiszolgáló tagja-e az Active Directoryban található RAS and IAS Servers csoportnak.  Az RRAS kiszolgálót fel kell vennünk a tartományi „RAS and IAS Servers” csoportba A statikus útvonal felvétele Már csak egy dolog maradt hátra: megmagyarázni az RRAS-nak, hogy a távoli alhálózatokon milyen címtartomány található, illetve azt, hogy ha ide szeretnénk csomagokat küldeni,

akkor előtte fel kell építeni a VPN kapcsolatot, majd azon továbbítani az adatokat. Ezt statikus útválasztási útvonal (static route) létrehozásával tehetjük meg Emlékezzünk: a központi alhálózat címtartománya 10.11x, a vidékié pedig 1022x Mindkét kiszolgálón az „ellentétes” címtartományhoz kell majd hozzárendelnünk az előzőleg létrehozott demand-dial kapcsolatot. Az RRAS konzol „IP routing / Static Routes” során válasszuk a „New Static Route” parancsot.  Kőbe vésett útvonal: a 10.11x bizony a központi router felé keresendő Itt válasszuk ki a VPN interfészt, a Destination mezőbe írjuk be a távoli alhálózat hálózatazonosítóját és alhálózati maszkját, valamint hagyjuk bekapcsolva a „Use this rule to initiate demand-dial connections” opciót. Így az RRAS kiszolgáló, amikor a távoli hálózatba tartó csomagot észlel, felépíti a kapcsolatot és továbbítja – alagútban, titkosítva – az adatokat.

Ugyanezt a beállítást persze meg kell tennünk a másik kiszolgálón is. A puding próbája a ping Ezután már csak a puding próbája, a ping van hátra. Ha a VPN interfész épp aktív lenne, kapcsoljuk le, majd nyissunk egy parancssori ablakot és próbáljunk megpingelni egy „távoli” IP címet. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 16 NetAcademia-tudástár  A ping aktiválja a VPN-t győztünk! Míg a VPN kapcsolat inaktív, „Destination host unreachable” üzenetet kapunk, viszont ezalatt az RRAS elkezdi a kapcsolat felépítését („Connecting”). Ahogy a kapcsolat felépült, némi gondolkodás után a válaszok is visszaérkeznek: győztünk Következő számunkban a DNS, WINS és egyéb címzési mizériáknak, finomságoknak nézünk utána, valamint szó esik majd a RADIUS kiszolgálókról is. Addig is, jó alagutazást! folytatjuk Fülöp Miklós

mick@netacademia.net A cikkben szereplő URL-ek: [1] http://support.microsoftcom/defaultaspx? scid=kb;en-us;Q253498 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 17