pi:remote_access
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
pi:remote_access [2025/04/14 21:19] – m0mzf | pi:remote_access [2025/04/14 22:08] (current) – [Remotely accessing your Pi - Roll your own!] m0mzf | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ======= | + | ======= |
- | Unsurprisingly there are many solutions to this particular cat; is the client Windows or Linux, do you have an internet connection with a public-facing IP address, do you want to roll your own or use / purchase a commercial | + | Unsurprisingly there are many solutions to this particular cat; is the client Windows or Linux, do you have an internet connection with a public-facing IP address, do you want to roll your own or use / purchase a third party solution, what on the Pi do you want to access; all these questions and scenarios have different solutions. This "guide" |
- | =====Roll your own===== | + | =====IP addresses, ports, and the internet===== |
- | ====IP addresses, ports, and the internet==== | + | |
To set up remote access without using a third party provider, save of course whichever ISPs you have chosen, you will need what is known as a //globally routable IP//, or //Public IP// This is a unique address on the internet which your ISP provides to you, and from this address you connect out, or indeed people connect in. There are two address spaces, IPv4 (which look like 173.194.203.102) and IPv6 (which look like 2607: | To set up remote access without using a third party provider, save of course whichever ISPs you have chosen, you will need what is known as a //globally routable IP//, or //Public IP// This is a unique address on the internet which your ISP provides to you, and from this address you connect out, or indeed people connect in. There are two address spaces, IPv4 (which look like 173.194.203.102) and IPv6 (which look like 2607: | ||
Line 17: | Line 16: | ||
Increasingly, | Increasingly, | ||
- | ** | + | **If your ISP is usig CGNAT your Public IP will not be a //Globally Routable IP//, and if both your home connection and remote connection are using CGNAT you will be unable to roll your own access, and must use a third party provider.** |
- | ** *If both your home connection and remote connection are using CGNAT you will be unable to roll your own access, and must use a third party provider* | + | |
Line 36: | Line 34: | ||
If you're provided with a globally routable IP address most ISPs will hand out a dynamic address. This is subject to change periodically, | If you're provided with a globally routable IP address most ISPs will hand out a dynamic address. This is subject to change periodically, | ||
- | When you set up dynamic DNS a program will run on your Pi, usually every few minutes or so, which grabs your Public IP | + | When you set up dynamic DNS a program will run on your Pi, usually every few minutes or so, which grabs your Public IP and sends it to the Dynamic DNS provider. Thus when your Public IP changes there will be, at most, a few minutes of outage before the Dynamic DNS provider is made aware of the new address. |
+ | |||
+ | Probably the best service is [[https:// | ||
+ | |||
+ | =====Remote access tools===== | ||
+ | |||
+ | By far and away the most secure, flexible and modern way of doing this is using wireguard. Wireguard creates a tunnel between two points, perhaps your Pi and your favourite home PC, and from there you can just use the IP address of the Pi's end of the tunnel to access anything you'd normally do over the network, just as if it was plugged in at home. Wireguard can do much more, but that's outside the scope of these ramblings. | ||
====SSH==== | ====SSH==== | ||
+ | < To do > | ||
Public / Private keys | Public / Private keys | ||
SOCKS proxying; browser / telnet | SOCKS proxying; browser / telnet | ||
====Wireguard==== | ====Wireguard==== | ||
- | Setup | + | (Further expansion needed! Is this the easiest? It's not the " |
- | Usage examples | + | |
+ | Setting up Wireguard is a little complex, but most of the work has been taken out of it by the superb [[https:// | ||
+ | |||
+ | Assuming your Pi is on an internet connection with a globally routable IP and you've set up dynamic DNS and port forwarding, this will work. | ||
+ | |||
+ | Take a look at the file you created in, for example, / | ||
+ | < | ||
+ | [Interface] | ||
+ | ListenPort = 51820 | ||
+ | PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= | ||
+ | Address = 172.16.23.58/ | ||
+ | |||
+ | [Peer] | ||
+ | PublicKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= | ||
+ | AllowedIPs = 0.0.0.0/0 | ||
+ | Endpoint = x.x.x.x: | ||
+ | PresharedKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= | ||
+ | </ | ||
+ | |||
+ | Make a note of the " | ||
+ | |||
+ | To set up the other end of the wireguard tunnel on Windows [[https:// | ||
+ | |||
+ | To set up the other end of the wireguard tunnel on (most) Linux Distributions (which use NetworkManager) [[https:// | ||
+ | |||
+ | Now you can, for example telnet into your linbpq node: | ||
+ | < | ||
+ | |||
+ | or view the LinBPQ web server | ||
+ | < | ||
+ | |||
+ | or SSH into your Pi | ||
+ | < | ||
- | =====Commercial | + | =======Remotely accessing your Pi - Third party solutions======= |
To do! | To do! | ||
- | * Tailscale | + | * Tailscale |
- | * Anydesk | + | * Anydesk |
- | * Rustdesk | + | * Rustdesk |
pi/remote_access.1744665582.txt.gz · Last modified: 2025/04/14 21:19 by m0mzf