DE102021127234A1

DE102021127234A1 - Authentifizierungsverkettung bei der bereitstellung von mikrofilialen

Info

Publication number: DE102021127234A1
Application number: DE102021127234.3A
Authority: DE
Inventors: Hao Lu; Xiaoding SHANG; Feng Ding; Qiwei Chang
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2021-02-22
Filing date: 2021-10-20
Publication date: 2022-08-25
Also published as: US11792718B2; CN114978567A; US20220272614A1

Abstract

Es werden Systeme und Verfahren für die Authentifizierungsverkettung und die Firewall-Optimierung in einer Mikro-Zweigstelleneinrichtung bereitgestellt, die eine Vielzahl verketteter Zugangspunkte (APs) und einen Gateway-AP umfasst. Die Topologie der Mikrozweigstelle kann durch erweitertes hierarchisches Beaconing bestimmt werden. Auf der Grundlage der ermittelten Topologie wird eine Authentifizierungskette entwickelt, über die ein Client-Gerät, das mit einem AP aus der Vielzahl der verketteten APs verbunden ist, authentifiziert werden kann und Zugang zu dem AP erhält. Nach der Authentifizierung des Client-Geräts wird eine Firewall-Optimierung durchgeführt, um Zugriffskontrollregeln nur bei dem AP zu implementieren, dem das Client-Gerät zugeordnet ist.

Description

Hintergrund
Software-definierte Weitverkehrsnetze (SDWANs) sind Netztopologien, die Standorte eines Weitverkehrsnetzes (WAN) miteinander verbinden und dabei die Grundsätze des Software-definierten Netzwerks (SDN) nutzen, z. B. die Trennung der Steuerungsebene der Verkehrsverwaltung von der Datenweiterleitungsebene. SDWANs unterstützen die Konsolidierung der Infrastruktur durch Virtualisierung von Netzwerkfunktionen (NFV). NFV reduziert den Verwaltungsaufwand und die Hardwarekosten für das Hinzufügen von Netzwerkfunktionen zu einem WAN durch Virtualisierung der Netzwerkfunktionen mithilfe virtueller Maschinen auf gängiger und kostengünstigerer „Standard“-Hardware.
Figurenliste
Die vorliegende Offenbarung wird in Übereinstimmung mit einer oder mehreren verschiedenen Ausführungsformen unter Bezugnahme auf die folgenden Figuren im Detail beschrieben. Die Figuren dienen nur der Veranschaulichung und stellen lediglich typische oder beispielhafte Ausführungsformen dar.

1 zeigt ein Beispielnetz mit Mikrozweigstellen, in denen die hier offengelegte Technologie angewendet werden kann.
2 zeigt ein Beispiel für die Verkettung von Zugangspunkten in einer Mikrofiliale.
3 zeigt ein Beispiel für die Erkennung der Topologie von Mikrozweigstellen gemäß einer Ausführungsform im Vergleich zur herkömmlichen Topologieerkennung.
4 zeigt ein Beispiel für die automatische Authentifizierungs-Proxy-Verkettung gemäß einer Ausführungsform im Vergleich zur herkömmlichen Authentifizierung.
5 zeigt ein Beispiel für eine Firewall-Optimierung gemäß einer Ausführungsform.
6A-6B sind Blockdiagramme von Beispielrechnerkomponenten oder - geräten für die Erkennung der Mikrozweigtopologie in Übereinstimmung mit einer Ausführungsform.
6C ist ein Blockdiagramm einer beispielhaften Computerkomponente oder eines Geräts zur Firewall-Optimierung gemäß einer Ausführungsform.
7 ist ein Beispiel für eine Computerkomponente, die zur Implementierung verschiedener Merkmale der in der vorliegenden Offenbarung beschriebenen Ausführungsformen verwendet werden kann.

