Howto:Hosting with V10

From innovaphone wiki
Revision as of 18:09, 23 April 2013 by Ckl (talk | contribs)
Jump to navigation Jump to search

This document describes general recommendations for setting up a „hosted PBX“-environment. It is based on a reference implementation done early 2013. Everything said in this article is merely a recommendation and you may deviate from it for real-life projects. However, it may still serve as a guideline of “what to think of”. There are no specific configurations given throughout the article. As such, it targets an iCE with some decent knowledge about innovaphone products as an audience. This article is still “work in progress”.

Overview

Each customer receives a dedicated PBX (best run as IPVA). So no “dynamic PBX”s are used. Each customer has exactly one such PBX. So no Slave- (as they do not seem to make sense) and no Standby-PBX (as this is better implemented using VMware tools such as High Availability or Fault Tolerance). This article does explicitly not deal with mixed environments where some PBXs are hosted and some on-premise. Further services (apart from the basic PBX) such as e.g. fax are provided by multi-tenant capable applications. How many customers and/or users (i.e. extensions) can be served by a single such application is for further study. However, from an administration point-of-view, it seems to be easier calculating the same application-server to number-of-customers ratio for all the applications, as it allows organizing the whole setups in clusters where a specific set of customers is associated to a specific set of application servers. In a real-life setup, there may or probably will be a central management server which may run software to simplify the management of the whole setup as well as provide an end customer portal. This server, called ‘’Management Server‘‘ in the overview graph is thought to be specific to the PBX hosting provider and is thus – although it has an important impact – not discussed in this document. Cloudkom-grobuebersicht1.png Most of the hosted services, as well the customer-PBXs and the shared services, will be located in a private network run by the hosting provider. This is to make sure they cannot be easily attacked and also to save on publicly available IP addresses (which may be a scarce resource). As a result, from a TCP/IP point-of-view, these services are not reachable from the customers own private network. Also, to save on resources and reduce complexity, no VPN is set up between the customer and the hosting provider. To implement the required customer access to these services, there are 2 extra services which need to have an additional external IP address (“dual homed”). These are called “SBC” and “Media-PBX”. The SBC provides:

  • Proxy registration of customers terminal devices (e.g. phones) located on premise to the customer PBX
Terminals in fact register with the SBC which in turn entertains a proxy-registration to the customer PBX for each endpoint
  • inbound NAT with port maps for selected protocols (such as e.g. HTTPS/443 und LDAPS/636,714)

The Media-PBX

  • provides a reachable media endpoint for media data provided or consumed by services within the hosting providers private newtork
This includes e.g. music on hold, locally generated calling tones, Voicemail, multi-party conferences and fax

This architecture ensures that the hosting providers network topology is invisible to 3rd parties (including possible attackers). Furthermore, the hosting provider only needs 2*n+1 public IP Addresses (where n is the number of shared service groups).

Cloudkom-netzuebersicht1.png


Passwords

Throughout the system, a number of passwords are used in various places. It is critical to use as less passwords as possible to make day-to-day administration easy and as much passwords as necessary to keep things secure. So here is an overview:

  • Admin passwords
Admin user authentication is based on Keberos. Each admin thus can and should have individual accounts and passwords (referred to as individual admin password)
all devices shall have a "local admin" passsword which should be kept secret and not be known by normal administrators and should normally never be used. This is referred to as system-wide admin password)
  • PBX passwords
PBX passwords needs to be the same in all oft he hosting providers PBXs (and do not need to be typed-in anywhere except during a PBXs initial configuration) . The are referred to as PBX password
  • Object password. There are 2 kinds:
    • Passwords, which need to be known to the customer. Registration passwords for terminal devices would be an example. Those are referred to as customer registration password). Another example are initial passwords for myPBX (that is, user passwords). They are referred to as customer login password. For each customer (not for each line), a distinct customer registration password is defined, which normally never changes. Furthermore, another customer login password is generated, which is used initially for all user objects but will be changed by the end users.
    • Password which are not disclosed to the customer. These are used for internal registrations, e.g. a local interface or gateway registering at the customer PBX. For this, the pbx password will always be used
  • Kerberos DB password
The PBX password shall be used for encryption of the Kerberos database (as it does make no sense to use a different password her)

Unfortunately, the Linux AP has no support for Kerberos so separate admin password are required. We distinguish passwords used during daily administration and those which are not.

  • Linux Admin password
this is the password used in dai-to-day administration, referred to as Linux Admin password. It is used as web server credentials, webdav access credentials, application access credentials, 'innovaphone Reporting access credentials, innovaphone Fax access credentials etc.
  • Linux System password
the password that is used as root credentials. Fort this, the PBX password shall be used
The database passwords (e.g. postgresql admin password) can be left as by default, as the DB server is accessible from 127.0.0.1 only anyway

NTP

