Implementace konektorů pro dynamické propojování distribuovaných virtuálních topologií v systému Virtlab

Z VirtlabWiki

Pokyny k vypracování

• Doplnit do GUI:
  • dát k dispozici seznam všech probíhajících rezervací s konektory (ze všech lokalit), na které se uživatel může potenciálně připojit (vyfiltrováno přes ACL). Konektory uživateli zobrazovat podle jejich logického pojmenování v log. topologii. ACL uchovávat asi v databázi (ResID x ConnID x ACL regexp)
    • pro dotazy mezi lokalitami využít SOAP API. Lokalita, ze které se iniciovala rezervace, bude umět pro zadané ResID poskytnout aktuální namapování konektorů (s čím jsou spojeny, ať už vedou do vlastní nebo do cizích lokalit) + interval platnosti ResID

• • možnost zobrazit si konektory konkrétní topologie vybrané z tohoto seznamu
  • možnost zobrazit si mé konektory a přiřadit k nim připojené konektory z jiných paralelně existujících topologií
  • online informace uživatelům, kdo a čím se napojil/odpojil na konektory jejich rezervace
  • při rezervaci topologie možnost stanovit komu bude dovoleno připojit se na konektory rezervované topologie (asi regulárním výrazem na login jméno, lokalitu, možná již využít nový systém skupin)

• Do vybavení.xml definovat v každé lokalitě několik konektorů s interface typu serial (sint) a Ethernet (eint)

• Vytvořit modul tunelovacího serveru přijímající provoz pro rozhraní cint a sint.
  • Použít CLI tunelovacího serveru pro definici (časově omezeného) aktuálního propojení konektorů.
    • Možná pouze použítexistující příkaz redir. Rámec putující po cestě

R1:e1@L1 - c1:eint1@L1 - c2:eint2@L2 - R2:e2@L2 

se bude směrovat neustále podle cílového rozhraní do správného modulu tunelovacího serveru příslušné lokality (takže vždy projde dovnitř a ven modulu konektoru pro každý konektor)

• Abychom mohli konektory vzájemně propojovat normální položkou v RedirectTable, zavedeme u každého konektoru pseudointerface iint vedoucí do Internetu. Nebude ve vybaveni.xml, aby na konektory nikdo nenapojoval více než jednu linku. Pokud bude mít provoz z konektoru odejít zase na konektor, doplní tunelovací server jako zdrojový i cílový interface řetězec iint. Modul konektorů v tunelovacím serveru zaregistruje rozhraní iint jako další rozhraní, které umí obsluhovat.

• Další komentáře
  • Zvážit možnost implementace konektoru na Internet (parametrizovatelná port-forwardning komponenta s jednou veřejnou adresou ?)
    • možná jen pro směr ven, za NATem (jedna veřejná adresa, vhodně omezená)
    • Z důvodu řešení případných bezpečnostních incidentů nutno mít možnost zjistit, kdo (ze které rezervace) šel kdy pod veřejnou adresou půjčenou z NAT ven.
  • Zamyslet se nad problémem možných smyček v topologii vzniklé propojením konektorů (asi nevadí, v lokálním případě také řeeeno jen rate limitingem na VLMUXu a přirozeným omezením kapacitou tunelovacího serveru)
    • Řešit patrně reaktivně (rozšíření paketu tunserveru o options s původním src a dst, pak mechanismem EBGP filtrovat), příp. proaktivně hledáním potenciální smyčky při zapojování konektoru za runtime
  • Optimálně by měly být použité fyzické konektory mapovány tak, aby byly ze stejné lokality jako prvek, kam je konektor v log. topologii) napojen. Toto ale bude řešeno v mapovacím algoritmu. Cílem je zajistit, abychom provoz mezi dvěmi prvky v téže lokalitě spojenými konektory neposílali přes fyzické konektor namapovaný do jiné lokality.
• Konektory na úrovni logické topologie patrně nedělit na násobné a jednoduché, rozdělit až za runtime, když se konektor "exportuje" - max. počet cizích připojených konektorů (spolu s regexpem na jméno uživatele)
• Možnost vstoupit do topologie za konektorem tím, že mne její vlastník po žádosti přidá k rezervaaci jako kolegu (ze své nebo cizí lokality)
• Vizualizace koberců topologií propojených přes konektory - možná hierarchicke grafy. Zatím např. jen textové zobrazení, v navazujících DP možno řešit grafické zobrazení

Ke zvážení

• Kolegové v rezervaci - definovat způsob práce s konektory (stejná práva jako vlastník rezervace ? nebo např. nemohou definovat filtry apod., ale mohou připojovat/odpojovat - asi nepraktické)
• Práce s konektory u uživatelů přizvaných s jiných lokalit
• Dotazy na aktuálně dostupné konektory v cizích lokalitách - pro unifikaci/enkapsulaci se ptát stejným způsobem (přes SOAP) i své lokality
  • Funkce vrátí i konektory právě dostupné od připojených PT
• Sémantika násobných konektorů (jak se přeposílá provoz z připojeného konektoru na připojený konektor a zda se duplikuje provoz od zařízení připojeného na násobný konektor na všechny napojené konektory
  • nutno zabránit smyčkám v šíření rámců (přes zdrojový port i mimo něj) a duplikacím
  • reaktivně (ve stylu BGP AS-PATH) nebo proaktivně - nedovolit vytvořit nežádoucí propojení
  • sémantika násobného konektoru by měla být srozumitalná pro uživatele (odpovídat např. chování nějakého typu sítě)
• Tap pseudokonektory
  • reprezentují pasivní odposlech na každé lince (tap zařízení)
    • možnost vložení IDS sond apod. kamkoli
  • vznikají v tunserveru automaticky pro každou linku (vhodně pojmenované s ohledem na názvy spojených prvků v log. topologii)
  • moznost pouziti stejneho mechanismu jako pro virtualni sondy
  • read/only (provoz z nich lze jen číst)