ale-stellar-remote-access-point-stellar-rap
Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen RevisionVorhergehende ÜberarbeitungNächste Überarbeitung | Vorhergehende Überarbeitung | ||
ale-stellar-remote-access-point-stellar-rap [2020/05/02 11:32] – benny | ale-stellar-remote-access-point-stellar-rap [2024/06/09 10:29] (aktuell) – Externe Bearbeitung 127.0.0.1 | ||
---|---|---|---|
Zeile 25: | Zeile 25: | ||
* [[https:// | * [[https:// | ||
* [[https:// | * [[https:// | ||
+ | |||
+ | <WRAP center round tip 60%> | ||
+ | Im Laufe des November erwarten wir OV 4.5R2, wo dann die Anleitung auch HyperV mit beschreibt. | ||
+ | </ | ||
+ | |||
===== Exemplarischer Aufbau ===== | ===== Exemplarischer Aufbau ===== | ||
Zeile 50: | Zeile 55: | ||
===== Technischer Aufbau ===== | ===== Technischer Aufbau ===== | ||
{{: | {{: | ||
+ | |||
+ | ===== Ablauf der Inbetriebnahme ===== | ||
+ | |||
+ | ==== Wenn Freemium OVC & OmniVista Enterprise verwendet werden ==== | ||
+ | |||
+ | - Erstellen des Freemium Accounts über https:// | ||
+ | - Nach erfolgreicher Registrierung der RAPs (alle außer AP1101 und derzeit noch Wi-Fi 6 APs!) den AP als RAP aktivieren. Bitte darauf achten, dass das aktuelle AWOS 4.0.0.42 ausgewählt wurde! Oder den AP vorher auf dieses Release upgraden! | ||
+ | - Ausfüllen aller notwendigen Parameter wie Public IP des Kunden + WireGuard Port usw. | ||
+ | - Dazu gibt es eine kurze Doku des Referenz-Setups unter: https:// | ||
+ | - Nach erneutem Verbinden des RAPs erhält dieser die Konfig über das WireGuard Setup, startet neu und stellt eine Verbindung zur WireGuard VA her. Das Setup für diese RAP VA sich über das ALE Business Partner Portal (Links oben) | ||
+ | - Sobald sich der RAP das zweite Mal am OV Cirrus Freemium Account gemeldet hat, werden auch die Encryption Keys erstellt. Danach über " | ||
+ | - Der RAP meldet sich am OV2500, welches sich beim Kunden befindet. Über "Trust AP" dem AP vertrauen. AP wird unter " | ||
+ | - Im OV2500 musst Du nun ein "Data VPN Servers" | ||
+ | - Erstellen einer AP-Gruppe und hinzufügen des erstellten "Data VPN Servers" | ||
+ | - Verschieben der Access Points/RAPs in die neue AP-Gruppe | ||
+ | - Anschließend exportieren der VPN Settings (xxx.conf) für das Data-VPN der RAP VA | ||
+ | |||
+ | ==== Wenn ausschließlich OmniVista Cirrus verwendet wird ==== | ||
+ | |||
+ | {{ :: | ||
+ | |||
+ | ===== Fragen und Antworten ===== | ||
+ | |||
+ | ==== Warum erscheint der Stellar RAP nicht in OmniVista 2500? ==== | ||
+ | |||
+ | Bitte prüfen, ob die VPN IP des Stellar RAPs von OmniVista 2500 (VA) aus anpingbar ist. Die VPN IP Adresse findet man über mehrere Wege heraus z.B. in der .conf Datei, die aus OmniVista Cirrus heraus exportiert wird oder im Menü der RAP VA unter Maintenance -> VPN Status. | ||
+ | Das Subnetz, in dem sich OmniVista Enterprise befindet, muss nicht direkt an der RAP VA anliegen. Das Netz kann auch geroutet werden (dafür muss man OmniVista Enterprise aber die Route mitgeben). | ||
+ | Wichtig ist, dass das VPN IP Netz (Client VPN IP Address Pool) ebenfalls über die RAP VA geroutet wird! Entweder direkt als Netzroute im OVE (wenn das Subnetz, in dem sich OVE befindet, direkt an der RAP VA anliegt) oder in der Firewall. | ||
+ | |||
+ | ==== Kann ich den Stellar RAP auch ohne OmniVista Cirrus betreiben? ==== | ||
+ | |||
+ | Über den OmniVista Cirrus (Freemium Tenant, es ist also keine Lizenz notwendig) wird die automatische Installation ermöglicht. Neben der Information wo OmniVista 2500 im Kundennetz erreichbar ist, werden über OmniVista Cirrus auch die Schlüssel für das VPN ausgerollt. Wir planen in einem zukünftigen OmniVista 2500 Release auch eine Inbetriebnahme ohne Cloud zu ermöglichen. Wenn das für das Projekt besonders wichtig ist, lasst es uns bitte wissen. | ||
+ | |||
+ | ==== Was gibt es bei VMware ESXi Servern mit NIC-Teaming zu beachten? ==== | ||
+ | |||
+ | Dieser Punkt äußert sich dadurch dass der Client am Stellar-RAP keine IP-Adresse erhält. | ||
+ | Wenn am ESXi-vSwitch kein LACP-basiertes Link-Aggregat verwendet wird, dann wird häufig ein " | ||
+ | |||
+ | Ein NIC-Teaming kann über mehrere Switches angelegt werden und bietet dadurch kostengünstig (ohne weitere Lizenz) eine zusätzliche Option für Durchsatz & Redundanz. | ||
+ | |||
+ | === Es kommt als Lösung eine der folgenden drei Optionen in Frage: === | ||
+ | |||
+ | - Nur eine Verbindung zwischen ESXi-Server und LAN (keine Redundanz) | ||
+ | - Verwendung der VMware Enterprise Lizenz + vCenter + Distributed vSwitch mit LACP | ||
+ | - NIC-Teaming im vSwitch mit Net.ReversePathFwdCheckPromisc | ||
+ | |||
+ | === Die Option " | ||
+ | |||
+ | **Im VMware WebUI:** | ||
+ | |||
+ | - Im Navigator " | ||
+ | - Runterscrollen oder in der Suchleiste nach der Net.ReversePathFwdCheckPromisc Option suchen | ||
+ | - Net.ReversePathFwdCheckPromisc auswählen und "Edit option" | ||
+ | - Die Option Net.ReversePathFwdCheckPromisc auf " | ||
+ | |||
+ | Die Net.ReversePathFwdCheckPromisc Option ist standardmäßig nicht aktiviert und wird auf dem hier beschriebenen Weg global aktiviert. | ||
+ | |||
+ | **ESXi:** | ||
+ | {{ :: | ||
+ | |||
+ | **vCenter: | ||
+ | {{ :: | ||
+ | |||
+ | **Aus der folgenden Tabelle lassen sich die weiteren zu verwendenden Einstellungen ableiten:** | ||
+ | {{ :: | ||
+ | |||
+ | |||
+ | ===== Local Breakout ===== | ||
+ | Local Breakout benutze ich dafür, dass bestimmter User-Traffic lokal ausbrechen kann (der gewünschte Traffic geht dann nicht mehr durch den WG-Tunnel). Die Performance des bestimmten Traffics steigt und der WG-Tunnel wird nicht mit Traffic belastet der nicht unbedingt durch den WG-Tunnel muss. | ||
+ | |||
+ | In den oberen Schritten ist bereits erklärt, wie man grundsätzlich einen RAP in Betrieb nimmt. Darauf bauen die folgenden Schritte auf. | ||
+ | |||
+ | |||
+ | === Konfiguration Local Breakout === | ||
+ | Unter dem Punkt "WLAN -> SSIDs" kann die SSID konfiguriert werden die genutzt werden soll. | ||
+ | {{ : | ||
+ | |||
+ | Grundsätzlich ist es so, dass der komplette Traffic dann lokal ausbricht. Falls bestimmter Traffic jedoch wieder in den Tunnel geleitet werden soll, muss eine statische Route angegeben werden. (siehe im oberen Bild) | ||
+ | |||
+ | Anschließend kann mit "Save and Apply to AP Group" die Konfiguration ausgerollt werden. | ||
+ | |||
+ | |||
+ | === Troubleshooting Local Breakout === | ||
+ | In den meisten Fällen sollte kontrolliert werden, ob gerade die statischen Routen an den AP übertragen wurden. (bitte nach dem Ausrollen der Konfiguration auf die AP Gruppe 2-3 min warten) | ||
+ | In diesem Fall kann in der AP Gruppe die SSH-Verbindung für die APs freigegeben werden und mit einem eigenen Passwort versehen werden. (Login-User ist " | ||
+ | Sobald man sich per SSH auf den AP eingeloggt hat, kann mit dem Befehl "route -n" kontrolliert werden, ob die Route(n) richtig auf dem AP hinterlegt sind. | ||
+ | {{ : | ||
+ | |||
+ | |||
+ | ===== Konfiguration von Ethernet-Ports hinter einem RAP ===== | ||
+ | Hier wird beschrieben, | ||
+ | |||
+ | Um ein Tagging auf einen RAP-Ethernet-Port benutzen zu können, muss auf der WireGuard VA, der Netzwerkadapter auf dem der Ethernet-Port terminieren soll, auf VLAN 4095 gestellt werden! | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | <WRAP center round tip 60%> | ||
+ | Aktuell ist 1x VLAN tag auf einem Ethernet-Port möglich. Die Möglichkeit mehrere VLANs auf einen Ethernet-Port zu programmieren, | ||
+ | </ | ||
+ | |||
+ | Im OV2500 muss unter " | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Das " | ||
+ | Zu guter Letzt muss noch die entsprechende AP Group ausgewählt werden. | ||
+ | |||
+ | {{ : | ||
+ | |||
+ | Sollte die Konfiguration fertig sein, kann man ein Gerät anschließen. Im Bereich " | ||
+ | |||
+ |
ale-stellar-remote-access-point-stellar-rap.1588419158.txt.gz · Zuletzt geändert: 2024/06/09 10:29 (Externe Bearbeitung)