This is not something you normally do. If you want the application to be listening on 192.168.0.10:2000, then bind your program to that IP+port tupple. Unconditionally forwarding like you propose buys you nothing and will slow down the flow of data as it has to go through another userland application (ie: your software proxy.)

Most OSes provide a NAT function (such as with PF under BSD or Netfilter under Linux), but here again, why waste kernel resources translating IPs instead of just putting your application on the IP you intend to listen for connections on? RFC1918 and IPv6 space is abundant, so it's a matter of needing a 2nd address, just assign one and bind to that.

If you still think you need to do what you propose, maybe you can elaborate on what you're attempting to do? This feels like a case of trying to fit a square-peg in a round-hole.

Now that I've (hopefully) talked you out of writing, or even using, a software proxy to talk to your own host, I'll give you some hints that socket code can get tricky. You need to worry about what I/O blocking mode you use, how to deal with partial reads and writes, what to do when one side performs a half-close (send EOF on a socket stream,) and similar complexities.

Writing good socket-code generally requires a decent understanding of how the protocols work, plus programmatic concepts like buffers, polling, plus some design decisions when dealing with a bi-directional socket on each end. That last part could mean you juggle 4 I/O flows (in+out from the sender, and in+out to the receiver,) or that you go to a forked or threaded model where each process handles the flow in a single direction across the proxy's pipe.

If you want to get more serious about socket code, I can recommend the UNPv1 book as an excellent place to start. The examples it has are in C, although the concepts are very usable in Perl (though reading the book's code examples really requires at least a basic understanding of C.)

nginx can definitely do this and divide/redirect traffic by conditions specified all the way up to the application layer (as a 'reverse' proxy).

However, I'm feeling this is an XY Problem, and that OP really doesn't want to be writing their own 'filter' or 'proxy'. Furthermore, it doesn't seem OP has the hardware resources (nor the financial resources or C-level backing) to do things properly.

Perhaps if OP would state a bit more about their infrastructure, traffic patterns (how does traffic arrive to the box), DNS setup (from the external and internal sides) and what they're trying to achieve overall, the network people here may be able to help them come up with a solution that isn't overly insecure, and doesn't compromise traffic destined for other services.

You do not want to promise something that you can't deliver, especially in an environment where you've got no backing whatsoever to make it so.