System dost˛epu do laboratorium badawczego

(1)

System dost˛epu do laboratorium badawczego

Marcin Dziuba, Marek Michalski, Mariusz ˙

Zal

Politechnika Pozna´nska, Wydział Elektroniki i Telekomunikacji, Katedra Sieci Telekomunikacyjnych i Komputerowych ul. Polanka 3, 60-965 Pozna´n, e-mail: imie.nazwisko@put.poznan.pl, http://nss.et.put.poznan.pl

Streszczenie—Niniejszy artykuł prezentuje mechanizmy zwi ˛a-zane ze zdalnym dost˛epem stanowi ˛ace zało˙zenia oraz elementy uruchomione w ramach pilota˙zu projektu zdalnego laboratorium do testowania ró˙znych protokołów, mi˛edzy innymi OpenFlow. Głównym elementem laboratorium s ˛a komputery wyposa˙zone w karty NetFPGA z interfejsami o przepustowo´sci 1Gbps oraz 10Gbps i sterowniki protokołu OpenFlow, z ich wykorzystaniem powstaje sie´c do testowania całej rodziny protokołów i mechani-zmów zwi ˛azanych z OpenFlow. Tak przygotowane laboratorium ma by´c dost˛epne zdalnie dla szerokiego grona badaczy, in˙zynie-rów i naukowców oraz studentów.

I. WPROWADZENIE

Mechanizmy działaj ˛ace w sieci Internet s ˛a stale modyfi-kowane w celu usprawnienia jej działania lub wprowadzenia nowych usług. Obecnie mo˙zemy wyró˙znić dwa podej´scia do zmian sieci Internet. Pierwsze z nich, zwane sposobem ewo-lucyjnym, polega na wprowadzaniu zmian małymi krokami, których rezultatem b˛edzie po˙z ˛adana architektura docelowa. Sieć uzyskana w ten sposób zwana jest sieci ˛a NGN (Next Generation Network). Drugie podej´scie polega na całkowitym przeprojektowaniu sieci, rozpoczynaj ˛ac od punktu zerowego. Takie sposób zmian w internecie wymaga zaprojektowania wszystkich niezb˛ednych elementów od pocz ˛atku. Ma swoje wady i zalety. Z jednej strony nowa architektura nie jest ob-ci ˛a˙zona dziedzictwem poprzednich rozwi ˛azań, z drugiej strony usługi, które mogłyby być dostarczane w pocz ˛atkowej fazie b˛ed ˛a miały znikom ˛a liczb˛e odbiorców. Obecnie prace badaw-cze nad Internetem Przyszło´sci, zgodnie z podej´sciem rewo-lucyjnym, prowadzone s ˛a w ramach wielu projektów badaw-czych. W obszarze Unii Europejskiej, w ramach 7. Programu Ramowego w celu „Network in the Future" [1] zrealizowano wiele projektów mi˛edzy innymi: TRILOGY/TRILOGY2 [2], 4WARD [3], GEYERS [4] itd. Równie˙z poza obszarem UE prowadzone s ˛a prace badawcze w tym zakresie - w Japoni projekt AKARI [5] lub w USA projekt GENI [6]. Architektury sieci i stosowane w nich mechanizmy nazywane s ˛a siecia-mi NWGN (New Generation Networks). Dla sieci NWGN przewiduje si˛e równie˙z nowe modele biznesowe, które dodaj ˛a nowych graczy do tradycyjnych dostawców usług sieciowych oraz dostawców tre´sci i usług.

Równie˙z Zespoły Badawcze z Politechniki Pozna´nskiej bior ˛a udział w rozwoju Internetu Przyszło´sci. Jednym z ta-kich projektów jest projekt realizowany w Katedrze Sieci Telekomunikacyjnych i Komputerowych pt. „ ´Srodowisko te-stowe protokołów sieciowych na bazie systemu OpenFlow”. Głównym celem projektu s ˛a badania nad nowymi protokołami i algorytmami steruj ˛acymi w ´srodowisku OpenFlow, które pozwala na ujednolicenie podej´scia do zagadnie´n zwi ˛azanych

