If you are in a LAN, in which there is a server that has public network IP, then you just do a port map using iptables. DNAT, specifically.
Suppose the server’s public network IP is 220.127.116.11, and its private network, i.e., LAN IP is 10.0.0.1, and your machine’s IP is 10.0.0.2 (Of course it’s a LAN IP and actually you don’t have a public network IP, otherwise you don’t bother the server.). Suppose you want to map the server’s TCP 4662 port to your machine’s 4662 port. Then the following command suffices:
iptables -t nat -A PREROUTING -d 18.104.22.168 -i venet0 -p tcp --dport 4662 -j DNAT --to-destination 10.0.0.2:4662
Isn’t it easy? The same applies to UDP as well. To get a HighID, you just need to map the TCP port 4662, as the example shows.
Next we analyze what has happened when you communicate with others using the mapped TCP port 4662.
When you make a connection to others using your TCP port 4662, for example, you initiate a connection to 22.214.171.124:80. So it’s something like 10.0.0.2:4662 -> 126.96.36.199:80. Your request is sent to the server 10.0.0.1 since its the exit (and entrance) of the LAN. (You make sure the packet is sent there by editing the routing table, or set it as the default gateway.) A SNAT will be done there, from 10.0.0.2 to 188.8.131.52 (You need to set this SNAT yourself.), then it becomes 184.108.40.206:4662 -> 220.127.116.11:80. Note that although the new source port is still 4662 here, it isn’t always the case. But iptables will try its best not to do an alternation. man iptables and see –to-source for details. Usually it works well. But you can always further specify the port converted.
Then 18.104.22.168 will see this request on its TCP port 80. It will send data back to 22.214.171.124:4662. Note that while doing SNAT,the server saves information about the conversion. (See this article: http://blog.cykerway.com/readpost.php?id=158) So when the reply comes back, the server knows how to convert back the IP and port and send the packet to the actual user, i.e., 10.0.0.2:4662.
That’s half the story. Now see what happens when someone on the public network, say, with IP and port 126.96.36.199:12345, initiates a connection to 10.0.0.2:4662. Of course that guy cannot use the IP 10.0.0.2. He can only make a connection to 188.8.131.52:4662. That’s why we do a port map. The command above just sends what received on 184.108.40.206:4662 to 10.0.0.2:4662. Note that the source address isn’t altered! So when 10.0.0.2 answers this request, it should reply to 220.127.116.11:12345! How can it know how to route this packet? It has a default gateway, right? If it doesn’t know where to send from the routing table, it just sends the packet to the default gateway. In this case, the gateway is usually the one who does the DNAT job, which should know how to deal with the public network IP 18.104.22.168.
There is another method to make the connection work well with DNAT. The server can do an extra SNAT after the DNAT. It can alter the IP address 22.214.171.124 to its own LAN IP, i.e., 10.0.0.1, then sends it to 10.0.0.2. (Note that the port is usually unaltered, as pointed out above. And the information of IP mapping is saved.) From the point of view of 10.0.0.2, the request is from 10.0.0.1. So it just replies to 10.0.0.1. The other work is done by 10.0.0.1 to make sure the reply goes to 126.96.36.199 exactly.