Virtuální laboratoř počítačových sítí, Implementace konektorů pro dynamické propojování distribuovaných virtuálních topologií v systému Virtlab
Z VirtlabWiki
(Rozdíly mezi verzemi)
| Verze z 18:16, 27. 8. 2008 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání |
Verze z 08:37, 25. 8. 2009 Gry72 (Diskuse | příspěvky) (→Ke zvážení) Následující porovnání → |
||
| Řádka 1: | Řádka 1: | ||
| - | {|align=right | + | == Pokyny k vypracování == |
| - | |__TOC__ | + | |
| - | |} | + | |
| - | [[Image:Eng.gif]] | + | * Doplnit do GUI: |
| - | ; [[Brief Project Overview in English]] | + | ** dát k dispozici seznam všech probíhajících rezervací s konektory (ze všech lokalit), na které se uživatel může potenciálně připojit (vyfiltrováno přes ACL). Konektory uživateli zobrazovat podle jejich logického pojmenování v log. topologii. ACL uchovávat asi v databázi (ResID x ConnID x ACL regexp) |
| - | ; [[Media:Prezentace-ENG.pdf|Project Presentation in English]] | + | *** pro dotazy mezi lokalitami využít SOAP API. Lokalita, ze které se iniciovala rezervace, bude umět pro zadané ResID poskytnout aktuální namapování konektorů (s čím jsou spojeny, ať už vedou do vlastní nebo do cizích lokalit) + interval platnosti ResID |
| - | ==Úvodem== | + | ** možnost zobrazit si konektory konkrétní topologie vybrané z tohoto seznamu |
| + | ** možnost zobrazit si mé konektory a přiřadit k nim připojené konektory z jiných paralelně existujících topologií | ||
| + | ** online informace uživatelům, kdo a čím se napojil/odpojil na konektory jejich rezervace | ||
| + | ** při rezervaci topologie možnost stanovit komu bude dovoleno připojit se na konektory rezervované topologie (asi regulárním výrazem na login jméno, lokalitu, možná již využít nový systém skupin) | ||
| - | Smyslem projektu '''Virtlab''' je zpřístupnit laboratorní prvky pro praktickou výuku počítačových sítí '''vzdáleně prostřednictvím Internetu'''. Studenti si mohou pomocí WWW rozhraní rezervovat laboratorní prvky na určitý časový interval a následně k nim přistupovat pomocí běžného WWW prohlížeče s podporou Java appletů. Propojení laboratorních prvků se uskuteční '''automaticky podle výběru konkrétní úlohy''' ze souboru nabízených laboratorních úloh, nebo si student může zadat '''svou vlastní topologii'''. | + | * Do vybavení.xml definovat v každé lokalitě několik konektorů s interface typu serial (sint) a Ethernet (eint) |
| - | [[Image:virtlab_architektura.jpg|thumb|center|500px|Základní architektura]] | + | * Vytvořit modul tunelovacího serveru přijímající provoz pro rozhraní cint a sint. |
| + | ** Použít CLI tunelovacího serveru pro definici (časově omezeného) aktuálního propojení konektorů. | ||
| + | *** Možná pouze použítexistující příkaz redir. Rámec putující po cestě | ||
| - | Systém nyní dovoluje '''spolupráci více lokalit''' vzájemně sdílejících síťové prvky a realizaci '''virtuálních síťových topologií přes Internet'''. Fyzické síťové prvky nutné pro vytvoření studentem vybrané topologie jsou v době rezervace '''vyhledávány dynamicky''' ve všech lokalitách. | + | R1:e1@L1 - c1:eint1@L1 - c2:eint2@L2 - R2:e2@L2 |
| + | : se bude směrovat neustále podle cílového rozhraní do správného modulu tunelovacího serveru příslušné lokality (takže vždy projde dovnitř a ven modulu konektoru pro každý konektor) | ||
| - | ==Historie== | + | * Abychom mohli konektory vzájemně propojovat normální položkou v RedirectTable, zavedeme u každého konektoru pseudointerface iint vedoucí do Internetu. Nebude ve vybaveni.xml, aby na konektory nikdo nenapojoval více než jednu linku. Pokud bude mít provoz z konektoru odejít zase na konektor, doplní tunelovací server jako zdrojový i cílový interface řetězec iint. Modul konektorů v tunelovacím serveru zaregistruje rozhraní iint jako další rozhraní, které umí obsluhovat. |
| - | Myšlenka virtuální laboratoře se vyvinula z potřeby poskytnout možnost řešení praktických laboratorních úloh studentům kombinovaného studia a také zpřístupnit jinak méně využité a často nákladné laboratorní síťové prvky pro samostatnou práci v časech mimo výuku. | + | * Další komentáře |
| + | ** Zvážit možnost implementace konektoru na Internet (parametrizovatelná port-forwardning komponenta s jednou veřejnou adresou ?) | ||
| + | *** možná jen pro směr ven, za NATem (jedna veřejná adresa, vhodně omezená) | ||
| + | *** Z důvodu řešení případných bezpečnostních incidentů nutno mít možnost zjistit, kdo (ze které rezervace) šel kdy pod veřejnou adresou půjčenou z NAT ven. | ||
| + | ** Zamyslet se nad problémem možných smyček v topologii vzniklé propojením konektorů (asi nevadí, v lokálním případě také řeeeno jen rate limitingem na VLMUXu a přirozeným omezením kapacitou tunelovacího serveru) | ||
| + | *** Řešit patrně reaktivně (rozšíření paketu tunserveru o options s původním src a dst, pak mechanismem EBGP filtrovat), příp. proaktivně hledáním potenciální smyčky při zapojování konektoru za runtime | ||
| + | ** Optimálně by měly být použité fyzické konektory mapovány tak, aby byly ze stejné lokality jako prvek, kam je konektor v log. topologii) napojen. Toto ale bude řešeno v mapovacím algoritmu. Cílem je zajistit, abychom provoz mezi dvěmi prvky v téže lokalitě spojenými konektory neposílali přes fyzické konektor namapovaný do jiné lokality. | ||
| + | * Konektory na úrovni logické topologie patrně nedělit na násobné a jednoduché, rozdělit až za runtime, když se konektor "exportuje" - max. počet cizích připojených konektorů (spolu s regexpem na jméno uživatele) | ||
| + | * Možnost vstoupit do topologie za konektorem tím, že mne její vlastník po žádosti přidá k rezervaaci jako kolegu (ze své nebo cizí lokality) | ||
| + | * Vizualizace koberců topologií propojených přes konektory - možná hierarchicke grafy. Zatím např. jen textové zobrazení, v navazujících DP možno řešit grafické zobrazení | ||
| - | Její vznik inicioval [[Uživatel:Gry72|Petr Grygárek]] a postupně ji realizuje s pomocí '''diplomantů''', zejména inženýrského studia, na '''katedře informatiky'''. Základní koncepce systému byla definována '''v roce 2005''' v diplomové práci [[Uživatel:Nem114|Pavla Němce]], který implementoval i základní prototyp aplikace. O rok později prototyp rozšířil formou diplomové práce [[Uživatel:Kub348|Roman Kubín]], který implementoval bezpečnostní prvky, podporu práce studentů s tutorem a v návaznosti na [[ASSSK | Automatizovaný systém správy síťových konfigurací]] (ASSSK a.k.a. Tatabazmek) vyvinutý v rámci diplomové práce Davida Seidla možnost '''definice vlastní topologie''' propojení síťových prvků podle přání studenta. | ||
| - | Koncepci automatizovaného systému pro spojování topologií poté Petr Grygárek zobecnil, aby bylo možné propojovat '''nejen sériové porty, ale i Ethernet porty včetně trunk spojů'''. Příslušné konfigurační skripty implementoval [[Uživatel:Dvo139|Jiří Dvořák]], čímž vzniklo tzv. '''virtuální spojovací pole'''. Později byla s pomocí [[Uživatel:kuc274|Tomáše Kučery]] do systému implementovány pracovní stanice simulované s použitím instancí '''User Mode Linux''' a za podpory Jiřího Dvořáka také '''virtuální směrovače Cisco 7200''' realizované s použitím projektu '''DynaMIPS/DynaGen'''. [[Uživatel:mil051|Martin Milata]] následně nahradil simulaci stanic pomocí UML použitím '''XEN''', který se ukázal se systémem Virtlab lépe integrovatelný (přístup na konzole pomocí čistého TCP spojení). | + | == Ke zvážení == |
| - | + | * Kolegové v rezervaci - definovat způsob práce s konektory (stejná práva jako vlastník rezervace ? nebo např. nemohou definovat filtry apod., ale mohou připojovat/odpojovat - asi nepraktické) | |
| - | Diplomant Ing. Davida Seidla Petr Sedlář v roce 2007 reimplementoval ASSSK-1 s použitím FPGA (nové zařízení je nazýváno ASSSK-2), což zjednodušilo opakovanou realizaci a řešení výrazně zlevnilo. Ve stejné době dokončili diplomanti [[Uživatel:Vav166|Jan Vavříček]] a [[Uživatel:hra196|Tomáš Hrabálek]] na '''distribuované verzi''' Virtlabu, která umožňuje vytvářet rozsáhlejší topologie z laboratorních prvků umístěných v '''několika lokalitách''' připojených k Internetu a optimálně mapovat fyzické laboratorní prvky pro topologie úloh paralelně požadovaných různými studenty. [[Uživatel:Dvo139|Jiří Dvořák]] reimplementoval podle návrhu Petra Grygárka konfigurační skripty spojovacího pole pro podporu více lokalit, což umožnilo vytváření virtuálních topologií přes Internet pomocí tunelovacího serveru Tomáše Hrabálka. Spojovací systém je nyní nazýván '''distribuovaným virtuálním spojovacím polem''', které dovoluje tunelovat provoz mezi '''segmenty''' virtuálního spojovacího pole umístěnými v jednotlivých lokalitách. | + | * Práce s konektory u uživatelů přizvaných s jiných lokalit |
| - | + | * Dotazy na aktuálně dostupné konektory v cizích lokalitách - pro unifikaci/enkapsulaci se ptát stejným způsobem (přes SOAP) i své lokality | |
| - | ==Aktuální vývoj (duben 2008)== | + | ** Funkce vrátí i konektory právě dostupné od připojených PT |
| - | + | * Sémantika násobných konektorů (jak se přeposílá provoz z připojeného konektoru na připojený konektor a zda se duplikuje provoz od zařízení připojeného na násobný konektor na všechny napojené konektory | |
| - | V současné době je provozována distribuovaná virtální laboratoř mezi VŠB-TU Ostrava a SLU OPF v Karviné. Distribuovaná topologie byla vybudována '''s podporou grantu Fondu rozvoje sdružení Cesnet č. 213/2006'''. | + | ** nutno zabránit smyčkám v šíření rámců (přes zdrojový port i mimo něj) a duplikacím |
| - | + | ** reaktivně (ve stylu BGP AS-PATH) nebo proaktivně - nedovolit vytvořit nežádoucí propojení | |
| - | V. Bortlík v rámci své DP zobecňuje konfigurační skripty distribuovaného virtuálního spojovacího pole a tunelovací server do podoby univerzálního tunelovacího systému - '''heterogenního distribuovaného virtuálního spojovacího pole''', které má za cíl enkapsulovat potenciálně různorodé technologie používané pro spojování laboratorních prvků v jednotlivých lokalitách a sjednotit způsob předávání provozu mezi prvky různých lokalit definicí jednotného formátu enkapsulace rámců tunelovaných přes Internet. Podporováno bude tunelování provozu mezi dvojicemi LAN i WAN portů síťových prvků. | + | ** sémantika násobného konektoru by měla být srozumitalná pro uživatele (odpovídat např. chování nějakého typu sítě) |
| - | + | ||
| - | V návaznosti na vývoj heterogenního distribuovaného virtuálního spojovacího pole momentálně dále pracujeme na řešeních, která umožní přes Internet tunelovat nejen ethernetové, ale i sériové WAN linky laboratorních prvků. Jedná se zejména o vývoj vlastní víceportové synchronní sériové karty do PC s ovladači pro Linux, další rozšíření ASSSK2 a vývoj plně distribuovaného spojovacího pole na bázi převodníků Ethernet-RS232 propojených počítačovou sítí. | + | |
| - | + | ||
| - | V rámci dokončovaných DP se do systému integruje mechanismus sond pro sledování provozu na libovolné z linek laboratorní topologie (zatím jen Ethernet, později bude zobecněno) a Honeypot server pro simulaci většího množství sítí a služeb. | + | |
| - | + | ||
| - | '''K vývoji systému mezi sebou rádi uvítáme další spolupracovníky a to i formou diplomových prací (Bc. i Mgr.)''' | + | |
| - | + | ||
| - | ==[[Vývojový tým]]== | + | |
| - | + | ||
| - | [[Image:vyvojovy_tym.jpg|thumb|center|600px|Vývojový tým (v ne zcela kompletní sestavě)]] | + | |
| - | + | ||
| - | ==Kontakty== | + | |
| - | + | ||
| - | '''Koordinátor vývoje:''' | + | |
| - | + | ||
| - | e-mail petr''<tecka>''grygarek''<zavinac>''vsb''<tecka>''cz | + | |
| - | + | ||
| - | tel. +420 59 732 3243 | + | |
| - | + | ||
| - | '''Celý vývojový tým:''' | + | |
| - | + | ||
| - | virtlab''<zavinac>''cs''<tecka>''vsb''<tecka>''cz | + | |
Verze z 08:37, 25. 8. 2009
Pokyny k vypracování
- Doplnit do GUI:
- dát k dispozici seznam všech probíhajících rezervací s konektory (ze všech lokalit), na které se uživatel může potenciálně připojit (vyfiltrováno přes ACL). Konektory uživateli zobrazovat podle jejich logického pojmenování v log. topologii. ACL uchovávat asi v databázi (ResID x ConnID x ACL regexp)
- pro dotazy mezi lokalitami využít SOAP API. Lokalita, ze které se iniciovala rezervace, bude umět pro zadané ResID poskytnout aktuální namapování konektorů (s čím jsou spojeny, ať už vedou do vlastní nebo do cizích lokalit) + interval platnosti ResID
- dát k dispozici seznam všech probíhajících rezervací s konektory (ze všech lokalit), na které se uživatel může potenciálně připojit (vyfiltrováno přes ACL). Konektory uživateli zobrazovat podle jejich logického pojmenování v log. topologii. ACL uchovávat asi v databázi (ResID x ConnID x ACL regexp)
- možnost zobrazit si konektory konkrétní topologie vybrané z tohoto seznamu
- možnost zobrazit si mé konektory a přiřadit k nim připojené konektory z jiných paralelně existujících topologií
- online informace uživatelům, kdo a čím se napojil/odpojil na konektory jejich rezervace
- při rezervaci topologie možnost stanovit komu bude dovoleno připojit se na konektory rezervované topologie (asi regulárním výrazem na login jméno, lokalitu, možná již využít nový systém skupin)
- Do vybavení.xml definovat v každé lokalitě několik konektorů s interface typu serial (sint) a Ethernet (eint)
- Vytvořit modul tunelovacího serveru přijímající provoz pro rozhraní cint a sint.
- Použít CLI tunelovacího serveru pro definici (časově omezeného) aktuálního propojení konektorů.
- Možná pouze použítexistující příkaz redir. Rámec putující po cestě
- Použít CLI tunelovacího serveru pro definici (časově omezeného) aktuálního propojení konektorů.
R1:e1@L1 - c1:eint1@L1 - c2:eint2@L2 - R2:e2@L2
- se bude směrovat neustále podle cílového rozhraní do správného modulu tunelovacího serveru příslušné lokality (takže vždy projde dovnitř a ven modulu konektoru pro každý konektor)
- Abychom mohli konektory vzájemně propojovat normální položkou v RedirectTable, zavedeme u každého konektoru pseudointerface iint vedoucí do Internetu. Nebude ve vybaveni.xml, aby na konektory nikdo nenapojoval více než jednu linku. Pokud bude mít provoz z konektoru odejít zase na konektor, doplní tunelovací server jako zdrojový i cílový interface řetězec iint. Modul konektorů v tunelovacím serveru zaregistruje rozhraní iint jako další rozhraní, které umí obsluhovat.
- Další komentáře
- Zvážit možnost implementace konektoru na Internet (parametrizovatelná port-forwardning komponenta s jednou veřejnou adresou ?)
- možná jen pro směr ven, za NATem (jedna veřejná adresa, vhodně omezená)
- Z důvodu řešení případných bezpečnostních incidentů nutno mít možnost zjistit, kdo (ze které rezervace) šel kdy pod veřejnou adresou půjčenou z NAT ven.
- Zamyslet se nad problémem možných smyček v topologii vzniklé propojením konektorů (asi nevadí, v lokálním případě také řeeeno jen rate limitingem na VLMUXu a přirozeným omezením kapacitou tunelovacího serveru)
- Řešit patrně reaktivně (rozšíření paketu tunserveru o options s původním src a dst, pak mechanismem EBGP filtrovat), příp. proaktivně hledáním potenciální smyčky při zapojování konektoru za runtime
- Optimálně by měly být použité fyzické konektory mapovány tak, aby byly ze stejné lokality jako prvek, kam je konektor v log. topologii) napojen. Toto ale bude řešeno v mapovacím algoritmu. Cílem je zajistit, abychom provoz mezi dvěmi prvky v téže lokalitě spojenými konektory neposílali přes fyzické konektor namapovaný do jiné lokality.
- Zvážit možnost implementace konektoru na Internet (parametrizovatelná port-forwardning komponenta s jednou veřejnou adresou ?)
- Konektory na úrovni logické topologie patrně nedělit na násobné a jednoduché, rozdělit až za runtime, když se konektor "exportuje" - max. počet cizích připojených konektorů (spolu s regexpem na jméno uživatele)
- Možnost vstoupit do topologie za konektorem tím, že mne její vlastník po žádosti přidá k rezervaaci jako kolegu (ze své nebo cizí lokality)
- Vizualizace koberců topologií propojených přes konektory - možná hierarchicke grafy. Zatím např. jen textové zobrazení, v navazujících DP možno řešit grafické zobrazení
Ke zvážení
- Kolegové v rezervaci - definovat způsob práce s konektory (stejná práva jako vlastník rezervace ? nebo např. nemohou definovat filtry apod., ale mohou připojovat/odpojovat - asi nepraktické)
- Práce s konektory u uživatelů přizvaných s jiných lokalit
- Dotazy na aktuálně dostupné konektory v cizích lokalitách - pro unifikaci/enkapsulaci se ptát stejným způsobem (přes SOAP) i své lokality
- Funkce vrátí i konektory právě dostupné od připojených PT
- Sémantika násobných konektorů (jak se přeposílá provoz z připojeného konektoru na připojený konektor a zda se duplikuje provoz od zařízení připojeného na násobný konektor na všechny napojené konektory
- nutno zabránit smyčkám v šíření rámců (přes zdrojový port i mimo něj) a duplikacím
- reaktivně (ve stylu BGP AS-PATH) nebo proaktivně - nedovolit vytvořit nežádoucí propojení
- sémantika násobného konektoru by měla být srozumitalná pro uživatele (odpovídat např. chování nějakého typu sítě)