z komutacj ˛a kanałów i komutacj ˛a pakietów w przeł ˛acznikach sieciowych. System OpenFlow dostarcza tak˙ze narz˛edzi nie-zb˛ednych dla wirtualizacji sieci. Wirtualizacja sieci, jak rów-nie˙z narz˛edzia jej słu˙z ˛ace s ˛a kluczowym elementem dla rozwo-ju Internetu Przyszło´sci. Cel główny został podzielony na dwa cele podrz˛edne. Pierwszym z nich jest opracowanie nowych metod transmisji danych, protokołów oraz algorytmów stero-wania dla w˛ezłów w sieciach pakietowych oraz przygotowanie eksperymentów maj ˛acych na celu zweryﬁkowanie poprawno-´sci proponowanych rozwi ˛aza´n. Drugim, równorz˛ednym celem jest opracowanie i implementacja ´srodowiska testowego, które pozwoli na przeprowadzenie planowanych jak i przyszłych eksperymentów z zakresu Internetu Przyszło´sci.

W artykule przedstawiono jeden z elementów realizowanego projektu - mechanizmy zdalnego dost˛epu do sieci ekspery-mentalnej. Pozostała cz˛e´sci artykułu została zorganizowana w nast˛epuj ˛acy sposób. W rozdziale II przedstawiono zasad˛e dzia-łania sieci wirtualnych oraz korzy´sci płyn ˛ace z ich stosowania. Kolejny rozdział zawiera zało˙zenia realizowanego projektu w zakresie zdalnego dost˛epu do sieci eksperymentalnej. W nast˛epnym rozdziale opisano laboratorium, w którym realizo-wane b˛ed ˛a eksperymenty z zakresu Internetu Przyszło´sci [7]. Cała idea zdalnego dost˛epu do laboratorium oraz wykorzysty-wane mechanizmy zostały opisane w rozdziale V. Rozdział VI zawiera podsumowanie oraz wskazuje dalsze kierunki rozwoju projektu.

II. WIRTUALNE SIECI PRYWATNE-OPIS OGÓLNY Współcze´snie wirtualizacja pojawia si˛e w wielu aspektach technicznych. Jest obecna pod wieloma postaciami. Mo˙zna wyró˙znić dwa główne nurty. Pierwszy z nich to wirtualizacja zasobów. Polega to na tym, ˙ze jeden, du˙zy, zbiór zasobów zostaje podzielony na mniejsze, niezale˙zne, podzbiory, które z punktu widzenia u˙zytkowania s ˛a odseparowane od innych u˙zytkowników (np. pojemno´sć ł ˛acza telekomunikacyjnego, dysku serwera, mocy obliczeniowej). W takiej sytuacji nale˙zy zwrócić uwag˛e na kilka istotnych parametrów realizacji tak poj˛etej wirtualizacji, np. separacja wydajno´sci. Taka wirtuali-zacja jest szeroko wykorzystywana, istnieje wiele narz˛edzi j ˛a realizuj ˛acych i wspieraj ˛acych. Drugim rodzajem wirtualizacji jest logiczny rozdział niefizycznych zasobów, np., przestrzeni nazw, adresów itp. Umo˙zliwia on współdzielenie zasobów fizycznych w taki sposób, ˙ze nie ma wzajemnego wpływu kon-figuracji poszczególnych u˙zytkowników. Najprostszym, wr˛ecz typowym przykładem, s ˛a wirtualne sieci lokalne (Virtual Local Area Network - VLAN), które powstaj ˛a przez portów w prze-ł ˛aczniku lokalnego segmentu sieci LAN do wyimaginowanej

(2)

Rysunek 1. Schemat poł ˛aczenia z wykorzystaniem VPN sieci LAN charakteryzowanej numerem. W tym przypadku zasoby fizyczne (takie jak pami˛eć przeł ˛acznika, bufory, prze-pustowo´sć ł ˛aczy i matrycy przeł ˛aczaj ˛acej) s ˛a współdzielone, natomiast logicznie urz ˛adzenia b˛ed ˛ace w ró˙znych VLANach nie maj ˛a ze sob ˛a bezpo´sredniej (na poziomie warstwy ł ˛acza danych) ł ˛aczno´sci. Innym rodzajem wirtualnych sieci s ˛a wir-tualne sieci prywatne (Virtual Private Networks - VPN). Ich wirtualizacja polega na logicznym poł ˛aczeniu fizycznie odle-głych zasobów. Dzi˛eki temu znikaj ˛a ograniczenia wynikaj ˛ace z fizycznego poło˙zenia, natomiast hosty b˛ed ˛ace w takiej sieci mog ˛a być skonfigurowane tak, jakby logicznie były wpi˛ete bezpo´srednio do sieci, z któr ˛a s ˛a poł ˛aczone. Sytuacj˛e tak ˛a przedstawiono na rysunku 1. Odpowiednie oprogramowanie umo˙zliwia klientowi zestawienie tunelu do serwera VPN i dzi˛eki temu ma on mo˙zliwo´sć korzystania z sieci laboratorium tak, jakby był wpiety do niej bezpo´srednio.

