Here is what I think.
When I make request to some website, router through modem makes the request to the internet, (website) and gets the response. (how does it get response?) , webserver knows the router's ip address. Then router knows my private ip address and gives me back what I requested.
The question is , I heard that there's a subnet mask and I know what It does. Why do I need NETWORK ID at all? I read somewhere that it's used so that response could find the network from where request was done, but in above scenario, there's no network needed as web server knows router's ip address and gives it response.
Why do I need(does router need) NetworkId and HostId to know specifically?
There seems to be a lot of confusion here. Your router does not need a network ID, and, in this context, I do not understand what you mean by a host ID.
When I make request to some website, router through modem makes the request to the internet, (website) and gets the response. (how does it get response?) , webserver knows the router's ip address. Then router knows my private ip address and gives me back what I requested.
Eh, no. That is not how it works. When your computer makes a request to a website your computer will first think about what to do with the request.
Is the target directly connected? That means, if I AND the ip address with the netmask, is it the same as my own ip address ANDed with the netmask?
Do I have a specific route for this ip address?
otherwise, send it to the default gateway.
BTW: my own ip address ANDed with the netmask is my network. So a router may store this if it does not want to perform the calculation every time.
Your router will forward the packet to the destination. It does not make a request to the Internet. In the case of a home-NAT-router, it will modify some fields in the protocol header, but it will not make a request of its own.
Related
I understand that if I tell my computer to send TCP packets from a fake ip address - say 128.5.32.3 - then my computer will happily send the packets out but not receive them in response.
But why is no response received? At which point in the chain is the return packet dropped?
Or, to give the same question asked another way - if my internet provider assigns me some arbitrary IP address, why can't my computer tell the internet provider to give me a different, arbitrary, IP address?
It's like sending a letter with a return address in it that is invalid. The mail will still get there, but if they send it back the postman (router) will at best be able to deliver it to a fake return address.
Your internet provider gives you an address on internet that isn't arbitrary rather one of it's internet addresses it has allocated. You can't 'move house' by wishing it.
If you do move house by getting another valid address you still need to receive a response using address supplied.
The postmen (routers) are incorruptible AFAIK :)
To start with your question about why no response is received, it is because the response goes to the person whose IP you spoofed. This can be abused, and an example if this is a "smurf attack". You would need to control the spoofed IP in order to receive the response, and there would be no point to spoofing if you had this control.
As for your question about why you cannot make your ISP assign you an IP is because, firstly, your ISP has control of a range of IPs and cannot assign IPs out of its permitted range. Secondly, most ISPs won't take into account the IP that your device wants. It has full control and will control your IP how it wants, so you cannot change your external IP at will.
There are many reasons why an ISP will not give an 'arbitrary' IP address. These include
They themselves only have a block of IP addresses they are allowed to allocate to users, if the IP address you want to use is not in this block there's nothing they can do (even if they want to, which they probably don't)
You are mostly likely being assigned an IP through DHCP (unless your provider is very generous or you are paying for a static IP). This also means that your IP is frequently changing.
The reason you receive no response is, as you put it, because the spoofed address is not your IP address. You are in essence telling the receiver of the TCP packets to respond to a different user (e.g., you send a packet, and they respond to some random stranger).
This could not be the right place, as it's not about pure programming;
nevertheless, as a simple web developer I find myself quite
ignorant on the subject of networking(Wikipedia usually mix
different subjects on the matter), and I feel as it is a "must" to know.
I sort of have an image of what happens when you write google.com
on your browser, and I don't know the whole process(I have a modem,
a router and a few computers connected to it. let's use my case for an example):
You write characters into chrome ->
there is some character encoding done to translate the address(ASCII or else) ->
DNS does something, not sure ->
your router receives a digital request from a computer's internet cable/WIFI, it saves the internal IPV4 address of
the sender in order to know to which computer to respond back. it sends the digital data to the modem ->
your modem receives digital data, and translates it from digital to analog ->
now your network provider does some work - >
the google server receives a request from an IP address - >
not sure how the google server handles the data, nevertheless it sends back data ->
service provider - > router gets translated digital data from the modem and remembers who sent the request, and sends it to the right person.
in order to optimize a web server or maybe to write a better code which involves networking, perhaps each beginner(such as myself) needs to understand this first? Thank you for your time.
EDIT: I did read wikipedia's OSI model, though it's not quite as helpful as I thought it would.
i will try to explain the idea, although its may be much ,more complicate - it depends on how deep you want to go ...
you write "www.stackoverflow.com"
your OS will try to resolve the www.stackoverflow.com to an IP address
since your OS probably cant, it needs to ask a DNS server
assuming you use an external DNS ( say IP=5.5.5.5 and your IP=10.10.10.10 which is on a different networks ), your OS will check if it knows how to reach 5.5.5.5
a default route 0.0.0.0/0 exists on your PC (this is also known as 'default-gw' which includes ALL internet, it points to your local router
an IP packet will be sent to the router MAC address with the DNS IP address in the destination
your router will probably change your private IP address to its own public IP address and will sends it to the ISP
ISP will route it to the internet until it reaches 5.5.5.5 which is the DNS
DNS will reply back resolving stackoverflow.com to an IP address
your PC now knows how to send packets to stackoverflow.com
packet will be sent to stackoverflow ip address (104.16.36.249) to port 80 (http)
stackoverflow web server listen to requests on port 80
once a packet arrives it will generate a response packet
it will send it back to you exactly in the same way
all that traffic can be seen with a network capture utility like wireshark, u can use those commands (windows) to verify...
ping stackoverflow.com
netstat -rn
ipconfig
nslookup
tracert -d
I have a static local IP Address: 10.8.4., and the public IP Address of my machine is: 72.43.135.. when the server(sitting on different network from my workstation) gets a request from my machine, it sees my IP address from
Context.Request.UserHostAddress
and got 10.20.102.*.
why it the server not getting the IP as: 72.43.135.*?
If you define public and local, you will get to know that these terms might refere to the same network under some conditions. This could be a demilitarized zone (DMZ) for example.
What IP the destination server sees, depends on the interface you send the packets through and the routers it crosses.
Is there masquerading (NAT) ? - Is the main question. You can be on totally different networks but the routers might still forward your local IP, now this also depends on the routing table. Can a packet find its way back to your host? Is there a reversed route from the host to your machine?
The destination host is propably having 2 interfaces, 1 with IP 72.43.. one with a 10.8.. maybe it recieves through the 72 but sends back through the 10.8 because it has a different route back. Networking can be real voodoo! Trace your packets, ask your sysadmins..
(not talking about proxies here, they deliver different custom headers with different IPs)
Let's assume I open my PC browser in a LAN at my home and type http://foo.com, the browser or another running service find the foo's IP address and send it through ISP to the foo's server.
Now the server knows I sent a request and generate a HTML page or something to respond my request. How its respond arrives to browser in a LAN?
IP packets contain the IP address of the source (i.e. the sender). So the server knows who initiated the request, and can then send its response to that IP address (no DNS lookup involved).
One common complexity is in a LAN behind a router using NAT (network address translation); this is the case in most residential settings. Although all the clients in the LAN have different local IP addresses, the router modifies all the IP packets so that they all have the same IP address (the router's external address). Therefore all the response traffic all gets sent back to that single IP address. The router is able to distinguish and send the packets back to the correct local client based on TCP/UDP port number.
Browser opens connection to the server and sends the request; server responds through the same connection.
Its nicely explained at:
http://technet.microsoft.com/en-us/library/cc780783(WS.10).aspx
Imagine the following:
User goes to script (http://sample.org/test.php),
Script sends an HTTP request to some other page (http://google.com/). For this example, we'll say using curl.
The script sets the IP address of the request to the user's IP, via CURLOPT_INTERFACE.
I know already that the requesting script will not receive the response, as the remote-host will send any responses to the IP address given in the request.
What I am wondering is what happens to this response? Assuming the client is on a LAN that has one external address and that all traffic sent to that IP is handled by a router acting as a DHCP server, will the response even get back to the user's machine? If it did, would there be any way to ensure that it was handled by the user's browser? And if so, how would the browser handle this, typically? Would it open a new window with Google in it?
I definitely have a follow up to this question, but I am very curious what goes on at this level, before I experiment further.
The script sets the IP address of the request to the user's IP, via CURLOPT_INTERFACE.
Usually, this won't work. Your ISP knows which IP address you are supposed to have and will not forward traffic coming from "fake" IP addresses.
In particular, since you can only communicate one-way with a fake IP (since the answer won't reach you), you would not be able to establish a working TCP connection, since TCP requires a three-way handshake. Thus, you wouldn't be able to submit your web request.
What I am wondering is what happens to this response? Assuming the client is on a LAN that has one external address and that all traffic sent to that IP is handled by a router acting as a DHCP server, will the response even get back to the user's machine?
If the user's PC has an internal IP address and uses NAT, the router will not know which LAN machine to forward the packet to (since it did not see any outgoing request to which it could match that response). Therefore, the answer would be dropped.
Even if you could get the response to reach the client:
If it did, would there be any way to ensure that it was handled by the user's browser?
No. As stated above, a TCP request consists of a three-way handshake. This handshake has not been completed, so the operating system would just drop the packet.
CURLOPT_INTERFACE is for use on computers that have multiple IP addresses assigned to them, to specify which of those addresses should be used as the source IP for the connection. You can't use it to spoof some other computer's IP address. Most likely you'll either get an error, or the option will be ignored and the OS will choose a source interface automatically (the default behavior).
The response will be returned on the same TCP connection as the request.