BES Installationen: Secure Connect funktioniert immer noch nicht – Teil II

  • 4 Minuten zum Lesen

Mit dem Erscheinen von BES 12.2 hat BlackBerry eine neue Technik der Endgeräteanbindung namens Secure Connect Plus (BSCP) eingeführt. In unserem Grundlagenartikel BlackBerry Secure Connect Plus: Erläuterung und Anleitung haben wir das Protokoll bereits beschrieben. Secure Connect Plus ist letztlich eine Punkt-zu-Punkt-Verbindung zwischen BES und Endgerät. Der BES “NATet” dabei den eingehenden Verkehr und sorgt so für einen transparenten gesicherten Zugriff nach Innen. Das hört sich zunächst relativ trivial an, hat aber für Interaktionen des Arbeitsbereiches mit dem Firmen-LAN erhebliche Bedeutung und schafft unzählige Optionen im Arbeitsbereich.

Leider treten bei BES Installationen mittlerweile zunehmend Probleme im Umfeld von Secure Connect Plus auf. Die zugrunde liegenden Ursachen sind mannigfaltig, im Ergebnis funktioniert es einfach schlichtweg nicht. Da eine MDM-Anbindung ohne BSCP nun keinen Spaß macht, haben wir schon einiges an Zeit investiert. Im Artikel BES Installationen: Secure Connect Plus funktioniert nicht beschreiben wir, wie man einen kleinen Setup-Fehler korrigiert. Es hat sich jedoch herausgestellt, dass eine manuelle Vergabe einer IP Adresse viele, aber leider nicht alle Probleme löst. Oft steht man trotz des Eingriffs vor einem stehenden, aber nicht funktionierenden BSCP-Tunnel.

Das Phänomen lässt sich in der Regel wie folgt beschreiben: Vom BES aus kann man den Handheld pingen. Endgeräteseitig wird bei OS10 in den Systeminformationen verbundenes Secure Connect Plus angezeigt. Beim PRIV signalisiert die BSCP-Anwendung den stehenden Tunnel. Dennoch ist kein Zugriff auf interne Ressourcen möglich. Trotz korrektem Mailprofil kommt es zudem zum Timeout, wenn man den Mailaccount einrichten will. Bei OS10 bringt ein Runterschalten auf MDS noch Abhilfe, beim PRIV bekommt man nichts ans Laufen.

Licht ins Dunkle brachte ein Debugging im Inneren des Tunnels. Hierzu muss man unter OS10 die native und kostenpflichtige App Networks Tools im geschäftlichen Bereich installieren. Beim PRIV übernehmen die kostenlosen Apps IP Tools und Terminal Emulator die Funktion. Diese Apps erlauben einfache Diagnosen wie Ping, Lookup oder Portscan und geben so Aufschluss darüber, was im Tunnel tatsächlich passiert.

Wir stellten folgendes fest: Operationen, die direkt auf IP-Adressen, intern wie extern, angewandt wurden, funktionierten alle fehlerfrei. Allerdings funktionierte keine Namensauflösung, so dass Ziele wie der Mailserver nicht über den Namen angesprochen werden konnten!

Der BlackBerry Support zeigte sich zunächst auch ratlos. Nach einigem hin und her hatte ein Mitarbeiter anhand eines Gerätelogs die Idee, dass es an der Bindungsreihenfolge der Netzwerkadapter liegen könnte und hat damit voll ins Schwarze getroffen. Folgende Vorgehensweise konnte das Problem in mehreren Fällen lösen:

1. Entfernen überzähliger Adapter aus dem System

In der heutigen Zeit haben wir fast 100% Virtualisierung erreicht. Dies betrifft ganz besonders BlackBerry Server, da der Hersteller verschiedene Hypervisoren wie vmware oder Hyper-V  sogar offiziell unterstützt. Kennzeichnend für diese Techniken ist, dass man neue Server nicht mehr installiert. Vielmehr werden Methoden wie Templating und Kloning zur Vervielfachung und anschließender Individualisierung verwendet. Dies kann aber auch einen entscheidenden Nachteil haben: Je ausgeprägter die Historie einer solchen Servervorlage ist, desto mehr “alte Netzwerkadapter” schlummern in so einer Installation. Wir raten hier zur Entfernung, da diese Überreste eine Installation empfindlich stören können.

In einer Kommandozeile muss hierzu die Variable devmgr_show_nonpresent_devices auf einen Wert von 1 gesetzt werden. 

01 - CMD

Anschließend ruft man daraus den Gerätemanager auf und lässt sich die ausgeblendeten Geräte anzeigen. Ein Vergleich zeigt dann sehr schnell, welche Adapter aktiv sind und welche nicht. Die inaktiven Netzwerkadapter werden deinstalliert. Erst danach sollte man installieren.

03 - localte aold adapters

 

2. Änderung der Reihenfolge der Netzwerkadapter

Eine BES12 Installation legt zum bereits vorhandenen Ethernet-Interface immer einen zusätzlichen TAP-basierten virtuellen Adapter mit dem Namen BlackBerry Secure Connect Plus an. Dabei scheint es eine Rolle zu spielen, in welcher Bindungsreihenfolge dieser Adapter zum primären Ethernet-Interface steht. Falls das beschriebene Problem fehlender Namensauflösung festgestellt wurde hilft es in der Regel, die Adapter-Reihenfolge abzuändern.

05 - adv settings press alt

Der Secure-Connect-Adapter muss dabei nachgeordnet zum Ethernet Interface sein. Dieser einfache Ansatz hat bereits in einigen Fällen das Problem der fehlenden Namensauflösung gelöst.

Achtung: Ich will nicht verschweigen, dass es in zwei Fällen mit BES 12.3 zu Störungen nach einem Neustart kam. Aufgrund “interner Fehler”, vermutlich bedingt durch inkonsistente Datenbankeinträge, konnten einige der BES12-Dienste nicht gestartet werden. Eine nachfolgende Updateinstallation auf BES 12.4 beseitigt diesen Fehler jedoch.

BSCP ist mittlerweile der Grundstein von BES geworden und wird noch viel wichtiger. Wir bleiben daher an dem Thema dran und werden bei Bedarf auch weitere Artikel hierüber schreiben. Wir wünschen, falls notwendig, viel Erfolg beim Debuggen von Secure Connect Plus.

Forumsdiskussion

 

Dieser Beitrag hat einen Kommentar

Schreibe einen Kommentar