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)
| Verze z 19:01, 4. 8. 2009 Gry72 (Diskuse | příspěvky) ← Předchozí porovnání |
Verze z 19:56, 6. 8. 2009 Gry72 (Diskuse | příspěvky) Následující porovnání → |
||
| Řádka 9: | Řádka 9: | ||
| *** nastavit do tuntap rozhraní na předdefinované MAC adresy a na straně laboratoře odchytávat a přemosťovat | *** 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) | ** 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) | ||
| + | |||
| + | == Filosofie úprav tunelovacího serveru == | ||
| + | |||
| + | === Názvy externích prvků === | ||
| + | |||
| + | PC<IP-adresa>@EXTERNAL:vl<port> | ||
| + | |||
| + | * 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 | ||
| + | |||
| + | * Ú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. | ||
| + | |||
| + | |||
| + | 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> | ||
Verze z 19:56, 6. 8. 2009
- Možnost orientace na tuntap, resp. tap-win32 drivery
- Viz také tuntap.txt a Slides o OpenVPN
- využívá je i openvpn pro vytváření síťových rozhraní
- příklad použití Tuntap viz EtherPuppet a 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)
Obsah |
Filosofie úprav tunelovacího serveru
Názvy externích prvků
PC<IP-adresa>@EXTERNAL:vl<port>
- 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
- Ú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.
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>