III. WYBRANE ZAŁO ˙ZENIA PROJEKTU

Głównym celem projektu jest udost˛epnienie w kontrolowa-ny sposób struktury laboratoryjnej badaczom i naukowcom, którzy uzyskaj ˛a akceptacj˛e planowanych badań. Wa˙znym ele-mentem jest bezpieczeństwo sprz˛etu oraz kontrola dost˛epu. Jednocze´snie istotna jest poufno´sć i autentyczno´sć przeka-zywanych informacji mi˛edzy zdalnym naukowcem a labora-torium, a tak˙ze bezpieczeństwo wyników przeprowadzanych badań. Zakładamy wst˛epn ˛a weryfikacj˛e oraz monitoring czyn-no´sci, które b˛ed ˛a realizowane przez zdalnych badaczy w na-szym laboratorium. Kwestia poufno´sci uzyskanych rezultatów wykracza poza techniczne aspekty i nie b˛edzie dyskutowana w niniejszym artykule.

Badacze, którzy zostan ˛a zaakceptowani do współpracy, uzyskaj ˛a szeroki dost˛ep do wyodr˛ebnionej cz˛e´sci laborato-rium, który pozwoli przeprowadzić zaplanowane eksperymen-ty. Techniczne mo˙zliwo´sci naszego laboratorium pozwalaj ˛a na przygotowanie oraz uruchomienie nawet bardzo zło˙zonych do-´swiadczeń i eksperymentów sieciowych. Mo˙zemy udost˛epnić hosty zarówno fizyczne jak i wirtualne, ale przede wszystkim sieć testow ˛a zbudowan ˛a z w pełni programowalnych w˛ezłów sieciowych pozwalaj ˛acych na tworzenie ró˙znych topologii sieciowych przez zdaln ˛a konfiguracj˛e w˛ezłów.

Aktualnie laboratorium jest dost˛epne dla badaczy prowadz ˛ a-cych prace w ramach projektu Alien [8], a tak˙ze dla studentów podczas niektórych zaj˛e´c laboratoryjnych i w celu przeprowa-dzenia bada´n pod k ˛atem prowadzonych prac dyplomowych. Zdalny dost˛ep do laboratorium wykorzystywany jest głównie

do realizacji prac zwi ˛azanych z badaniami wykorzystania protokołu OpenFlow [9].

IV. LABORATORIUM PROJEKTOWE

Struktura laboratorium jest heterogeniczna. Obok typowych urz ˛adzeń sieciowych (rutery i przeł ˛aczniki wielu ró˙znych firm) oraz hostów (fizycznych oraz wirtualnych) dost˛epne s ˛a bardzo nowoczesne urz ˛adzenia deweloperskie o ogromnym potencjalne naukowym i badawczym. S ˛a to komputery wy-posa˙zone w karty NetFPGA [10], procesory sieciowe [11] oraz urz ˛adzenia pomiarowe [12]. Karty NetFPGA s ˛a kartami rozszerzeń do komputerów PC, posiadaj ˛a po cztery interfejsy sieciowe. Ich główny układ jest programowalny, dzi˛eki temu mo˙zna przygotowywać i uruchamiać instancje zmodyfikowa-nych protokołów sieciowych lub ich prototypy. Aktualnie w laboratorium posiadamy 12 kart NetFPGA z interfejsami o przepustowo´sci 1Gbps oraz 5 kart o przepustowo´sci 10Gbps. Wa˙znym elementem laboratorium jest generator i analizator ruchu sieciowego - Spirent Test Center [12]. Wi˛ekszo´sć po-miarów b˛edzie dokonywana za pomoc ˛a narz˛edzi autorskich, jednak dokładne pomiary przepustowo´sci i opó´znienia mog ˛a być zrealizowane przy u˙zyciu certyfikowanego, referencyjne-go, urz ˛adzenia pomiarowego.

V. WYKORZYSTANIE MECHANIZMÓWVPN

