ASP.NET Request.ServerVariables liefert die lokale IP-Adresse und nicht die entfernte IP-Adresse.

Question

Ich habe eine asp.net-Webseite in c#. Eine Sache, die wir gerne tun würden, ist, Hits auf die Website zu verfolgen, einschließlich ihrer IP-Adresse. Ich habe einige Codes implementiert (Dank SO), aber die protokollierte IP-Adresse scheint immer lokal zu sein, d.h. 192.168.x.x. Ich habe es von verschiedenen Geräten ausprobiert, sogar von meinem Telefon und Version MiFi, nur um sicherzustellen, dass es nicht etwas Seltsames mit dem ISP ist, aber das Protokoll listet immer dieselben 2-3 verschiedenen internen IP-Adressen auf (sie ändern sich etwas im Laufe des Tages).

Hier ist meine Funktion, die die IP-Adresse abruft (nochmals danke für die Beiträge hier auf SO):

geschützte IPAddress GetIp(HttpRequest-Anforderung)
{
    string ipString;
    if (string.IsNullOrEmpty(request.ServerVariables["HTTP_X_FORWARDED_FOR"]))
        ipString = request.ServerVariables["REMOTE_ADDR"];
    else
        ipString = request.ServerVariables["HTTP_X_FORWARDED_FOR"].Split(",".ToCharArray(), StringSplitOptions.RemoveEmptyEntries).FirstOrDefault();

    IPAddress-Ergebnis;
    wenn (!IPAddress.TryParse(ipString, out result))
        Ergebnis = IPAddress.None;

    zurückgeben Ergebnis;
}

public void logHit()
{
    IPAddress ip = GetIp(Aufforderung);
    string sIP = ip.ToString();
}

Ich habe auch dies versucht, was das gleiche Ergebnis liefert:

HttpContext.Current.Request.UserHostAddress;

Wenn ich auf der Clientseite einen Aufruf mache und so etwas wie den Service auf appspot verwende, funktioniert es einwandfrei:

    Funktion getip(json) {
        //txtIP ist ein Eingabefeld im Formular
        document.getElementById("txtIP").value = json.ip;
    }

Ich könnte einen Umweg gehen, indem ich diesen appspot-Link aufrufe und ihn analysiere, aber das scheint mir für etwas, das einfach sein sollte, ziemlich umständlich.

Könnte es am IIS auf dem Server liegen? Gibt es eine Art Weiterleitung? Die protokollierten IP-Adressen sind NICHT die des Servers. Das Problem ist, dass ich keinen direkten Zugriff darauf habe, also muss ich mit den Leuten sprechen, die es administrieren, und ihnen gerne etwas Richtung geben, bevor sie einfach anfangen, Dinge zu ändern.

Danke

Ernie

Answer 1

Wenn der HTTP_X_FORWARDED_FOR-Header wirklich unterstützt wird, dann denke ich, dass dies weder durch einen Forward- noch Reverse-Proxy-Server verursacht wird, sondern wahrscheinlich durch Dynamic Network Address Translation oder Dynamic Port Address Translation, was unterhalb der Anwendungsebene im TCP/IP-Stack passiert und somit keinen Einfluss auf einen HTTP-Anforderungsheader haben würde.

Es gibt viele Möglichkeiten, NAT zu konfigurieren, die meisten würden diese Symptome nicht verursachen, aber es ist sicherlich möglich, NAT so zu konfigurieren, dass dieses Problem auftritt. Dynamisches NAT oder Dynamisches PAT wären zwei Beispiele dafür, und ich würde vorschlagen, dass Sie sich an Ihre Netzwerkadministratoren wenden.

Weitere Informationen zu Dynamic NAT/PAT mit guten Beispielen finden Sie hier: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html

In einem typischen NAT-Szenario erreichen die Anforderungspakete das NAT-Gerät (Firewall oder Router) folgendermaßen: VON - 5.5.5.5 (öffentliche Adresse des Clients) ZU - 6.6.6.6 (die öffentliche Adresse des Servers)

Die "typische" NAT-Konfiguration würde nur das Ziel umschreiben, folgendermaßen: VON - 5.5.5.5 ZU - 192.168.6.6 (die private Adresse des Servers)

In diesem typischen Fall würde der Server weiterhin REMOTE_ADDR als 5.5.5.5 sehen, da dies die Quelladresse der eingehenden Anforderung ist. Dann würden die Pakete an 5.5.5.5 zurückgegeben werden und die Antwort würde erfolgreich zum Client zurückkehren.

In dem Fall von dynamischem PAT würde die Anforderung zum Beispiel folgendermaßen beim NAT-Gerät ankommen: VON - 5.5.5.5 ZU - 6.6.6.6

Dann würde das NAT-Gerät beide Quell- und Ziel-Pakete umschreiben und diese "dynamische" Zuordnung nur für die Lebensdauer der Anforderung aufrechterhalten: VON - 192.168.1.1:12345 (die dynamische PAT-Adresse) ZU - 192.168.6.6 (die private Adresse des Servers)

Wenn der Server diese Anforderung sieht, scheint sie tatsächlich von der privaten Adresse 192.168.1.1 zu sein. Tatsächlich werden bei strengem PAT alle Anforderungen von dieser Adresse ausgehen. In Ihrem Fall gibt es 2 oder 3 solcher Adressen, wahrscheinlich weil Sie genug Datenverkehr haben, bei dem Sie Gefahr laufen, die Ports auszuschöpfen, wenn Sie nur eine einzige dynamische PAT-Adresse verwenden.

Also ist Ihr REMOTE_ADDR 192.168.1.1, da dies tatsächlich die Quelladresse der Anforderungspakete ist. Es gibt kein HTTP_X_FORWARDED_FOR, weil das Dynamic PAT auf einer niedrigeren TCP/IP-Ebene (Adresse und nicht Anwendung) erfolgt.

Schließlich wird die Antwort an 192.168.1.1:12345 zurückgesendet, was zum NAT-Gerät führt, das für die Dauer der Anfrage/Antwort (siehe die obige Cisco-Dokumentation) diese dann wieder auf 5.5.5.5 zurückführt und dann die "dynamische" Zuordnung fallen lässt.

Alles hat einwandfrei funktioniert, der Client erhält die Antwort zurück, aber Sie haben keine Vorstellung von der tatsächlichen Clientadresse aus der Sicht des Servers. Und wenn dynamisches NAT im Spiel ist, sehe ich nicht, wie Sie diese Information vom Server erhalten könnten.

Glücklicherweise haben Sie genau das Richtige getan, um die Informationen im JavaScript auf dem Client zu erhalten, also löst dies Ihr Problem höchstwahrscheinlich so gut wie möglich.

Answer 2

Es hängt von Ihrer Netzwerkstruktur ab. Ein einfacher Firewall oder Load Balancer kann die Variablen ändern, die Sie überprüfen.

Wenn Sie einen Load Balancer verwenden, überprüfen Sie dies: Wie bekomme ich die Besucher-IP-Adresse auf einer Lastenausgleichsmaschine mit asp.net?

Wenn Ihr Server hinter einer Firewall liegt, überprüfen Sie dies: Herausfinden, ob die Anfrage von der Firewall an IIS weitergeleitet wurde