Is it possible to tell whether two IP addresses belong to the same server?

No, it's not, in the general case.

Some additions, to make our guests from SO happy:

• There is nothing in the base TCP/IP protocols (e.g. IP/TCP/UDP,ICMP) that is specifically meant to make the distinction asked for in the question.
• The same is true for many higher level protocols, e.g. HTTP.
• It is indeed possible to use more or less subtle differences in answer patterns to make a guess about the system. If you have two very different systems, e.g. a Linux and a Windows server, this might be enough to be sure about having two hosts.
• This will become more difficult the more similar the systems are. Two nodes in a HA web cluster with identical hardware and OS are likely impossible to keep apart this way. I consider this the general case in most scenarios today.
• Lastly: Are two virtual machines on the same physical box one or two servers? Depending on why you try to differentiate in the first place, this might be important and it's completely impossible to tell on the networking level.

Curious as to "why." Concerns about dual homed machines are typically localized as some unnamed sysadmin's headache. Details are meant to be hidden by the OSI model.

Linux centric answer ahead.

There are some ways to generate fingerprints and make an educational guess.

1. nmap -o and nmap with a decent port scan. Servers don't always bind to both NICs. But a lot of times they do.

2. MAC addresses. If you had any means to get the MAC addresses, manufacturers like to use consecutive addresses for integrated hardware. Two nearly identical MAC addresses are more likely the same motherboard. This doesn't apply to aftermarket cards, of course.

3. Greetings. Telnet, ftp, smtp, and the like all offer identifying information. See if these services are running, offer enough distinct information. Banners are likely rare today but still worth a shot.

4. Test NIC independent behavior. For example, try to trip deny hosts by providing bogus authentication to ssh a dozen times. If deny hosts is tripped, you should find the socket closes immediately on the next try. See if this is happening for the other IP as well.

A /27 net is ... what, 29 hosts? I'd say chances of identifying a dual homes machine with high confidence is super slim, maybe 5%. But given so few hosts, you might be able to make an educated guess.

Fun question for an interview. I may steal it actually.

Theoretically you can give a meaningful confidence level in most cases. There are a couple of caveats though that make it much harder in practice.

I'm going to be overlapping other answers, and I've probably missed stuff out, but this is at least a detailed reasoning as to why these particular bits matter or don't.

First though, forget any thoughts of MAC addresses. Unless you have direct access to the network segment you won't be able to see them.

Also don't trust port scans. It's trivial to firewall ports for only certain IPs, have software listen only on certain IPs or have an IDS/IPS system that applies filtering when a scan is detected. All these will muck up your testing.

Ok, so the way you can tell is simple: the probability of two boxes being exactly identical is low unless they are otherwise related anyway. So what you're actually doing is trying to prove they are different boxes, not trying to prove they are the same.

1. Ping. You need to test both at the same time and do lots of tests. It turns out that while there is jitter in network times it is fairly high quality pseudo-random noise, if you have enough samples in a small time frame the noise averages out enough to give you an accurate comparison.

   Each layer 2 hop in a network adds a tiny amount of latency, different congestion levels will give different latency values. If the two IPs show significantly different concurrent latency then you can assume they are probably not the same box.

   Caveat 1: A single server with two uplinks (not bonded) and configured with a different IP on each uplink could have enough uplink imbalance to throw this off.

2. Port scan. Destination ports can be in one of three states: listening, closed, filtered. Which they're in isn't actually much use as noted above, but there's still useful information to be had.

   1. Boxes with ports open on multiple IPs will most likely be running the same software on all IPs. It's possible to run, say, nginx on one IP and apache on another, but most people don't bother. Fingerprint the services running to look for similarities. Look for what software and version it's advertising itself as, what options it supports, what hostname (if any) is advertised, if there are any quirks in the behaviour of the software, things like that.

      Web services are the least useful for this, much more useful are things like SMTP (hard to mix and match due to sendmail support, leaks a lot of info), SNMP (an information gold mine), SSH (who runs multiple SSH daemons?) and HTTPS (if you luck out and they're running the same software you can check for differences in SSL configuration, an identical but unusual config is a good indicator). NTP used to be a good test but it's being locked down hard now due to it's heavy use as a DoS amplifier, SNTP isn't really accurate enough for a smoking gun in the same way.

   2. Layer 3 fingerprinting. The main way of fingerprinting an OS remotely is from quirks in it's TCP/IP implementation. The exact details are far too long to go in to here but essentially the packet metadata leaks a lot of information, as does how a closed or filtered port responds to a connection and how a host behaves when receiving malformed packets. While these characteristics aren't a certain thing for telling what's running, they are reasonably guaranteed to be close to the same for every IP bound to a particular TCP/IP stack. Significantly different systems should have significantly different characteristics.

   Caveat 2: Two boxes running exactly the same OS and vendor patches is likely to look the same. On Windows, two copies of the same windows version running auto updates will be pretty indistinguishable unless they have different firewalls running. On Linux the differences are likely to relate mainly to exactly what kernel version and options are shipped. This test can only give high probability that two IPs aren't on the same OS.

3. Replay attacks. With the list of ports open on both IPs, perform identical actions on each IP and look for discrepancies in behaviour. Things like time outs, error messages, retry limits, etc. Some software is harder or less often configured to be different based on IP. If you know one IP is accepting mail for a particular domain, see if the other IP also accepts mail for that domain.

   Caveat 3: This is lower quality data than the service fingerprinting part of test 2 because this stuff is easier to configure differently on different IPs and there's all kinds of behind the scenes interaction possible. High chance of false results makes for little confidence in those results.

So as I said, the underlying theory is that different hosts are probably going to be different configurations and that leaks information.

What this doesn't account for is that it's much harder to tell if the same site running on two IPs is the same server or two servers configured for redundancy. It also doesn't account for system admins who are running config management to keep their systems very similar. Nor does it account for hosts that are DNATing multiple services running on different hosts to a single IP address.

Virtualisation tech throws some odd spanners in the works. Containerised systems like Docker are sharing enough of the stack to make the separate containers look more similar than they might actually be. Virtual nics bridged to a physical nic should be impossible to distinguish from physically separate hardware but aren't, stemming mainly from the fact that the bridge is software and thus the packets have to pass through the host IP stack.

There are many ways to confuse people trying to test for repeatability. The best you can hope for is a pattern that has a low margin of doubt.

The moral of this, for people running servers, is that you should configure your servers to leak as little information as possible:

1. Turn down banner information as far as possible. The less an attack knows about your config the better for you.

2. Have software only accept connections on the IP it's supposed to be serving on and only when necessary. If it doesn't need to be externally accessible, make it bind to localhost only. Reducing attack surface is always good.

3. If you absolutely must have something listening, and you want to avoid correlation between two IPs, try to keep unusual options to a minimum. You want it to blend in.

4. Have a firewall running with a default drop policy. I think there may be value in an IDS setup that responds to attackers with random responses, noise would make it harder for an attacker to trust their results but does result in making you stand out.

5. Random delay modules are worthless for preventing timing attacks. No, really. Pick a random number then roll a die a bunch of times, writing down the result plus the number you chose at the start. What you end up with is a range with a fixed offset. If the random number is substituted the range moves. If the range is changed the offset remains the same and it's just a matter of repeating the sampling process to get a new baseline.

6. IP stack normalisers do exist but were a neglected portion of security research last time I looked. It would probably be a nice market to invest in for a security vendor.