All devices require correct time setting. They all must have be a working NTP time source configured (and probably also a working alternate). The dual-homed devices (see above) shall use 2 reliable time sources (either run by the hosting provider or from the internet). All other devices shall use "their" own SBC as NTP Server (a backup time source is not strictly required here as these devices are anyway unusable for customers when the SBC is down).

Certificates

The entire HTTP and LDAP traffic from and to the customers network is encrypted. This affects for example a customers access to the PBX (e.g. if the customer is granted (limited) access to the PBX config or for myPBX), as well as access to the reporting service. To facilitate access to these devices without any warnings issued by the clients (e.g. browser security alerts) all devices require suitable certificates (that is, the host name and IP address must be noted in the certificate and they must be derived from a single signing authority so that end-users only need to import a single root certificate in order to accept all of these device certificates. The devices built-in certifcates cannot be used as they only refer to the devices NetBIOS name (e.g. IPVA-a8-5a-38) which will not be used to access the devices. Also, in the case of IPVA, the default certificate is self-signed as opposed to being derived from the aforementioned uniform root certificate. To derive device-certificates which all inherit from the same root certificate, a so-called RootCA is needed. There are multiple ways to implement this. Although there are better schemes available, one way to do it that requires no 3rd party gear is to generate a RootCA (in General/Certificates/RootCA) on a dedicated IPVA. This RootCA then can be used to generate all of the other certificates. They are stored in the IPVA’s virtual CF card (/DRIVE/CF0/CA/certs/) and can be exported to the other devices from there.

RootCA

For the RootCA, we use the IPVA that also implements the central Kerberos server. Unfortunately, the current firmware that each generated device certificate will also replace the IPVA’s own device certificate. This is of course somewhat unfortunate, however, it is not really an issue as no end-customer will ever access the Kerberos IPVA anyway. The Kerberos server itself does not rely on the device certificate. You first generate a RootCA on the RootCA-IPVA ('General/Kerberos). The following data must be used: C=your-country (e.g. Germany) , O=hoster, CN=hoster Device Certification Authority, Key-length 4096, lifetime 20 years This new RootCA (which is now the IPVA’s device certificate) needs to be trusted on the IPVA (General/Admin).

Device Certificates

To create individual device certificates, use the RootCA created and use the following data: Key 4096, Common Name=devices NetBIOS Name, Organization=hoster, Country=your-country (e.g. Germany) , DNS Name 1=devices external IP address, DNS Name 2=devices internal IP address, IP Address 1=devices external IP address , IP Address 2=devices internal IP address For devices with an internal IP address only, it is important to specify the IP address of NAT router used to access the device as external IP address (e.g. for a customer PBX, this will be the SBC used). You specify the IP address only, not the port map. If you intend to assign real DNS names to your devices, you may of course specify these as DNS Name 3 too. In order to be able to export the new certificate to the target device, you need to make sure you tick the Backup on CF check-mark, so it is saved on the CF as serialno.pem. To transfer the new certificate to the target device, take note of the serial number and download the respective certificate file from /DRIVE/CF0/CA/certs/serialno.pem. This file can then be uploaded to the target device (General / Certificates / Device certificate / Upload).

Browser Installation of the Root Certificate

To get rid of the browser security alerts when accessing devices with e.g. HTTPS, the public key of the root certificate must be trusted by the browser. For this, it needs to be exported in to a file (you can best do this from the RootCA’s trust list in General/Certificates/Download/PEM into certificate.crt). It must then be imported to the browser. This needs to be done once by both administrators and customers. Firefox

  • Extras / Einstellungen / Erweitert / Zertifikate anzeigen / Zertifizierungsstellen / Importieren
  • import the .crt file
  • tick Dieser CA vertrauen, um Websites zu identifizieren

Internet Explorer

  • Extras / Internetoptionen / Inhalte / Zertifikate / Beabsichtigter Zweck Clientauthentifizierung / Vertrauenswürdige Stammzertifizierungsstellen / Importieren
  • import the .crt file

Kerberos

Kerberos is used to implement authentication for all devices. This includes both devices in the PBX hosting provider’s infrastructure and the CPE. For this to work, all devices must subscribe to the Kerberos realm. The PBX hosting provider’s DNS domain (e.g. ‘’hoster’’.tld) should be used as Kerberos domain name. This way, Kerberos can be found using DNS SRV records. The IPVA used as RootCA can be used as master kerberos service too. A stand-alone Kerberos server (that is, the one that is implemented in the Gateway level) is being used. The (probably limited) number of admin accounts is maintained manually. In fact, if the PBX hosting provider uses an active directory service to manage employee accounts, an AD-replicated PBX run on the central Kerberos IPVA is also a viable option. Either way, a standby Kerberos server should be setup as a separate IPVA and can be replicated from the master kerberos as usual. Unless an active directory is used, no trust relationships are required. If so, the system-wide admin password should be used as shared secret. The devices which rely on kerberos for authentication (that is, all devices!) locate the Kerberos servers using DNS SRV records. Devices within the hosting provider’s private network use the internal IP address for this; external (e.g. CPE) devices use their respective SBC. For this to work, each SBC needs an UDP NAT map (udp/7088 -> kerberos-intern-ip:88 and udp/7089 -> secondary-kerberos-intern-ip:88). The PBX hosting provider’s DNS needs to have the following entries: 

# hoster.tld is the hosters domain used as kerberos realm name
A kerberos1i.hoster.tld x.x.x.x (interne Adresse des primären Kerberos)
A kerberos2i.hoster.tld y.y.y.y (interne Adresse des sekundären Kerberos)
A sbc1.hoster.tld x.x.x.x (externe Adresse des SBC1)
A sbcn.hoster.tld x.x.x.x (externe Adresse des SBCn, n ist Sequenznummer des SBC)

SRV _kerberos._udp.hoster.tld
    priority       = 0
    weight         = 0
    port           = 88
    svr hostname   = kerberos1i.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 5
    weight         = 0
    port           = 88
    svr hostname   = kerberos2i.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 10
    weight         = 0
    port           = 7088
    svr hostname   = sbc1.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 15
    weight         = 0
    port           = 7089
    svr hostname   = sbc1.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 10
    weight         = 0
    port           = 7088
    svr hostname   = sbcn.hoster.tld

SRV _kerberos._udp.hoster.tld
    priority       = 15
    weight         = 0
    port           = 7089
    svr hostname   = sbcn.hoster.tld

With this setup, all devices will prefer the internal IP addresses. External (e.g. CPE) devices will of course not be able to reach these internal addresses, but they will succeed with one of the SBCs. Thus CPE devices will use any of the available SBCs, not necessarily their own. This will work as all SBCs ultimately NAT to the same Kerberos server. Instead of relying on the PNX hosting provider’s DNS server, the SRV records can be set in the devices during staging. This way, the setup can be somewhat simpler as each device can be configured to use its associated SBC only: 

config change DNS0 
   /srv-name _kerberos._udp.hoster.tld/srv-target kerberos1i.hoster.tld /srv-port 88 /srv-prio 0 /srv-weight 0 
   /srv-name _kerberos._udp.hoster.tld /srv-target kerberos2i.hoster.tld /srv-port 88 /srv-prio 5 /srv-weight 0
   /srv-name _kerberos._udp.hoster.tld /srv-target sbcn.hoster.tld /srv-port 7088 /srv-prio 10 /srv-weight 0 
   /srv-name _kerberos._udp.hoster.tld /srv-target sbcndup.hoster.tld /srv-port 7089 /srv-prio 15 /srv-weight 0
   /a-name kerberos1i.hoster.tld /a-addr i.i.i.i
   /a-name kerberos2i.hoster.tld /a-addr i.i.i.i
   /a-name sbcn.hoster.tld /a-addr x.x.x.x
   /a-name sbcndup.hoster.tld /a-addr x.x.x.x

NB: the somewhat strange confuiguration of sbcndup.hoster.tld (which is in fact identical to sbcn.hoster.tld) is due to the fact that V10 firmware before beta6 did not support multiple SRV records for the same host.

Kerberos User

In addition to the accounts for the administrators, there must be a service account paccess used for programmatic access to the devices. This will for example be used by the Metadir server to access the SBC (and can also be used by a hosting provider specific administration software). In addition to that, this account is to be configured under Services/HTTP/Client for URLs https:// and http:// on the SBC, Media-PBX and customer PBXs. This allows all these device to access all other devices using HTTP/S. The credential for this account need tob e kept securely, as they allow admin access to all devices in the infrastructure! To facilitate automatic join into the kerberos domain during staging, there needs to be an additional special account with Join Realm rights only: : joiner, joiner. This account is not particularly relevant from a security point of view, as aside from adding or removing devices from a realm nothing relevant can be done on behalf of it.

Licenses

It is in the PBX hosting provider’s best interest to implement a centralized license management. A central licensing server instance is needed thus. This can be run on the master and standby Kerberos server. All licenses purchased by the PBX hosting provider are installed here. The license server runs a PBX. The only task for this PBX is to host the licenses and distribute them to the SBC and Media PBXs, which are registered as License only slaves and will further distribute the licenses to the customer PBXs (which are in turn registered as License only slaves to their respective Media-PBX). If you choose to use a PBX based Kerberos server (see above), this same PBXs can be used. The license server PBXs will have the PBX hosting provider’s domain name as System Name (e.g. hoster.tld) and . as PBX Name.

SBC

The SBC

  • accepts external registrations from customer CPE
  • provides a central (virtual) CF-card storage for non-sensitive data (e.g. firmware files)
  • supports mutliple customer PBXs. The exact number is yet ffs., however, we estimate no more than 135 currently. SBCs will simply be numbered (sbc1, sbc2 etc.)

NAT

  • The SBC will provide inbound NAT mappings for HTTPS and LDAPS. This allows for controlled access to the IPVAs within the PBX hosting provider’s private network from external. Each customer PBX uses its associated SBC for NAT, that is, each SBC provides NAT for all customers that have it associated as SBC. The number of customers per SBC is limited by the number of NAT maps that can be created, which in turn depends on the length oft he resulting config file line. Currently, there is a limit of approximately 290 maps per SBC. 2 distinctive maps are needed per customer
  • Additionally, some maps shared by all customers (e.g. for services like Metadir, FaxServer, Reporting) are required. About 20 maps should be reserved for this
  • So we end up with the aforementioned number of 135 customers per SBC

PBX

  • System Name is the PBX hosting provider’s domain name (e.g. hoster.tld)
  • PBX Name is sbcn
  • registers as Slave PBX with the central license server PBX (License Only)
  • receives required licenses from the central license server thus
Customer related Configuration
  • One Session Border object (SBC) for each (potential) terminal registration to a customer PBX
  • Long Name as well as Registration to internal PBX/Name set tot he CPE-ID (see below)
  • Password set to the customer registration password
  • Registration from external/Name set to the CPE’s hardware-ID (NetBIOS name) PBX Password ticked

See also #Configuration of customer related objects in the customer’s PBX and SBC

Medienserver

Services

Der Medienserver muss für Ansagen und voice-mails auf die WebDav Server der Kunden-PBXen zugreifen können. Daher HTTP Client credentials für die URLs http:// und https:// über paccess@hoster.tld.

PBX

  • PBX Objekt für jeden Kunden (Long Name, Name: Kuenkel00001, Nummer #+Nummer-aus-Kuenkel00001)
  • Gateway Objekt HTTP-EXT ohne Nummer. 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 ein Tone interface registrieren
  • Objekt HTTP-OUT mit Nummer ###12. To offload the announcements of WQ and VM object.

Kunden PBX

Jede Kunden-PBX bekommt eine eigene logische Kunden-ID, die zur Benennung von Objekten herangezogen wird. Sie besteht aus einem Namenskürzel (irgendwie aus dem Kundennamen) sowie einer fortlaufenden Nummer. Die fortlaufende Nummer ist die Kundennummer beim Hoster. So ein Name könnte also wie Künkel00001 aussehen.

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), denn wenn der weg ist, dann geht eh nix mehr mit dieser Kunden-PBX
  • Unknown Registrations an mit With PBX Pwd only. Dadurch kann sich der Endkunde mit seinem Endgerät anonym anmelden und damit die Zuordnung zum Teilnehmer wie üblich per Zero Administration ausführen

Globale Objekte in der Kunden-PBX

default template
  • heißt default
  • Hide from LDAP und Critical
  • Store Phone Config
  • alle Häkchen unter License
  • unter Access einen Eintrag für @customer.tld (das ist der System Name aus der PBX Config) mit allen Häkchen
  • unter Config wird nur die LDAP Config (Directories) gesetzt:

<phone> 

 <loc cc='ountry-code' ac='area-code' ntp='0' itp='00' pbx='subscriber-number'/>
 <ldap id='2' 
   tls='1' port='ldap-port-map-to-pbx-on-sbc, e.g. 9004'/>
 <ldap id='3' 
   enable='1' tls='1' mode='basic' 
   addr='sbc-ip-address' port='ldap-port-map-to-metadir-on-sbc, e.g. 9007' 
   dn='PBX Name' pw='??' base='dc=PBX Name' 
   attr='sn,givenName,company' phone='telephoneNumber:D,mobile:M,:@'/>

</phone> 

pw für ldap2 ist heikel: das ist sensitiv (Kundendaten öffentlich zugänglich per LDAP)

Configuration of customer related objects in the customer’s PBX and SBC

Auf der Kundenseite sollte zur Konfiguration der Endgeräteregistrierung keine Geräteindividuelle Einstellung nötig sein. Daher wird hier als Registrierungsname der NetBIOS Name (z.B. IP232-01-02-03) verwendet. Damit ist dies auch der korrekte Wert für Registration from external im dazugehörigen SBC Objekt.

Als Registrierungskennwort vom Endgerät und damit als Wert für Password im SBC Objekt wird das Kunden-Registrier-Kennwort für den Kunden verwendet.

Als Long Name sowie Name für Registration to internal PBX im SBC Objekt (und damit als Registriername in der Kunden-PBX) wird eine Kombination aus Kunden-ID und einer fortlaufenden Endgeräte-ID des Kunden benutzt (z.B. Künkel00001-001). Der fortlaufende Teil der Endgeräte-ID beginnt für jeden Kunden bei 0. Dies dient dazu, beim Tracen/Debuggen/Konfigurieren eine bessere Übersicht zu haben. Zusätzlich kann man dann auf dem SBC schön nach der Kunden-ID filtern. Ansonsten könnten man genauso gut den NetBIOS Namen verwenden. Der lässt aber außer auf der Kunden-PBX keine Rückschlüsse auf den Kunden zu.

Als Kennwort zur Registrierung vom SBC zur Kunden-PBX wird das globale PBX Kennwort verwendet, also die PBX Kennwort Häkchen im SBC-Objekt bei Registration to internal PBX und am entsprechenden Device im User Objekt auf der Kunden-PBX. Initial wird in den Kundenobjekten kein Device eingetragen. Damit wird die Einbuchung von Endgeräten durch den Kunden auf das gewünschte Endgerät durch Zero Administration möglich.

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. Es gibt kein gerätespezifisches Update-Script.

Struktur auf der Kunden-PBX 

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

Damit die Backups geschrieben werden können, muss das Backup Verzeichnis (/DRIVE/CF0/update/backup/) auf der Kunden-PBX unter Services/HTTP/Public compact flash access zum Schreiben (und nur zum Schreiben) frei gegeben werden.

Die Firmware liegt auf einem zentralen Verzeichnis des jeweiligen SBC. Damit muss man zwar die Firmware auf jedem SBC vorhalten, dafür wird die dadurch erzeugte Last verteilt.

Soll die Firmware aller Kunden eines SBCs aktualisiert werden, dann muss das update.txt des SBC angepasst werden. Ebenso wenn generelle Config Eigenschaften geändert werden sollen.

Das Staging erfolgt in 3 Stufen:

das ist ein Web Dienst, der anhand der Seriennummer des Gerätes den Hoster und den (End)Kunden aus my.innovaphone.com und das update script schlussendlich auf das Staging Script auf dem richtigen SBC des Hosters ändert
  • das Endgerät wird auf das SBC-weite staging script (staging.txt) umgeleitet, wo generelle einmalige Einstellungen gemacht werden können
  • das Endgerät wird auf das SBC-weite update script (update.txt) umgeleitet, wo Einstellungen gemacht werden können, die im laufenden Betrieb geändert werden könnten

Struktur auf dem SBC 

/DRIVE/CF0/
    update/
      staging.txt           - spezielles staging script
      update.txt            - dauerhaftes update script nach dem staging
      global.txt            - overrides für globale settings im laufenden update (nach dem staging)
      local.txt             - overrides für SBC-lokale settings im laufenden update (nach dem staging)
      set-customerid.txt    - overrides für Kundenspezifische settings im laufenden update (nach dem staging)
      staging/              - speziell Skripte für das Staging
        global.txt            - settings die für den hoster global gelten
        local.txt             - settings, die für dieses SBCn/Median Set gelten
        set-customerid.txt    - settings, die für den speziellen Kunden gelten
        dev-IPxxx.txt         - settings für einen bestimmten Gerätetyp
        cfg-phone.txt         - settings für eine bestimmte Geräteklasse
        cfg-gateway.txt       - dito
      firm/                 - firmware
        nnnnnn/
          bootxxx.bin
          ipxxx.bin

Damit die Firmware gelesen werden kann, muss das Firmware Verzeichnis (/DRIVE/CF0/update/firm/) auf dem SBC unter Services/HTTP/Public compact flash access zum Lesen (und nur zum Lesen) frei gegeben werden. Damit die Update Scripte gelesen werden können, muss das update Verzeichnis (/DRIVE/CF0/update) lesbar (und nur lesbar) sein. Es kann also für beides /DRIVE/CF0/update/ zum Lesen freigegeben werden.


Die Zuweisung der initialen 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.

Update Skripte

Sind in vault:$web/hosting/ (inno Seite) und vault:$web/hosting/cloudkom (Hoster Seite).

  • redirect.php
    1. Zertifikat des Hosters in die Trustlist (damit das Update Script per HTTPS gelesen werden kann)
    2. individuelle Geräteinfos (kommen aus den #-Replacements des Update Clients) in VARs übertragen zur späteren Nutzung in den Hoster Scripten
  • staging.txt
    1. firmware update
    2. DNS für Kerberos richtig einrichten
    3. der Kerberos Domain beitreten. Damit kann sich ein Hoster Admin, wenn er denn überhaupt Zugriff auf die Geräte des Kunden hat (über VPN oder TeamViewer), auf den Geräten authentifizieren
    4. Zentralisierung von Logs, Alarm&Events (auf die Kunden-PBX). Damit hat der Hoster einen Einblick in den Funktionszustand der Geräte
    5. Verzweigen ins Geräteklassen-Staging (cfg-xxx.txt)
  • cfg-phone.txt
    1. Anmeldung der primären Registrierung an der richtigen PBX. In den Beispielscripten wird das Telefon direkt angemeldet (wobei man davon ausgeht
  • cfg-gateway.txt
    1. Anmeldung der Schnittstellen an der richtigen PBX
  • update.txt
    1. Datensicherung (auf die Kunden-PBX)

Die Staging Scripte verwenden einige weitere Scripte, die nur Daten zur Installation enthalten:

  • global.txt: Daten, die für den Hoster insgesamt gelten (z.b. sein Domain Name). Ist auf jedem SBC identisch
  • local.txt: Daten, die für einen speziellen SBC gilt (z.b. die IP Adressen der Media-PBX)
  • set-Kundenname.txt: Daten, die für einen einzelnen Kunden gelten (z.b. die IP Adresse seiner PBX und die verschlüsselten Anmelde-Passwörter des Kunden). Diese Datei kann vom Hoster Kundenspezifisch über eine hosting site generiert werden
  • dev-Gerätetyp.txt: legen für jeden verwendeten Gerätetyp fest, welches Geräteklassenspezifisches staging-config Script (z.b. cfg-phone.txt) verwendet wird
Update Script Sicherheit

Das update Script kann die Registrierungskennwörter enthalten (siehe set-Kundenname.txt oben). Im Prinzip sind die staging Scripte für jederman lesbar. Das kann man auch nicht ändern, da die einzige Alternative wäre, den Kunden (bzw. ihren Geräten) ein Admin Kennwort für den Update Script Server zu geben (zumindest wenn es sich dabei um ein Gerät von uns handelt). Wenn das als Sicherheitsproblem aufgefasst wird, dann muss man die Kennwörter nicht generieren (device= leer lassen) und der Kunde muß das Kennwort selber mit dem Web Interface eintragen oder über das Telefon-UI eintragen.

Inbetriebnahme

Initial

Zentrale Geräte anlegen

  • Kerberos und Kerberos Backup anlegen
  • Neuen Kunden-Account für den Hoster in my.innovaphone anlegen
Neue Infrastruktur

Von einer Gruppe von Kunden genutzte Geräte anlegen

  • SBC anlegen
  • MediaPBX anlegen
  • Metadir anlegen
  • Reporting und Fax Linux-AP anlegen
  • global.txt, cfg-*.txt, dev-*.txt auf dem SBC ablegen (die sind immer identisch auf allen SBCs)
  • das passende local.txt erzeugen und auf dem SBC ablegen
Neuer Kunde
  • VM mit PBX anlegen
  • das passende set-Kundenname.txt erzeugen und auf dem SBC ablegen
  • Einrichten der passenden User Objekte auf der Kunden-PBX und der dazu gehörenden SBC Objekte auf dem SBC
  • Projekt für den Kunden in my.innovaphone anlegen, als URL das staging.txt des Hosters (z.b. https://212.124.38.120/DRIVE/CF0/update/staging.txt) und als Trust das Root-Zertifikat des Hosters eintragen (wie aus der config), sofern der Hoster mit HTTPS arbeitet
Endgerät
  • Device in das Kunden-Projekt eintragen
  • Gerät lang resetten
  • unter Services/Upate als Command File URL immer das Redirect Script http://145.253.157.4/redirect.php eintragen
  • ggf. poll forcieren
  • Endgerät bucht sich auf der richtigen Kunden-PBX als _UNKNOWN_ ein und kann per ZAD einem Userobjekt zugewiesen werden

Support / debugging von Kundenproblemen

  • Alarms, Events und syslog sind auf der jeweiligen Kunden-PBX zentralisiert
  • Config Sicherung erfolgt auf die CF der Kunden-PBX
  • Alle Geräte (auch die beim Kunden) sind in der Kerberos Domäne, wodurch Hoster Admins sich dort anmelden können
  • Kunde muss Zugriff durch Teamviewer erlauben falls nötig
  • Inbetriebnahme semi-automatisch

Reporting (Multiple PBX)

VM muß von Anfang an eine größere VM betrieben werden:

  • Plattengröße von 50GB haben um die erwarteten CDR Daten für 200 Kunden ein Jahr lang auzubewahren
sehr grobe Schätzung. Da muss man Erfahrungen sammeln
  • RAM 1GB

V10 Linux Image und Reporting Files werden benötigt, nur die enthalten die Mandantenfähigkeit. Gebraucht wird die Linux-AP und das Reporting. Eine solche Linux-AP kann mehrere (200) Kunden bezüglich der Ruflisten und des Reportings bedienen (Erfahrungen fehlen allerdings noch).


Namenskonventionen

Für Hoster:

Filtername: Systemname z.B. ckls.net

(Extra Filter für Hoster überhaupt notwendig? Abrechnungstechnisch? Überblick gewinnen?)

Reporting-Login: Systemname

Passwort: ?


Für Kunden-PBXen

Filtername: PBX-Name (=Kunden-ID) z.B. Kuenkel00001

Reporting-Login: PBX-Name (=Kunden-ID)

Passwd: Kunden-Registrier-Kennwort


TODO:

  • Mails??
  • Reporting Zugang

--> Sollte zentral verlinkt werden..DNS? Problem ist: https://212.124.38.120:8102/apps/innovaphone-reporting/user/login.php Sobald portmapping sich ändert funktioniert der link nicht mehr..


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

Konfiguration Kunden-PBX

Gateway / CDR0
  • Type Remote-AP-S
  • Address Reporting Linux-AP
  • Port 443
PBX / myPBX / Call List Service
  • Type Remote-AP-S
  • Host SBC-IP-addr:Reporting-User-HTTP-Map-Port-auf-SBC
  • User innovaphone-reporting ?????

pass: reporting

Fax Server

VM sollte von Anfang an eine Plattengröße von 50MB haben!

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

Telefonbuch - PBX

  • pro Kunde wird im SBC ein NAT-Port-Map für LDAPS(TCP Port 636) zur entsprechenden Kunden-IPVA konfiguriert. Das Telefon hat die Möglichkeit den Port in der Phone/User/Directories/PBX anzugeben und benutzt dadurch den LDAP-Server der Kunden-IPVA-PBX(und nicht den des SBC).
  • Es wird LDAPS verwendet, 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 das erhaltene Zertifikat nur zur Verschlüsselung.

Telefonbuch - External LDAP Server

Estos Metadir
  • pro SBC gibt es einen Metadir Server der alle im SBC verwaltete Kunden bedient. Für alle Kunden an einem SBC gibt es ein gemeinsam-genutztes NAT-Map(beim SBC1 ist es Port 9007) zum Metadir Server
  • pro Kunde gibt es einen LDAP-Knoten (dc=Kunden-ID) und 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 contacts.csv verwenden, damit der Replikator immer einheitlich konfiguriert werden kann.
      • die CSV Datei wird via https auf der CF-Karte des SBCs hochgeladen. Jeder Kunde hat auf der CF-Karte ein eigenes Verzeichnis (Kunden-ID) darin enthalten ist die contacts.csv Datei. Der Kunde verwendet curl um die csv-Datei auf den SBC zu laden.
        Die Syntax dafür ist: curl --verbose -k https://212.124.38.120/DRIVE/CF0/directory/Kunden-ID/ -T contacts.csv

Struktur auf dem SBC 

/DRIVE/CF0/
    directory/                  - directory Verzeichnis und Unterverzeichnisse sind write-only ohne Authentifizierung
      Kunden-ID/           
        contacts.csv
  • der Estos Metadir Server hat die gleiche Ordnerstruktur wie die CF-Karte des SBC
    C:\directory\
      script.bat                - script wird vom Replikator vor dem Einlesen der csv-Datei ausgeführt. Script überschreibt die csv-Datei mit dem Inhalt der csv-Datei auf dem SBC
      contacts.csv              - Vorlage für eine contacts.csv, wird verwendet beim Erstellen des Replikators
      Kunden-ID\           
        contacts.csv
  • Der Replikator verwendet die entsprechende lokale contacts.csv, vor dem Lesen der csv-Datei ruft der Replikator noch die script.bat mit dem Parameter Kunden-ID auf(z.b. script.bat Kuenkel0001). Das der Replikator vor/nach dem Replizieren eine Datei ausführt, kann man beim Erstellen/Bearbeiten des Replikators über die Metadir-Admin-Oberfläche(genannt Datenbank-Wizard) im Menu "Zusätzliche Anwendungen" konfigurieren.

Die script.bat lädt via curl die csv-Datei aus dem per Parameter übergebenen Verzeichnis und stellt somit sicher dass man immer die aktuelle csv-Datei(vom SBC) verwendet. Die curl - syntax ist:
curl --verbose -k -u user:password https://10.30.255.0/DRIVE/CF0/directory/%1/contacts.csv -o c:\directory\%1\contacts.csv

user:password in der script.bat Datei sind Administrator - Credentials auf dem Kerberos-Server(Berechtigung muss Administrator sein, Viewer geht nicht)

Der Replikator wird alle 3 Stunden(möglicher Zeitintervall x Minuten - Monate) gestartet.
Alternativ kann der Replikator per cmd-line gestartet werden, dafür gibt es im EstosMetadir Installationsordner für jeden Replikator eine entsprechende exe-Datei(z.B. für den TXT/CSV Replikator - TextReplicator.exe). Die weiteren Parameter zum Aufruf der exe-Datei sieht man in der ebenfalls im InstallOrdner vorhandenen Datei "lastreplicator.bat". Falls diese noch nicht existiert, muss man den Replikator über die MetadirAdmin - Oberfläche einmalig starten, die "lastreplicator.bat" enthält dann die cmd-line Ausgabe des Replikator-Start-Befehls.
Im Replikator-Wizard werden die Spalten der csv Datei ("Nachname","Vorname","Firma","Telefon geschäftlich","Mobiltelefon") den gleichnamigen LDAP-Attributen/DB-Felder zugeordnet. Als Primärschlüssel verwendet man eine Kombination von "Nachname","Vorname","Telefon geschäftlich","Mobiltelefon".
Graphische Uebersicht des Replikator-Mechanismus

  • LDAP-Knoten:
    • Authentifizierung für den Zugriff auf LDAP-Knoten erfolgt per Username(=Kunden-ID)/Passwort(=Kunden-Registrier-Kennwort), es gibt keine Einschränkung auf IP-Netze.
    • als Profil wird immer das "Default" Profil(bei der Installation des Metadir Servers erstelltes Profil, ohne Rufnummerinfo) verwendet. Man braucht durch unsere "Dialing Location" am Telefon keine Kundenspezifischen Profile.
    • als Vorlage ist im Cloudkom-Metadir Server ein Template eingerichtet "dc=template". Die config-Einstellungen sind aus dem screenshot ersichtlich.
  • kurze Anleitung zum exportieren von Kontakten in Outlook 2010:
    • man kann nur eigene 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 der 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 den Port (bei Cloudkom 9007)
LDAP-Client
  • die Directories Einstellungen sollten per config - template verteilt werden, auf der VM10 gibt es dazu als Beispiel das config-template "default"
  • Phone/User/Directories/External LDAP Server Einstellungen
  • die Dialing Location am Telefon wird entsprechend der Amtsleitung des Kunden konfiguriert
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) nichts anfangen. Durch ein Parameter kann man im PBX0 Modul fest konfigurieren welcher LDAP Server genutzt werden soll.

config add PBX0 /ldap-default-addr 10.30.0.7 /ldap-default-port 714 (wobei 10.30.0.7 die IP des Metadir-Servers ist und 714 der LDAPS port)

Voicemail

Läuft auf der Kunden-PBX. Als Medienendpunkt muss das Webmedia auf der Media-PBX verwendet werden. Das Script und die Voice-Mails liegen auf der Kunden-PBX. Um ein externes Webmedia-IF verwenden zu können, muss es eine Registrierung auf dem VM-Objekt geben. Über diese wird der Ruf zum fernen Webmedia abgewickelt. Die Registrierung wird von einem GWxx lokal durchgeführt deren Rufe alle zum lokalen HTTP-EXT geroutet werden (Rufe zum VM-Objekt gibt es nicht, nur von dem Objekt).

Aktivierung der VM je nach Kundenwunsch.

PBX

Gateway

    • vmrelay GWxx, Register as Gateway, 127.0.0.1, Name= vmrelay
    • Route GWxx (vmrelay) --> ###12 GWyy (HTTP-EXT)

MWI

Geht einfach so.

Mail MWI

Versand erfolgt über den Mail Server des Hosters. In der Regel erfordert das eine SMTP Authentifizierung. Für jede Kunden-VM kann und muss das email.xml angepasst werden:

  • message sender
  • Betreff der MWI Mail
  • mail server
  • authentifizierung

Die Änderungen sind (zumindest für gleichsprachige Kunden, cf. Betreff) gleich. Das kann also einmal gemacht und dann immer kopiert werden.

Für jeden mail Empfänger muss die Email Adresse vollständig in den URL Parameter des User eingetragen werden (praktischer als als Textfile in den User Directories),

Operator

Datensicherung

Die Datensicherung gegen "Disaster Recovery" (also das Wiederherstellen verloren gegangener Daten) sollte durch den Hoster erfolgen. Konkret bedeutet dies, dass der in der LÖage sein sollte, eine oder mehrere VMs aus seinen Sicherungen wieder herzustellen.

Die Sicherung der Benutzerdaten (individuelle Telefonkonfigurationen, Ruflisten und Verzeichniseinträge) erfolgt per Update Script auf die Kunden-VM. Die Konfiguration der Kunden-PBX erfolgt auf den SBC. Diese Daten dienen eher der Wiederherstellung versehtnlich gelöschter oder unerwünscht (ver-)konfigurierter Daten. Die Sicherung dieser Daten wiederum erfolgt dann (s.o.) durch den Hoster.

Logistik

Im Moment sehen wir keine spezielle Logistik vor. Das bedeutet, dass alle Produkte(vor allem also Telefone) "Standard-Produkte" sind. Es gibt daher auch keine spezielle Provisionierung dafür. Der in Update Server oben beschriebene Staging Mechanismus basiert auf den normalen Features und erfordert daher einen manuellen Eingriff des Hosters/Resellers/Endkunden (Festlegen der Update URL am Gerät oder im DHCP Server des Kunden).

UI

Im Moment ist keinerlei spezielles UI für den Hoster, den Reseller oder den Endkunden vorgesehen. Dies kann (und muss recht wahrscheinlich) durch den Hoster und/oder Reseller selbst realisiert werden, wenn er das für sein Geschäftsmodell für erforderlich hält.

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