Wirtualna sieć prywatna VPN (ang. Virtual Private Ne-twork) została utworzona na potrzeby zdalnego dost˛epu do za-sobów sprz˛etowych znajduj ˛acych si˛e w laboratorium. W głów-nej mierze chodziło o zabezpieczenie danych przesyłanych sieci ˛a publiczn ˛a pomi˛edzy u˙zytkownikiem, a serwerem VPN działaj ˛acym w laboratorium. Zastosowanie wirtualnej sieci dało mo˙zliwo´sć kodowania przesyłanych danych oraz przesy-łania ich transparentnie przez w˛ezły sieci publiczej. Schemat zdalnego poł ˛aczenia do laboratorium z wykorzystaniem VPN-a zostVPN-ał przedstVPN-awiony nVPN-a rysunku 1. JVPN-ak mo˙znVPN-a zVPN-auwVPN-a˙zyć z rysunku 1, wszystkie poł ˛aczenia z wykorzystaniem VPN-a maj ˛a całkowit ˛a izolacj˛e od sieci publicznej. Wykorzystanym rodzajem VPNa jest OpenVPN [13]. Jest to darmowy pakiet oprogramowania, dzi˛eki któremu mo˙zna tworzyć bezpieczne poł ˛aczenia typu punkt-punkt lub sieć-sieć. W celu zestawia-nia zaszyfrowanych poł ˛aczeń pomi˛edzy hostami, OpenVPN wykorzystuje bibliotek˛e OpenSSL [14], która swoje działanie opiera na protokołach SSLv3 oraz TLSv1.

W laboratorium został przygotowany sprz˛et komputerowy, na którym zainstalowano system operacyjny Fedora 15x64. Na tak skonfigurowanym ´srodowisku zainstalowano serwer OpenVPN. Konfiguracja serwera przebiega poprzez modyfi-kacj˛e skrypu uruchamianego podczas startu serwera. Przykład takiego skrytu przedstawiono na rysunku 2.

W linii 2 oraz 3 zostało okre´slone na jakim porcie ma działa´c serwer (1180) oraz wykorzystywany protokół warstwy transportowej (UDP). Kolejna linie deﬁniuje w jakim trybie pracuje serwer VPN. W prezentowanym przykładzie jest to tryb mostkowania (tap). Jest to tryb, w którym klient jest podł ˛aczony bezpo´srednio do sieci LAN serwera. Podł ˛aczony

(3)

Rysunek 2. Plik konﬁguracyjny serwera

klient otrzymuje ten sam adres co pozostałe urz ˛adzenia pod-ł ˛aczone do servera. Tryb mostkowania wymaga zestawienia mostka pomi˛edzy wirtualnym interfejsem OpenVPN (tap0), a interfejsem maj ˛acym dost˛ep do sieci LAN serwera. Linie 6-9 wzkazuj ˛a na miejsce, gdzie zostały zapisane pliki certyfikuj ˛ace dla serwera. Kolejne linie (12-13) okre´slaj ˛a w jakim trybie ma działać serwer (tryb mostkowania). Wewn˛etrzny adres IP serwera to 10.3.3.1, a klienci b˛ed ˛a otrzymywali adresy z zakresu 10.3.3.10-10.3.3.30. Wpisy w liniach 15-19 okre´slaj ˛a dokładnie adresy sieci do jakich podł ˛aczony klient b˛edzie miał dost˛ep. Ostatnimi wa˙znymi wpisami w pliku konfiguracyjnym s ˛a linie 26 oraz 27. S ˛a to polecenia odpowiedzialne za dokonywanie wpisów w osobnych plikach logowania. Pliki te zawieraj ˛a informacje o zalogowanych klientach oraz prze-chowuj ˛a informacje o wcze´sniejszych logowaniach klientów. Przechowywane informacje pozwalaj ˛a administratorowi zwe-ryfikować, jazy klienci ł ˛aczyli si˛e ł ˛aczyli si˛e z serwerem VPN. Generowanie kont klienckich, pozwalaj ˛acych na zdalne ł ˛ a-czenie si˛e z serwerem VPN, nie nale˙zy do rzeczy łatwych. Szczególnie uci ˛a˙zliwe dla administratora było tworzenie kilku-nastu kont jednorazowo, gdzie nale˙zy podawać nazw˛e ka˙zdego konta oraz podpisywać potrzebne ceftyfikaty. W celu uła-twienia procedury generowania konta, został zaprojektowany i utworzony specjalny system, który w znaczny sposób uła-twia ten proces. Do przygotowania działaj ˛acego konta VPN, niezb˛edne s ˛a cztery pliki, z których trzy s ˛a plikami certy-fikuj ˛acymi klienta, a ostatni konfiguruje ustawienia klienta VPN. Wszystkie pliki mog ˛a zostać utworzone przez kilenta z wykorzystaniem przygtowanego systemu. Potrzebne jest zało˙zenie własnego konta systemowego oraz zalogowanie si˛e do systemu. Na potrzeby, wspomnianego wcze´sniej systemu,

