Ein anderes Verfahren, um das zu erreichen, wird mit der Azure Ressource ‘Azure Relay’ realisiert. Ein Kollege hat dieses Thema bereits 2019 hier beschrieben. In diesem Artikel kann man sehen, dass ein relativ hoher Konfigurationsaufwand am Web-Service notwendig ist.
Die Einrichtung und beispielhafte Nutzung sind in diesem Artikel von Microsoft beschrieben. Auf den ersten Blick eine komplizierte Angelegenheit. Aber wenn man es erst einmal durchgespielt hat und die wesentlichen Punkte herausgefunden hat, reduziert sich der Aufwand rapide:
Voraussetzungen
- Azure Tenat
- Mit Azure AD Lizenz Modell P1 oder P2 wie z.B. in der folgenden Abbildung
- User Berechtigung als Global Administrator
Szenario
Mein lokales Netzwerk ist über eine FritzBox mit dem Internet verbunden. Auf einem Rechner läuft in einer VirtualBox ein Windows Server. Dieser Server erreicht über die FritzBox das Internet, ist aber aufgrund seiner Netzwerkkonfiguration im lokalen Netzwerk nicht erreichbar.
Das Problem
Auf diesem Server habe ich einen Web-Service ‘MyService’ gehostet. Ich möchte mit Postman diesen Service testen. Da ich den Server aus meinem lokalen Netzwerk nicht erreichen kann, brauche ich eine andere Möglichkeit, um auf MyService zuzugreifen.
Die Lösung
Eine mögliche Lösung ist das von Azure AD bereitgestellte Feature ‘Application Proxy’. Dieses Feature stellt einen öffentlichen Endpunkt bereit und leitet Requests zu einem zu installierenden Connector auf der lokalen Maschine weiter. In der folgenden Abbildung sehen wir die Konfigurationsseite eines App-Proxy.
Konfiguration
Die Konfiguration ist relativ einfach. Man vergibt einen Displaynamen und trägt die URI des lokalen Service in das Feld ‘Interne URL’ ein. Hier ist zu beachten, dass nur die URI bis einschließlich des Hostnamen verwendet wird. Also nicht localhost/MeinService, sondern nur http://localhost. Die ‘Externe URL’ wird dann automatisch gemäss den Eingaben generiert und ist auch nicht änderbar. Im gelb markierten Bereich kann man noch eine Einstellung vornehmen, die einen recht grossen Effekt zur Folge hat.
Es gibt zwei Optionen:
Stellt man Passthrough ein, kann man davon ausgehen, dass es eine schnelle und unkomplizierte Lösung wird. In diesem Fall wird der Request vom App-Proxy direkt zum Konnektor durchgereicht. Hier wird dem Service die Authentifizierung überlassen.
Der zweite Fall ‘Azure Active Directory’ ist zwar auch einfach auszuwählen aber eben nicht mal eben schnell mit ‘Postman’ zu testen. Dieses Verfahren würde ich in einem anderen Beitrag mal beschreiben.
Im einfachen Fall wird, nachdem wir auf ‘Add’ geklickt haben, eine Application erzeugt.
Ein Teil der Aufgabe ist damit schon erledigt.
Connector
Der Connector ist ein Stück Software, das als Windows Service ausgeführt wird. Man kann ihn auf der Site des App-Proxy herunterladen.
Nach dem Download muss man die Installation ausführen. Dabei ist zu beachten, dass der Service nur auf einem Windows Server installiert werden kann. Ich habe bei der Konfiguration bei der internen URL ‘localhost’ verwendet. Das kann man nur machen, wenn der Connector auf der Maschine installiert wird, wo auch der Service deployt wurde. Sonst ersetzt man ‘localhost’ durch den Maschinennamen. Wenn alles funktioniert hat, erscheint im Portal in der Default Connector Gruppe ein Eintrag mit dem Maschinennamen des Computers, auf dem der Connector installiert wurde. Wenn der Status auf "aktiviert" steht, kann man schon den ersten Request an die Externe URL absetzten. Ist der lokale Web-Service z.B. mit Basic Authentifizierung abgesichert, wird der Auth Header auch mit durchgereicht. Der Request wird abgelehnt, wenn die Anmeldedaten nicht eingegeben worden.
Fazit
Es ist eine weitere Alternative, um lokale Webserver ohne die Öffnung einer Firewall zu erreichen. Allerdings ohne den Port 80 ausgehend geht es auch nicht.
