Laden...

Webs-API .NET Client mit VPN - Lokal funktioniert es, in der Firma gehen keine Calls raus

Erstellt von tobi45f vor 5 Jahren Letzter Beitrag vor 5 Jahren 2.052 Views
T
tobi45f Themenstarter:in
59 Beiträge seit 2017
vor 5 Jahren
Webs-API .NET Client mit VPN - Lokal funktioniert es, in der Firma gehen keine Calls raus

Hallo zusammen,

ich würde gern mittels Webs-API Daten von einem Server abfragen. Mithilfe diesen Beispiels habe ich das ganze auch umgesetzt bekommen.

Das Problem ist jedoch, dass das Programm auf einem "normalen" Computer funktioniert, auf dem Firmen-Laptop jedoch nicht. Hier geht keine Anfrage an den Server raus. Laut unserer IT wäre eine mögliche Lösung, dass der VPN im Programmcode angegeben wird, denn, wenn ich den Link zum Server im Browser eingebe, dann werden die Daten angezeigt. Prinipiell scheint es also zu funktionieren. Der Browser nutzt logischerweise den konfigurierten VPN. Ports und Firewalls sollen angeblich nichts blockieren.

Wenn ich in den Internetoptionen schaue, dann sehe ich, dass ein VPN eingerichtet ist. In den Optionen des VPNs ist ein Skript über ein Link hinterlegt zu einer .dat Datei (Bild im Anhang). Leider sagt mir das nicht viel, ich hatte mit sowas noch nichts am Hut. Ich bin kein Informatiker X(

Kann mir jemand sagen, wie ich meine Serveranfrage mit diesen Optionen vereinige? Oder ist diese Idee Quatsch, da automatisch der VPN verwendet wird?

Grüße Tobias

16.806 Beiträge seit 2008
vor 5 Jahren

Laut unserer IT wäre eine mögliche Lösung, dass der VPN im Programmcode angegeben wird, denn, wenn ich den Link zum Server im Browser eingebe, dann werden die Daten angezeigt.

🤔 🤔 VPN im Programm-Code? Wie soll das gehen?
VPN ist ein Infrastrukturelement eines Rechners. Damit wird der gesamte Verkehr einer Maschine durch einen Tunnel umgeleitet.

Evtl. ist das ein Client Feature eures VPN Clients, dass nur gewisse Programme umgeleitet werden; aber das entspricht nicht der üblichen VPN Verbindung.
Es gibt auch gewisse VPN Anbieter, die zB. Chrome Extensions zur Verfügung stellen, sodass nur einzelne Tabs über einen VPN schicken - aber das sind alles spezifische VPN Client Features (und erfolgen i.d.R. über entsprechende, proprietäre Socket-Verbindungen).

Das, was Du da auf dem Bild siehst, das ist eben genau das: ein VPN für die gesamte Maschine.

Warum keine Serverfrage raus geht, das kann ich Dir nicht sagen.
Das kannst Du im Prinzip nur mit Tools wie Fiddler4 oder Wireshark heraus finden - bzw. kannst Du raus finden, wohin die Anfrage geht.
Wenn Dein Service im Intranet ist und nicht vom Internet aus erreichbar ist; Du aber Remote aus drauf zugreifen musst, dann brauchst Du am Client eine VPN Verbindung in das Firmennetzwerk und i.d.R. muss sich der Service dann im DMZ berfinden bzw. muss die IT das VPN-Routing intern setzen.
Aus Sicherheitsgründen ist es nämlich so, dass man auch im VPN auf so wenig wie möglich Zugriff hat und die IT entsprechende Netzwerk-Dienste pro User einrichten muss.

Aber wir kennen Deine Netzwerksituation nicht; daher ist das ziemlich in den Nebel gestochert.

709 Beiträge seit 2008
vor 5 Jahren

VPN ist ein Infrastrukturelement eines Rechners. Damit wird der gesamte Verkehr einer Maschine durch einen Tunnel umgeleitet.

Je nach Konfiguration kann man auch nur Traffic für einen bestimmten Adressbereich durch den Tunnel leiten lassen.

16.806 Beiträge seit 2008
vor 5 Jahren

Jo, das ist dann aber auch die Konfiguration des Clients.

T
tobi45f Themenstarter:in
59 Beiträge seit 2017
vor 5 Jahren

Hi,

ah ok, danke für die Erklärung. Ich bin halt ein Elektrotechniker mit selbst beigebrachten Programmierkenntnissen. Ich kenn mich mit sowas nur ganz dürftig aus 😉

Mit einem Kollegen aus dem Projekt habe ich mich zusammengesetzt und das Problem gelöst. Es war eher die Kategorie mehr Glück als Verstand.

static async Task<Sammlung> GetProductAsync(string path)
        {

            System.Net.WebRequest.DefaultWebProxy.Credentials = System.Net.CredentialCache.DefaultNetworkCredentials;
.....
}

Und schon macht er, was er soll. Rein für mein Verständnis, warum geht es damit? Wieso muss ich einen DefaultWebProxy definieren, obwohl ich keinen Proxy verwende, sondern einen VPN?

16.806 Beiträge seit 2008
vor 5 Jahren

Ich glaube nicht, dass der VPN hiermit was zutun hat - wenn überhaupt dann ohne Dein zutun.
Ihr werdet viel eher zusätzlich zum VPN noch einen HTTP Proxy haben(üblich in Unternehmen); der authentifizierte Requests haben will - daher diese Zeile Code.

1.029 Beiträge seit 2010
vor 5 Jahren

Hi,

da kann ich Abt nur beipflichten - hat mit dem VPN wenig zu tun - ihr setzt in der Firma sicherlich eine "Firewall"-Appliance ein, die eben nicht jeden "raus" lässt. Um http/https-Requests zu machen, müssen diese also an den Proxy gerichtet sein und zusätzlich mit den WindowsCredentials authentifiziert werden.

Diese Appliances scannen unter Anderem solchen Verkehr nämlich auf Viren etc. und gehen oft auch soweit https-Verbindungen aufzubrechen um auch diesen Verkehr zu scannen.

Ein Hinweis allerdings trotzdem:
Ich würde drauf wetten, dass das nicht nur ein TimeOut war - sondern du einen HTTP 407 (Proxy Authentication Required) bekommen hast, womit du nicht so im Dunkeln hättest stochern müssen.

LG

T
tobi45f Themenstarter:in
59 Beiträge seit 2017
vor 5 Jahren

Hallo zusammen,

ich müsste dieses Thema noch einmal wiederbeleben. Und zwar läuft die Schnittstelle (Konsolenanwendung Beispielprojekt von Microsoft) in ihrem eigenen Projekt einwandfrei. Daten abrufen, Daten posten alles super.
Nun wollte ich diese Funktion in mein bestehendes Projekt (WPF) einbinden. Leider funktioniert dies aber nicht.

Wenn ich den Code eins zu eins kopiere, dann läuft dieser im anderen Projekt nicht. Ich habe die Pakete (Microsoft.AspNet.WebApi.Client und Newtonsoft.Json - selbe Versionen) installiert und alle Verweise sind vorhanden. Kein Code wird als fehlerhaft in VS angezeigt.

Wenn ich die Anwendung starte, dann friert das Fenster einfach ein und wirft auch kein Fehler (egal, ob nur eigenen Code debuggen oder nicht). Er führt folgenden Code nicht mehr aus:
HttpResponseMessage response = await client.GetAsync(path);

Den einzigen Unterschied den ich feststellen kann findet sich im packages.config. Bei dem Beispielprojekt, in dem es läuft haben die Pakete targetFramework="net461". In meinem anderen Projekt wurden diese mit targetFramework="net452" installiert. Manuelles umbenennen der Version hilft nicht.

Ich weiß ehrlich gesagt nicht, welchen Code ich hier posten soll, damit ihr mir helfen könnt. Ich denke, es liegt ein genereller Fehler (Einstellung? Verweis? Installierte Pakete? Version?) vor, der scheinbar codeunabhängig ist, da es ja im Beispielprojekt funktioniert?

Hat jemand eine Idee? Ich bin leider ratlos...

Grüße Tobias

16.806 Beiträge seit 2008
vor 5 Jahren

Die Fehlerbeschreibung riecht nach einem Timeout, dessen Exception Du offensichtlich (wieder) nicht abwartest; im Falle von GetAsync sollte eine TaskCanceledException mit einer entsprechenden InnerException kommen.
Es kann nicht sein, dass .NET eine Methode einfach so nicht ausführt - und die besagte Zeile ist dafür bekannt (und es ist dokumentiert), dass sie einen Timeout haben kann.

Und wenn Das Fenster einfriert, dann ist das ein klassischer Programmierfehler, der zunächst mit dem WebRequest an für sich wenig zutun hat:
[FAQ] Warum blockiert mein GUI?

-> [Tutorial] Vertrackte Fehler durch Vergleich von echtem Projekt mit minimalem Testprojekt finden

T
tobi45f Themenstarter:in
59 Beiträge seit 2017
vor 5 Jahren

also ich habe das mit dem Timeout abwarten auch versucht. Nach ca. 5-7 Minuten habe ich das Warten abgebrochen.
"Request result:
Hier stecke ich fest
Der Thread 0x2250 hat mit Code 0 (0x0) geendet.
Der Thread 0xd5c hat mit Code 0 (0x0) geendet.
Der Thread 0x2338 hat mit Code 0 (0x0) geendet.
Der Thread 0x18bc hat mit Code 0 (0x0) geendet.
Der Thread 0x1030 hat mit Code 0 (0x0) geendet.
Der Thread 0x1708 hat mit Code 0 (0x0) geendet."

Console.WriteLine($"Request result:");
....
Console.WriteLine($"Hier stecke ich fest");
            HttpResponseMessage response = await client.GetAsync(path);
            Console.WriteLine($"es geht doch!");

Ich rufe die Methode so auf:

private void test_click(object sender, RoutedEventArgs e)
        {
            RunAsync().GetAwaiter().GetResult();
        }

Um eins zu eins so aufzurufen, wie in der Konsolenanwendung.

Sicherlich kann ich die Methode auch Asynchron aufrufen, aber die Fehlerquelle des Aufrufs wollte ich ausschließen.
Ob die Anwendung einfriert oder nicht, ist tatsächlich eine Information, die hier keine Rolle spielt.

709 Beiträge seit 2008
vor 5 Jahren

Genau so sollte man das nicht aufrufen.

Auszug aus der Doku der GetResult-Methode:
Diese API unterstützt die Produktinfrastruktur und ist nicht für die direkte Verwendung aus Ihrem Code gedacht.

Versuch's mal mit


private async void test_click(object sender, RoutedEventArgs e)
{
    try
    {
        var x = await RunAsync();
        // ...
    }
    catch (Exception e)
    {
        // ...
    }
}
T
tobi45f Themenstarter:in
59 Beiträge seit 2017
vor 5 Jahren

Wäre ja auch zu einfach gewesen, das gleich so zu testen. Funktioniert so. Hätte ich irgendwie auch selbst drauf kommen können.. Danke dir!

16.806 Beiträge seit 2008
vor 5 Jahren

"Funktioniert so" heisst, dass Du nun eine Exception bekommst? 🤔

T
tobi45f Themenstarter:in
59 Beiträge seit 2017
vor 5 Jahren

Ne, sogar ohne 😁 8)