Suppose I have static ip in a subnet that has DHCP server. If i gonna send DHCPINFORM
message to the server, what will happen ?
amit
As per RFC-2131 tropic 4.3.5 for DHCPINFORM message:
"The DHCP server responds to a DHCPINFORM message by sending a DHCPACK message directly to the address given in the 'ciaddr' field of the DHCPINFORM message. The server MUST NOT send a lease expiration time to the client and SHOULD NOT fill in 'yiaddr'. The server includes
other parameters in the DHCPACK message as defined in section 4.3.1. "
1.
Since a "DHCPAck" message does not mandate to add all requested network configuration parameters, a DHCP server is free to respond to a "DHCPInform" message, with/without requested parameter responses (implementation dependent), provided the client's static ip settings are validated under dhcp server pools.
2.
Also, the dhcp-client may receive "DHCPAck" messages from many DHCP servers in response to its "DHCPInform" message. The client need to filters all of the "DHCPAck" messages received from DHCP servers to extract response parameters.
[ Example: The dhcp-client may searches each received "DHCPAck" message for a predetermined vendor-specific tag. If a "DHCPAck" message includes a predetermined vendor-specific tag, the dhcp-client extracts response parameters from this message. ]
The question:
If I send a DHCPINFORM message to the server, what will happen ?
Good question :) The answer is not quite so clear. There are variances in DHCP server implementations, and the RFCs are a bit ambiguous. Additionally, the DHCPINFORM message (always initiated by the client) has gone through some revisions - or revelations if you prefer, and so the answer may also depend on the vintage of your DHCP server software:
DHCPINFORM was initially defined in RFC2131 in March, 1997. RFC2131 has been updated 4 times by: 3396, 4361, 5494, 6842. Since RFC 2131's publication, DHCPINFORM itself has subsequently been "clarified" 7 times through 2011. A search will highlight some of the confusion sown in the wake of the creation of the DHCPINFORM message; for example.
A bit more recently, RFC 3203 created a FORCERENEW message which forces the client (incl. hosts using the DHCPINFORM message) to the RENEW state. RFC 6704 updates RFC 3203 with details on use of the Nonce Authentication protocol for security. These standards have made the answer to your question still more ambiguous.
Due to variances in DHCP server implementations, perhaps the best way to answer your question is to use nmap (or similar) to discover the contents of the ACK message issued by your server in response to a DHCPINFORM. I chose nmap to illustrate this because of the dhcp-discover script that is part of the nmap scripting engine sends a DHCPINFORM message. Here's how it worked on my system:
$ sudo nmap -sU -p 67 --script=dhcp-discover 192.168.1.1
Starting Nmap 7.70 ( https://nmap.org ) at 2022-05-30 18:37 CDT
Nmap scan report for myprivlan.com (192.168.1.1)
Host is up (0.0013s latency).
PORT STATE SERVICE
67/udp open dhcps
| dhcp-discover:
| DHCP Message Type: DHCPACK
| Server Identifier: 192.168.1.1
| Subnet Mask: 255.255.255.0
| Router: 192.168.1.1
| Domain Name Server: 192.168.1.1
|_ Domain Name: myprivlan.com
MAC Address: 00:25:B0:E0:A9:F5
Nmap done: 1 IP address (1 host up) scanned in 1.51 seconds
And so you can see what information was included in the server's ACK message. AIUI, this information may only be a subset of the complete set of information in the ACK message - a subset defined in the dhcp-discover script; you may analyze the script code to verify that.
As a further experiment, I made some changes to my DHCP server's configuration (the OPNsense firewall), and re-ran the same nmap command. In each case, the change I made on the server was accurately reflected in the nmap output.
Consequently, it seems that DHCPINFORM does meet the original objective - to update clients with static ip configurations. But it is the client's responsibility to request this update periodically.
Related
When using the -T option to use TCP SYN for probes, (1.)is this how it works: SYN is sent and ACK is received so only a two way handshake occurs so connection with server is made but no confirmation is sent back to server? and it still tracks the server address and data received through traceroute,(2.) is this what keeps the probes from being identified by server firewall/ applications?
I have a server in AWS-East-1 (N. Virginia) and I am trying to ping www.binance.com whose server is located in AWS Tokyo.
Command: ping www.binance.com
I get ping times of 0.5ms which is not true. Possibly, the ping is returning from some nearby router and theoretically even at the speed of light, the return trip should take atleast 75ms.
How do I measure the correct ping latency from my Linux terminal?
Assuming you need to make this test to check performance of application or network.......
Maybe, you can use other approach:
curl -o /dev/null -s -w '%{time_connect}\n' https://www.binance.com
It will return the time_connect so maybe it can help you in your analysis.
I recommend you to measure a round trip delay. It is the delay between the time when your network node request packet is sent and a time when the response packet from remote server arrives back to you. It can be measured by the Wireshark network analyzer. It analyzes a real traffic. The results are more accurate then from the ICMP protocol (ping) tests.
Wireshark usage
Ensure you have not opened any connection to your destination server (e.g. www.binance.com). Check all tabs in your web browser(s).
Find out the IP address of your destination server: dig +short www.binance.com and note all found addresses.
Install the Wireshark application if it is not installed.
Start the Wireshark, select correct interface on which the network data will be captured and start the capturing.
Open the IP address of page you will measure e.g. 65.9.96.71 in the browser. Refresh the page. It is not problem if error is displayed in browser.
Stop the capturing in Wireshark.
Put a filter string to the display filter field of the Wireshark. (See below for filter examples.) Press Enter. Only packets which have selected IP address will be displayed.
Watch the packet times in second column. Calculate the delay between the request packet and the response one.
Wireshark display filters (each line is one example):
ip.addr==65.9.96.71
ip.addr==65.9.96.30 and tcp.port==80
ip.addr==65.9.96.30 and tcp.port==443
Note:
The Wireshark installation in Linux requires some special steps. Confirm you agree that the Wireshark can be used by all users in system. Add your user to the wireshark group and re-login to apply new user setting.
usermod -aG wireshark <your_user>
Additional information
You can trace the network path between your client and remote server by traceroute. It shows you what nodes (routers) are there.
Verify in which country the destination IP address is situated. Use some IP Whois web page to get details. https://ipwhois.io/
I want to understand how my local IP address (localhost) can be exposed to Internet. For that I've read [here] a method of port forwarding using SSH. Which basically does routing from publicly available server to our localhost using SSH.
But I wonder how the service like 'LocalTunnel' works? In above article it's written as following:
There services (localtunnel for example) creates a tunnel from their server back to port 3000 on your dev box. It functions pretty much exactly like an SSH tunnel, but doesn’t require that you have a server.
I've tried reading code from it's github repository and what I understood is:
These services have a server which is publicly available, which generates different URLs, and when we hit that URL, It forward the request to localhost corresponding to that URL.
So basically it's works like a proxy server.
Is these understanding correct? If yes then what I don't understand is that how these server has access to some localhost running on my computer? How it perform request to it? What I'm missing here? Here is the code which I referred.
The Short Answer (TL;DR)
The Remote (i.e. the localtunnel software on your computer) initializes the connection to the Relay (i.e. localtunnel.me) acts as a multiplexing proxy and when Clients (i.e. web browsers) connect, the relay multiplexes the connections between remotes and clients by appending special headers with network information.
Browser <--\ /--> Device
Browser <---- M-PROXY Service ----> Device
Browser <--/ \--> Device
Video Presentation
If you prefer a video preso, I just gave a talk on this at UtahJS Conf 2018, in which I talk a little about all of the other potential solutions as well: SSH Socksv5 proxies (which you mentioned), VPN, UPnP, DHT, Relays, etc:
Access Ability: Access your Devices, Share your Stuff
Slides: http://telebit.cloud/utahjs2018
How localtunnel, ngrok, and Telebit work (Long Answer)
I'm the author of Telebit, which provides service with similar features to what ngrok, localtunnel, and libp2p provide (as well as open source code for both the remote/client and relay/server to run it yourself).
Although I don't know the exact internals of how localtunnel is implemented, I can give you an explanation of how it's generally done (and how we do it), and it's most likely nearly identical to how they do it.
The magic that you're curious about happens in two places: the remote socket and the multiplexer.
How does a remote client access the server on my localhost?
1. The Remote Socket
This is pretty simple. When you run a "remote" (telebit, ngrok, and localtunnel all work nearly the same in this regard), it's actually your computer that initiates the request.
So imagine that the relay (the localtunnel proxy in your case) uses port 7777 to receive traffic from "remotes" (like your computer) and your socket number (randomly chosen source address on your computer) is 1234:
Devices: [Your Computer] (tcp 1234:7777) [Proxy Server]
Software: [Remote] -----------------------> [Relay]
(auth & request 5678)
However, the clients (such as browsers, netcat, or other user agents) that connect to you actually also initiate requests with the relay.
Devices: [Proxy Service] (tcp 5678) [Client Computer]
Software: [Relay] <------------------------ [netcat]
If you're using tcp ports, then the relay service keeps an internal mapping, much like NAT
Internal Relay "Routing Table"
Rule:
Socket remote[src:1234] --- Captures ------> ALL_INCOMING[dst:5678]
Condition:
Incoming client[dst:5678] --- MATCHES -------> ALL_INCOMING[dst:5678]
Therefore:
Incoming client[dst:5678] --- Forwards To ---> remote[src:1234]
Both connections are "incoming" connections, but the remote connection on the "south end" is authorized to receive traffic coming from another incoming source (without some form of authorized session anyone could claim use of that port or address and hijack your traffic).
[Client Computer] (tcp 5678) [Proxy Service] (tcp 1234) [Your Computer]
[netcat] --------------> <--[Relay]--> <------------ [remote]
2. The Multiplexer
You may have noticed that there's a critical flaw in the description above. If you just route the traffic as-is, your computer (the remote) could only handle one connection at a time. If another client (browser, netcat, etc) hopped on the connection, your computer wouldn't be able to tell which packets came from where.
Browser <--\ /--> Device
Browser <---- M-PROXY Service ----> Device
Browser <--/ \--> Device
Essentially what the relay (i.e. localtunnel proxy) and the remote (i.e. your computer) do is place a header in front of all data that is to be received by the client. It needs to be something very similar to HAProxy's The PROXY Protocol, but works for non-local traffic as well. It could look like this:
<src-address>,<src-port>,<sni>,<dst-port>,<protocol-guess>,<datalen>
For example
172.2.3.4,1234,example.com,443,https,1024
That info could be sent exactly before or append to each data packet that's routed.
Likewise, when the remote responds to the relay, it has to include that information so that the relay knows which client the data packet is responding to.
See https://www.npmjs.com/package/proxy-packer for long details
Sidenote/Rant: Ports vs TLS SNI
The initial explanation I gave using tcp ports, because it's easy to understand. However, localtunnel, ngrok, and telebit all have the ability to use tls servername indicator (SNI) instead of relying on port numbers.
[Client Computer] (https 443) [Proxy Service] (wss 443) [Your Computer]
[netcat+openssl] --------------------> <--[Relay]--> <------------ [remote]
(or web browser) (sni:xyz.somerelay.com) (sni:somerelay.com)
MITM vs p2p
There are still a few different ways you can go about this (and this is where I want to give a shameless plug for telebit because if you're into decentralization and peer-to-peer, this is where we shine!)
If you only use the tls sni for routing (which is how localtunnel and ngrok both work by default last time I checked) all of the traffic is decrypted at the relay.
Anther way requires ACME/Let's Encrypt integration (i.e. Greenlock.js) so that the traffic remains encrypted, end-to-end, routing the tls traffic to the client without decrypting it. This method functions as peer-to-peer channel for all practical purposes (the relay acts as just another opaque "switch" on the network of the Internet, unaware of the contents of the traffic).
Furthermore, if https is used both for remotes (for example, via Secure WebSockets) and the clients, then the clients look just like any other type of https request and won't be hindered by poorly configured firewalls or other harsh / unfavorable network conditions.
Now, solutions built on libp2p also give you a virtualized peer connection, but it's far more indirect and requires routing through untrusted parties. I'm not a fan of that because it's typically slower and I see it as more risky. I'm a big believer than network federation will win out over anonymization (like libp2p) in the long. (for our use case we needed something that could be federated - run by independently trusted parties- which is why we built our solution the way that we did)
If it were possible to retrieve the remote IP from a packet received by my Apache2 server (through a custom plugin perhaps), would it always be guaranteed to be accurate? Or is this value as easy to spoof as the referrer header?
My intended use case is to rate-limit unauthenticated API calls.
If it's a TCP packet, then it'll be accurate as to the sending host. IPs in TCP packets cannot be spoofed unless you've got control of the routers involved. With spoofed source packets, only the initial SYN packet will come back, and then the SYN+ACK response from the server will go to the spoofed address, not wherever the forgery came from - e.g. you cannot do the full 3-way handshake unless you can control packet routing from the targetted machine.
UDP packets, on the other hand, can be trivially forged and you cannot trust anything about them.
As well, even simple things like proxy servers and NAT gateways can cloak the 'real' ip from where the packet originated. You'll get an IP, but it'll be the IP of the gateway/proxy, not the original machine.
It is not reliable. Not only because it can be spoofed, but also because a network element can make your server see a different IP address.
For example, it is very typical in a company to access the Internet through a proxy. Depending on the configuration, from your server point of view, all the different users come from the same IP address.
In any case is a filter you can use in many scenarios. For example, show a captcha when you detect too many login requests from the same IP address.
If your intention is to rate-limit invalid API calls you might want to consider using a service like spamhaus. They list IP's that are likely bots and probes. There are other companies and lists as well. But if your intention is to ever ID the 'bad guy' the source IP is very unlikely to be correct.
Imagine a user sitting at an Ethernet-connected PC. He has a browser open. He types "www.google.com" in the address bar and hits enter.
Now tell me what the first packet to appear on the Ethernet is.
I found this question here: Interview Questions on Socket Programming and Multi-Threading
As I'm not a networking expert, I'd like to hear the answer (I'd assume it is "It depends" ;) ).
With a tool like Wireshark, I can obviously check my own computers behaviour. I'd like to know whether the packets I see (e.g. ARP, DNS, VRRP) are the same in each ethernet configuration (is it dependent on the OS? the driver? the browser even :)?) and which are the conditions in which they appear. Being on the data-link layer, is it maybe even dependent on the physical network (connected to a hub/switch/router)?
The answers that talk about using ARP to find the DNS server are generally wrong.
In particular, IP address resolution for off-net IP addresses is never done using ARP, and it's not the router's responsibility to answer such an ARP query.
Off-net routing is done by the client machine knowing which IP addresses are on the local subnets to which it is connected. If the requested IP address is not local, then the client machine refers to its routing table to find out which gateway to send the packet to.
Hence in most circumstances the first packet sent out will be an ARP request to find the MAC address of the default gateway, if it's not already in the ARP cache.
Only then can it send the DNS query via the gateway. In this case the packet is sent with the DNS server's IP address in the IP destination field, but with the gateway's MAC address on the ethernet packet.
You can always download wireshark and take a look.
Though to spoil the fun.
Assuming, the IP address of the host is not cached, and the MAC address of the DNS server is not cached, the first thing that will be sent will be a broadcast ARP message trying to find out the MAC address of the DNS server (which the router will respond to with its own address).
Next, the host name will be resolved using DNS. Then the returned IP address will be resolved using ARP (again the router will respond with its own address), and finally, the HTTP message will actually be sent.
Actually, it depends on a variety of initial conditions you left unspecified.
Assuming the PC is running an operating system containing a local DNS caching resolver (mine does), the first thing that happens before any packets are sent is the cache is searched for an IP address. This is complicated, because "www.google.com" isn't a fully-qualified domain name, i.e. it's missing the trailing dot, so the DNS resolver will accept any records already in its cache that match its search domain list first. For example, if your search domain list is "example.com." followed by "yoyodyne.com." then cached resources matching the names "www.google.com.example.com." "www.google.com.yoyodyne.com." and finally "www.google.com." will be used if available. Also note: if the web browser is one of the more popular ones, and the PC is running a reasonably current operating system, and the host has at least one network interface with a global scope IPv6 address assigned (and the host is on a network where www.google.com has AAAA records in its DNS horizon), then the remote address of the server might be IPv6 not IPv4. This will be important later.
If the remote address of the Google web server was locally cached in DNS, and the ARP/ND6 cache contains an entry for the IPv4/IPv6 address (respectively) of a default router, then the first transmitted packet will be a TCP SYN packet sourced from the interface address attached to the router and destined for the cached remote IPv4/IPv6 address. Alternatively, the default router could be reachable over some kind of layer-2 or layer-3 tunnel, in which case, the SYN packet will be appropriately encapsulated.
If the remote address of the Google web server was not locally cached, then the host will first need to query for the A and/or AAAA records in the DNS domain search list in sequence until it gets a positive response. If the first DNS resolving server address in the resolver configuration is in one of the local IPv4 subnet ranges, or in a locally attached IPv6 prefix with the L=1 bit set in the router advertisement, and the ARP/ND6 cache already contains an entry for the address in question, then the first packet the host will send is a direct DNS query for either an A record or a AAAA record matching the first fully-qualified domain name in the domain search list. Alternatively, if the first DNS server is not addressable on-link, and a default router has an ARP/ND6 cache entry already, then the DNS query packet will be sent to the default router to forward to the DNS server.
In the event the local on-link DNS server or a default router (respectively, as the case above may be) has no entry in the ARP/ND6 cache, then the first packet the host will send is either an ARP request or an ICMP6 neighbor solicitation for the corresponding address.
Oh, but wait... it's even more horrible. There are tweaky weird edge cases where the first packet the host sends might be a LLMNR query, an IKE initiation, or... or... or... how much do you really care about all this, buckaroo?
It depends
Got that right. E.g. does the local DNS cache contain the address? If not then a DNS lookup is likely to be the first thing.
If the host name is not in DNS cache nor in hosts file, first packet will go to DNS.
Otherwise, the first packet will be HTTP GET.
Well, whatever you try to do, the first thing happening is some Ethernet protocol related data. Notably, Ethernet adapters have to decide whether the Ethernet bus is available (so there's some collision detection taking place here)
It's hard to answer your question because it depends a lot on the type of ethernet network you're using. More information on Ethernet transmission can be found here and here