Howto:Hosting with V10

From innovaphone wiki
Revision as of 15:23, 19 February 2013 by Ckl (talk | contribs) (New page: == Konzepte == Dieses Dokument beschäftigt sich mit der prinzipiellen Funktionsweise der Hosting-Komponenten Ala Cloudkom. Konkrete Konfigurationsdaten finden sich dagegen in [[#Globe In...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Konzepte

Dieses Dokument beschäftigt sich mit der prinzipiellen Funktionsweise der Hosting-Komponenten Ala Cloudkom. Konkrete Konfigurationsdaten finden sich dagegen in Abschnitt Globe Installation.

Gesamtübersicht

Für jeden Kunden wird eine dedizierte PBX (IPVA) aufgebaut. Jeder Kunde hat genau eine solche PBX (also keine Slaves). Weitere Dienste werden durch mandantenfähige Anwendungen bereitgestellt (Shared Services). Jede dieser shared services bedient eine Anzahl von Kunden. Im ersten Ansatz sind das für jeden der Dienste genau gleich viel (was die Verwaltung bzw. Zuordnung vereinfachen sollte). Wie viele Kunden ein shared service bedienen ist for further study.

Den Management Server gibt es je Hoster nur genau ein mal.

Cloudkom-grobuebersicht1.png

Grundsätzlich sind die Kunden-PBXen und die shared services im privaten Netz des Hosters. Somit sind sie von aussen und damit auch aus dem Kundennetz nicht erreichbar. Zwischen Kunde und Hoster wird kein VPN aufgebaut. Um nun den notwendigen Zugriff des Kunden auf PBX und Dienste zu ermöglichen gibt es 2 Dienste, die auch über eine öffentlich zugängliche IP Adresse verfügen (dual homed). Dies sind der SBC und die Media-PBX.

Der SBC leistet zweierlei:

  • Proxy Registrierung der Endgeräte des Kunden
Die Endgeräte registrieren sich am SBC, der wiederum eine Proxy-Registrierung zur Kunden-PBX unterhält
  • NAT eingehend mit Portmaps für ausgewählte Protokolle (HTTPS/443 und LDAPS/636,714)

Die Media-PBX

  • stellt dem Kunden einen öffentlich erreichbaren Übergabepunkt für zentral generierte oder verarbeitete Mediendaten zur Verfügung
Dazu gehören z.B. music on hold, lokal erzeugte Ruftöne, Voicemail, Konferenzen und Faxempfang

Durch die Aufteilung bleibt die Netztopologie des Hosters unsichtbar. Der Hoster benötigt insgesamt nur 2*n+1 öffentliche IP Addressen (wobei n die Anzahl an shared service Gruppen ist).

Cloudkom-netzuebersicht1.png


Im gesamten Hosting System werden an den verschiedensten Stellen Kennwörter vergeben/verwendet. Um hier die Übersicht zu behalten gilt folgendes:

  • Admin Kennwörter
Die Authentifizierung der Admins erfolgt über Kerberos. Admins können daher individuelle Kennwörter haben (im Folgenden als individuelles Admin Kennwort bezeichnet)
alle Boxen haben als Fallback ein supergeheimes "local admin" Kennwort, dass man in der Regel aber nicht benutzt (im Folgenden als systemweites Admin Kennwort bezeichnet)
  • PBX Kennwörter
Die PBX Kennwörter müssen auf allen PBXen im gesamten Verbund gleich sein (und müssen niemals irgendwo eingegeben werden nach der Grundkonfiguration) (im Folgenden als PBX Kennwort bezeichnet)
  • Objektkennwörter. Hier gibt es zwei Arten:
    • Kennwörter, die dem Kunden bekannt gemacht werden. Das sind z.b. Registrierungskennwörter für Endgeräte (im Folgenden als Kunden-Registrier-Kennwort bezeichnet) und Initialkennwörter für myPBX (also Userkennwörter, im Folgenden als Kunden-Login-Kennwort bezeichnet). Für jeden Kunden wird ein eigenes Kunden-Registrier-Kennwort festgelegt, dass in der Regel nie geändert wird. Ebenso wird ein anderes Kunden-Login-Kennwort generiert, das für alle User Objekte als Initialwert verwendet wird, von den Nutzern aber verändert werden kann
    • Kennwörter, die dem Kunden nicht bekannt gemacht werden. Für z.B. interne Objektregistrierungen (z.B. ein lokales GWxx an ein PBX-Objekt) wird immer das PBX Kennwort verwendet
  • Kerberos Kennwort
Hier wird das systemweite Admin Kennwort verwendet

Zertifikate

Der gesamte HTTP und LDAP Verkehr zum Kunden hin ist verschlüsselt. Dies betrifft einen eventuellen Admin Zugang zur Kunden-PBX (durch den Reseller z.B.) und den Reporting und myPBX Zugang des Endkunden. Um hier die Benutzung durch den Endnutzer zu ermöglichen, werden auf den Geräten in jeder Hinsicht "passende" Zertifikate benötigt (also Hostname und Authority Trust).

Dazu wird je Hoster ein signierfähiges Zertifikat benötigt (RootCA) von dem die jeweiligen Device-Certificates abgeleitet werden. Als RootCA wird eine dedizierte IPVA verwendet, auf der eine RootCA generiert wurde (General/Certificates/RootCA). Die Geräte-Zertifikate werden immer auf dieser IPVA generiert und dann von der CF Karte (/DRIVE/CF0/CA/certs/) auf die Geräte exportiert.

Als RootCA wird eine zentrale IPVA verwendet, die auch das zentrale Kerberos realisiert. Die Erzeugung der Device-Certificates auf der RootCA hat mit aktueller Firmware den Seiteneffekt, dass das Gerätezertifkat des generierenden Gerätes überschrieben wird. Das ist zwtr unschön aber auch nicht tragisch und beeinflusst die Funktion des Kerberos Servers nicht.

Kerberos

Die zentral IPVA die auch die RootCA realisiert stellt ebenso die zentrale Kerberos Instanz zur Verfügung.

Die ersten beiden SBCs realisieren den primary und secondary Kerberos für die gesamte Cloudkom Installation. Es wird der Kerberos Server im Relay verwendet, die Admin-User werden in General/Kerberos eingetragen.

Tools clipart.png FIXME: Hier ist zu überlegen, ob man nicht besser dedizierte Kerberos-Server verwendet. Das konkurriert dann nicht mit der PBX um Flash und ist obendrein abgetrennt vom Internet.

SBC

PBX

  • Port9, IPVA9 und SBC9 Lizenzen benötigt
  • PBX Password Fx67abkc42, muss auf allen Kunden-PBXen gleich sein
  • Für jedes Telefon ein Session Border Objekt
    • Long Name: HW Id des Telefons
    • Für Registrierung dieser Telefone von extern individuelle passwords
    • Registrierung der Telefone nach intern mit PBX Admin Password. Die Idee dabei ist, dass man auf allen PBXen das gleiche PBX Admin Password verwendet (Fx67abkc42), das man auch dem Reseller/Kunden nicht gibt (braucht der auch nciht zur Administration). Das kann also nicht verändert werden, ohne dass alle Telefone die Registrierung verlieren
  • SBCs agieren als Kerberos Server für die Admins aller cloudkom inno "Boxen"
  • SBCs leisten auch das HTTP (und LDAP) inbound NAT um den Zugriff auf die IPVAs im privaten Netz zu ermöglichen. Jede IPVA nutzt "ihren" SBC eben auch als NAT Server.

Medienserver

  • Lizenzmaster für alle Kunden PBXen. Port9 und IPVA9 Lizenzen
  • PBX Objekt für jeden Kunden (Long Name, Name: Name des Kunden, Nummer 90+<Port im NAT Mapping>)
  • Gateway Objekte mit Name <Kunden Name>-media. Daran können sich die Kunden PBXen registrieren für Media Daten
  • Objekt MOH mit Nummer ###10. Dort kann sich die MOH Quelle registrieren
  • Objekt TONE mit Nummer ###11. Dort kann sich eine Tone interface registrieren
  • Objekt HTTP-OUT mit Nummer ###12. To offload the announcements of WQ and VM object.


Kunden PBX

Die Kunden-PBX steht im privaten Hoster Netz. Sie kann daher keine Medien zum Endkunden spielen. Dazu wird die ihr zugeordnete Media-n PBX verwendet, die dual-homed ist.

  • SBC als Time Server (Zeit notwendig für Kerberos)

Update Server

Aufgaben:

  • Staging (z.b. aufspielen geeigneter Trust Lists)
  • Update der Firmware auf den Kundengeräten und der Kunden-PBX
  • Sicherung der Configs von allen Kundengeräten und der Kunden-PBX

Die Sicherung findet auf die CF der Kunden-PBX statt. Das macht Sinn, da es hier nicht um Desaster Recovery geht (die wird vom Hoster gewährleistet), sondern um das Recovery nach Fehlkonfigurationen. Das kundenspezifische Update Script befindet sich ebenso auf der Kunden-CF. Es gibt kein gerätespezifisches Update-Script.

Struktur 

/DRIVE/CF0/
  update/
    update.txt
    backup/
      backup-mac-datum.txt

Soll die Firmware eines Kunden aktualisiert werden, dann muss das update.txt des Kunden angepasst werden.

Die Firmware liegt auf einem zentralen Verzeichnis.

Struktur 

/DRIVE/CF0/
    update/
      firm/
        nnnnnn/
          bootxxx.bin
          ipxxx.bin
      firmupdate.txt

Die initiale Update URL kann nicht über die normalen Mechanismen (DHCP) erfolgen (da man den DHCP Server des Kunden nicht beeinflussen kann). Die langfristige Idee ist, dass man in der inno Logisitik weiß, welches Telefon zu welchem Hoster geht. Geräte, die überhaupt zu einem Hoster-Kunden gehen bekommen eine spezielle manufacturer-id die wiederum eine spezielle update URL in der config hat: http://config.innovaphone.com/staging.txt. Dahinter steckt eine Anwendung, die aus der Seriennummer ermittelt, zu welchem Hoster das geht und ersetzt die URL durch ein http://config.hoster.com/staging.txt (oder was immer für den Hoster bekannt gegeben wurde). Bei dem Hoster wiederum kann entweder ein statisches Staging Script dahinter stehen (unlikely) oder eine Hosterspezifische Anwendung, die das Staging für den Kunden (den dann die Anwendung vom Kunden wissen muss) macht.

Bis dahin muss allerdings jemand (Hoster oder Kunde) die passende URL nach einem langem Reset ins Kundengerät eingeben.

Staging Tasks

  • Zertifikat in die Trustlist
  • Zentralisierung von Logs, Alarm&Events (auf die Kunden-PBX)

Support / debugging von Kundenproblemen

  • Alarms & Events Zentralisierung
    • wie, was kann man daraus erkennen
  • syslog
    • wie, wo, was sichern
  • wer macht support
  • zusammenarbeit mit toplink bei SIP-Trunk Probleme
  • mantis <mantis-issue id=95379/>

Reporting (Multiple PBX)

V10 Linux Image und Reporting Files von der linux-10 (also der neuen ) Version werden benötigt, nur die enthalten die Mandantenfähigkeit. Gebraucht wird die Linux-AP und das Reporting. Eine solche Linux-AP kann mehrere (viele) Kunde bezüglich der Ruflisten und des Reportings bedienen.

<dfslink>\\inno-sifi\dfs\build\linux-10</dfslink>

Konfiguration PBX

  • CDR0: Remote-AP-S, 10.30.100.2, 443
  • Call List Service myPBX: Remote-AP-S, 212.124.38.120:8102, user:innovaphone-reporting, pass: reporting

Konfiguration Reporting

  • PBX-Name
  • Filter für PBX VM9 und VM10 erstellt
  • User angelegt die diesen Filter verwenden
  • Reportin Login Page
  • Mit user/passwd:ckl_report/callme38 anmelden, dann sieht man nur calls aus PBX VM10
  • Mit user/passwd:inno_report/callme38 anmelden, dann nur calls aus PBX VM9 sichtbar

Fax Server

Da das FAX-Interface im Öffentlichen Netz stehen muss, um T.38 Pakete empfangen zu können, wird dieses von der CustomerPBX auf Media1 Gateway ausgelagert. Die SOAP-Verbindung wird trotzdem auf die CustomerPBX aufgebaut.

Routing fax.png

Mail to Fax Gateway

Für Kunden, auf deren POP3 Server aus Cloudkom Netz nicht zugegriffen werden kann, wird ein SMTP Server auf Basis von IP-AP aufgestellt. Dort können die Kunden dann per E-Mail die Faxe anliefern. (<mantis-issue id=89710/>)

Use Case "Fax verschicken":

  • Kunde schickt aus dem E-Mail Programm ein Mail mit PDF-Anhang an z.B. +497031730099@fax.cloudkom.com
  • Rufnummer für Zielfax muss im User Part der To: Mailadresse stehen (im Beispiel ist es +497031730099)
  • Das passende Postfach für Fax Server des jeweiligen Kunden wird anhand der From: Mailadresse bestimmt.

Damit die From: Adresse nicht gefaked werden kann, werden nur authentifizierte SMTP-Verbindungen zugelassen. Der Kunde muss dazu bei sich im Exchange einen "SMTP Send Connector" für die Domäne fax.cloudkom.com einrichten ([1]) mit Basic Auth over TLS.

Als SMTP-Server kann man ein Postfix mit Postgresql Erweiterung nehmen, damit man die Kunden Daten (Domains, Postfächer, Logins) direkt aus der Fax Server Datenbank lesen kann.

Als POP3-Server (damit Fax Server die Mails lesen kann) wird dann Dovecot eingesetzt.


Beschreibung der Implementierung: E-Mail_Fax_Server_Gateway_(Project_Cloudkom).

Adressbücher

Directories - PBX

  • pro Kunde wird im SBC ein NAT-Port-Map für LDAP zur entsprechenden Kunden-IPVA konfiguriert. Das Telefon hat die Möglichkeit ein Port in der PBX-Directories anzugeben und benutzt daudrch den LDAP-Server der PBX(und nicht den des SBC).
  • Es wird LDAPS verwenden, das Zertifikat der Kunden-IPVA muss jedoch nicht extra in der Trustlist des Telefons aufgenommen werden. Das Telefon überprüft nicht ob das SSL - Zertifikat gültig ist(cn, Ablaufdatum, etc) sondern verwendet einfach das erhaltene Zertifikat nur zur Verschlüsselung.

Directories - External LDAP Server

  • pro Kunde gibt es einen LDAP-Knoten (dc=kundennr.), ein Replikator. Es wird LDAPS verwendet.
    • Replikator:
      • Kunde exportiert seine Outlook - Kontakte in eine CSV Datei (Kommagetrennte Werte(Windows)). Die CSV Datei sollte nur folgende Spalten/Felder enthalten: "Nachname","Vorname","Firma","Telefon geschäftlich","Mobiltelefon". Die Telefonnummern sollten im E164 Format vorliegen, also +49703173009123. Als Dateiname immer Kontakte.csv verwenden, damit Replikator immer relativ einheitlich konfiguriert werden kann.
      • die CSV Datei wird via https und webdav - client (z.B. BitKinex) auf der CF-Karte der Kunden PBX kopiert. Hier sollte man den Unterordner "Ext-Dir" verwenden (falls nicht vorhanden anlegen)
      • der Estos Metadir Server greift via http/webdav auf die CF-Karten aller Kunden-IPVAs zu und importiert die CSV Dateien
    • LDAP-Knoten:
      • Authentifizierung für den Zugriff auf LDAP-Knoten erfolgt per Username/Passwort, keine Einschränkung auf IP-Netze.
      • als Profil wird immer das "Default" Profil verwendet. Man braucht durch unsere "Dialing Location" am Telefon keine Kundenspezifischen Profile.
      • als Vorlage ist im Metadir Server ist ein Template eingerichtet "dc=template"
  • kurze Anleitung zum exportieren von Kontakten in Outlook 2010:
    • man kann nur eigen Kontakte exportieren. Hat man nur eine globale Kontaktliste, muss man diese Kontakte erstmals in die eigene Kontakte kopieren. (IP Kontakte -> Rechtsklick -> kopieren -> eigene Kontakte auswählen)
    • in Outlook Datei -> Öffnen -> Importieren -> In Datei exportieren -> Kommagetrennte Werte(Windows) -> Kontakte/IP Kontakte auswählen -> "Benutzerdefinierte Felder zuordnen" -> Nachname, Vorname, Firma, Telefon geschäftlich, Mobiltelefon auswählen -> Fertigstellen
  • LDAPS
    • Selfsigned Zertifikat auf den Metadir Server installiert. Da LDAP-Client auf dem Telefon das Zertifikat nicht überprüft, sollte es hier keine Probleme geben.
    • Metadir Server verwendet port 714 für LDAPS, SBC1 hat dafür ein NAT-Map für Port 9007
  • die Directories Einstellungen sollten per config - template verteilt werden, auf der VM10 gibt es dazu als Beispiel das config-template "default"

myPBX

  • hier gibt es das Problem dass normalerweise die PBX die LDAP - Anfrage des myPBX - Clients macht, dazu verwendet man normalerweise die am User gespeicherte phone-config. Da die PBX im internen Globe Netz ist, kann es mit der darin enthaltenen public-IP(externe IP des NAT Routers) nicht anfangen. durch ein Hack von Matthias kann man im PBX0 modul fest konfigurieren welcher LDAP Server genutzt werden soll.

config add PBX0 /ldap-default-addr 10.30.0.2 /ldap-default-port 714

Voicemail

Konfiguration Kunden PBX

  • Gateway-config
    • Media GW1, Register as Gateway, 212.124.38.123, Name= innovaphone-media
    • HTTP-INT GW3, Register as Gateway, 127.0.0.1, Name= HTTP-INT
    • HTTP-EXT GW4, Register as Gateway, 212.124.38.123 (Media1), Name= HTTP-EXT
    • vmrelay GW5, Register as Gateway, 127.0.0.1, Name= vmrelay
  • Routes
    • GW3 HTTP-INT --> ###12 GW4 HTTP-EXT
    • GW5 vmrelay --> ###12 GW4 HTTP-EXT
  • https Zertifikate trusten auf Media1.

Operator

Datensicherung

Thomas Leone 16:50, 8. Jan. 2013 (CET) Datensicherungskonzept überlegen.

Ausser uns auf globe zu verlassen, dass IPVAs wieder hergestellt werden können, sollten configs extra gesichert werden.

1. Wie am 17.12. besprochen, Datensicherung der PBXn lokal. PBX Admins können dann configs selbst einspielen. --> IPVA kaputt (warum auch immer), ist die Sicherung weg.

2. Configs der Kunden-PBXn auf Michael Khayats Windows Server (zusätzlich) sichern. Server ist im auch im privaten Netz. Configs könnten auch von Michael K. wieder upgeloadet werden.

3. Eine IPVA als Reserve. Kann von uns schnell gestartet und konfiguriert werden. Globe wird dann noch nicht benötigt.

Thomas Leone 11:38, 23. Jan. 2013 (CET) Desaster Recovery von Globe

1. Jede VM wird 2 Wochen Montag -Freitag + 1 x Monatlich gesichert. Es gibt also von jeder VM 11 separate Generationen die auf Wunsch wiederhergestellt werden können.

2. Die Aussage, dass unsere IPVA nicht VSphere konform sind ist obsolet (kam vorschnell aus der Technik da unsere VM nicht bei VSphere aufgelistet sind).

3. Recovery wurde mit VM8 (IPVA) und VM12 (LAP) erfolgreich getestet.

Retrieved from "https://wiki.innovaphone.com/index.php?title=Howto:Hosting_with_V10&oldid=28537"