.NET-Anwendung/-Website hinter Proxy-Servern & Kommunikation mit Azure Service Bus

Eine Anwendung oder Webseite durch einen Proxy von einem Netzwerk nach außen kommunizieren zu lassen ist kein Sonderfall. Der Proxy-Server dient dabei als Kommunikationsschnittstelle und Abgrenzung. Er stellt über seine eigene Adresse eine Verbindung dar.

Allerdings ist es unserer Website oder Anwendung dadurch nicht möglich, direkt nach außen zu kommunizieren. Wenn zum Beispiel global verfügbare Dienste, wie ein Azure Service Bus, angefragt werden müssen, muss die Kommunikation über den Proxy-Server laufen.

Je nach Anwendung bzw. Website gibt es Möglichkeiten, Anfragen über den Proxy laufen zu lassen. Wenn eine importierte Bibliothek (.dll) die Anfragen stellt oder abfängt, müssen gegebenenfalls zusätzliche Einstellungen vorgenommen werden (Siehe Kapitel “Kommunikation durch Assemblies, Beispiel: Azure Service Bus”).

.NET 4 Konsolen-Anwendung

Eine Konsolenanwendung soll Dienste außerhalb des Netzwerks verwenden können. Mit dem Erstellen der Anwendung durch Visual Studio wird die App.config erstellt. Vergleichbar mit web.config von Webseiten, enthält diese Einstellungen für die Lauffähigkeit der Anwendung. Um alle Anfragen der Anwendung nach außen über einen Proxy laufen zu lassen, der beispielsweise mit dem Internet kommunizieren kann, muss folgende Einstellungen in die App.config innerhalb des <configuration> Tags eingefügt werden:

<system.net>
<defaultProxy>
<proxy
proxyaddress=”http://123.45.67.89:8080″
bypassonlocal=”True”
/>
</defaultProxy>
</system.net>

Vollständiges Beispiel App.config:

<?xml version=”1.0″ encoding=”utf-8″?>
<configuration>
<startup>
<supportedRuntime version=”v4.0″ sku=”.NETFramework,Version=v4.6.1″ />
</startup>
<runtime>
<assemblyBinding xmlns=”urn:schemas-microsoft-com:asm.v1″>
<dependentAssembly>
<assemblyIdentity name=”Microsoft.IdentityModel.Clients.ActiveDirectory” publicKeyToken=”31bf3856ad364e35″ culture=”neutral” />
<bindingRedirect oldVersion=”0.0.0.0-3.17.2.31801″ newVersion=”3.17.2.31801″ />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name=”Microsoft.IdentityModel.Clients.ActiveDirectory.Platform” publicKeyToken=”31bf3856ad364e35″ culture=”neutral” />
<bindingRedirect oldVersion=”0.0.0.0-3.17.2.31801″ newVersion=”3.17.2.31801″ />
</dependentAssembly>
</assemblyBinding>
</runtime>
<!– Proxy settings for network –>
<system.net>
<defaultProxy>
<proxy
proxyaddress=”http://123.45.67.89:8080″
bypassonlocal=”True”
/>
</defaultProxy>
</system.net>
</configuration>

.NET 4 Website

Um Anfragen von der Website nach außen oder Pakete zur Anwendung über einen Proxy übermitteln zu lassen, muss der gleiche XML-Code in die web.config innerhalb des <configuration>-Tags eingefügt werden:

<system.net>
<defaultProxy>
<proxy
proxyaddress=”http://123.45.67.89:8080″
bypassonlocal=”True”
/>
</defaultProxy>
</system.net>

.Net Core

Da .Net Core über einen eigenen Webserver “Kestrel” verfügt, ist es nicht möglich, über globale Einstellungen alle Requests über einen Proxy laufen zu lassen. Da es zu empfehlen ist, eine Middleware mit Kestrel zu verwenden, kann diese als zusätzlicher Vermittler mit dem Proxy kommunizieren.

Wird Kestrel hinter einen IIS gehostet (ab 2.2 auch im w3wp.exe-Prozess möglich) wird eine web.config vom IIS erstellt, die manuell bearbeitet werden kann. Allerdings ist dies lediglich ein Workaround.

Die empfohlene Variante ist, die Kommunikation selbst zu implementieren. Das “IWebProxy” Interface ist durch “System.Net.Primitives.dll” auch in .Net Core verfügbar.
Siehe: https://docs.microsoft.com/en-us/dotnet/api/system.net.iwebproxy?redirectedfrom=MSDN&view=netframework-4.7.2

Kommunikation durch Assemblies

Beispiel: Azure Service Bus

Eine Anwendung oder Website kann durch eine importierte Bibliothek (Assembly) kommunizieren. Mancher Assembly muss jedoch mitgeteilt werden, dass die oben eingestellten Proxy-Einstellungen ebenfalls für ihre Anfragen gelten sollen.

Als Beispiel muss eine Anwendung sich an einen Azure Service Bus registrieren, um Nachrichten zu erhalten. Durch die Verwendung des SubscriptionClient von “Microsoft.Azure.ServiceBus” muss der TransportType von AMQP (Default) zu AMQP mit WebSockets umgestellt werden, da AMQP ohne WebSocket über TCP und Port 5671 kommuniziert und somit die web.config- oder app.config- Einstellungen keine Auswirkungen haben.
Siehe: https://docs.microsoft.com/en-us/dotnet/api/microsoft.azure.servicebus.transporttype?view=azure-dotnet

Der TransportType einer SubscriptionClient kann wie folgt angepasst werden:

ISubscriptionClient subscriptionClient = new SubscriptionClient(<ServiceBusConnectionString>, <TopicName>, <SubscriptionName>);
// Use websocket to use the proxy in web.config for receiving messages
subscriptionClient.ServiceBusConnection.TransportType = TransportType.AmqpWebSockets;

Bildnachweise

By |2019-02-05T08:51:53+00:00February 5th, 2019|Allgemein, Azure|0 Comments

About the Author:

Associate Technology Specialist

Leave a Reply

%d bloggers like this:

novaCapta verwendet Cookies, um die Funktionalität dieser Website zu verbessern. Durch die Nutzung dieser Seite stimmen Sie der Verwendung von Cookies zu. Weiterlesen

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close