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

Přejít na: navigace, hledání
  • 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é).

Alternativní řešení 1

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

Alternativní řešení 2

Každé PC svou vlastní lokalitou 

PC@<ip-adresa>:vl<port>
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