ASP.NET Anfrage.ServerVariables Renditen lokale IP-Adresse remote-IP nicht
Bekam eine asp.net web-Seite in c#. Eine Sache, die wir tun möchten, ist der track trifft auf die Website einschließlich Ihrer IP-Adresse. Ich führte einige code (Dank SO), aber die geloggten IP-Adresse immer zu sein scheinen, lokal, ie: 192.168.x.x. Ich habe es versucht, aus einer Vielzahl von Geräten, sogar mein Handy und die Version MiFi, nur um sicherzugehen, dass es nicht etwas komisch mit der ISP aber die melden sich immer die gleichen 2-3 verschiedene interne ip-Adressen (scheint ein wenig ändern, als der Tag geht weiter).
Hier ist meine Funktion, die bekommt die IP (wieder Dank der postings hier SO):
protected IPAddress GetIp(HttpRequest request)
{
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 result;
if (!IPAddress.TryParse(ipString, out result))
result = IPAddress.None;
return result;
}
public void logHit()
{
IPAddress ip = GetIp(Request);
string sIP = ip.ToString();
}Habe ich versucht, dieses so gut, das ergibt dasselbe Ergebnis:
HttpContext.Current.Request.UserHostAddress;Wenn ich einen Anruf auf der client-Seite mit so etwas wie der service auf appspot, es funktioniert Prima:
<script type="application/javascript">
function getip(json) {
//txtIP is a input box on the form
document.getElementById("txtIP").value = json.ip;
}
</script>
<script type="application/javascript" src="http://jsonip.appspot.com/?callback=getip"></script>Ich nehme an, ich könnte einen Umweg, indem Sie auf diesen appspot link und analysieren Sie es aus, aber das scheint eine ganze Menge ärger für etwas, das einfach sein sollte.
Könnte es sein, den IIS auf dem server? Irgendeine Art von Umleitung geht? Die ip-Adressen protokolliert werden, NICHT der Server. Das problem ist, ich dont haben direkten Zugang zu ihm, so habe ich zu reden mit den Jungs, dass admin und möchte Ihnen ein wenig die Richtung, bevor Sie einfach anfangen, Dinge zu verändern.
Dank
Ernie
- Sie können einen Versuch geben, um "X-Forwarded-For" - header, anstelle von (oder zusätzlich zu ) "HTTP_X_FORWARDED_FOR". Jedenfalls, wenn die app gehostet ist hinter einem reverse-proxy, könnten Sie ein Problem haben, weil nicht alle RP implementieren *X_FORWARDED_FOR richtig.
- Ernie werfen Sie einen Blick auf diese stackoverflow-posting und versuchen die Antwort durch @algreat stackoverflow.com/questions/735350/...
- für die Reaktion. Ich habe es ausprobiert, aber es kommt wieder null.
- Danke für den link. Ich tatsächlich gelesen, dass vorher und habe versucht, alle der genannten Antworten. Kommen alle wieder mit den gleichen ip-Adressen. Ich habe selbst eine test-Seite, die Schleifen durch alle Einträge in ServerVariables und die DNS-AddressList und stürzt Sie auf der client-Seite in html, um zu sehen, wenn es ein anderer var, dass könnte es haben, leider nichts getan. Das einzige, was funktioniert ist die javascript. Ernie
- Ich war nur neugierig, und habe mit meinem ISP. xeondev.weblapportal.hu/Webform1.aspx "HTTP_X_FORWARDED_FOR" unterstützt wird , werden vielleicht einige IIS-Einstellung ? ....
Du musst angemeldet sein, um einen Kommentar abzugeben.
Es hängt von Ihrem Netzwerk-Struktur. Einfach eine firewall oder load balancer können ändern Sie die Variablen, die Sie überprüfen möchten.
wenn Sie einen load balancer prüfen:
Wie man Besucher auf IP-load-balancing-Maschine mit asp.net
wenn Ihr Server hinter einer firewall prüfen:
Finden, wenn die Anfrage weitergeleitet wurde von firewall zu IIS
Wenn die HTTP_X_FORWARDED_FOR header wird wirklich unterstützt, dann denke ich, wäre dies nicht entweder vorwärts-oder reverse-proxy-server verursacht, aber mehr wahrscheinlich Dynamic Network Address Translation) oder Dynamischer Port-Adresse-Übersetzung, das geschieht unter der Anwendung-Schicht auf der TCP/IP-stack und würde somit nicht auf einer HTTP-Anfrage-header.
Gibt es viele Möglichkeiten für die Konfiguration von NAT, von denen die meisten würden nicht diese Symptome verursachen, aber es ist durchaus möglich, zum konfigurieren von NAT in einer Weise zu präsentieren, würde diesem problem. Dynamisches NAT oder Dynamische PAT wäre zwei solche Beispiele, und ich möchte behaupten, dass das, was Sie Fragen Sie Ihren Netzwerk-Administratoren.
Mehr auf Dynamische NAT/PAT, gute Beispiele, Sie könnten Kritik: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/nat_dynamic.html
In einem typischen NAT-Szenario, das request-Pakete erreichen das NAT-Gerät (firewall oder router) als:
AUS - 5.5.5.5 (öffentliche Adresse des Kunden)
ZU 6.6.6.6 (die öffentliche Adresse des Servers)
Den "typischen" NAT-Konfiguration umschreiben würde nur das Ziel, wie folgt:
AUS - 5.5.5.5
ZU 192.168.6.6 (die private Adresse des Servers)
In diesem typischen Fall der server würde immer noch sehen REMOTE_ADDR als 5.5.5.5, denn das ist die Quell-Adresse der eingehenden Anfrage. Dann werden die Pakete zurückgegeben werden, um 5.5.5.5, und die Antwort zurück an den client erfolgreich.
Nun, im Fall von dynamischen PAT, zum Beispiel die Anforderung erreichen würde das NAT-Gerät wie folgt:
AUS - 5.5.5.5
ZU 6.6.6.6
Dann das NAT-Gerät würde umzuschreiben beide Quell-und Ziel-Pakete, die Aufrechterhaltung dieses "dynamische" mapping nur für die Lebensdauer der Anfrage:
VON 192.168.1.1:12345 (die dynamische PAT-Adresse)
ZU 192.168.6.6 (die private Adresse des Servers)
Nun, wenn der server sieht diese Anfrage, es scheint aus zu sein private Adresse 192.168.1.1. In der Tat, mit einem strengen PAT alle - Anfragen zu sein scheinen, von dieser Adresse. In deinem Fall gibt es 2 oder 3 von diesen Adressen, wahrscheinlich, weil Sie kann genug Verkehr, dass man Gefahr läuft die ports, wenn Sie nur einen einzigen dynamischen PAT-Adresse.
So, Ihr REMOTE_ADDR 192.168.1.1 ist, denn das ist eigentlich die source-Adresse in die request-Pakete. Es gibt keine HTTP_X_FORWARDED_FOR, weil die Dynamische PAT Auftritt bei einer niedrigeren TCP/IP-Schicht-Adresse und (nicht Anwendung).
Endlich, die Antwort wird gesendet zurück zu 192.168.1.1:12345, welche Routen für das NAT-Gerät, das für die Dauer von Anfrage/Antwort (siehe die Cisco-Dokumentation oben) Karten, die es zurück zu 5.5.5.5, und dann fällt die "dynamic" - mapping.
Alles perfekt funktioniert, der client bekommt die Antwort zurück, außer, dass Sie keine Vorstellung von der eigentlichen client-Adresse aus der Sicht des Servers. Und wenn es dynamisch ist NAT im Spiel ist, sehe ich nicht, wie könnte man diese Informationen auf dem server.
Glücklicherweise, Sie Tat genau das richtige, um die Daten in javascript auf dem client, so dass dies wahrscheinlich Ihr problem löst, als auch, wie es gelöst werden könnte.