przygotowano baz˛e danych, w której zapisywane s ˛a dane klientów VPN, oraz dane wszystkich wygenerowanych kont VPN. Serwer bazy danych został zainstalowany i uruchomiony na tej samem maszynie, na której równolegle działa serwer VPN. Na rysunku 3 zaprezentowano stron˛e logowania klienta do systemu oraz stron˛e, na której podaj ˛ac własne dane mo˙zna zało˙zy´c konto systemowe.

Rysunek 3. Strona logowania i tworzenia konta w systemie Po pomy´slnej procedurze rejestracyjnej i weryfikacji danych przez administratora, badacz ma dost˛ep do wszystkich zaso-bów i mo˙zliwo´sci systemu automatycznej generacji kont. Na rysunku 4 przedstawiono stron˛e główn ˛a systemu, na której umieszczono opis laboratorium oraz sprz˛etu znajduj ˛acego si˛e w laboratorium badawczym. Przechodz ˛ac do odpowiedniej zakładni mo˙zna znale´zć dane kontaktowe do administratora systemu, podejrzeć jakie konta istniej ˛a, pobrać ponownie pliki konta VPN, usun ˛ać własne konto VPN b ˛ad´z wylogować si˛e ze strony.

Jedn ˛a z najwa˙zniejszych opcji, jaka była opisywana wcze-´sniej, jest mo˙zliwo´sć generowania własnych kont VPN. Jest to mo˙zliwe za pomoc ˛a formularza dost˛epnego w zakładce Załó˙z konto VPN. Rysunek 5 przedstawia formularz, który nale˙zy uzupełnić w celu wygenerowania odpowiedniego konta. Oprócz danych osobowych, niezb˛edne jest wybranie sieci do której u˙zytkownik chce mieć dost˛ep. W celu zapewnienia bezpeiczeństwa oraz porz ˛adku w sieci laboratoryjnej, zdecy-dowano, ˙ze ka˙zde urz ˛adzenie, które jest osi ˛agalne w zdalnym dost˛epie, działa w osobnej wewn˛etrznej sieci. Dla przykładu, je´sli u˙zytkownik chce mieć dost˛ep do kart NetFPGA [10], musi wygenerować konto, które da mu mo˙zliwo´sć dost˛epu do sieci 7.7.7.0/24. Po wypełnieniu formularza nale˙zy u˙zyć przycisku Utwórz konto VPN aby otrzymać skonfigurowane konto. W tym czasie system uruchamia odpowiednie skryp-ty generuj ˛ace pliki certyfikuj ˛ace. Uruchamiany jest równie˙z specjalnie przygotowany program, pozwalaj ˛acy na wygenero-wanie pliku konfiguracyjnego klienta VPN. Po pomy´slnej

(4)

pro-Rysunek 4. Główna strona automatycznego systemu generowania kont cedurze tworzenia konta VPN oraz podpisaniu odpowiednich certfikatów zostaje przygotowane nowe konto VPN, daj ˛ace dost˛ep do serwera VPN działaj ˛acego w laboratorium. Konto jest wa˙zne przez pewien okres czasu, zale˙zny od konfogu-racji serwera. Je´sli czas ten upłynie, wówczas konto traci wa˙zno´sć i nie daje mo˙zliwo´sci poł ˛aczenia si˛e z serwerem. Konto mo˙ze zostać usuni˛ete równie˙z przy pomocy systemu automatycznego tworzenia kont. Na stronie systemowej znaj-suje si˛e specjalna zakładka, która daje mo˙zliwo´sć przegl ˛ a-dania istniej ˛acych ju˙z kont oraz ich usuwania przy pomocy odpowiedniego przycisku. Ta funkcja pozwala na usuwanie kont wykorzytywanych na zaj˛eciach ze studentami. Je´sli konta zostały u˙zyte na zaj˛eciach, to w celach bezpieczeństwa mog ˛a zostać usuni˛ete przez administratora lub prowadz ˛acego zaj˛ecia, który wcze´sniej wygenerował konta dla studentów.

