Authentication protocol which detects client impersonation from another machine Consider following authentication protocol.

Client ClientA knows some initial secret KeyA shared with server.
Client also knows IP of legitimate server.

Now when client wants to establish connection with server she will send KeyA to server and her ID (for server to know which key to use).

The server generates new random number Key1A and sends back to client. Now following request will only be accepted if Key1A is sent by the client along her ID. When client sends another request with Key1A, server will generate Key2Aand send to client, and etc.

Now if attacker captures say KeyAn - if she uses KeyAn, it means client will not be able to communicate with the server anymore - because the server will have generated KeyAn+1 already. And expect only KeyAn+1 which the client will not know if attacker used KeyAn already. We will detect that one client with ID clientA "died" - because ID is also sent to the server. And disable request from clientA.

Does this provide identification of client in a secure way?
If no how can I improve this protocol such that if attacker steals some secret and tries to authenticate with server instead of some client A (from a different computer though), then at least I can detect it?
There are a few issues with your protocol. Namely it doesn't protect against men-in-the-middle.

Issue #1 (mentioned by fgrieu in the comments): Assume I host one of the (many) servers all your IP packets have to travel through from ClientA to Server. If I drop the server's Key1A (or KeynA) any future request won't work and I have successfully denied your user the usage of the server. He will have to re-perform the secure initial secret exchange which is likely expensive.
While this won't break the protocol in the sense you're interested in, this is still potentially harmful as it may cost you money (by losing customers being angry about the unrelieability of your protocol) if you need to do an expensive renegotiation (which involves human interaction?) too often. 

Issue #2: If I don't just drop the packet, but flip a single bit, the client will get a wrong key and the server will assume the client has been successfully broken, so your legitimate client will be angry at you and has to re-perform the secure exchange. (see issue #1)

Issue #3: If I can eavesdrop on any of the server's responses and I'm able to drop all users packets, I can successfully take over the role of the client.
You send the next valid token in each of your server's responses and if I can get my hands on that and one valid client request (for getting the ID) I can successfully use said ID and the valid token to make my own requests.
All I have to ensure is that the client won't make any requests himself until I've finished all my evil requests.
The time-frame I need may be relatively short (a few seconds or minutes maybe) and I may be very well able to pretend the server is offline for maintenance for this time-frame. Or I could just launch a packet flooding attack on the client (which probably doesn't have more than 100Mbps bandwith?).
You shouldn't rely on an attacker not being able to DoS your client just because "it's not easy", a good protocol wouldn't create this situation in the first place (and the below mitigation should fix this issue anyways), for example you could avoid sending the next valid token at all,
but cleverly use HMAC to only send derived values and thereby only send the next valid nonce.

Issue #4: If the client actually is some piece of software that should authenticate to the server, I as the (not-so) legitimate user can extract the full program state from RAM / disk drive and just copy it over to another machine to perform my evil requests from there, and maybe I even install some software (like increasing packet loss or just root-level blocking the application) to make sure the legitimate client needs some time to figure out, I stole his credentials. This will be detected, but I still have some time (minutes up to days) to make my evil requests which may cause serious harm to the system and make you lose customers / money.

I hope this points the main issues of your protocol out (if anyone finds any else, please comment / answer yourself).



Now for the improvement.

The best thing to do is: Don't roll your own crypto.

The easiest way to mitigate the issues #1-#3 is by simply using your protocol on top of server-authenticated TLS. This would mean a modified packet would never reach your client application, the server would notice (thanks to record numbers / TCP) if a key didn't reach the destination and an eavesdropper wouldn't be able to read the valid tokens (and mitm is mitigated if the client checks the certificate properly). To fully mitigate man-in-the-middle attacks, you have to deploy DNSSEC along with TLS (and maybe DANE if you're at it) which would ensure you get the correct IP from the domain name for which you know the correct certificate (and can cross-check via DANE) and would allow you to drop the "known IP" requirement.

Issue #4 can't be mitigated with a pure software solution. I can go ahead and copy the state of any program (if I'm root / admin on a PC) and continue running it somewhere else (at least for some time). You need to use a hardware solution in order to ensure that a specific PC was used for a specific client or the client will be able to just shut-down his PC and copy the app to another one (in the same network?) and run it from there. The cheapest approach to this is using the TPM many modern PCs have (and which Windows 10 will require as of july 2016 for Windows 10 logo certification of PCs)