TheLanc3/rustdesk
1
0
Fork 0
mirror of https://github.com/rustdesk/rustdesk.git synced 2026-04-20 10:33:19 +03:00
Code Issues Packages Projects Releases Wiki Activity

Updated FAQ (markdown)

RustDesk
2025-08-23 11:10:17 +08:00
parent ccbf037956
commit c6a9a501ea
1 changed files with 6 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
FAQ.md

@@ -461,6 +461,12 @@ Here is how ChatGPT explains NAT hairping.
>
> - With NAT Hairpinning: When your router has NAT Hairpinning enabled, it recognizes that the request from an internal device is destined for its own public IP (which is also configured to forward to an internal server). Instead of sending the request out to the internet and then trying to route it back in (which is inefficient and often fails), the router intelligently redirects the request directly back into the internal network to the correct internal IP address of the server.
Also we high recommend you deploy on cloud instance which make your life quite simple, here is an example.
> User: Well, I DID deploy the server in intranet (LAN) but I also am using DNS and DID set up a DNS re-write to the LAN version of the Rustdesk server IP for intranet endpoints but I am still having these issues. I did #2 here: https://rustdesk.com/docs/en/self-host/nat-loopback-issues/, The NAT hairpinning *might* explain the lack of connectivity to an onsite endpoint that has VPN turned on. But it does not explain me being unable to remote control offsite endpoints from campus...
> ...
> User: I just migrated it to a Linode instance and redirected DNS and everything is good now. Thanks for your help!
One simple solution for NAT hairping (loopback) is that both internal and external use domain. Internally, use an internal DNS Server (or modify your hosts file) to point the domain to an intranet IP.
https://rustdesk.com/docs/en/self-host/nat-loopback-issues/