Virtuální laboratoř počítačových sítí, Integrace vzdáleného uživatele do laboratorní topologie a rozšíření spojovacího mechanismu distribuované virtuální laboratoře počítačových sítí

Z VirtlabWiki

(Rozdíly mezi verzemi)
Přejít na: navigace, hledání
Verze z 18:16, 27. 8. 2008
Gry72 (Diskuse | příspěvky)

← Předchozí porovnání		 Verze z 06:01, 7. 8. 2009
Gry72 (Diskuse | příspěvky)
(→Uživatelský pohled na připojování vzdáleného PC)
Následující porovnání →
Řádka 1: Řádka 1:
-{|align=right+* Možnost orientace na [http://vtun.sourceforge.net/tun/ tuntap], resp. [http://i3.cs.berkeley.edu/impl/win/tap-win32.html tap-win32] drivery
- |__TOC__+** Viz také [http://www.kernel.org/pub/linux/kernel/people/marcelo/linux-2.4/Documentation/networking/tuntap.txt tuntap.txt] a [http://openvpn.net/papers/BLUG-talk/7.html Slides o OpenVPN]
- |}+** využívá je i openvpn pro vytváření síťových rozhraní
 +** příklad použití Tuntap viz [http://www.secdev.org/projects/etherpuppet EtherPuppet] a [http://www.secdev.org/projects/tuntap_udp/ tuntap_UDP]
 +* Alternativy řešení problému současného připojení vzdáleného uživatelského PC do laboratorního topologie a do Internetu (nutno zachovat pro přístup k WWW GUI a konzolovému serveru)
 +** nevíme, jaký adresní rozsah uživatel má v laboratorní topologii, jakou adresu chce mít na svém PC
 +** problém dvou default GW (do lab. topologie a do Internetu)
 +** možnost připojení jen do lab. topologie, zamanipulovat u uživatele s routing table (/32 záznamy pro adresy WWW a conserveru) a s ARP záznamy
 +*** nastavit do tuntap rozhraní na předdefinované MAC adresy a na straně laboratoře odchytávat a přemosťovat
 +** jednodušší a rozumnější možnost je nechat nastavení směrování manuálně zcela na uživateli (prefixy použití v lab. topologii nasměrovat na tuntap rozhraní, default asi nechat do Internetu)
-[[Image:Eng.gif]]+== Filosofie úprav tunelovacího serveru ==
-; [[Brief Project Overview in English]]+
-; [[Media:Prezentace-ENG.pdf|Project Presentation in English]]+
-==Úvodem==+=== Názvy externích prvků ===
-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'''. +* Pro identifikaci vešech rozhraní prvků zůstáva totožný identifikátor prvku jako celku
 +* Externí prvek je identifikován IP adresou, na které je dostupný, jeho jednotlivá rozhraní portem
 +** lze zavést konvenci pro přemapovávání jména TAP rozhraní v OS a čísla portu
-[[Image:virtlab_architektura.jpg|thumb|center|500px|Základní architektura]]+=== Daná fakta ===
-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.+* Úpravám v modulu InternetPort se nevyhneme. Ten zatím umí zasílat enkapsulované pakety jen do lokalit, které má ve své konfiguraci, nikoli dynamicky na adresy vzdálených PC podle adresy zakomponované v názvu prvku
 +* Nechat (nově vytvořený) modul (RemotePort) pro komunikaci TS se vzdálenými PC přes Internet nechceme - vznikl by další externí vstupní bod ke hlídání, enkapsulace paketů tunelovaných přes Internet by byla duplikována apod.
 +**Mimo to pro odchozí směr tunelovací server neřeší cílový modul podle regulárního výrazu a jména interface, ale jména lokality - cokoli pro jinou než místní lokalitu jde automaticky na InternetPort (ne na RemotePort).
 +*** šlo by obejít tím, že by vzdálená PC patřila do jednotlivých lokalit
 +=== Řešení 1 ===
-==Historie==+ PC<IP-adresa>@EXTERNAL:vl<port>
-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.+Tok paketů směrem ven z TS:
 +* Podle lokality EXTERNAL (neshodující se s názvem místní lokality) se rámec automaticky pošle na InternetPort
 +** ten je modifikován, aby uměl v případě zasílání do lokality EXTERNAL vyčíst ze jména prvku IP adresu a port a tam enkapsulovaný paket poslat, místo hledání cílové adresy v konfiguraci podle jména lokality
-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.+Tok paketů směrem dovnitř do TS:
 +* Paket příjde na InternetPort TS pouze v případě, že má jít na rozhraní některého prvku v místní lokalitě. Na příslušný modul je dále směrován podle regulárního výrazu a názvu cílového rozhraní.
-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í).+Problém: Není možná vzájemná komunikace mezi Remote PC - do lokality EXTERNAL nejde nic poslat. Což ale možná nevadí, protože Remote PC se stejně budou připojovat jen na konektory (příp. násobné). Ale to je spíše filosofické aplikační omezení, distributed virtual crossconnect by měl být raději obecný a toto umožnovat.
-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.+=== Řešení 2 - patrně preferované ===
-==Aktuální vývoj (duben 2008)==+Nechat všechna vzdálená PC ve své "domovské" lokalitě, implementovat modul RemotePort, který bude na sebe stahovat (regulárním výrazem) všechna rozhraní vl*.
-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'''.+Tvar jména remote PC prvku by byl
-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ů.+ PC<IP-adresa>@thissite:vl<port>
-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í. +Tok paketů směrem ven z TS:
-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.+* Podle rozhraní vlX se pošle na RemotePort, ten přesměruje na InternetPort (ten bude modifikován pro exkrakci IP adresy a portu ze jména prvku v tomto případě
 +** pokud nechceme mít 2 externí vstupní body do TS, jinak by mohl sám enkapsulovat poslat sám přímo na remote PC
-'''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.)'''+Tok paketů směrem dovnitř do TS:
 +* InternetPort pošle deenkapsulovaný rámec přímo přepínacímu jádru TS a ten dále na příslušný modul (Port). Do modulu RemotePort se dostane pouze v případě, že by šlo o komunikaci Remote PC - Remote PC. I to by ovšem fungovalo.
 +** Pokud bychom dovolili 2 externí vstupní body, enkapsulované rámce by vstupovaly přímo do RemotePort
-==[[Vývojový tým]]==+Výhodou je, že pokud bychom se pro 2 externí vstupní body do TS přece jen rozhodli, můžeme (např. z důvodu jiné enkapsulace pro přemostění s cizími systémy, jejichž enkapsulaci nemůžeme přizpůsobit naší). Přemostění do jiných systémů bychom ale patrně stejně řešili instalací proxy tunelovacího serveru na straně cizího systému.
-[[Image:vyvojovy_tym.jpg|thumb|center|600px|Vývojový tým (v ne zcela kompletní sestavě)]]+Výhodou je znalost, která lokalita je "zodpovědná" za které Remote PC.
-==Kontakty==+==== Komunikace pc1<a.a.a.a>@ostrava:vl10000 -> pc1<a.a.a.a>@karvina:vl10000 ====
-'''Koordinátor vývoje:'''+CO SE BUDE VLASTNE ZADAVAT DO REMOTE PC, KAM MA POSILAT PAKETY ? Z BEZPECNOSTNICH DUVODU RADEJI TS MISTNI LOKALITY
-e-mail petr''<tecka>''grygarek''<zavinac>''vsb''<tecka>''cz+??? pc1@ostrava -> TS@ostrava:InternetPort -> TS@ostrava:
-tel. +420 59 732 3243+=== Řešení 3 ===
-'''Celý vývojový tým:'''+Každé PC svou vlastní lokalitou
-virtlab''<zavinac>''cs''<tecka>''vsb''<tecka>''cz+ PC@<ip-adresa>:vl<port>
 + 
 +Má obdobnou nevýhodu jako Řešení 1 (nemožnost přímé komunikace mezi vzdálenými PC)
 + 
 +== Speciální případy ==
 + 
 +Více remote prvků na stejné adrese (jednom PC - např. Dynampis s více instancemi routerů apod.):
 + 
 +Ničemu nevadí, pokud budou mít jejich rozhraní jiné porty
 + 
 + prvek1<158.196.100.100>@ostrava:vl10000
 + prvek1<158.196.100.100>@ostrava:vl10001
 + .
 + prvek2<158.196.100.100>@ostrava:vl10002
 + prvek2<158.196.100.100>@ostrava:vl10003
 + 
 +== Logická úroveň ==
 + 
 +=== Se kterým TS bude Remote PC komunikovat ===
 + 
 +* Zatím TS přijímá enkapuslované rámce jen od TS jiných lokalit (full mesh IPSec tunelů mezi lokalitami)
 +* Rámce od/k RemotePC mohou být směřovány na interface prvku ve kterékoli lokalitě
 +* Z bezpečnostních důvodů však nepovažujeme za vhodné, aby kterýkoli RemotePC mohl posílat rámce na tunserver kterékoli lokality - problematická kontrola oprávnění
 +* To vede k zavedení "proxy" módu tunserveru (obdobná filosofie jako u konzolového serveru) - lokalita je branou pro (své) uživatele, které do topologie nějakým způsobem "vpustila" (na konzole, na síťová rozhraní, ...)
 +* Přímou komunikaci RemotePC-RemotePC zakázat, vždy přes tunelovací server (např. kvůli sondám)
 +** ani za cenu zvýšení režie při komunikaci mezi PC obsluhovaných tunelovacími servery různých lokalit a nutnosti průchodu rámce přes 2 tunelovací servery (a možná k tomu ještě přes moduly konektorů)
 +** pro přímou vzájemnou komunikaci RemotePC Virtlab ani není určen
 + 
 + 
 +=== Uživatelský pohled na připojování vzdáleného PC ===
 +* Pro kontrolovatelnost dění v laboratorní topologii chceme, aby se RemotePC mohlo připojovat jen na explicitně dovolená místa laboratorní topologie - na konektory
 +* Při připojení RemotePC automaticky vznikne na tunserveru domovské lokality (psedo)konektor, který až poté uživatel propojí s dalším konektorem
 +** tím se automaticky zavede proxy mód tunserveru (propojení s konektory napojenými na prvky v jiných lokalitách), aniž bychom tunserver museli modifikovat
 +** filosofie a nutná rozšíření tuserveru o modul pseudokonektorů obdobná [[Integrace distribuované laboratoře počítačových sítí se simulátorem PacketTracer | návrhu připojování vzdálených PacketTracerů]]
 +** autentizace RemotePC může být řešena stejně, jak je navrženo pro PacketTracer (sdělení řídícím WWW rozhraním vygenerováného OTP uživateli, resp. jeho předání jako parametru programu na RemotePC přemosťujícímu mezi TAP rozhraním a UDP)
 +*** OTP by se dalo použít pro generování HASHe rámců enkapsulovaných v UDP vyměnovaných s tunserverem
 + 
 +== Interfacing s cizími systémy ==
 + 
 +Zde diskutujeme integraci s cizími systémy, které nemají charakter množiny volně dostupných a na požádání vzájemně kombinovatelných prvků, dostupných přes společné (vnější) rozhraní našeho standardního tunelovacího a konzolového serveru, mazatelné mazacím serverem a individuálně rezervovatelné našim rezervačním serverem (všechny zmíněné servery v instalovány v cizí lokalitě a dále napojeny, popř. vnitřně upraveny podle potřeb daného cizího systému).
 + 
 +Pro řízení na logické úrovni můžeme použít (do cizích lokalit implementovat) SOAP API řídících serverů lokalit
 + 
 +=== Typy/charakter systémů, které můžeme potenciálně chtít integrovat ===
 + 
 +* Systém s neměnnou topologií složený složený z více samostatných síťových prvků
 +** může být plně izolovaný nebo mít definována síťová rozhraní, jimiž se bude propojovat s dalšími částmi distribuované laboratorní topologie (chovat se jako enkapsulovaná entita s několika rozhraními)
 +* ... co ještě ?
 + 
 + 
 +Definovat zacházení s typy rozhraní (L2 rámců), o nichž nemáme zatím potuchy (umíme jen interface typu Ethernet a Serial)
 +* Mapovací alg. zatím chápe jako propojitelné rozhraní "stejného typu" (máme Serial a Ethernet). Tunelovací servery kompatibilitu neřeši, pošlou rámec tam, kam jsou nakonfigurovány. Tím se mohou na rozhraní při nevhodné konfiguraci dostávat i nesprávné typy rámců (což nevadí).
 +* Možná "vyčistit" definici typu rozhraní ne na Ethernet/Serial, ale podle typu rámce - linkového protokolu, OSI RM L2 (L1 rozhraní neřešit, je enkapsulována za tunelovacím serverem)
 +** Při tom vzít v úvahu Serial porty na způsob Cisco směrovačů, které umí několik typů rámců - rozhraní tedy definovat výčtem L2 protokolů, které umí
 + 
 +----
 + 
 +Implementace proxy tunserveru na hranici cizího systému, který se bude jevit jako standardní lokalita. Proxy tunserver bude směrem do Internetu (k ostatním lokalitám Virtlabu) používat standardní Virtlabovou UDP enkapsulaci, pro směr do cizího systému jeho vlastní,
 + 
 +=== Příklad integrace pro systém s fixní topologií: ===
 + 
 +Zavedeme speciální typ prvku, který bude obalovat celou cizí topologii s interfacy, která topologie poskytuje ven. V konfiguraci definujeme, že tento prvek je 1x k dispozici v lokalitě cizího systému. S tímto prvkem pak budeme v logických topologiích normálně pracovat a mapovat jej na tuto jedinou jeho instanci.
 +Toto neřeší problém přístupu na konzoly jednotlivých prvků cizí topologie (kompozitní prvek by měl jen jednu konzoli jako každý jiný prvek). Šlo by řešit proxy konzolovým serverem, který by po přihlášení dovolil výběr konzoly konkrétního prvku (menu + rozvětvení).

Verze z 06:01, 7. 8. 2009

  • Možnost orientace na tuntap, resp. tap-win32 drivery
  • Alternativy řešení problému současného připojení vzdáleného uživatelského PC do laboratorního topologie a do Internetu (nutno zachovat pro přístup k WWW GUI a konzolovému serveru)
    • nevíme, jaký adresní rozsah uživatel má v laboratorní topologii, jakou adresu chce mít na svém PC
    • problém dvou default GW (do lab. topologie a do Internetu)
    • možnost připojení jen do lab. topologie, zamanipulovat u uživatele s routing table (/32 záznamy pro adresy WWW a conserveru) a s ARP záznamy
      • nastavit do tuntap rozhraní na předdefinované MAC adresy a na straně laboratoře odchytávat a přemosťovat
    • jednodušší a rozumnější možnost je nechat nastavení směrování manuálně zcela na uživateli (prefixy použití v lab. topologii nasměrovat na tuntap rozhraní, default asi nechat do Internetu)

Obsah

Filosofie úprav tunelovacího serveru

Názvy externích prvků

  • Pro identifikaci vešech rozhraní prvků zůstáva totožný identifikátor prvku jako celku
  • Externí prvek je identifikován IP adresou, na které je dostupný, jeho jednotlivá rozhraní portem
    • lze zavést konvenci pro přemapovávání jména TAP rozhraní v OS a čísla portu

Daná fakta

  • Úpravám v modulu InternetPort se nevyhneme. Ten zatím umí zasílat enkapsulované pakety jen do lokalit, které má ve své konfiguraci, nikoli dynamicky na adresy vzdálených PC podle adresy zakomponované v názvu prvku
  • Nechat (nově vytvořený) modul (RemotePort) pro komunikaci TS se vzdálenými PC přes Internet nechceme - vznikl by další externí vstupní bod ke hlídání, enkapsulace paketů tunelovaných přes Internet by byla duplikována apod.
    • Mimo to pro odchozí směr tunelovací server neřeší cílový modul podle regulárního výrazu a jména interface, ale jména lokality - cokoli pro jinou než místní lokalitu jde automaticky na InternetPort (ne na RemotePort).
      • šlo by obejít tím, že by vzdálená PC patřila do jednotlivých lokalit

Řešení 1 

PC<IP-adresa>@EXTERNAL:vl<port>

Tok paketů směrem ven z TS:

  • Podle lokality EXTERNAL (neshodující se s názvem místní lokality) se rámec automaticky pošle na InternetPort
    • ten je modifikován, aby uměl v případě zasílání do lokality EXTERNAL vyčíst ze jména prvku IP adresu a port a tam enkapsulovaný paket poslat, místo hledání cílové adresy v konfiguraci podle jména lokality

Tok paketů směrem dovnitř do TS:

  • Paket příjde na InternetPort TS pouze v případě, že má jít na rozhraní některého prvku v místní lokalitě. Na příslušný modul je dále směrován podle regulárního výrazu a názvu cílového rozhraní.

Problém: Není možná vzájemná komunikace mezi Remote PC - do lokality EXTERNAL nejde nic poslat. Což ale možná nevadí, protože Remote PC se stejně budou připojovat jen na konektory (příp. násobné). Ale to je spíše filosofické aplikační omezení, distributed virtual crossconnect by měl být raději obecný a toto umožnovat.

Řešení 2 - patrně preferované

Nechat všechna vzdálená PC ve své "domovské" lokalitě, implementovat modul RemotePort, který bude na sebe stahovat (regulárním výrazem) všechna rozhraní vl*.

Tvar jména remote PC prvku by byl 

PC<IP-adresa>@thissite:vl<port>

Tok paketů směrem ven z TS:

  • Podle rozhraní vlX se pošle na RemotePort, ten přesměruje na InternetPort (ten bude modifikován pro exkrakci IP adresy a portu ze jména prvku v tomto případě
    • pokud nechceme mít 2 externí vstupní body do TS, jinak by mohl sám enkapsulovat poslat sám přímo na remote PC

Tok paketů směrem dovnitř do TS:

  • InternetPort pošle deenkapsulovaný rámec přímo přepínacímu jádru TS a ten dále na příslušný modul (Port). Do modulu RemotePort se dostane pouze v případě, že by šlo o komunikaci Remote PC - Remote PC. I to by ovšem fungovalo.
    • Pokud bychom dovolili 2 externí vstupní body, enkapsulované rámce by vstupovaly přímo do RemotePort

Výhodou je, že pokud bychom se pro 2 externí vstupní body do TS přece jen rozhodli, můžeme (např. z důvodu jiné enkapsulace pro přemostění s cizími systémy, jejichž enkapsulaci nemůžeme přizpůsobit naší). Přemostění do jiných systémů bychom ale patrně stejně řešili instalací proxy tunelovacího serveru na straně cizího systému.

Výhodou je znalost, která lokalita je "zodpovědná" za které Remote PC.

Komunikace pc1<a.a.a.a>@ostrava:vl10000 -> pc1<a.a.a.a>@karvina:vl10000

CO SE BUDE VLASTNE ZADAVAT DO REMOTE PC, KAM MA POSILAT PAKETY ? Z BEZPECNOSTNICH DUVODU RADEJI TS MISTNI LOKALITY

??? pc1@ostrava -> TS@ostrava:InternetPort -> TS@ostrava:

Řešení 3

Každé PC svou vlastní lokalitou 

PC@<ip-adresa>:vl<port>

Má obdobnou nevýhodu jako Řešení 1 (nemožnost přímé komunikace mezi vzdálenými PC)

Speciální případy

Více remote prvků na stejné adrese (jednom PC - např. Dynampis s více instancemi routerů apod.):

Ničemu nevadí, pokud budou mít jejich rozhraní jiné porty 

prvek1<158.196.100.100>@ostrava:vl10000
prvek1<158.196.100.100>@ostrava:vl10001
.
prvek2<158.196.100.100>@ostrava:vl10002
prvek2<158.196.100.100>@ostrava:vl10003

Logická úroveň

Se kterým TS bude Remote PC komunikovat

  • Zatím TS přijímá enkapuslované rámce jen od TS jiných lokalit (full mesh IPSec tunelů mezi lokalitami)
  • Rámce od/k RemotePC mohou být směřovány na interface prvku ve kterékoli lokalitě
  • Z bezpečnostních důvodů však nepovažujeme za vhodné, aby kterýkoli RemotePC mohl posílat rámce na tunserver kterékoli lokality - problematická kontrola oprávnění
  • To vede k zavedení "proxy" módu tunserveru (obdobná filosofie jako u konzolového serveru) - lokalita je branou pro (své) uživatele, které do topologie nějakým způsobem "vpustila" (na konzole, na síťová rozhraní, ...)
  • Přímou komunikaci RemotePC-RemotePC zakázat, vždy přes tunelovací server (např. kvůli sondám)
    • ani za cenu zvýšení režie při komunikaci mezi PC obsluhovaných tunelovacími servery různých lokalit a nutnosti průchodu rámce přes 2 tunelovací servery (a možná k tomu ještě přes moduly konektorů)
    • pro přímou vzájemnou komunikaci RemotePC Virtlab ani není určen


Uživatelský pohled na připojování vzdáleného PC

  • Pro kontrolovatelnost dění v laboratorní topologii chceme, aby se RemotePC mohlo připojovat jen na explicitně dovolená místa laboratorní topologie - na konektory
  • Při připojení RemotePC automaticky vznikne na tunserveru domovské lokality (psedo)konektor, který až poté uživatel propojí s dalším konektorem
    • tím se automaticky zavede proxy mód tunserveru (propojení s konektory napojenými na prvky v jiných lokalitách), aniž bychom tunserver museli modifikovat
    • filosofie a nutná rozšíření tuserveru o modul pseudokonektorů obdobná návrhu připojování vzdálených PacketTracerů
    • autentizace RemotePC může být řešena stejně, jak je navrženo pro PacketTracer (sdělení řídícím WWW rozhraním vygenerováného OTP uživateli, resp. jeho předání jako parametru programu na RemotePC přemosťujícímu mezi TAP rozhraním a UDP)
      • OTP by se dalo použít pro generování HASHe rámců enkapsulovaných v UDP vyměnovaných s tunserverem

Interfacing s cizími systémy

Zde diskutujeme integraci s cizími systémy, které nemají charakter množiny volně dostupných a na požádání vzájemně kombinovatelných prvků, dostupných přes společné (vnější) rozhraní našeho standardního tunelovacího a konzolového serveru, mazatelné mazacím serverem a individuálně rezervovatelné našim rezervačním serverem (všechny zmíněné servery v instalovány v cizí lokalitě a dále napojeny, popř. vnitřně upraveny podle potřeb daného cizího systému).

Pro řízení na logické úrovni můžeme použít (do cizích lokalit implementovat) SOAP API řídících serverů lokalit

Typy/charakter systémů, které můžeme potenciálně chtít integrovat

  • Systém s neměnnou topologií složený složený z více samostatných síťových prvků
    • může být plně izolovaný nebo mít definována síťová rozhraní, jimiž se bude propojovat s dalšími částmi distribuované laboratorní topologie (chovat se jako enkapsulovaná entita s několika rozhraními)
  • ... co ještě ?


Definovat zacházení s typy rozhraní (L2 rámců), o nichž nemáme zatím potuchy (umíme jen interface typu Ethernet a Serial)

  • Mapovací alg. zatím chápe jako propojitelné rozhraní "stejného typu" (máme Serial a Ethernet). Tunelovací servery kompatibilitu neřeši, pošlou rámec tam, kam jsou nakonfigurovány. Tím se mohou na rozhraní při nevhodné konfiguraci dostávat i nesprávné typy rámců (což nevadí).
  • Možná "vyčistit" definici typu rozhraní ne na Ethernet/Serial, ale podle typu rámce - linkového protokolu, OSI RM L2 (L1 rozhraní neřešit, je enkapsulována za tunelovacím serverem)
    • Při tom vzít v úvahu Serial porty na způsob Cisco směrovačů, které umí několik typů rámců - rozhraní tedy definovat výčtem L2 protokolů, které umí

Implementace proxy tunserveru na hranici cizího systému, který se bude jevit jako standardní lokalita. Proxy tunserver bude směrem do Internetu (k ostatním lokalitám Virtlabu) používat standardní Virtlabovou UDP enkapsulaci, pro směr do cizího systému jeho vlastní,

Příklad integrace pro systém s fixní topologií:

Zavedeme speciální typ prvku, který bude obalovat celou cizí topologii s interfacy, která topologie poskytuje ven. V konfiguraci definujeme, že tento prvek je 1x k dispozici v lokalitě cizího systému. S tímto prvkem pak budeme v logických topologiích normálně pracovat a mapovat jej na tuto jedinou jeho instanci. Toto neřeší problém přístupu na konzoly jednotlivých prvků cizí topologie (kompozitní prvek by měl jen jednu konzoli jako každý jiný prvek). Šlo by řešit proxy konzolovým serverem, který by po přihlášení dovolil výběr konzoly konkrétního prvku (menu + rozvětvení).

Citováno z „http://infra2.cs.vsb.cz/vl-wiki/index.php/Virtu%C3%A1ln%C3%AD_laborato%C5%99_po%C4%8D%C3%ADta%C4%8Dov%C3%BDch_s%C3%ADt%C3%AD“
Osobní nástroje