One exception to this is when the client is inside the same LAN as the server. (When a reply packet comes back at R1, other things make sure the packet finds its way to the client.) If you want to know why not all communication is simply MAC-based, have a look at this question on serverfault. For the communication to work, that's all it needs to know besides the original IP from R1. In the end, the server will only be able to see the MAC address from R3. Moving forward, R2 will not tamper with any of the IPs like R1 did because it is not a NAT router (like most consumers have). Source MAC: 02:01:01:02:02:02 (belongs to: R1)ĭestination MAC: 03:01:01:02:02:02 (belongs to: R2)Īs you can see, the destination IP doesn't change, but the MAC addresses changes every time it gets forwarded (by a router) based on which router it is forwarded to and which router it came from. The packet now contains: Source IP: 172.16.1.1 (public IP from R1) It changes the source IP to the public IP (so that the server can send a packet back), and forwards it to R2. Then R1 is like "Oh, that IP is somewhere on the internet". The packet contains: Source IP: 192.168.1.100 (belongs to: Client)ĭestination IP: 10.1.1.1 (belongs to: Server)
The client then sends it to their router, R1, in the hope that it will be able to forward it to the destination. Nope, the server has a 10.x IP, and the client an IP.
If the client wants to send a packet to the server, it first checks whether the server is in the same subnet. To understand why, you must know a thing or two about how the internet works.Ĭommunication between devices is commonly done via the Ethernet protocol (wiki), and despite the source and destination being identified by IP, actual communication is done per MAC. In short, the answer is no, you usually can't block based on MAC address.
0 kommentar(er)
