A while ago, about a week ago, I wanted to speed up RDP for my Windows chicken, and then began to think about various solutions (including but not limited to science, various remote desktop software, transit, etc.). I went to loc to learn about it. I found that transferring rdp is a mainstream solution, and then I started a bold attempt (all kinds of treading holes).
The machine is from Holland, and the average ping of my network directly connected to the past was about 300, which was totally useless (every mouse had to react for half a day, and the experience was extremely bad. I just used 4-core AMD out of 2-core Buffalo).
I don't want to talk about jumping into a pit first. When I think about the transfer, of course, the service provided by others will be stable and lasting. Then I use the loser's scp to transfer. I remember that the Hong Kong BGP line used at the beginning was not connected to my computer, and the Guangzhou Mobile line was still not connected. Shanghai Unicom and Hunan Unicom were still not connected. Anyway, I tried the cheap ones almost once, The last one can't be connected. Then I came to the conclusion that the chicken head family could not transfer to RDP. Of course, this conclusion was wrong. Once when I talked about this question in the water group, the chicken always replied that I could turn to RDP. Then I tried again. Finally, I was successfully connected to the third line of Zhenjiang Unicom. At least I could use ping190.
After the transfer failed, I tried to build a transfer with chickens. The first thing to consider is that hk is lightweight, but it has struggled for several times without success. After the use of one click scripts (iptablesUtils, nftables-nat-rust), the local cannot connect to the rdp through them. This is the second pit, which is fascinating. Then I used 4837, 9929, and GIA lines for transit speed measurement. They can all use iptablesUtils. I didn't care about the other one. Then the effect is still not obvious, the delay is still around 190, but I feel that the mouse really needs to follow a lot. After a long time of connection, I found that the 9929 has good stability. Then I began to look for my favorite chick. At this time, I knew nothing about the problem that the lightweight cloud could not be connected. Later, I compared the 9929 in the United States and Germany and found that the delay in Germany was more suitable, so I bought it to transfer to the Dutch win.
Until today, I finally understood what the situation of that lightweight cloud was. ifconfig The test found that the IP v4 in its network card is an intranet IP. If you use the script directly, the intranet IP will be used as a transit IP by default. This is a huge hole. Now let's get to the point. Thanks to an old brother I helped, I can call him Xiao A. XiaoA asked for help in a transit group and said that he wanted to use Didu lightweight to transit American IP, but it was unsuccessful. I don't know what went wrong. I thought I had filled in the wrong port number and password, and then I started to discuss it with him. As a result, good guy, I fell into a big hole.
It's magic to say, but it's funny to think about. According to the process, I confirmed the basic information to him to see if he made any low-level mistakes. Later, I found that his operation steps were OK. A has a U.S. IP (IP1 for short), a supporting port (P1 for short), and a user name and password. Then a transit port (P2) is set up on the domestic lightweight cloud (its IP is called IP2), and this part is over. This process is no problem. I have also confirmed it. But IP2 and P2 are not connected. My first reaction is, yes, it is. Then he tried several other ports in succession, but all of them indicated that the connection failed. If you ping IP1 and IP2, there is no problem. This is not normal. It should not be a problem. Then I thought of the second possibility. The firewall set by A was not opened, but actually it was opened. Without opening all TCP and UDP, I added the ports to be used again. We also tried many times, once thought it was a bug in our conscience. The second one is also excluded. Then I thought about the problem of the system's own firewall, and started Baidu's solution. Later, I found that the Ubuntu system's firewall was not open, which made me uncomfortable. This is suitable for me to get the chicken's password, and I can directly master the chicken. I was thinking that, since there was a problem with the transit software he used, would it be different if I used a good iptablesUtils? Then I started an operation. As a result, it was still impossible to test with the PING.pe port, and this fourth method was also not possible. Then I thought about whether the delay was too big. Later, I pinged the chicken and found that although the delay was high, it was not enough to lose contact. At last, there was no way out. I began to compare it with the chicken successfully transferred with iptablesUtils. After comparison, we found that there was a problem with the chicken IP in transit. How could it be an intranet IP. Later, I started the magic operation. I ran to the customer service of Conscience Cloud and asked if I could change the intranet IP displayed by the network card IP to the public IP. I asked in a variety of ways, but the customer service refused me in an orderly manner. I had to say that there was something about the customer service. I found introductions about the internal IP and external IP everywhere and sent them to me. Some introduced PCHOME and others introduced Conscience Cloud on the official website. After I failed to find a solution for customer service, I started a more magical operation. I changed the IP of the network card configuration myself. My good fellow, this change of IP made me tired. Either I couldn't understand it or it was all the same. Fortunately, I found a tutorial that looked reliable, and finally I successfully changed the IP manually. Then, after the reboot, the connection was not connected directly, which was very split. Fortunately, I made the image in advance, and the image was successfully rolled back, which was a bit funny. Finally, I realized that it was wrong. Maybe it was the script incompatibility. Later, it was proved that this was true. Both manual iptables and socat were successfully transferred. It's a joke.