Die Figuren sind nicht erschöpfend und beschränken die vorliegende Offenbarung nicht auf die genaue Form, die offengelegt wird.
Detaillierte Beschreibung
Verschiedene Ausführungsformen beziehen sich auf Systeme und Verfahren zur Authentifizierungsverkettung in einer Mikroverzweigungseinrichtung, die das Problem mehrerer Firewalls in einer Daisy-Chaining-Netzwerktopologie angehen können, z. B. wenn APs in Reihe geschaltet/verbunden sein können. Erstens kann ein hierarchischer Beacon-Mechanismus für Instant Access Points (IAPs) (z. B. controllerlose APs) verbessert werden, um den Baum der Netzwerktopologie einer Mikroverzweigung zu ermitteln. Zweitens können Informationen über diese Topologie verwendet werden, um eine Authentifizierungs-Proxy-Kette aufzubauen. Wenn sich ein Client-Gerät mit einem Mikrozweig-Netzwerk verbindet, kann diese Authentifizierungs-Proxy-Kette automatisch von einem Blatt-AP zu einem Gateway-AP (GAP) ausgelöst werden. Drittens, und als Ergebnis dieses Proxy-Kettenprozesses, kann jeder AP in einer Mikrozweigstelle den Zugang zum Client-Gerät und die Firewall-Richtlinie ordnungsgemäß bereitstellen, wobei doppelte Authentifizierungstransaktionen vermieden und die Gesamtverarbeitungszeiten für den Verkehrsfluss optimiert werden.
Es sollte beachtet werden, dass die Begriffe „optimieren“, „optimal“ und dergleichen, wie sie hier verwendet werden, so verwendet werden können, dass sie die Leistung so effektiv oder perfekt wie möglich machen oder erreichen. Wie jedoch ein Fachmann, der dieses Dokument liest, erkennen wird, kann Perfektion nicht immer erreicht werden. Dementsprechend können diese Begriffe auch bedeuten, die Leistung so gut oder effektiv wie unter den gegebenen Umständen möglich oder praktikabel zu machen oder zu erreichen, oder die Leistung besser zu machen oder zu erreichen als die, die mit anderen Einstellungen oder Parametern erreicht werden kann.
Ein softwaredefiniertes Weitverkehrsnetz (SDWAN) ermöglicht es einem Netzwerkadministrator, Zweigstellen über ein Weitverkehrsnetz (WAN) mit einem Hauptstandort zu verbinden. Die Verwendung von Software Defined Networking (SDN) entkoppelt die Entscheidungen über den Netzwerkverkehr von den verschiedenen Geräten innerhalb des Netzwerks, wie z. B. Routern, Switches, Brücken und anderen gängigen Netzwerkgeräten. Durch diese Entkopplung wird jedes Netzwerkgerät im Wesentlichen zu einem einfachen Gerät für die Weiterleitung von Paketen. Das SDWAN legt auf der Grundlage von Client-Richtlinien (z. B. QoS-Anforderungen, Bandbreite usw.) die potenziellen Verkehrswege durch jedes Netzwerkgerät fest, um die Zweigstellen innerhalb des SDWAN mit dem Kernstandort oder dem Rechenzentrum zu verbinden, das jedem Netzwerkgerät über einen Kontrollkanal zur Verfügung gestellt wird. Anstatt eine Entscheidung über die Weiterleitung des Datenverkehrs zu treffen, wenn Daten empfangen werden, führen die Netzwerkgeräte einfach die vom SDWAN-Administrator festgelegte Route aus.
Wie bereits angedeutet, erleichtert der Einsatz eines SDWAN die Virtualisierung von Netzwerkdiensten über das WAN. Die Netzwerkfunktionsvirtualisierung (NFV) verringert den Verwaltungsaufwand und die Hardwarekosten für das Hinzufügen von Netzwerkfunktionen zu einem WAN, indem die Netzwerkfunktionen mithilfe virtueller Maschinen auf gängigerer und billigerer „Standard“-Hardware virtualisiert werden, anstatt auf proprietärer, dedizierter Hardware (wie traditionell erforderlich). So können beispielsweise Funktionen wie Routing, Lastausgleich und Firewalls als virtuelle Maschinen (VMs) betrieben werden, die in einem Rechenzentrum und/oder in der Cloud gehostet werden. NFV konzentriert sich jedoch auf die Virtualisierung von Funktionen, kümmert sich aber nicht darum, wie die Datenpakete zu den virtuellen Maschinen geleitet werden, auf denen die Netzwerkfunktionen ausgeführt werden. SDWAN in Kombination mit NFV bietet ein umfassenderes virtuelles Netzwerk, bei dem das SDWAN die Routing-Richtlinien für die Verkehrsströme von den Zweigstellen zum Kernstandort oder zum Rechenzentrum, in dem die virtuellen NFV-Maschinen laufen, bereitstellt. Zweigstellenbenutzer sind in der Lage, diese Ressourcen über das SDWAN zu nutzen, wodurch die Abhängigkeit von teurer proprietärer Hardware verringert und die Menge der an den Zweigstellen des WAN erforderlichen Computerhardware reduziert wird.
SDWANs können durch die Schaffung eines virtuellen Overlay implementiert werden, das transportunabhängig ist und die zugrunde liegenden privaten oder öffentlichen Netzverbindungen abstrahiert. Zu diesen Netzverbindungen können Multiprotocol Label Switching (MPLS), Internet-Breitband, Glasfaser, Wireless oder Long Term Evolution (LTE) gehören, um nur einige zu nennen. In einigen Beispielen werden VPN-Tunnel (Virtual Private Network) zwischen WAN-Standorten eingerichtet, um eine private, sichere Verbindung über potenziell anfällige und unsichere öffentliche Verbindungen (z. B. Internetverbindungen) zu ermöglichen. Die Kunden können bestehende WAN-Verbindungen beibehalten und ein Overlay-SDWAN implementieren, das diese Tunnel nutzt, um die Bandbreite zu optimieren, indem der WAN-Verkehr zu und von anderen WAN-Standorten über bestimmte Routen geleitet wird, die diese Tunnel einschließen. Dementsprechend können SDWANs verwendet werden, um die Netzwerkkontrolle über das gesamte WAN zu zentralisieren. Fernanwender, z. B. in Zweigstellen, können Ressourcen nutzen, die in einem Rechenzentrum und/oder in der Cloud gehostet werden, um Anwendungen innerhalb des Netzwerks auszuführen.
Ein praktisches Beispiel: Eine herkömmliche Zweigstelleneinrichtung unterstützt die Anforderungen an die Client-Konnektivität an verschiedenen geografischen Standorten für verschiedene Arten von Geschäftsabläufen. Die Standorte an entfernten geografischen Standorten dienen als Zweigstellen, während der Hauptsitz oder die Hauptniederlassung als Datenzentrum dient, das Netzwerkressourcen zum Speichern, Verwalten und Verteilen von Daten hostet. Die Hauptniederlassung beherbergt auch ein zentrales Virtual Private Network (VPN)-Managementsystem, um den Datenverkehr von den entfernten Zweigstellen zu bündeln. Ein SDWAN ermöglicht die Verbindung mehrerer lokaler Netzwerke mit einem zentralen Unternehmensnetzwerk oder mit weit voneinander entfernten Rechenzentren.
Für den Einsatz in Mikrofilialen ist kein dediziertes Gateway-Gerät erforderlich. Stattdessen kann ein einzelner Gateway-AP (GAP) als WAN-Gateway verwendet werden. Zusätzliche APs können „unter“ dem GAP hinzugefügt werden, um die drahtlose Abdeckung in der Mikrozweigstelle zu erweitern. APs können sich auf ein Netzwerkgerät beziehen, das es einem drahtlosen Gerät, wie z. B. einem Client-Gerät, einer Station (STA) usw., ermöglicht, eine Verbindung zu einem drahtgebundenen Netzwerk herzustellen. Somit fungiert ein AP im Wesentlichen als Erweiterungsmechanismus von einem bestehenden drahtgebundenen Netz zu einer Gemeinschaft von drahtlosen Client-Geräten. Als Gateways werden in der Regel APs bezeichnet, die über Network Address Translation (NAT) Routing und Dynamic Host Control Protocol (DHCP) Server-Funktionen verfügen.
In Mikrozweigstellen „besitzt“ der GAP die öffentliche IP-Adresse, bietet Gateway-/Gateway-ähnliche Funktionen (z. B. DHCP, NAT, Routing usw.) und kann darüber hinaus einen VPN-Client hosten, der eine sichere Verbindung zu einem entfernten Rechenzentrum (z. B. der Hauptniederlassung) oder anderen Cloud-Diensten herstellt, je nach den Anforderungen der Mikrozweigstelle. Die Konfiguration zwischen dem GAP einer Mikrofiliale und den zusätzlichen APs ist in der Regel unterschiedlich, da sie in einer Mikrofiliale unterschiedliche Aufgaben haben.
Bevor Ausführungsformen der offengelegten Systeme und Verfahren im Detail beschrieben werden, ist es nützlich, ein Beispiel für ein Netzwerk mit Mikrozweigstellen zu beschreiben, mit dem die offengelegten Systeme und Verfahren in verschiedenen Anwendungen implementiert werden könnten. 1 zeigt ein Beispiel für ein Netzwerk 100, das Mikrozweigverteilungen umfasst. In diesem Beispiel kann das Netzwerk 100 ein Datenzentrum 102 umfassen, mit dem eine Einzel-AP-Mikrofilialeinrichtung 120 und eine Multi-AP-Mikrofilialeinrichtung 130 operativ verbunden sind. Teil des Netzwerks 100 ist auch ein Bereitstellungssystem, z. B. ein Cloud-basiertes Zero-Touch-Bereitstellungssystem/-service 114. Wie bereits erwähnt, ermöglicht ein SDWAN, wie z. B. das WAN 112, die Verbindung der verschiedenen Elemente/Einheiten des Netzwerks 100 untereinander. Es ist zu beachten, dass die hier beschriebenen Ausführungsformen auf die Verwendung eines SDWAN verweisen oder Merkmale/Funktionen im Kontext eines SDWAN beschreiben können. Die Ausführungsformen der vorliegenden Offenbarung sind jedoch nicht auf SDWANs beschränkt, sondern können auch in herkömmlichen WANs/im herkömmlichen WAN-Kontext verwendet werden.
Wie bereits angedeutet, kann das Rechenzentrum 102 eine Unternehmenszentrale darstellen. Das Rechenzentrum 102 kann einen Controller oder Core-Switch 104 umfassen, mit dem ein DHCP-Server 106 und eine Policy-Management-Plattform 108 operativ verbunden sind. Je nachdem, wie eine Verbindung zwischen dem Rechenzentrum 102 und einer entfernten Zweigstelle (in diesem Beispiel die Mikrozweigstellen 120, 130) implementiert wird, kann sich die Funktionalität des Elements 104 unterscheiden. Einige virtuelle LANs können auf Layer 3 geroutet werden, in diesem Fall kann ein VPN-Konzentrator Verkehrsströme an einen Core-Switch senden, z. B. an den Core-Switch 104, der ein Hochgeschwindigkeits-Core-Switch sein kann. Der Core-Switch 104 kann dann die Pakete der Datenströme an den erforderlichen nachfolgenden Hop weiterleiten. Alternativ kann der VPN-Konzentrator im Zusammenhang mit virtuellen LANs, die über Layer 2 verbunden sind, GRE-Pakete (wie unten beschrieben) einfach an einen Controller weiterleiten, der in diesem Fall das Element 104 wäre, das auch als Controller fungiert.
Wie der Fachmann weiß, kann sich der DHCP-Server 106 auf ein Netzelement beziehen, das jedem Gerät im Netz dynamisch eine IP-Adresse und andere Netzparameter zuweist. Die Policy-Management-Plattform 108 kann implementiert werden, um Geräte, wie z. B. Client-Geräte, sicher/ordnungsgemäß mit einem Netzwerk zu verbinden. Beispielsweise kann die Policy-Management-Plattform 108 neue Geräte einbinden, unterschiedliche Zugriffsstufen auf das Netz gewähren, die Netzsicherheit aufrechterhalten usw.
Wie in 1 weiter dargestellt, ist das Rechenzentrum 102 über einen Overlay-Tunnel 116A mit der Mikrofiliale 120 verbunden. Wie bereits erwähnt, können VPN-Tunnel zwischen Standorten, in diesem Fall dem Rechenzentrum 102 und der Mikrofiliale 120, eingerichtet werden, um ein SDWAN-Overlay-Netzwerk zu schaffen. Insbesondere kann der Overlay-Tunnel 116A den AP 122 der Mikrozweigstelle 120 mit einem Headend-Gateway 110 verbinden, das als VPN-Konzentrator und Overlay-Terminator (z. B. unter Verwendung eines Generic Routing Encapsulation (GRE)-Tunneling-Protokolls) für die Terminierung von VPN-Tunneln, in diesem Fall des Overlay-Tunnels 116A, fungieren kann, wodurch ein Routing von der Mikrozweigstelle 120 in das Rechenzentrum 102 ermöglicht wird. In ähnlicher Weise kann die Mikroverzweigung 130 (die im Gegensatz zur Mikroverzweigung 120 eine Multi-AP-Mikroverzweigung mit Root-AP 132 und Leaf-APs 134A-134C ist) über den Overlay-Tunnel 116B operativ mit dem Datenzentrum 102 verbunden werden.
Die Mikroverzweigung 120 ist eine Einzel-AP-Mikroverzweigung, bei der ein oder mehrere Client-Geräte, wie z. B. die Client-Geräte 124A-E, mit einem AP, z. B. AP 122 (drahtlos oder über eine Kabelverbindung), verbunden werden können, um eine Verbindung zum Datenzentrum 102 zu ermöglichen. Die Mikroverzweigung 130 ist eine Multi-AP-Mikroverzweigung, bei der in diesem Beispiel mehrere APs 134A-134C operativ mit dem Root-AP 132 verbunden sind, über den die Konnektivität zum Datenzentrum 102 hergestellt werden kann. Die Mikroverzweigung 130 kann ein oder mehrere Client-Geräte enthalten, z. B. die Client-Geräte 138A-C, von denen jedes direkt mit dem Root-AP 132 oder einem der APs 134A-134C verbunden sein kann. In diesem Beispiel kann die Mikroverzweigung 130 außerdem einen unverwalteten Switch 136 umfassen, an den zusätzliche Client-Geräte, z. B. die Client-Geräte 138D-E, angeschlossen sind.
In 2 ist eine weitere Mikrozweigstelle 200 dargestellt, wobei die Mikrozweigstelle 200 eine Daisy-Chain-Topologie/Hierarchie in Bezug auf ihre APs aufweist. Wie bereits erwähnt, ist in einer Mikroverzweigungseinrichtung, wie der Mikroverzweigungseinrichtung 200, kein dediziertes Gateway erforderlich. Stattdessen fungiert ein GAP, z. B. GAP 202, als WAN-Gateway und kann in diesem Beispiel über eine Ethernet-Verbindung (Eth-0) über einen WAN-Port 203 des GAP 202 angeschlossen werden. Ein erster Zugangspunkt (AP 210) kann operativ mit dem GAP 202 verbunden sein, und ein zweiter Zugangspunkt (AP 220) kann wiederum operativ mit dem AP 210 verbunden sein, d. h. die APs 210 und 220 sind mit dem GAP 202 verkettet.
Wie in 2 dargestellt, können zwei Client-Geräte 204 und 206, z. B. ein Laptop, ein Telefon, ein Drucker oder ein anderes Computergerät, drahtlos mit dem GAP 202 verbunden sein. In diesem Beispiel kann GAP 202 so konfiguriert sein, dass es als eine Vielzahl von virtuellen APs (VAPs) arbeitet. Wie der Fachmann weiß, simulieren VAPs mehrere APs auf einem einzigen physischen AP. Jeder VAP kann seine eigene eindeutige Service Set ID (SSID) haben, wodurch ein WLAN in mehrere Broadcast-Domänen segmentiert wird. Die Sicherheit kann angepasst/konfiguriert werden, um den Zugriff von drahtlosen Client-Geräten zu kontrollieren. In diesem Beispiel kann dem Client-Gerät 204, wenn es sich mit dem GAP 202 verbindet, eine bestimmte Benutzerrolle zugewiesen werden. Es versteht sich von selbst, dass jedes Client-Gerät im Netzwerk, z. B. im Netzwerk 100 (1), mit dem die Mikrozweigstelle 200 operativ verbunden sein kann, einer Benutzerrolle zugeordnet ist. Diese Benutzerrolle bestimmt die Netzwerkprivilegien dieses Client-Geräts, die Häufigkeit der erneuten Authentifizierung, die anwendbaren Bandbreitenverträge und so weiter. In diesem Beispiel ist das Client-Gerät 204 (aus der Sicht von GAP 202) mit einer Benutzerrolle, Rolle A, verbunden. Ein zweites Client-Gerät, das mit GAP 202 verbunden ist, d. h. das Client-Gerät 206, kann in den Augen von GAP 202 eine eigene Benutzerrolle, Rolle B, haben.
In Bezug auf AP 210 der Mikrofiliale 200 kann ein Client-Gerät 212, das wiederum ein Laptop, ein Telefon, ein anderes Benutzer-/Client-Gerät usw. sein kann, mit einem auf AP 210 konfigurierten VAP (VAP-X) verbunden werden. Das Client-Gerät 212 kann aus Sicht des AP 210 einer Benutzerrolle, Rolle A, zugeordnet sein. Da der AP 210 jedoch „mit/unter" dem GAP 202 verbunden ist, kann das Client-Gerät 212 aus der Perspektive des GAP 202 einer Benutzerrolle, Rolle D, zugeordnet sein. Es versteht sich von selbst, dass Benutzerrollen auf verschiedene Weise basierend auf der Netzwerkkonfiguration zugewiesen werden können. In einigen Ausführungsformen kann sich eine zugewiesene Benutzerrolle auf eine statische Rolle (kombiniert mit einem Port) beziehen, so dass allen Client-Geräten, die mit demselben Port/VAP verbunden sind, dieselbe Benutzerrolle zugewiesen werden kann. Alternativ kann eine Benutzerrollenableitung verwendet werden, die auf Client-Geräteattributen wie der MAC-Adresse, dem angeschlossenen Port usw. basieren kann. Außerdem kann sich eine Benutzerrolle auf einen Richtliniencontainer beziehen, in dem typischerweise verschiedene Richtlinien für verschiedene Rollen konfiguriert werden können, obwohl es möglich ist, dieselbe Richtlinie für verschiedene Benutzerrollen zu konfigurieren. Typischerweise können APs, kabelgebundenen Client-Geräten und drahtlosen Client-Geräten unterschiedliche Benutzerrollen zugewiesen werden. Ein weiteres Client-Gerät 216 kann mit AP 210 verbunden sein, diesmal über eine Ethernet-Verbindung, und ihm kann eine Benutzerrolle, Rolle D, zugewiesen werden. Ein weiteres Client-Gerät 222 kann mit einem VAP (VAP-X) von AP 220 verbunden sein und ihm kann seine eigene Benutzerrolle, Rolle A, zugewiesen werden.
Da AP 220 über AP 210 mit GAP 202 verbunden ist, kann AP 210 dem Client-Gerät 222 ebenfalls eine Benutzerrolle zuweisen, in diesem Beispiel die Rolle D (wie Client-Gerät 216). Weiter oben in der Kette bis zu GAP 202 „sieht“ GAP 202 jedes Client-Gerät, das mit den APs 210 und 220 verbunden ist, und kann daher jedem dieser Client-Geräte eine bestimmte Benutzerrolle zuweisen, in diesem Fall dem Client-Gerät 216 (mit AP 210 verbunden) die Rolle D. GAP 202 kann auch dem Client-Gerät 222 (mit AP 220 verbunden) eine Benutzerrolle zuweisen, d. h. die Rolle D. Es ist verständlich, dass die Berechtigungen, z. B. die Firewall-Richtlinie, nicht unbedingt über alle APs (GAP 202, AP 210, AP 220) hinweg konsistent sind. Es sollte auch beachtet werden, dass AP 220, AP 210 und GAP 220 über eine kabelgebundene Verbindung, z. B. Ethernet, verbunden sind und die jeweiligen Benutzerrollen, die den Client-Geräten zugewiesen sind, die mit den verketteten APs verbunden sind, von einem Eth-X-Server bedient werden (der sowohl seine eigenen verbundenen, kabelgebundenen Client-Geräte als auch alle anderen kabelgebundenen/drahtlosen Clients bedienen kann, die von einem Downlink-AP bedient werden). Ein VAP-X-Server bedient normalerweise nur drahtlose Client-Geräte, die mit einem VAP-Port verbunden sind.
Um diese Inkonsistenz der Firewall zu beheben, kann ein Netzwerkadministrator die Richtlinien der Port-Zugriffskontrollliste (ACL) für die verdrahteten (Eth-X-)Ports auf herkömmliche Weise entfernen. Ein Netzwerkadministrator kann zum Beispiel alle verkabelten Ports so konfigurieren, dass sie im TRUST-Modus arbeiten, oder eine „permit-all“-Port-ACL konfigurieren, um den Firewall-Prozess für diese verkabelten Ports zuzulassen. Obwohl Firewall-Inkonsistenzen beseitigt werden, kann die Konfiguration von verkabelten Ports auf diese Weise zu einem potenziellen Sicherheitsrisiko für das Netzwerk führen. Ein Angreifer könnte beispielsweise ein Client-Gerät, z. B. einen Laptop, an einen der verkabelten Ports eines verketteten APs anschließen. Da der kabelgebundene Port im TRUST-Modus arbeitet oder es ermöglicht, die Firewall zu umgehen, ohne eine Authentifizierung des Client-Geräts vorzunehmen, kann der Angreifer auf das Micro Branch Deployment Network 200 zugreifen. Dies wiederum ermöglicht dem Angreifer einen vollständigen Netzwerkzugriff auf das Hauptnetzwerk (z. B. das Rechenzentrum 110 von 1) sowie auf andere Zweigstellennetzwerke, z. B. die Mikrozweigstellennetzwerke 120, 130 (1).
Ein weiterer herkömmlicher Mechanismus zur Vermeidung von Firewall-Inkonsistenzen ist die Verkettung der Authentifizierung und die Verwendung der Rollenableitung, z. B. unter Verwendung der Radius-Authentifizierung. Wenn beispielsweise das Client-Gerät 222 eine Verbindung zu einem AP, z. B. AP 220, herstellt, kann die Radius-Authentifizierung sofort für die verbundene drahtlose SSID (VAP-X) ausgelöst werden, und es kann eine Benutzerrolle, z. B. Rolle A, abgeleitet werden. Wenn die Pakete des Client-Geräts 222 einen AP der „oberen Schicht“, hier AP 210, erreichen, kann die Radius-Authentifizierung für dasselbe Client-Gerät, Client-Gerät 222, am kabelgebundenen Port (Eth-X) von AP 210 erneut ausgelöst werden. Dementsprechend könnte dieselbe Benutzerrolle abgeleitet und auf den kabelgebundenen Port von AP 210 angewendet werden. Wenn ein Paket von Client-Gerät 222 GAP 202 erreicht, kann die gleiche Authentifizierung und Ableitung der Benutzerrolle erfolgen. Obwohl die Firewall-Verarbeitung über die APs (und GAP) hinweg konsistent bleibt, werden redundante Authentifizierungstransaktionen eingeführt, und es entsteht zusätzliche Zeit für die Verarbeitung des Datenflusses.
In einer typischen SDWAN/WAN-Zweigstelleneinrichtung steht ein dediziertes Gateway-Gerät als WAN-Gateway zur Verfügung. Die Aktivierung eines Authentifizierungsproxys, z. B. eines Radius-Proxys, auf einem solchen Gateway-Gerät kann dazu führen, dass als Teil der Benutzerkonfiguration jede SSID/jeder Port auf das Gateway-Gerät abgebildet wird. So weiß ein AP, dass das Gateway ein Authentifizierungs-Proxy-Gerät ist. Wenn ein Client-Gerät eine Verbindung zu einem AP herstellt, sendet dieser AP eine Authentifizierungsanforderung an das Gateway-Gerät, das seinerseits über den Authentifizierungsproxy eine Authentifizierung bei einem Backend-Authentifizierungsserver durchführt. Wenn eine Authentifizierungsantwort vom Authentifizierungsserver zurückkommt, sind sowohl das Gateway-Gerät als auch der AP in der Lage, die zugewiesene Benutzerrolle aufgrund des Authentifizierungsproxys festzustellen.
Aber auch in diesem Szenario können Probleme auftreten. Im Overlay-Fall fallen diese Client-Geräte in eine Overlay-Vlan-Liste, das Gateway-Gerät richtet Datenpfad-Benutzereinträge ein und wendet die abgeleitete Benutzerrolle auf den Gateway-Datenpfad an. Es sollte klar sein, dass sich Overlay in diesem Zusammenhang auf die Verwendung eines Tunnels, z. B. eines GRE-Tunnels, beziehen kann, um den Datenverkehr von Client-Geräten zwischen einem AP und dem Gateway-Gerät zu übertragen. Die gleiche Benutzerrolle wird jedoch nicht vom AP verwendet (was wiederum zu Inkonsistenzen in der Firewall führt). Dementsprechend müsste ein Administrator eine separate Benutzerrolle für das SSID/verkabelte Port-Profil des APs konfigurieren, die sich vom Authentifizierungs- und Benutzerrollen-Ableitungsprozess unterscheiden würde. Während ein solcher Ansatz das Problem redundanter/duplizierter Authentifizierungstransaktionen löst, führt er dennoch zu zusätzlichem Verwaltungsaufwand, ganz zu schweigen davon, dass der Administrator sehr genau wissen muss, welche Richtlinien vom Gateway-Gerät und vom AP konfiguriert und ausgeführt werden müssen.
Im Underlay-Fall fallen diese Clients nicht in eine Overlay-Vlan-Liste, das Gateway richtet keinen Datenpfad-Benutzereintrag ein, und es wird keine Benutzerrolle auf den Gateway-Datenpfad angewendet. Underlay kann sich in diesem Zusammenhang auf Datenverkehr beziehen, der in einer Mikroverzweigung direkt überbrückt wird (kein GRE-Tunnel), und als solches sehen alle APs in einer Mikroverzweigung die gleichen Client-Geräte in der Mikroverzweigung, d. h. es gibt kein Overlay innerhalb der Mikroverzweigung. Stattdessen befindet sich der Benutzereintrag im AP-Datenpfad, und die abgeleitete Benutzerrolle wird vom AP angewendet. Dies ist zwar ausreichend, wenn die APs nur einen Schritt vom Gateway entfernt sind, aber im Fall von verketteten APs über die kabelgebundenen Ports der APs führt das Versäumnis, eine ACL-Richtlinie auf diese kabelgebundenen Ports anzuwenden, wieder zu einem Sicherheitsrisiko. Wenn die Authentifizierung und die Ableitung der Benutzerrolle für jeden verkabelten Port konfiguriert sind, werden die doppelten Authentifizierungstransaktionen und die zusätzliche Zeit für die Verarbeitung des Datenflusses erneut zu einem Problem für die verketteten APs. Wie bereits erwähnt, gibt es im Gegensatz zu einer typischen Zweigstellenbereitstellung bei einer Mikrozweigstellenbereitstellung kein dediziertes Gateway, sondern nur ein GAP.
Wie bereits erwähnt, sind verschiedene Ausführungsformen darauf ausgerichtet, ACL-Regeln letztlich nur auf den AP anzuwenden, mit dem ein Client-Gerät direkt verbunden/assoziiert ist. Andere APs in einem Verkettungspfad zum GAP eines Mikrozweig-Einsatzes müssen keine Regeln anwenden, um redundante Authentifizierungs- und Benutzerregelableitungsprozesse zu vermeiden. Diese anderen APs müssen nur wissen, dass ein bestimmtes Client-Gerät mit einem Leaf-AP verbunden ist, so dass beim Empfang von Verkehr/Paketen von dem Client-Gerät herkömmliche Verarbeitungen/Vorgänge bezüglich Authentifizierung/Benutzerregelableitung ignoriert oder anderweitig umgangen werden können. Es sollte beachtet werden, dass verschiedene Ausführungsformen nicht von einem Cloud-Dienst/einer Cloud-basierten Funktionalität abhängig sind. Ein erster Schritt zur Erreichung dieser Unabhängigkeit besteht darin, die Eltern-Kind-Topologie einer Mikrofiliale zu ermitteln.
Wenn ein AP gemäß einer „AP config service“-Operation konfiguriert wird, wird auch ein eindeutiger „branch-key“ von der Cloud an alle APs innerhalb der Zweigstelle übertragen. Im Falle einer Mikrozweigstelle wird ein „Mikrozweigstellen-Gateway-AP“-Flag vom AP-Konfigurationsdienst der Cloud an das GAP der Mikrozweigstelle übertragen, z. B. an das GAP 202 (2). Dieses Micro-Branch-Gateway-AP-Flag wird in einer Speichereinheit, z. B. im Flash-Speicher des GAPs, gespeichert. Gemäß einer Ausführungsform kann dieses Mikroverzweigungs-Gateway-AP-Flag (oder einfach GAP) genutzt werden, um anzuzeigen, dass dieses bestimmte GAP der „IAP-Master“ für die Mikroverzweigung ist. Nachdem das GAP als „IAP-Master“ festgelegt ist, kann der herkömmliche hierarchische IAP-Ermittlungsprozess beginnen.
Das heißt, der GAP kann sein Erscheinen periodisch über eine hierarchische Bake ankündigen, die periodisch (z. B. jede Sekunde) über alle seine verkabelten Ports gesendet wird. Bei dieser hierarchischen Bake kann es sich um ein Layer 2 (L2) Broadcast-Datenpaket handeln, das einer Bridge Protocol Data Unit (BPDU) ähnelt, d. h. einer Nachricht, die von Brücken aneinander gesendet wird, um die Bestimmung einer Spanning Tree Topologie zu erleichtern. Innerhalb der Nachricht enthält ein als „ROOT IP“ bezeichnetes Feld die Management-IP-Adresse des GAPs.
Bezugnehmend auf 3 und in Übereinstimmung mit dem konventionellen hierarchischen Beaconing-Prozess 300, wenn ein Downlink-AP, z. B. AP 210, eine hierarchische Beacon-Nachricht von GAP 202 bei Operation 302 empfängt, wird dem AP, z. B. AP 210, bewusst, dass ein Root-AP mit der IP-Adresse des GAP im Netzwerk existiert. Mit anderen Worten: AP 210 erfährt von der Existenz von GAP 202. Der Downlink-AP, in diesem Beispiel AP 210, kann dann bei Operation 304 eine hierarchische Bestätigung (ACK) an den Root-AP, in diesem Beispiel GAP 202, senden, wobei diese ACK ein als „AP_IP“ bezeichnetes Feld enthält. „Das heißt, AP 210 setzt die AP_IP-Adresse auf seine IP-Adresse‟. Auf diese Weise erfährt der Root-AP, d. h. GAP 202, die IP-Adresse des Downlink-AP, d. h. die IP-Adresse von AP 210. Wenn ein Downlink-AP aus irgendeinem Grund stirbt oder neu startet, können solche Downlink-APs kein hierarchisches ACK zurück an den GAP senden. Daher kann das GAP diesen AP aus seiner AP-Datenbank entfernen, so dass nur noch die Downlink-APs innerhalb der Mikrofiliale aktiv sind.
In ähnlicher Weise kann der AP 220 nach dem Empfang der hierarchischen Bake vom Root-AP, d. h. GAP 202, in Operation 302 auf die hierarchische Bake antworten, indem er in Operation 306 eine hierarchische ACK zurück an GAP 202 sendet, die seine IP-Adresse im AP_IP-Feld der hierarchischen ACK enthält. Dementsprechend kann der GAP einer Mikrozweigstelle alle APs im Netzwerk der Mikrozweigstelle kennenlernen. Ebenso können die untergeordneten APs in einer Mikroverzweigung etwas über ihren Stamm-AP/GAP erfahren. Da ein Root-AP die IP-Adressen seiner Downlink-APs kennt, kann er z. B. in einem Szenario zur Aktualisierung des Zweigstellen-Images weitere Informationen überdie Downlink-APs sammeln, z. B. Informationen über den AP-Typ. Der Root-AP kann dann entweder alle erforderlichen AP-Images direkt herunterladen oder einige der APs anweisen, das Upgrade-Image von einem Remote-Image-Server herunterzuladen.
Obwohl der oben beschriebene Erkennungsmechanismus es einem Downlink-AP ermöglicht, den Root-AP des Mikrozweig-Einsatzes zu erfahren, weiß der Downlink-AP nicht unbedingt, welcher Uplink-AP sein „exakter“/direkter Eltern-AP ist. Dementsprechend bieten verschiedene Ausführungsformen Verbesserungen des herkömmlichen hierarchischen IAP-Erkennungsprozesses oder -mechanismus. Insbesondere wird zusätzlich zum Feld „ROOT IP“, das bereits in der hierarchischen Bake enthalten ist, das Feld „AP_IP“ in die hierarchische Bake eingefügt, zusätzlich zum Feld „Root IP“, das bereits Teil der hierarchischen Bake ist. Der von der Cloud empfangene Branch-Key-AP kann zwischen den APs für die Pre-Shared-Key-Authentifizierung (PSK) sowie für die Triple Data Encryption Standard (3DES)-Verschlüsselung verwendet werden und bietet somit mehr Sicherheit für den Topologieerkennungsprozess.
Infolge der Hinzufügung des Feldes „AP_IP“ zum hierarchischen Beacon, das vom GAP gesendet wird, kann das GAP damit beginnen, seine periodischen hierarchischen Beacons zu senden und sowohl die Felder „ROOT IP“ als auch „AP_IP“ so einzustellen, dass sie mit seiner eigenen Management-IP-Adresse übereinstimmen. In 3 ist der erweiterte hierarchische Erkennungsprozess 310 dargestellt. Wenn der AP 210 beispielsweise ein hierarchisches Beacon von seinem Uplink-Port bei Operation 312 empfängt, wird dem AP 210 bewusst, dass ein übergeordneter AP in seinem Mikrozweigverteilungsnetz existiert und dass dieser übergeordnete AP auch der Root-AP des Mikrozweigverteilungsnetzes ist. AP 210 kann dann auf die hierarchische Bake in Operation 314 reagieren, indem er eine hierarchische ACK an GAP 202 über denselben Uplink-Port sendet. Auf diese Weise erfährt GAP 202 von der Existenz eines Zweig-AP in seinem Mikro-Zweigstellennetz, d. h. des Downlink-AP 210.
Bei Vorgang 316 ändert AP 210 die ursprüngliche hierarchische Bake, die er von GAP 202 empfangen hat, indem er das Feld „AP_IP“ so ändert, dass es seine eigene IP-Adresse (und nicht die IP-Adresse von GAP 202) wiedergibt, und kann dann die (neue) geänderte hierarchische Bake an alle seine drahtgebundenen Downlink-Ports senden. Wenn AP 220 diese modifizierte hierarchische Bake von seinem Uplink-Port empfängt, erfährt AP 220, dass GAP 202 der Root-AP des Micro Branch Deployment Network ist, während AP 210 der Parent-AP von AP 220 ist. Bei Operation 318 kann AP 220 dann sein eigenes hierarchisches ACK an GAP 202 über den Uplink-Port senden, über den er das modifizierte hierarchische Beacon von AP 210 empfangen hat. Aufgrund der Daisy-Chain-Topologie geht die von AP 220 gesendete hierarchische ACK auf dem Weg zu GAP 202 an AP 210. Zu diesem Zeitpunkt erfährt AP 210, dass er einen untergeordneten AP hat, nämlich AP 220. AP 210 kann dann den hierarchischen ACK von AP 220 bis zu GAP 202 weiterleiten. An diesem Punkt erfährt GAP 202 von der Existenz eines weiteren Neben-AP, AP 220, der mit seinen drahtgebundenen Downlink-Ports verbunden ist.
Es versteht sich, dass der obige Prozess/die obige Methode wiederholt werden kann, je nachdem, wie viele APs in einer Mikroverzweigung eine hierarchische Bake vom Root-AP/GAP empfangen und wie viele APs mit ihren jeweiligen hierarchischen ACKs antworten. Da hierarchische Beacons periodisch, z. B. jede Sekunde, gesendet werden, kann die Topologie der Mikrozweige kontinuierlich entdeckt/bestimmt und aktualisiert werden. Es ist zu beachten, dass hierarchische Beacons nur dann berücksichtigt werden sollten, wenn sie von/über den Uplink-Port eines APs empfangen werden. Dementsprechend wird jede Bake, die von/über den Downlink-Port eines APs empfangen wird, verworfen/ignoriert. Ebenso sollte ein hierarchisches ACK nur berücksichtigt werden, wenn es von einem Downlink-Port eines APs empfangen wird, und jede hierarchische ACK-Nachricht, die von/über einen Uplink-Port eines APs empfangen wird, wird verworfen/ignoriert. Wenn dieses Schema nicht befolgt wird, ist ein AP nicht in der Lage, zwischen Uplink/Parent APs oder dem GAP und Downlink/Child APs zu unterscheiden.
Wie bereits erwähnt, beinhaltet ein zweiter Schritt zur Erreichung des Ziels, ACL-Regeln nur auf den AP anzuwenden, mit dem ein Client-Gerät direkt verbunden/assoziiert ist, ohne redundante Authentifizierungs-/Benutzerregelableitung, den Aufbau einer Authentifizierungs-Proxy-Kette unter Verwendung der Mikrozweigstellen-Topologie. Auf diese Weise kann diese Authentifizierungs-Proxy-Kette automatisch von einem Blatt-AP zu einem Gateway-AP (GAP) ausgelöst werden, wenn sich ein Client-Gerät mit einem Mikrozweig-Netzwerk verbindet.
Wie oben angedeutet und in 4 dargestellt, beinhaltet eine herkömmliche Authentifizierungsmethode 400 für Client-Geräte in einer Mikro-Zweigstelleneinrichtung, in der APs verkettet sind, Authentifizierungsanfragen, die von jedem AP, der von einem Client-Geräte-Paket/Verkehr durchquert wird, an denselben Authentifizierungsserver gehen. Beim Empfang eines Pakets von einem Client-Gerät (in 4 nicht dargestellt), das mit AP 220 verbunden ist, wird beispielsweise die Authentifizierung durch die Anforderung der Authentifizierung von einem entfernten Authentifizierungsserver ausgelöst, z. B. die Radius-Authentifizierung von einem entfernten Radius-Server. Während das Paket AP 210 durchläuft, wird die Authentifizierung erneut über den entfernten Radius-Server ausgelöst, und so weiter bis zum GAP 202. Dies führt jedoch dazu, dass redundante Authentifizierungsvorgänge ausgelöst werden.
Stattdessen und gemäß einer Ausführungsform kann die herkömmliche Authentifizierung durch eine automatische Authentifizierungs-Proxy-Verkettung ersetzt werden, die durch das Verfahren 410 reflektiert wird. Wie in 4 dargestellt, ist ein Authentifizierungs-Client in einem AP, z. B. ein Radius-Client, so konfiguriert oder eingerichtet, dass er Zugriffsanforderungsnachrichten, z. B. Radius-Zugriffsanforderungen, für alle mit einem AP verbundenen Client-Geräte initiiert und Authentifizierungsnachrichten/-pakete mit einem entsprechenden Authentifizierungsserver, z. B. einem Radius-Server, austauscht. Abweichend von der konventionellen Authentifizierung wird der Authentifizierungsserver, an den Radius-Zugriffsanfragen gerichtet werden, an den übergeordneten AP dieses AP gerichtet. So stellt beispielsweise AP 220 seinen Authentifizierungsserver auf seinen übergeordneten AP ein (den AP 220 über den oben beschriebenen Mechanismus zur Erkennung der Topologie von Mikrofilialen entdeckt/erlernt hat). Im Gegenzug stellt AP 210 seinen Authentifizierungsserver auf seinen übergeordneten AP ein, der in diesem Beispiel der Root-AP/GAP 202 ist (der wiederum durch den oben erwähnten Topologie-Ermittlungsmechanismus ermittelt wurde). Bei GAP 202 ist der Authentifizierungsserver ein tatsächlicher Radius-Server, an den die Radius-Zugriffsanfragen letztendlich weitergeleitet werden. Es sollte klar sein, dass der Netzwerkadministrator am GAP 202 den „echten“ Authentifizierungsserver einstellt, da GAP 202 keinen Uplink/Parent AP hat. Mit anderen Worten, die übergeordneten APs fungieren als Proxy-Authentifizierungsserver (Proxy-Kette), über die Authentifizierungszugriffsanfragen weitergeleitet werden, bis ein tatsächlicher Authentifizierungsserver erreicht wird.
So kann z. B. aufgrund des Prozesses zur Erkennung der Mikrozweigtopologie festgestellt werden, dass AP 220 ein Kind von AP 210, seinem Eltern-AP, ist. AP 210 kann intern bestimmte Informationen einstellen oder spezifizieren, wodurch AP 220 in eine Authentifizierungs-/Radius-Akzeptanzliste aufgenommen wird, so dass er in der Lage ist, jede Authentifizierungs-/Radius-Zugangsanfrage von AP 220 zu akzeptieren. AP 210 kann außerdem GAP 202 als Authentifizierungs-/Radius-Server einstellen oder spezifizieren, so dass, wenn AP 210 eine Authentifizierungs-/Radius-Zugangsanfrage von AP 220 erhält, die Anfrage an GAP 202 weitergeleitet werden kann. In umgekehrter Richtung, wenn GAP 202 eine Authentifizierungs-/Radius-Zugangsantwort empfängt, die sich auf dieselbe MAC-Adresse des Client-Geräts bezieht, weiß GAP 202, dass die Authentifizierungs-/Radius-Zugangsantwort für den Authentifizierungs-/Radius-Client (in diesem Fall AP 210) relevant ist. Daher kann GAP 202 die Authentifizierungs-/Radius-Zugangsantwort an AP 210 senden/weiterleiten. AP 210 arbeitet in gleicher Weise, indem er die Authentifizierungs-/Radius-Zugangsantwort an seinen Authentifizierungs-/Radius-Client, AP 220, sendet/weiterleitet.
Wie bereits erwähnt, beinhaltet ein dritter Schritt zur Erzielung einer konsistenten Firewall-Richtlinie die Firewall-Optimierung, bei der nur der AP, mit dem ein Client-Gerät direkt verbunden/assoziiert ist, Rechte/Regeln durchsetzt, die der einem Client-Gerät zugewiesenen Benutzerrolle entsprechen. 5 zeigt ein Verfahren zur Firewall-Optimierung (500). Ein Client-Gerät 222 kann versuchen, eine Verbindung zu einem AP (z. B. AP 220) herzustellen, entweder über eine WLAN-SSID oder einen kabelgebundenen Port. Nehmen wir als Beispiel an, dass das Client-Gerät 222 versucht, sich über eine WLAN-SSID mit AP 220 zu verbinden. AP 220, der als Authentifizierungsclient, z. B. Radius-Client, fungiert, erstellt eine Zugriffsanforderung, z. B. eine Radius-Zugriffsanforderung, die AP 220 an seinen übergeordneten AP, in diesem Fall AP 210, sendet. Auch hier führt die Erkennung der Baumtopologie der Mikroverzweigung dazu, dass jeder AP in der Mikroverzweigung seine übergeordneten/untergeordneten APs (falls vorhanden) kennenlernt/erkennt. Eine Zugriffsanforderungsnachricht, z. B. eine Radius-Zugriffsanforderung, kann die folgenden Informationen enthalten: User-Name <=> Benutzername; Calling-Station-Id <=> MAC-Adresse des Client-Geräts; Network-Profile <=> SSID-Profilname oder kabelgebundener Port-Profilname; NAS-Port-Type <=> um Informationen über den kabelgebundenen/drahtlosen Typ zu erhalten. Es ist zu verstehen, dass sich das Netzwerkprofil auf ein neues herstellerspezifisches Attribut (VSA) bezieht, das den SSID-Namen oder den Namen des kabelgebundenen Portprofils enthält. Diese Informationen helfen einem GAP, z. B. GAP 202, den richtigen Authentifizierungsserver, z. B. Radius-Server, für die SSID zu finden, zu der das Client-Gerät 222 eine Verbindung herzustellen versucht. Wenn AP 210 (der als Radius-Proxy fungiert) diese Radius-Zugriffsanfrage erhält, sendet AP 210 die Zugriffsanfrage an GAP 202. Das Ergebnis ist eine Authentifizierungs- (z. B. Radius-) Anforderungskette 504. GAP 202 dekodiert die Radius-Zugangsanforderung, erfährt den „SSID-Profilnamen“, der in der Anforderungsnachricht enthalten ist, und verwendet dann diesen Namen, um den korrekten (von einem Netzwerkadministrator konfigurierten) Radius-Server zu bestimmen, an den die Zugangsanforderungsnachricht weitergeleitet werden sollte.
Wenn ein Authentifizierungsserver konfiguriert ist, sendet GAP 202 die Zugangsanfrage an diesen Authentifizierungsserver. GAP 202 erwartet eine Antwort, die den Zugriff akzeptiert oder ablehnt, z. B. Radius Access Accept oder Radius Access Reject. Nachdem GAP 202 die erwartete Authentifizierungsantwort erhalten hat, sendet GAP 202 die Authentifizierungsantwort an AP 210. Wenn der Authentifizierungsserver vorübergehend nicht erreichbar ist oder GAP 202 keinen Authentifizierungsserver für diese bestimmte Zugriffsanforderung finden kann, verwendet GAP 202 einen Ausweichmodus, indem es direkt eine Authentifizierungszugriffsannahmeantwort an AP 210 sendet. GAP 202 kann auch einen vertrauenswürdigen Benutzereintrag (mit der MAC-Adresse des Client-Geräts 222) für den Datenpfad einrichten. Dadurch kann sichergestellt werden, dass weitere Datenpakete, die vom Client-Gerät 222 kommen, keinen Authentifizierungsprozess auf GAP 202 auslösen. Außerdem wendet GAP 202 die abgeleitete Benutzerrolle nicht auf den Datenpfad von GAP 202 an, so dass diese Datenpakete vom Client-Gerät 222 nicht von GAP 202 abgefangen werden.
Andernfalls, wenn die gleiche Antwort bei AP 210 eintrifft, wird AP 210 entsprechend reagieren. Das heißt, AP 210 kann die Antwort auf die Annahme des Authentifizierungszugangs an AP 220 senden und einen vertrauenswürdigen Benutzereintrag in den Datenpfad von AP 210 einrichten. Dieser vertrauenswürdige Benutzereintrag (mit der MAC-Adresse des Client-Geräts 222) stellt wiederum sicher, dass keine weitere Authentifizierung für das Client-Gerät 222 erforderlich ist. Ebenso wendet AP 210 die abgeleitete Benutzerrolle nicht auf seinen Datenpfad an, so dass das Client-Gerät 222 von AP 210 nicht mit einer Firewall versehen wird.
Wenn AP 220 die Antwort auf den Authentifizierungszugang erhält, konsumiert AP 220 die Antwortnachricht, da er der Authentifizierungsclient für das Client-Gerät 222 ist. Das Ergebnis ist eine Authentifizierungsantwortkette 506. AP 220 kann dadurch den Authentifizierungskettenprozess beenden und einen normalen/unvertrauenswürdigen Datenweg-Benutzereintrag einrichten, der mit einer abgeleiteten Benutzerrolle auf der Grundlage der Authentifizierungs-(Radius-)VSA bei Vorgang 508 angewendet werden kann. Im Fall der Verwendung des Fallback-Modus, da GAP 202 keine VSA für die Rollenableitung sendet, kann AP 220 einfach die Standard-Benutzerrolle nach der Authentifizierung für diese SSID/den verdrahteten Port anwenden. Es sollte klar sein, dass in einer Authentifizierungs-/Radius-Antwort ein Feld verwendet wird, um anzugeben, welche Benutzerrolle ein AP auf ein bestimmtes Client-Gerät/einen bestimmten Benutzer anwenden soll. Ein Netzwerkadministrator kann beispielsweise eine Zeichenfolge wie „Gast“ verwenden, die auf dem eigentlichen Authentifizierungsserver angegeben ist. Wenn AP 220 die Antwort auf den Authentifizierungszugriff empfängt, dekodiert er die Nutzdaten und weiß, dass einem bestimmten Client-Gerät die Benutzerrolle „Gast“ zugewiesen werden soll. AP 220 kann seine lokale Konfiguration durchsuchen, um festzustellen, was für die Gastbenutzerrolle konfiguriert wurde. In den meisten Fällen wird die Konfiguration bereits eine Benutzerrolle enthalten, aber wenn keine Benutzerrolle konfiguriert wurde, kann eine Standard-Benutzerrolle für die bestimmte SSID/den verdrahteten Port verwendet werden.
Es sollte beachtet werden, dass, wenn die SSID/der verdrahtete Port eines APs als OPEN oder PSK konfiguriert ist, die MAC-Authentifizierung automatisch für diese SSID/den verdrahteten Port aktiviert werden kann. Dadurch wird derselbe Authentifizierungs- und Verkettungsprozess ausgelöst. Da GAP 202 jedoch nicht in der Lage ist, einen gültigen Authentifizierungsserver auf der Grundlage der „Network-Profile“-Informationen zu finden, wird es den oben erwähnten Fallback-Modus verwenden, um die Authentifizierungsantwort an die Downlink-APs, z. B. APs 210 und 220, zu senden. Es ist zu beachten, dass die hier beschriebenen Ausführungsformen sich auf die Radius-Authentifizierung beziehen. Die Radius-Authentifizierung ist nur ein möglicher Authentifizierungsmechanismus bzw. ein System, das verwendet werden kann. Andere Ausführungsformen sehen die Verwendung anderer Authentifizierungsmechanismen als Radius vor, z.B. LDAP, TACACS+, XTACACS, usw.
6A ist ein Blockdiagramm einer beispielhaften Rechnerkomponente oder eines Geräts 600 zur Erkennung der Mikrozweigtopologie in Übereinstimmung mit einer Ausführungsform. Bei der Rechnerkomponente 600 kann es sich beispielsweise um einen Controller, Prozessor oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten und die Funktionalität eines GAP zu realisieren. In der Beispielimplementierung von 6A umfasst die Rechnerkomponente 600 einen Hardware-Prozessor 602 und ein maschinenlesbares Speichermedium 604.
Bei dem Hardware-Prozessor 602 kann es sich um eine oder mehrere Zentraleinheiten (CPUs), halbleiterbasierte Mikroprozessoren und/oder andere Hardwarevorrichtungen handeln, die zum Abrufen und Ausführen von Anweisungen geeignet sind, die in dem maschinenlesbaren Speichermedium 404 gespeichert sind. Der Hardware-Prozessor 602 kann Befehle, wie die Befehle 606-610, abrufen, dekodieren und ausführen, um Prozesse oder Vorgänge zum Aufbau von Verbindungen, zur Synchronisierung und zur Veröffentlichung von Routen/Zuständen zu steuern. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann der Hardware-Prozessor 602 einen oder mehrere elektronische Schaltkreise enthalten, die elektronische Komponenten zur Ausführung der Funktionalität eines oder mehrerer Befehle umfassen, wie z. B. ein Field Programmable Gate Array (FPGA), anwendungsspezifische integrierte Schaltkreise (ASIC) oder andere elektronische Schaltkreise.
Ein maschinenlesbares Speichermedium, wie das maschinenlesbare Speichermedium 604, kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät sein, das ausführbare Anweisungen enthält oder speichert. Bei dem maschinenlesbaren Speichermedium 604 kann es sich beispielsweise um einen Arbeitsspeicher (RAM), einen nichtflüchtigen Arbeitsspeicher (NVRAM), einen elektrisch löschbaren, programmierbaren Festspeicher (EEPROM), ein Speichergerät, eine optische Platte und dergleichen handeln. In einigen Ausführungsformen kann das maschinenlesbare Speichermedium 404 ein nicht-transitorisches Speichermedium sein, wobei der Begriff „nicht-transitorisch“ nicht die transitorischen Übertragungssignale umfasst. Wie nachstehend im Detail beschrieben, kann das maschinenlesbare Speichermedium 604 mit ausführbaren Befehlen kodiert sein, z. B. mit den Befehlen 606-608.
Der Hardware-Prozessor 602 kann die Anweisung 606 ausführen, um eine hierarchische Bake zu senden, die einen GAP als Stamm-AP identifiziert. Es sollte klar sein, dass die Computerkomponente 600 in einigen Ausführungsformen ein GAP in einer Mikrozweigstelle sein kann. Wie oben erwähnt, kann der hierarchische Beaconing-Prozess als GAP eines Mikrozweig-Einsatzes angepasst werden, indem ein AP_IP-Identifikator/Indikator zum hierarchischen Beacon zusätzlich zum Root_IP-Idikator/Indikator hinzugefügt wird. Das heißt, dass sowohl die AP _IP- als auch die root_IP-Kennung/Kennung so eingestellt werden, dass sie die Management-IP-Adresse des GAP wiedergeben.
Ein Downlink-AP, der das hierarchische Beacon empfängt, erfährt von der Existenz eines übergeordneten AP, in diesem Fall des GAP, der auch der Root-AP des Mikrozweig-Einsatzes ist. Dieser Downlink-AP kann auf die hierarchische Bake mit einer hierarchischen Bestätigung antworten. Auf diese Weise erfährt der GAP von der Existenz eines untergeordneten oder Downlink-Zweig-AP. Dieser Downlink-Zweig-AP kann dann die ursprünglich empfangene hierarchische Bake modifizieren, indem er die AP_IP-Kennung/den AP_IP-Indikator so ändert, dass sie/er die eigene IP-Adresse des Downlink-Zweig-APs widerspiegelt, und diese modifizierte hierarchische Bake an seine drahtgebundenen Downlink-Ports sendet, um sie an andere Downlink-APs in der MikroZweig-Einrichtung zu senden. Das heißt, der Hardware-Prozessor 602 kann die Anweisung 608 ausführen, um hierarchische Bestätigungen von einem oder mehreren Downlink-APs zu empfangen, die das Vorhandensein des einen oder der mehreren Downlink-APs anzeigen, wobei die hierarchischen Bestätigungen auf iterativ modifizierte Versionen der hierarchischen Bake reagieren, die über jeden der einen oder mehreren Downlink-APs weitergeleitet werden. Obwohl einige Ausführungsformen im Zusammenhang mit mehreren Downlink-APs beschrieben werden, können sich Client-Geräte mit einem einzigen Downlink-AP verbinden/assoziieren und durch den GAP (z. B. Ethernet-Downlink-Port) mit einer Firewall versehen werden. Dementsprechend können die hier beschriebenen Ausführungsformen auch auf eine Topologie mit einem einzigen Downlink-AP anwendbar sein.
Es versteht sich von selbst, dass der GAP die hierarchische Bake auch auf seinen drahtgebundenen Downlink-Ports sendet und alle APs der Downlink-Zweige die ursprüngliche(n) oder modifizierte(n) hierarchische(n) Bake(s) auf ihren jeweiligen drahtgebundenen Uplink-Ports empfangen. Dieser Prozess kann so lange fortgesetzt werden, bis die Topologie der Mikroverzweigung aus Sicht des GAP und aller APs in der Mikroverzweigungseinrichtung erkannt wurde.
6B ist ein Blockdiagramm einer beispielhaften Rechnerkomponente oder eines Geräts 610 zur Erkennung der Mikrozweig-AP-Topologie in Übereinstimmung mit einer Ausführungsform. Bei der Rechnerkomponente 610 kann es sich beispielsweise um einen Controller, einen Prozessor oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten und die Funktionalität eines APs zu realisieren. Das heißt, 6B illustriert die Mikrozweig-AP-Topologieerkennung aus der Perspektive eines Downlink-AP. In der Beispielimplementierung von 6B umfasst die Rechnerkomponente 610 einen Hardwareprozessor 612 und ein maschinenlesbares Speichermedium 614, bei dem es sich um weitere Ausführungsformen von z. B. Hardwareprozessor 602 und maschinenlesbarem Speichermedium 604 handeln kann.
Der Hardware-Prozessor 612 kann den Befehl 616 ausführen, um eine hierarchische Bake zu empfangen, die einen GAP als Root-AP für den AP identifiziert. Wie oben beschrieben, enthält die hierarchische Bake nicht nur eine root_IP-Kennung, sondern auch eine AP-IP-Kennung, wobei der GAP sowohl in der root_IP- als auch in der AP_IP-Kennung enthalten ist.
Der Hardware-Prozessor 612 kann die Anweisung 618 ausführen, um eine hierarchische Bestätigung als Antwort auf die hierarchische Bake zu senden, z. B. zurück zum GAP oder seinem unmittelbaren Eltern-AP. Der Hardware-Prozessor 612 kann die Anweisung 620 ausführen, um die hierarchische Bake so zu modifizieren, dass sie die eigene IP-Adresse des APs widerspiegelt und die modifizierte hierarchische Bake an einen oder mehrere Downlink-APs sendet. Der Hardware-Prozessor 612 kann die Anweisung 622 ausführen, um empfangene hierarchische Bestätigungen von einem oder mehreren Downlink-APs an das GAP weiterzuleiten. Auf diese Weise wird die hierarchische Bake iterativ modifiziert, während sie sich durch jeden Downlink-AP bewegt, und jeder Downlink-AP wird sich des GAPs (identifiziert über den root_IP-Identifier) und seines jeweiligen Eltern-APs (identifiziert über die iterativ modifizierte hierarchische Bake, wobei die Modifikation im Hinblick auf den sich ändernden AP_IP-Identifier während der Bewegung durch jeden der APs in der Mikroverzweigung entsteht. Jede am GAP empfangene hierarchische Bestätigung informiert den GAP auch über jeden seiner Downlink-Zweig-APs.
6C ist ein Blockdiagramm einer beispielhaften Rechnerkomponente oder eines Geräts 630 zur Durchführung der Firewall-Optimierung gemäß einer Ausführungsform. Bei der Rechnerkomponente 630 kann es sich beispielsweise um einen Controller, einen Prozessor oder eine andere ähnliche Rechnerkomponente handeln, die in der Lage ist, Daten zu verarbeiten und die Funktionalität eines APs zu realisieren. In der Beispielimplementierung von 6C umfasst die Rechnerkomponente 630 einen Hardwareprozessor 632 und ein maschinenlesbares Speichermedium 634, bei dem es sich um weitere Ausführungsformen von z. B. Hardwareprozessor 602 und maschinenlesbarem Speichermedium 604 handeln kann.
Der Hardware-Prozessor 632 kann den Befehl 636 ausführen, um eine Authentifizierungs-Zugriffsanforderung für ein Client-Gerät zu initiieren. Es sollte klar sein, dass die Computerkomponente ein Downlink-AP einer Mikrozweigstelle sein kann, mit der das Client-Gerät verbunden ist. Wie bereits erwähnt, kann eine Authentifizierungs-Proxy-Kette eingerichtet werden, bei der jeder Downlink-AP in der Mikroverzweigung an einen Authentifizierungsserver (für den Empfang einer Authentifizierungs-Zugriffsanforderung) geleitet wird, der als übergeordneter AP des AP definiert ist, der die Authentifizierungs-Zugriffsanforderung erzeugt/übermittelt. Mit anderen Worten: Jeder AP, der ein übergeordneter AP für einen untergeordneten AP ist, fungiert als Authentifizierungs-Proxy, bis der übergeordnete AP in der Kette der Authentifizierungs-Proxys der GAP ist. Der GAP kann dann auf einen tatsächlichen Authentifizierungsserver verweisen, um die Authentifizierung des Client-Geräts durchzuführen. Dementsprechend kann der Hardware-Prozessor 632 die Anweisung 638 ausführen, um die Authentifizierungszugriffsanforderung an einen übergeordneten Zugangspunkt zu übermitteln, wobei die Authentifizierungszugriffsanforderung an einen Authentifizierungsserver-Proxy gerichtet wird, der als übergeordneter Zugangspunkt definiert ist.
Der Hardware-Prozessor 632 kann die Anweisung 640 ausführen, um eine Antwort auf den Authentifizierungszugriff zu empfangen, wobei die Antwort auf den Authentifizierungszugriff von einem tatsächlichen Authentifizierungsserver erzeugt wird, der über den übergeordneten AP, der als Proxy für den Authentifizierungsserver definiert ist, weitergeleitet wird. Das heißt, dass nach der Verarbeitung der Authentifizierungszugriffsanforderung auf dem eigentlichen Authentifizierungsserver (der gegenüber den APs in der Mikrozweigverwendung als Proxy fungiert) eine Authentifizierungszugriffsantwort in ähnlicher Weise durch die APs zurück nach unten weitergeleitet werden kann, bis sie den AP erreicht, der die Authentifizierungszugriffsanforderung übermittelt hat. Wie oben in 5 beschrieben, kann das GAP der Mikrozweigstelle einen TRUST-Benutzereintrag einrichten, um die Firewall-Behandlung von Datenpaketen zu unterbinden, die vom Client-Gerät an einem beliebigen AP empfangen werden, mit Ausnahme des AP, dem das Client-Gerät zugeordnet ist, wodurch eine redundante Anwendung von Firewall-Richtlinien vermieden wird.
Wie bereits erwähnt, nutzen verschiedene Ausführungsformen den bestehenden hierarchischen IAP-Beacon-Mechanismus in verbesserter Weise (d. h. durch Aufnahme einer AP_IP-Kennung in den von einem GAP gesendeten hierarchischen Beacon), so dass die GAP/AP-Topologie einer Mikrofiliale ermittelt werden kann. Die ermittelte Topologie ermöglicht den automatischen Aufbau einer Authentifizierungs-Proxy-Kette in der gesamten Mikrozweigstelle. Wenn sich Client-Geräte mit einem der APs in der Mikrofiliale verbinden, werden diese Client-Geräte gemäß der Authentifizierungs-Proxy-Kette authentifiziert. Auf diese Weise wird die Authentifizierung nur an dem AP ausgelöst, mit dem der Client verbunden ist, wodurch redundante Authentifizierungsvorgänge vermieden werden. Die Firewall wird nur auf dem AP ausgeführt, mit dem sich der Client verbindet, wodurch das oben erwähnte Problem der mehrfachen Firewalls vermieden und die Verarbeitungszeit des Datenflusses verbessert wird. Darüber hinaus kann z. B. mit Hilfe der Radius-Authentifizierung eine einzige Benutzerrolle abgeleitet und auf den angeschlossenen AP angewendet werden, so dass ein Netzwerkadministrator seine Firewall-Richtlinie nicht über mehrere Geräte hinweg koordinieren muss, was den Verwaltungsaufwand vereinfacht. Dementsprechend kann der Hardware-Prozessor die Anweisung 642 ausführen, um eine Benutzerrolle für das Client-Gerät auf der Grundlage der Authentifizierungszugriffsantwort anzuwenden.
7 zeigt ein Blockdiagramm eines beispielhaften Computersystems 700, in dem verschiedene der hier beschriebenen Ausführungsformen implementiert werden können. Das Computersystem 700 umfasst einen Bus 702 oder einen anderen Kommunikationsmechanismus zur Übermittlung von Informationen sowie einen oder mehrere Hardware-Prozessoren 704, die zur Verarbeitung von Informationen mit dem Bus 702 verbunden sind. Bei dem/den Hardware-Prozessor(en) 704 kann es sich zum Beispiel um einen oder mehrere Allzweck-Mikroprozessoren handeln.
Das Computersystem 700 umfasst auch Speichereinheiten, wie z. B. einen Hauptspeicher 706, wie z. B. einen Direktzugriffsspeicher (RAM), einen Cache und/oder andere dynamische Speichergeräte, die mit dem Bus 702 verbunden sind, um Informationen und Befehle zu speichern, die vom Prozessor 704 ausgeführt werden sollen. Der Hauptspeicher 706 kann auch zum Speichern von temporären Variablen oder anderen Zwischeninformationen während der Ausführung von Anweisungen verwendet werden, die vom Prozessor 704 ausgeführt werden sollen. Wenn solche Befehle in Speichermedien gespeichert werden, auf die der Prozessor 704 zugreifen kann, wird das Computersystem 700 zu einer Spezialmaschine, die so angepasst ist, dass sie die in den Befehlen angegebenen Operationen ausführen kann.
Das Computersystem 700 umfasst außerdem einen Festwertspeicher (ROM) 708 oder ein anderes statisches Speichergerät, das mit dem Bus 702 verbunden ist, um statische Informationen und Anweisungen für den Prozessor 704 zu speichern. Ein Speichergerät 710, wie z. B. eine Magnetplatte, eine optische Platte oder ein USB-Stick (Flash-Laufwerk) usw., ist vorgesehen und mit dem Bus 702 verbunden, um Informationen und Anweisungen zu speichern.
Im Allgemeinen kann sich der hier verwendete Begriff „Engine“, „Komponente“, „System“, „Datenbank“ und dergleichen auf eine in Hardware oder Firmware verkörperte Logik oder auf eine Sammlung von Softwareanweisungen beziehen, die möglicherweise Ein- und Ausstiegspunkte haben und in einer Programmiersprache wie z. B. Java, C oder C++ geschrieben sind. Eine Softwarekomponente kann kompiliert und zu einem ausführbaren Programm verknüpft werden, in einer dynamischen Link-Bibliothek installiert werden oder in einer interpretierten Programmiersprache wie BASIC, Perl oder Python geschrieben sein. Es versteht sich von selbst, dass Softwarekomponenten von anderen Komponenten oder von sich selbst aus aufrufbar sein können und/oder als Reaktion auf erkannte Ereignisse oder Unterbrechungen aufgerufen werden können. Softwarekomponenten, die für die Ausführung auf Computergeräten konfiguriert sind, können auf einem computerlesbaren Medium, wie z. B. einer Compact Disc, einer digitalen Videodisc, einem Flash-Laufwerk, einer Magnetplatte oder einem anderen greifbaren Medium, oder als digitaler Download bereitgestellt werden (und können ursprünglich in einem komprimierten oder installierbaren Format gespeichert sein, das vor der Ausführung eine Installation, Dekomprimierung oder Entschlüsselung erfordert). Ein solcher Softwarecode kann teilweise oder vollständig in einem Speicher des ausführenden Computergeräts gespeichert werden, damit er von dem Computergerät ausgeführt werden kann. Softwareanweisungen können in Firmware, wie z. B. einem EPROM, eingebettet sein. Darüber hinaus können die Hardwarekomponenten aus verbundenen Logikeinheiten wie Gattern und Flipflops und/oder aus programmierbaren Einheiten wie programmierbaren Gatteranordnungen oder Prozessoren bestehen.
Das Computersystem 700 kann die hierin beschriebenen Techniken unter Verwendung von kundenspezifischer festverdrahteter Logik, einem oder mehreren ASICs oder FPGAs, Firmware und/oder Programmlogik implementieren, die in Kombination mit dem Computersystem bewirkt oder programmiert, dass das Computersystem 700 eine Spezialmaschine ist. Gemäß einer Ausführungsform werden die hierin beschriebenen Techniken vom Computersystem 700 als Reaktion auf den/die Prozessor(en) 704 ausgeführt, der/die eine oder mehrere Sequenzen von einem oder mehreren im Hauptspeicher 706 enthaltenen Befehlen ausführt/ausführen. Solche Anweisungen können in den Hauptspeicher 706 von einem anderen Speichermedium, wie z. B. dem Speichergerät 710, eingelesen werden. Die Ausführung der im Hauptspeicher 706 enthaltenen Befehlssequenzen veranlasst den/die Prozessor(en) 704, die hier beschriebenen Prozessschritte durchzuführen. In alternativen Ausführungsformen können festverdrahtete Schaltungen anstelle von oder in Kombination mit Softwareanweisungen verwendet werden.
Der Begriff „nichtflüchtige Medien“ und ähnliche Begriffe, wie sie hier verwendet werden, beziehen sich auf alle Medien, die Daten und/oder Befehle speichern, die den Betrieb einer Maschine in einer bestimmten Weise bewirken. Solche nichtflüchtigen Medien können nichtflüchtige Medien und/oder flüchtige Medien umfassen. Zu den nichtflüchtigen Medien gehören beispielsweise optische oder magnetische Festplatten, wie die Speichervorrichtung 710. Zu den flüchtigen Medien gehören dynamische Speicher, wie der Hauptspeicher 706. Zu den gängigen Formen nichtflüchtiger Medien gehören beispielsweise Disketten, flexible Platten, Festplatten, Solid-State-Laufwerke, Magnetbänder oder andere magnetische Datenspeichermedien, CD-ROMs, andere optische Datenspeichermedien, physische Medien mit Lochmustern, RAM, PROM und EPROM, FLASH-EPROM, NVRAM, andere Speicherchips oder -kassetten sowie deren vernetzte Versionen.
Nicht-transitorische Medien unterscheiden sich von Übertragungsmedien, können aber in Verbindung mit ihnen verwendet werden. Übertragungsmedien sind an der Übertragung von Informationen zwischen nichttransitorischen Medien beteiligt. Zu den Übertragungsmedien gehören z. B. Koaxialkabel, Kupfer- und Glasfaserkabel, einschließlich der Drähte, aus denen der Bus 702 besteht. Übertragungsmedien können auch in Form von Schall- oder Lichtwellen auftreten, wie sie bei der Datenkommunikation über Funk und Infrarot erzeugt werden.
Das Computersystem 700 umfasst auch eine Kommunikationsschnittstelle 718, die mit dem Bus 702 verbunden ist. Die Kommunikationsschnittstelle 718 stellt eine Zweiwege-Datenkommunikationsverbindung zu einer oder mehreren Netzwerkverbindungen her, die mit einem oder mehreren lokalen Netzwerken verbunden sind. Bei der Kommunikationsschnittstelle 718 kann es sich beispielsweise um eine ISDN-Karte (Integrated Services Digital Network), ein Kabelmodem, ein Satellitenmodem oder ein Modem handeln, um eine Datenkommunikationsverbindung zu einer entsprechenden Art von Telefonleitung herzustellen. Als weiteres Beispiel kann die Kommunikationsschnittstelle 718 eine LAN-Karte sein, um eine Datenkommunikationsverbindung zu einem kompatiblen LAN (oder einer WAN-Komponente zur Kommunikation mit einem WAN) herzustellen. Es können auch drahtlose Verbindungen implementiert werden. In jeder dieser Implementierungen sendet und empfängt die Kommunikationsschnittstelle 718 elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen, die verschiedene Arten von Informationen darstellen.
Eine Netzverbindung ermöglicht in der Regel die Datenkommunikation über ein oder mehrere Netze zu anderen Datengeräten. Eine Netzverbindung kann beispielsweise eine Verbindung über ein lokales Netz zu einem Host-Computer oder zu Datengeräten herstellen, die von einem Internetdienstanbieter (ISP) betrieben werden. Der ISP wiederum bietet Datenkommunikationsdienste über das weltweite Paketdatenkommunikationsnetz an, das heute gemeinhin als „Internet“ bezeichnet wird. Sowohl das lokale Netz als auch das Internet verwenden elektrische, elektromagnetische oder optische Signale, die digitale Datenströme übertragen. Die Signale über die verschiedenen Netze und die Signale auf der Netzverbindung und über die Kommunikationsschnittstelle 718, die die digitalen Daten zum und vom Computersystem 700 übertragen, sind Beispiele für Übertragungsmedien.
Das Computersystem 700 kann über das/die Netzwerk(e), die Netzwerkverbindung und die Kommunikationsschnittstelle 718 Nachrichten senden und Daten, einschließlich Programmcode, empfangen. In dem Internet-Beispiel könnte ein Server einen angeforderten Code für ein Anwendungsprogramm über das Internet, den ISP, das lokale Netzwerk und die Kommunikationsschnittstelle 718 übertragen.
Der hier verwendete Begriff „oder“ kann sowohl in einem einschließenden als auch in einem ausschließenden Sinn verstanden werden. Darüber hinaus ist die Beschreibung von Ressourcen, Vorgängen oder Strukturen im Singular nicht so zu verstehen, dass der Plural ausgeschlossen wird. Bedingte Ausdrücke, wie z. B. „kann“, „könnte“, „könnte“ oder „kann“, sind, sofern nicht ausdrücklich anders angegeben oder im Kontext anders verstanden, im Allgemeinen so zu verstehen, dass bestimmte Ausführungsformen bestimmte Merkmale, Elemente und/oder Schritte enthalten, während andere Ausführungsformen diese nicht enthalten. Begriffe und Ausdrücke, die in diesem Dokument verwendet werden, und Variationen davon, sofern nicht ausdrücklich anders angegeben, sollten als offen und nicht als einschränkend verstanden werden. Als Beispiele für das Vorstehende ist der Begriff „einschließlich“ im Sinne von „einschließlich, ohne Einschränkung“ oder dergleichen zu verstehen. Der Begriff „Beispiel“ wird verwendet, um exemplarische Beispiele für den Gegenstand der Diskussion zu geben, nicht um eine erschöpfende oder einschränkende Liste zu erstellen. Die Begriffe „ein“ oder „ein“ sind im Sinne von „mindestens ein“, „ein oder mehrere“ oder ähnlichem zu verstehen. Das Vorhandensein von erweiternden Wörtern und Ausdrücken wie „einer oder mehrere“, „mindestens“, „aber nicht beschränkt auf“ oder ähnlichen Ausdrücken in einigen Fällen ist nicht so zu verstehen, dass der engere Fall beabsichtigt oder erforderlich ist, wenn solche erweiternden Ausdrücke nicht vorhanden sind.

Claims

Ein Verfahren, das Folgendes umfasst: Senden eines hierarchischen Bakens von einem Gateway-Zugangspunkt (GAP), der den GAP als Root-Zugangspunkt (AP) eines Mikro-Zweigstellennetzes identifiziert; Empfangen von hierarchischen Bakenbestätigungen von einem oder mehreren Downlink-APs am GAP, die das Vorhandensein des einen oder der mehreren Downlink-APs in dem Mikrozweigverteilungsnetz anzeigen, wobei die hierarchischen Bestätigungen auf iterativ modifizierte Versionen der hierarchischen Bake reagieren, die durch jeden des einen oder der mehreren Downlink-APs weitergeleitet werden; und Entdeckung einer Topologie des Mikrofilialnetzes auf der Grundlage der empfangenen hierarchischen Bakenbestätigungen.
Verfahren nach Anspruch 1, wobei der eine oder die mehreren Downlink-APs als verkettete APs implementiert sind, die operativ über entsprechende verdrahtete Ports des einen oder der mehreren Downlink-APs in Reihe geschaltet sind.
Verfahren nach Anspruch 2, wobei das Aussenden der hierarchischen Bake und das Weiterleiten der iterativ modifizierten Versionen der hierarchischen Bake über einen verdrahteten Downlink-Port des GAP und entsprechende Downlink-Ports des einen oder der mehreren Downlink-APs erfolgt, und wobei der Empfang der hierarchischen Bake und der iterativ modifizierten Versionen der hierarchischen Baken über entsprechende Uplink-Ports des einen oder der mehreren Downlink-APs erfolgt.
Verfahren nach Anspruch 1, wobei die hierarchische Bake ein Schicht-2-Broadcast-Datenpaket umfasst, das ein Root-Internetprotokoll-Feld (ROOT_IP) und ein AP_IP-Feld enthält, die jeweils die Management-IP-Adresse des GAP vor ihrer iterativen Modifikation wiedergeben.
Verfahren nach Anspruch 4, wobei die iterativ modifizierten Versionen der hierarchischen Bake ein modifiziertes AP_IP-Feld umfassen, das eine IP-Adresse eines empfangenden Downlink-AP aus der Vielzahl der Downlink-APs wiedergibt.
Ein Verfahren, das Folgendes umfasst: Empfangen einer hierarchischen Bake, die einen Gateway-AP (GAP) als Root-AP des Mikrozweigverteilungsnetzes identifiziert, an einem Downlink-Zugangspunkt (AP) eines Mikrozweigverteilungsnetzes; Übertragen einer hierarchischen Bestätigung vom Downlink-AP als Antwort auf die empfangene hierarchische Bake; Modifizieren der hierarchischen Bake am Downlink-AP, um die eigene IP-Adresse des Downlink-AP wiederzugeben, und Rundsenden der modifizierten hierarchischen Bake an einen oder mehrere zusätzliche Downlink-APs des Mikrozweigverteilungsnetzes; Weiterleiten von empfangenen hierarchischen Bestätigungen von dem einen oder den mehreren zusätzlichen Downlink-APs von dem Downlink-AP an den GAP; und Entdeckung einer Topologie des Mikrozweigverteilungsnetzes durch den Downlink-AP auf der Grundlage des empfangenen hierarchischen Bakens und der empfangenen hierarchischen Bestätigungen.
Verfahren nach Anspruch 6, wobei der Downlink-AP und der eine oder die mehreren zusätzlichen Downlink-APs als verkettete APs implementiert sind, die operativ über ihre jeweiligen verdrahteten Ports in Reihe geschaltet sind.
Verfahren nach Anspruch 7, wobei die Aussendung der modifizierten hierarchischen Bake über einen verdrahteten Downlink-Port des Downlink-AP erfolgt, die Weiterleitung der empfangenen hierarchischen Bestätigungen über einen verdrahteten Uplink-Port des Downlink-AP erfolgt und wobei der Empfang der hierarchischen Bake vom GAP über einen verdrahteten Uplink-Port des Downlink-AP erfolgt.
Verfahren nach Anspruch 6, wobei die hierarchische Bake ein Schicht-2-Broadcast-Datenpaket umfasst, das ein Root-Internetprotokollfeld (ROOT_IP) und ein AP_IP-Feld enthält, die jeweils die Management-IP-Adresse des GAP wiedergeben.
Verfahren nach Anspruch 9, wobei die modifizierte hierarchische Bake ein modifiziertes AP_IP-Feld umfasst, das eine IP-Adresse des Downlink-AP wiedergibt.
Ein Verfahren, das Folgendes umfasst: Initiieren einer Authentifizierungs-Zugriffsanforderung für ein Client-Gerät, das dem Downlink-AP zugeordnet ist, durch einen Downlink-Zugangspunkt (AP) eines Mikrozweigverteilungsnetzes; Übertragen der Authentifizierungs-Zugriffsanforderung von dem Downlink-AP an einen übergeordneten AP, wobei die Authentifizierungs-Zugriffsanforderung an einen Authentifizierungsserver-Proxy gerichtet ist, der als der übergeordnete AP definiert ist; Empfangen einer Authentifizierungszugriffsantwort am Downlink-AP, wobei die Authentifizierungszugriffsantwort von einem tatsächlichen Authentifizierungsserver erzeugt wird, der über den als Authentifizierungsserver-Proxy definierten übergeordneten AP weitergeleitet wird; und Anwenden einer Benutzerrolle für das Client-Gerät auf der Grundlage der Authentifizierungszugriffsantwort.
Verfahren nach Anspruch 11, wobei die Benutzerrolle aus einer Nutzlast der Authentifizierungszugriffsantwort abgeleitet wird und die Anwendung der Benutzerrolle nur an dem Downlink-AP erfolgt, dem das Client-Gerät zugeordnet ist.
Das Verfahren nach Anspruch 12 umfasst ferner die Einrichtung eines vertrauenswürdigen Benutzereintrags mit der MAC-Adresse (Media Access Control) des zugehörigen Client-Geräts an einem Gateway-AP des Mikrozweigverteilungsnetzes, der operativ als Root-AP des Mikrozweigverteilungsnetzes implementiert ist, so dass zusätzliche Datenpakete, die von dem zugehörigen Client-Gerät empfangen werden, keine Authentifizierung am GAP auslösen.
Verfahren nach Anspruch 13, ferner umfassend das Einrichten eines vertrauenswürdigen Benutzereintrags mit der MAC-Adresse (Media Access Control) des zugehörigen Client-Geräts am übergeordneten AP, so dass zusätzliche Datenpakete, die von dem zugehörigen Client-Gerät empfangen werden, keine Authentifizierung am übergeordneten AP auslösen.
Verfahren nach Anspruch 14, wobei die Anwendung der Benutzerrolle nur am Downlink-AP das Einrichten eines nicht vertrauenswürdigen Datenpfad-Benutzereintrags am Downlink-AP umfasst.
Verfahren nach Anspruch 15, wobei das Anwenden der Benutzerrolle nur am Downlink-AP ferner das Anwenden einer abgeleiteten Benutzerrolle auf den nicht vertrauenswürdigen Datenpfadbenutzer umfasst.
Verfahren nach Anspruch 16, wobei die Authentifizierungszugriffsanforderung entweder einen Service Set Identifier (SSID) oder einen verdrahteten Portprofilnamen des Downlink-AP umfasst, der den tatsächlichen Authentifizierungsserver identifiziert, der das zugehörige Clientgerät bedient.
Verfahren nach Anspruch 16, wobei die abgeleitete Benutzerrolle auf der SSID oder dem Profilnamen des verkabelten Anschlusses basiert.
Verfahren nach Anspruch 13, das ferner umfasst, dass vor der Einleitung der Authentifizierungszugriffsanforderung für das zugehörige Client-Gerät eine Topologie des Mikrozweigverteilungsnetzes bestimmt wird, um festzustellen, welcher einer Vielzahl von APs in dem Mikrozweigverteilungsnetz den GAP umfasst.
Verfahren nach Anspruch 19, das ferner umfasst, dass vor der Einleitung der Authentifizierungszugriffsanforderung für das zugehörige Client-Gerät die Topologie des Mikrozweigverteilungsnetzes bestimmt wird, um festzustellen, welcher der mehreren APs in dem Mikrozweigverteilungsnetz den übergeordneten AP des Downlink-AP umfasst.