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 20:01, 6. 8. 2009
Gry72 (Diskuse | příspěvky)
(→Filosofie úprav tunelovacího serveru)
← Předchozí porovnání		 Verze z 20:03, 6. 8. 2009
Gry72 (Diskuse | příspěvky)
(→Otázky k dořešení)
Následující porovnání →
Řádka 62: Řádka 62:
Má obdobnou nevýhodu jako Řešení 1 (nemožnost přímé komunikace mezi vzdálenými PC) Má obdobnou nevýhodu jako Řešení 1 (nemožnost přímé komunikace mezi vzdálenými PC)
-== Otázky k dořešení ==+== Speciální případy ==
 + 
 +Více prvků na stejné adrese:
 + 
 +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

Verze z 20:03, 6. 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
  • Implementovat další modul pro komunikaci přes Internet se vzdálenými PC 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.


Ř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é).

Ř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

Ř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 prvků na stejné adrese:

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
Citováno z „http://infra2.cs.vsb.cz/vl-wiki/index.php/Integrace_vzd%C3%A1len%C3%A9ho_u%C5%BEivatele_do_laboratorn%C3%AD_topologie_a_roz%C5%A1%C3%AD%C5%99en%C3%AD_spojovac%C3%ADho_mechanismu_distribuovan%C3%A9_virtu%C3%A1ln%C3%AD_laborato%C5%99e_po%C4%8D%C3%ADta%C4%8Dov%C3%BDch_s%C3%ADt%C3%AD“