Dva tenanté provozují stejnou aplikaci na 10.50.0.10. Poskytovatel je drží oddělené v samostatných MPLS VPN a BIG-IP uchovává jejich lokální provoz v samostatných doménách směrování. Toto uspořádání funguje až do předání, kde chybějící sufix nebo zkopírovaný cíl trasy tiše umístí paket jednoho tenanta do kontextu druhého. Tato příručka spojuje oba modely a končí testem pro každého tenanta.

Pracovní list: jeden řádek na tenanta

Vyplňte jej, než cokoli změníte. Každý další krok odkazuje na buňku v něm a prázdná buňka je rozhodnutí, které ještě nikdo neudělal.

TenantBIG-IP sideProvider side
AVLAN or tunnel, route domain, self address, virtual serverVRF, attachment, route targets for import and export
BSeparate VLAN or tunnel, separate route domain, separate self addressSeparate VRF, separate route targets

Krok 1: připněte každý objekt k jeho doméně směrování

Dokumentace F5 k doménám směrování popisuje izolované kontexty provozu, duplicitní adresy a notaci address%ID pro konfigurační objekty. Adresa zapsaná jako 10.50.0.10%2 pojmenovává lokální kontext domény směrování a tento sufix není MPLS značka nesená v IP paketu zákazníka.

VLAN nebo podporovaný tunel patří v dokumentovaném modelu k jedné doméně směrování, takže rozhraní a adresa musí souhlasit. Zkontrolujte také výchozí doménu směrování administrativní partition, protože vynechaný sufix neznamená žádný kontext; znamená ten kontext, který partition používá jako výchozí. Tato jediná výchozí hodnota vysvětluje většinu incidentů, kdy nový objekt tiše odpovídal špatnému tenantovi. Ověřte ji, než přidáte vlastní adresu.

tmsh list net route-domain
tmsh list net vlan | grep -i domain
tmsh list ltm virtual one_vs

Krok 2: použijte VRF a cíle tras poskytovatele

Na okraji MPLS je tenant určen VRF poskytovatele a dohodnutou zákaznickou službou směrování. Cíle tras řídí, které trasy poskytovatel importuje a exportuje mezi VRF, a volba podobně vypadajícího čísla domény směrování na BIG-IP z tohoto vztahu nevytvoří nic.

Oba identifikátory žijí v různých systémech a znamenají různé věci. ID domény směrování je lokální kontext na zařízení. Cíl trasy je atribut zásady na straně poskytovatele, který rozhoduje o distribuci tras, a rozlišovač trasy je zase třetí věc, která slouží k udržení jinak shodných prefixů odděleně.

Krok 3: rozhodněte, zda kontexty mohou sdílet dosažitelnost

Záměrně projděte nastavení vyhledávání v nadřazené doméně a striktní izolace, protože mění, kam se kontext může dostat. Průvodce F5 povoluje řízené předávání přes tyto vztahy, a právě proto by se doména směrování neměla sama o sobě brát jako úplná bezpečnostní politika tenanta.

Pokud oba tenanté potřebují sdílenou službu, určete schválenou cestu a oprávnění, místo abyste jednoho tenanta jen tak nasměrovali do kontextu směrování druhého. Zachovejte identitu aplikace a případný záměrný překlad zdroje spolu se síťovým cílem, jinak sdílená služba uvidí jednoho tenanta jako druhého.

Běžné směrované předání spojuje BIG-IP s hraničním routerem poskytovatele, aniž by z BIG-IP udělalo MPLS PE. Pokud je přímá integrace MPLS nebo rodiny tras VPN skutečně potřeba, získejte výslovnou podporu pro přesnou platformu a verzi, protože lokální izolace domény směrování tuto schopnost nezakládá.

Krok 4: ověřujte po jednom tenantovi

Otestujte tenanta A z koncového bodu v kontextu A na adresu aplikace A a poté totéž zopakujte pro B. V diagnostice používejte tvar %ID, abyste prokázali, který kontext odpověděl, a potvrďte, že požadavek ze špatného kontextu selže, místo aby přistál na nějakém uvěřitelném místě.

Ve stejném průchodu zkontrolujte i stranu poskytovatele: prefix je ve správném VRF, cíle tras odpovídají pracovnímu listu a zpětná cesta používá zamýšlené připojení. Ping, který funguje ze samotného zařízení, dokazuje kontext zařízení, ne tenanta.

Zapište konečné mapování do pracovního listu, včetně výchozí domény směrování každé partition a každého vztahu nadřazené domény, který jste povolili. Příští změnu v tomto prostředí provede někdo, kdo čte tuto tabulku, ne někdo, kdo čte tento článek.

Související články