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

• 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 1 Filosofie úprav tunelovacího serveru 1.1 Názvy externích prvků 1.2 Daná fakta 1.3 Řešení 1 1.4 Řešení 2 - Preferované 1.5 Řešení 3 2 Speciální případy 3 Logická úroveň 3.1 Se kterým TS bude Remote PC komunikovat 3.2 Uživatelský pohled na připojování vzdáleného PC

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 komunikovat přímo 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 - Preferované

NUTNO DOMYSLET PRUCHOD PRES NAT - PRECHOD NA TCP ???

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

%REMOTE-<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 extrakci IP adresy a portu ze jména prvku v tomto případě (pozná podle speciálního vyhrazeného začátku názvu prvku)
  • pokud nechceme mít 2 externí vstupní body do TS, jinak by mohl sám enkapsulovat a 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.

Ř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
• Přemosťovací program mezi TAP rozhraním a UDP RemotePC bude zasílat rámce vždy na domovský tunelovací server (a přijímat je jen z něj). Dostane jeho IP adresu a port, jméno svého (zdrojového) prvku/rozhraní cílového prvku/rozhraní - to prakticky bude konektor
  • (technicky by ale šlo zadat přími i rozhraní prvku, i z jiné lokality - tunserveru nevadí, když něco příjde z InternetPortu a posílá to opět na InteretPort (zdrojový Port neřeší), takže proxy mód by takto měl fungovat automaticky.

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