Rysunek 5. Formularz tworzenia nowego konta VPN

Ł ˛aczenie z serwerem odbywa si˛e przy pomocy specjalnej aplikacji o nazwie OpenVPN GUI wykorzystuj ˛acej pliki kon-figuracyjne aktywnych kont VPN. Po udanej procedurze insta-lacyjnej oprogramowania kliencikiego w systemie Windows, nale˙zy umie´scić plik konfiguracyjny klienta oraz pliki certyfi-kuj ˛ace w katalogu config, który znajduje si˛e w drzewie kata-logów oprogramowania OpenVPN GUI. Dwukrotne klikli˛ecie

na ikon˛e aplikacji OpenVPN GUI, spowoduje pojawienie si˛e dodatkowej mniejszej ikonki z prawej strony, dolnego paska narz˛edzi. Mniejsza ikonka pozwala na wybranie konta, któ-re dany klient chce wykorzysta´c. Weryﬁkacj ˛a prawidłowego poł ˛aczenia jest sprawdzenie tablicy routingu na komputerze klienckim. Przykład tablicy przedstawiono na rysunku 6.

Rysunek 6. Przykład tablicy routingu klienta po poł ˛aczeniu z serwerem VPN Jak mo˙zna zauwa˙zyć, dodane zostały dwie trasy do sieci 7.7.7.0/24 oraz 10.3.3.0/24. Sieci te s ˛a osi ˛agalne przez bram˛e, której adres IP jest to˙zsamy z adresem servera VPN. Bra-ma jest osi ˛agalna przez interfejs komputera klienciekiego o adresie 10.3.3.18. Kolejne dwie sieci 150.254.11.0/24 oraz 150.254.29.0 równie˙z s ˛a osi ˛agalne przez server VPN oraz interfejs 10.3.3.18. Dwie ostatnie sieci s ˛a sieciami z puli sieci Politechniki Poznańskiej. Dzi˛eki ł ˛aczeniu si˛e z tymi sieciami przez server VPN, zapewniane jest bezpieczeństwo danych poprzez ich szyfrowanie. Wszystkie trasy s ˛a automatycznie dodawane po pomy´slnym poł ˛aczeniu z zerwerem VPN. To ser-wer poprzez swoj ˛a odpowiedni ˛a konfiguracj˛e wymusza dodat-kowe wpisy w tablicy routingu klienta. Server VPN odpowiada równie˙z za utworzenie wirtualnego (programowego) interfejsu, na który kierowany jest cały ruch danych dedykowany do sieci zwi ˛azanych z serwerem VPN.

VI. PODSUMOWANIE I DALSZE PRACE

Przedstawione mechanizmy zostały uruchomione i prze-testowane niezale˙znie (nale˙zy zwrócić uwag˛e, i˙z z powodu ogólnie poj˛etego bezpieczeństwa, publiczne adresy IP oraz nymery portów, jak i pewne wra˙zliwe informacje, zostały zmienione lub pomini˛ete). Pierwszym wydarzeniem, podczas którego przygotowane mechanizmy zostały wykorzystane, by-ły pi˛eciodniowe warsztaty z programowania i wykorzystania kart NetFPGA [15], [16]. Odbyły si˛e one w salach labora-toryjnych Wydziału Elektroniki i Telekomunikacji Politech-niki Poznańskiej w maju 2013 roku, zostały one zorgani-zowane przy współpracy pracowników Katedry Sieci Tele-komunikacyjnych oraz Computer Laboratory University of Cambridge [17]. Podczas przygotowań do nich instruktorzy z Cambridge mieli zdalny dost˛ep do wewn˛etrznej sieci IP i urz ˛adzeń znajduj ˛acych si˛e w laboratorium. Dzi˛eki temu mogli na bie˙z ˛aco weryfikować konfiguracj˛e topologii podczas jej przygotowywania do zaj˛eć laboratoryjnych. Równie˙z uczest-nicy warsztatów, nocy mieli dost˛ep poprzez SSH oraz X-tunneling do maszyn, na których pracowali. Pozwalało im to przeprowadzać i nadzorować długotrwałe operacje symulacji, testów i syntezy przygotowywanych projektów. Ł ˛acznie z instruktorami, w szczytowym momencie w sieci było ak-tywnych 30 zdalnych u˙zytkowników. Testy zaawansowanej

