Yes, this can be done. No, you don't want to. Unlike some other answers I see, I'm about to delve into more details of why (particularly for my second sentence).
Let's say you control a computer, and you can set it's IP address. And so you type in an IP address of 126.96.36.199. Can you do that? Yes.
Now, "routing" could be an issue (as I'm going to elaborate on in a later part of this answer). However, there may be ways around that. So, let's say that a remote end contacted your ICMP server and ran "ping 188.8.131.52". Would your ICMP server (typically built into "TCP/IP stack" software components) respond? Yup. No problem.
Let's say that you start up a server on this computer, such as a DNS server. If your computer was running a DNS server and received the response, could it respond and could everything work? Yes. No problem.
Let's say that you start up an HTTP server. If another computer opened up a web browser and ended up communicating to your computer with the IP address, then could your computer respond and everything work? Um... well... it used to be that the answer was "Yes". But, now, things got a bit more complicated due to HPKP. For more details, you can see Wikipedia's web page on HTTP Public Key Pinning]. So, that might not work so well. To summarize: popular web browsers considered this a style of attack, and came with some details about proper HTTPS certificates/connections for some of the world's top sites. Another related technique may be "HSTS preloading", which is related to HSTS ("HTTP Strict Transport Security"). So, when people install modern versions of web browsers, those browsers may come with some details about some websites. If your fake "Google" site doesn't match expectations, the browser may intervene (and presumably let the end user know of a problem).
And, as you suggested, if you do these sorts of things, the legitimate site won't be able to be contacted on this IP address.
Now, why am I saying you don't want to do this?
First, there is a better solution. Have devices rely on DHCP. Then, on your local network, have a DHCP server that points places to use your local DNS servers, at a sensible address (e.g., FEC0:0:0:ffff::/126 or an IPv6 address starting with fd or perhaps fec0:, or IPv4 using the address ranges from IETF BCP 5 ("RFC 1918")). If you standardize that for client machines, then mobile systems will likely work remotely and on your local network as desired.
The big challenge with doing things as you expect is routing. If you set up an address at 192.168.55.3/24 and another computer at 192.168.55.105/24 tries to communicate with you, then the computers will recognize the /24 (a.k.a. a subnet mask of 255.255.255.0) and figure out that anything matching the first three octets (starting with "192.168.55.") is on the local network, and will try a direct communication.
If a DNS client is at 192.168.55.105/24 and try to communicate with 184.108.40.206, then the computer will recognize that 220.127.116.11 does not match the first three octets, and so the computer will attempt send the traffic to a gateway device, most commonly a "default gateway" which sends information to the Internet. (This "gateway" device needs to be on the local network. Using more technical terms, the gateway needs to be in the same subnet.)
So, there are three approaches that could be done to still get your computers to communicate with 18.104.22.168
- You could make your client systems illegitimately use the 22.214.171.124/24 range. Then 126.96.36.199 would seem close. Note that this would break valid communications to 188.8.131.52, and you couldn't simultaneously use this strategy to also have your local computers be in the same close IP range as a different address.
- You could make your local system use 192.168.55.105/0 instead of 192.168.55.105/24. This means you're using a subnet mask of 0.0.0.0, so now you've effectively convinced your computer that 184.108.40.206 is a local address. So communications won't go to your "default gateway", but instead communications will try to reach 220.127.116.11 directly on your local network. If both the client and server are doing this, that will likely work.
- However, using the extreme example shown here, what you've effectively done is convince your computer that all IP addresses are part of your local network. So, this illegitimate method has now convinced the affected computer that the entire Internet is to be treated like it is on your local network. Now instead of breaking communications with the legitimate Google site at 18.104.22.168, you've effectively broken communications with all legitimate IP addresses on the Internet. Ouch. Bad.
- You could set up some custom routing on your "default gateway" device, so that information sent to 22.214.171.124 gets redirected to the local IP address of your desires, instead of getting passed onto your Internet service provider.
While the third approach could theoretically work without too many problems or unwanted side effects, the biggest drawback is that it requires that you muck around with traffic routing. If you're going to muck with something, I suggest that you understand it well first.
As someone who does understand traffic routing, I would suggest that you may need some amount of expertise to successfully break the legitimate connections that you want (to the real 126.96.36.199) while not also breaking legitimate connections that you don't want broken. And if you have that much expertise to pull that off, then you probably also have some expertise to simply run a DNS server on an established private address. So, why not do things in the standardized way which is less likely to cause weird rare side effects that are harder to foresee and troubleshoot?
In answer to what you asked and how you asked it, yes, technically something like this could be possible. But do also keep in mind that if communication isn't going to where it should go, then that is often described as a "Man In The Middle" ("MITM") attack. Web browser connections have already evolved to support HKPK to defeat such shenanigans. A lesser-known fact is that DNS has largely been replaced with using EDNS (using "Extension mechanisms for DNS"), and a more widely known fact is that there are some newer enhancements to DNS security called DNSSec. If you were unaware of any of this, then realize that the current maintainers of popular Internet-based software code might already be way ahead of you, so you might want to keep that in mind before trying to include an "MITM-attack" as a critical part of some sort of fancy new design of any network you oversee.
So, to summarize, the main reason I think you don't want to do this for a real network (rather than a test lab where you're exploring possibilities) is simply that, to accomplish useful legitimate goals, there is a better way. Which is, when you're trying to design how your network behaves, do things the right way. You're likely to experience less pain overall.
To re-clarify in case this was forgotten, the "right way" I am referring to is to just operate your local DNS server on a private address, fooling nobody, and encourage computers to use the local private address or to rely on DHCP, and have your local DHCP servers tell devices to rely on your local DNS server. It is a more honest style of design which doesn't break the ability to communicate with a public site, and is widely supported so maintainers of Internet standards are less likely to do something that breaks such a legitimate design on many local networks used throughout the world.