I'm working on a project to determine from my Apache logs the geographic location of incoming requests.
My question in this context is, which IP address does Apache log - the HTTP request header IP address or the connecting device's IP address acquired from the incoming socket connection?
It's from the socket (TCP/IP layer) connection, not HTTP.
(There's no remote-address HTTP header.)
Related
I have a router provided to me by my iSP (Bezeq). In the router, I have configured port forwarding for port 80 to one of the machines on my local network. When the packets are received by the web server, they show the originating IP address as the address of the router. How can I get the IP address that originated the request?
Using tcpdump, I have inspected the packets and see no reference to this address. There has to be some obscure router setting I need to change to make this work.
Through tcpdump in dhcp-server, it shows the server can receive the DHCPDISCOVER package and send the DHCPOFFER package, but can not receive the DHCPREQUEST package from the dhcp-client, so the client can not get IP address and always in send DHCPDISCOVER package.
But the dhcp-server which runs in VMWARE's instance can send DHCPACK to client and the same client will get the IP success. The dhcp-server using the same configure as in Openstack's instance.
And, if I configure the static IP address in the client instance, it will ping the dhcp-server's IP successful.
One more thing, the server and client are in the same vlan.
Is there any limit rule in Openstack's instance? How can I resolve this problem, THX.
The essential reason is that the traffic of port is limited by the security groups in openstack.
By default, all security groups contain a series of basic (sanity) and anti-spoofing rules that perform the following actions:
Deny egress DHCP and DHCPv6 responses to prevent instances from acting as DHCP(v6) servers.
Resolution:
disable security groups (no recommend)
set dhcp-relay to the dhcp server in router (recommend)
security groups limited the traffic by hypervisor's iptables which will drop the packets which's src port is 67 and dst port is 68.
DHCPOFFER packets will send to router by src and dst port 67, and it will works to all vlans.
For DHCP relay and DHCP proxy, packets sent to the DHCP server from the router have both the source and destination UDP ports set to 67. The DHCP server responds using the same ports.
Maybe there are some methods but I can't find out until now ?
I've configured X_FORWARDED_FOR to capture client IP for a HTTPS request and it works as expected.
However, for MQTT, the data is sent over SSL and HTTP/S does not come into the picture.
ssl://<HOST_NAME>:<PORT>
I've tried adding the following to the backend server on HAproxy config. No luck so far.
backend TestServer
mode tcp
server TestServer01 10.6.186.24:48080 send-proxy-v2
------
server TestServer01 10.6.186.24:48080 send-proxy
------
server TestServer01 10.6.186.24:48080 send-proxy-v2-ssl
Is there a way to capture client (source) IP for an incoming MQTT request by changing HAProxy configuration?
No, there is no where in the MQTT protocol to store the original client IP address (like adding extra headers to HTTP requests).
The proxy is literally just forwarding packets that arrive on it's public port to the backend servers (with the possible exception of doing SSL termination) it doesn't change the packets at all.
If you wanted the IP address to do stick-table based abuse protection, you will need to key your stick-table with the MQTT client identifier.
For example this will reject clients if their connection rate is greater than 1 per second, over a 10s window.
tcp-request content set-var(txn.client_id) req.payload(0,0),mqtt_field_value(connect,client_identifier) if data_in_buffer
stick-table type string len 64 size 100k expire 5m store gpc0,gpc0_rate(10s)
tcp-request content track-sc0 var(txn.client_id)
tcp-request content sc-inc-gpc0(0)
tcp-request content reject if { sc0_gpc0_rate gt 10 }
I have the following model that i drew below:
I have a number of processes running on the server. I want nginx or apache to direct the incoming clients through port 80 to one of the server processes to handle the requests. However each connection also establishes a websocket connection to the same process. This is currently initiated from the client side within javascript. At the moment for testing purposes I pass the port within the html rendered on the client. The client then takes this port and estabilishes a websocket connection to the same port that handled its request.
Moving forward to an nginx or apache envionment would it be possible not to pass the port value to the client and have nginx or apache know where it directed the incoming client and use the same port for the websocket connection?
This would have the benefit on not opening all the server ports 8000, 8001, 8002 in the diagram below to the public.
Currently i have facing one problem in portrestrictedcone nattype.When my udp client hit the server with test1.dns.com (to sepcific IP 111.111.111.111 and this ip is bind with DNS test1.dns.com) where i am getting response from different IP and not with 111.111.111.111, however the same scenario is working for fullcone nattype. If the server response from the same above ip i am able to get the response.
Currently there are two services running on the server on UDP, one is which is working in portrestrictedcone and send response on same IP as a result i am getting the response, however second service is not behaving in same was as first service works.
i am running both the services on same DNS as i have describe above.
Can i get the help what i need to change on the server or client side to get this resolve?
I think your problem is that you are not sending the packet to the port you received it from (Allocated by NAT). When you receive a packet, check the port that was used to send it then send your response to that port and not to a predefined port because the NAT might change it.