(5)

funkcjonalno´sci zdalnego dost˛epu wykonywane s ˛a na bie˙z ˛aco przez pracowników katedry, którzy s ˛a zarówno twórcami tego systemu, jak i jego pierwszymi u˙zytkownikami. Takie podej´scie pozwala zweryfikować poprawno´sć działania oraz na bie˙z ˛aco rozbudowywać funkcjonalno´sć systemu. Zdalny dost˛ep przedstawiony w niniejszym artykule jest regularnie wykorzystywany podczas zaj˛eć laboratoryjnych ze studentami. Pozwala to zrealizować wiele praktycznych ćwiczeń i wyko-rzystać ró˙znorodne mechanizmy sieciowe. Przy wykorzystaniu odpowiednio przygotowanych kont VPN niektórzy studenci maj ˛a nieograniczony czasowo dost˛ep do wybranych urz ˛adzeń laboratoryjnych w celu realizacji badań i eksperymentów przeprowadzanych na potrzeby ich prac dyplomowych. Wyko-rzystanie zdalnego dost˛epu zwalnia z obowi ˛azku bezpo´sredniej obecno´sci w laboratorium pracownika pilnuj ˛acego studentów, natomiast samym studentom daje ogromn ˛a elastyczno´sć w planowaniu własnych działań. Równie˙z pracownicy ch˛etnie wykorzystuj ˛a zdalny dost˛ep, gdy˙z pozwala on w pełni ko-rzystać z laboratorium, a nie zmusza do fizycznej w nim obecno´sci, co mo˙ze być kłopotliwe, szczególnie w godzinach wieczornych i nocnych.

VII. PODZI ˛EKOWANIA

Projekt został sﬁnansowany ze ´srodków Narodowego Cen-trum Nauki przyznanych na podstawie decyzji numer DEC-2011/01/B/ST7/03959

LITERATURA

[1] Decision No. 1982/2006/Ec of the European Parliament and of the Coun-cil of 18 December 2006 concerning the Seventh Framework Programme of the European Community for research, technological development and demonstration activities (2007-2013). December 2006.

[2] TRILOGY2 , Dost˛epne na stronie: http://http://www.trilogy2.it.uc3m.es [Stan z dnia: 2013-11-03].

[3] 4WARD, Dost˛epne na stronie: http://www.4ward-project.eu [Stan z dnia: 2013-11-03].

[4] GEYSERS, Dost˛epne na stronie: http://www.geysers.eu [Stan z dnia: 2013-11-03].

[5] AKARI, Dost˛epne na stronie: http://akari-project.nict.go.jp [Stan z dnia: 2013-11-03].

[6] GENI, Dost˛epne na stronie: http://www.geni.net [Stan z dnia: 2013-11-03].

[7] Strona projektu „In˙zynieria Internetu Przyszło´sci” http://www.iip.net.pl [Stan z dnia: 2013-11-03].

[8] Strona projektu „Alien - Abstraction Layer For Implementation Of

Extensions In Programmable Networks” http://www.fp7-alien.eu/ [Stan

z dnia: 2013-11-03].

[9] Strona projektu „ ´Srodowisko testowe protokołów sieciowych na bazie systemu OpenFlow” http://openﬂow.et.put.poznan.pl [Stan z dnia:

2013-11-03].

[10] Główna strona po´swi˛econa kartom NetFPGA http://netfpga.org/ [Stan z dnia: 2013-11-03].

[11] Strona produktu NP3 ﬁrmy EzChip - Network Processor http://www. ezchip.com/p_np3.htm [Stan z dnia: 2013-11-03].

[12] Strona produktu Spirent Test Center http://www.spirent.com/Products/ Spirent-TestCenter_Live [Stan z dnia: 2013-11-03].

[13] Główna strona Openvpn http://openvpn.net/ [Stan z dnia: 2013-11-03]. [14] Główna strona Openssl http://openssl.org/

[15] Strona informacyja warsztatów NetFPGA http://www.netfpga.pl. [16] Wydarzenia organizowane w ramach projektu NetFPGA

http://netfpga.org/events.html [Stan z dnia: 2013-11-03].

[17] Główna strona www Computer Laboratory, Faculty of Computer Science and Technology, University of Cambridge http://www.cl.cam.ac.uk/ [Stan z dnia: 2013-11-03].