You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The challenge most of us face with remotely accessing your home network is that you don't have a static IP. From time to time the IP that your ISP assigns to you changes and it's difficult to keep up. Fortunately, there is a solution, a DynamicDNS. The section below shows you how to set up an easy to remember address that follows your public IP no matter when it changes.
3
2
4
-
Secondly, how do you get into your home network? Your router has a firewall that is designed to keep the rest of the internet out of your network to protect you. Here we install a VPN and configure the firewall to only allow very secure VPN traffic in.
3
+
The challenge most of us face with remotely accessing our home networks is that our routers usually have a dynamically-allocated IP address on the public (WAN) interface.
5
4
6
-
## DuckDNS
7
-
If you want to have a dynamic DNS point to your Public IP I added a helper script.
8
-
Register with duckdns.org and create a subdomain name. Then edit the `nano ~/IOTstack/duck/duck.sh` file and add your
5
+
From time to time the IP address that your ISP assigns changes and it's difficult to keep up. Fortunately, there is a solution: Dynamic DNS. The section below shows you how to set up an easy-to-remember domain name that follows your public IP address no matter when it changes.
6
+
7
+
Secondly, how do you get into your home network? Your router has a firewall that is designed to keep the rest of the internet out of your network to protect you. The solution to that is a Virtual Private Network (VPN) or "tunnel".
8
+
9
+
## <aname="dynamicDNS"> Dynamic DNS </a>
10
+
11
+
There are two parts to a Dynamic DNS service:
12
+
13
+
1. You have to register with a Dynamic DNS service provider and obtain a domain name that is not already taken by someone else.
14
+
2. Something on your side of the network needs to propagate updates so that your chosen domain name remains in sync with your router's dynamically-allocated public IP address.
15
+
16
+
### <aname="registerDDNS"> Register with a Dynamic DNS service provider </a>
17
+
18
+
The first part is fairly simple and there are quite a few Dynamic DNS service providers including:
19
+
20
+
*[DuckDNS.org](https://www.duckdns.org)
21
+
*[NoIP.com](https://www.noip.com)
22
+
23
+
> You can find more service providers by Googling ["Dynamic DNS service"](https://www.google.com/search?q=%22Dynamic%20DNS%20service%22).
24
+
25
+
Some router vendors also provide their own built-in Dynamic DNS capabilities for registered customers so it's a good idea to check your router's capabilities before you plough ahead.
26
+
27
+
### <aname="propagateDDNS"> Dynamic DNS propagation </a>
28
+
29
+
The "something" on your side of the network propagating WAN IP address changes can be either:
30
+
31
+
* your router; or
32
+
* a "behind the router" technique, typically a periodic job running on the same Raspberry Pi that is hosting IOTstack and WireGuard.
33
+
34
+
If you have the choice, your router is to be preferred. That's because your router is usually the only device in your network that actually knows when its WAN IP address changes. A Dynamic DNS client running on your router will propagate changes immediately and will only transmit updates when necessary. More importantly, it will persist through network interruptions or Dynamic DNS service provider outages until it receives an acknowledgement that the update has been accepted.
35
+
36
+
Nevertheless, your router may not support the Dynamic DNS service provider you wish to use, or may come with constraints that you find unsatisfactory so any behind-the-router technique is always a viable option, providing you understand its limitations.
37
+
38
+
A behind-the-router technique usually relies on sending updates according to a schedule. An example is a `cron` job that runs every five minutes. That means any router WAN IP address changes won't be propagated until the next scheduled update. In the event of network interruptions or service provider outages, it may take some time before everything is back in sync. Moreover, given that WAN IP address changes are infrequent events, most scheduled updates will be sending information unnecessarily, contributing unnecessarily to server load.
39
+
40
+
> This seems to be a problem for DuckDNS which takes a beating because almost every person using it is sending an update bang-on five minutes.
41
+
42
+
### <aname="duckDNSclient"> DuckDNS client </a>
43
+
44
+
IOTstack provides a solution for DuckDNS. The best approach to running it is:
9
45
10
46
```bash
11
-
DOMAINS="YOUR_DOMAINS"
47
+
$ mkdir -p ~/.local/bin
48
+
$ cp ~/IOTstack/duck/duck.sh ~/.local/bin
49
+
```
50
+
51
+
> The reason for recommending that you make a copy of `duck.sh` is because the "original" is under Git control. If you change the "original", Git will keep telling you that the file has changed and it may block incoming updates from GitHub.
52
+
53
+
Then edit `~/.local/bin/duck.sh` to add your DuckDNS domain name(s) and token:
54
+
55
+
```bash
56
+
DOMAINS="YOURS.duckdns.org"
12
57
DUCKDNS_TOKEN="YOUR_DUCKDNS_TOKEN"
13
58
```
14
59
15
-
first test the script to make sure it works `sudo ~/IOTstack/duck/duck.sh` then `cat /var/log/duck.log`. If you get KO then something has gone wrong and you should check out your settings in the script. If you get an OK then you can do the next step.
The timestamp is produced by the `duck.sh` script. The [expected responses from the DuckDNS service](https://www.duckdns.org/spec.jsp) are:
84
+
85
+
* "OK" - indicating success; or
86
+
* "KO" - indicating failure.
87
+
88
+
Check your work if you get "KO" or any other errors.
89
+
90
+
Next, assuming `dig` is installed on your Raspberry Pi (`sudo apt install dnsutils`), you can test propagation by sending a directed query to a DuckDNS name server. For example, assuming the domain name you registered was `downunda.duckdns.org`, you would query like this:
The expected result is the IP address of your router's WAN interface. It is a good idea to confirm that it is the same as you get from [whatismyipaddress.com](https://whatismyipaddress.com).
97
+
98
+
A null result indicates failure so check your work.
99
+
100
+
Remember, the Domain Name System is a *distributed* database. It takes *time* for changes to propagate. The response you get from directing a query to ns1.duckdns.org may not be the same as the response you get from any other DNS server. You often have to wait until cached records expire and a recursive query reaches the authoritative DuckDNS name-servers.
101
+
102
+
#### <aname="duckDNSauto"> Running the DuckDNS client automatically </a>
103
+
104
+
The recommended arrangement for keeping your Dynamic DNS service up-to-date is to invoke `duck.sh` from `cron` at five minute intervals.
105
+
106
+
If you are new to `cron`, see these guides for more information about setting up and editing your `crontab`:
The first three lines construct the runtime environment correctly and should be at the start of any `crontab`.
122
+
123
+
The last line means "run duck.sh every five minutes". See [crontab.guru](https://crontab.guru/#*/5_*_*_*_*) if you want to understand the syntax of the last line.
124
+
125
+
When launched in the background by `cron`, the script supplied with IOTstack adds a random delay of up to one minute to try to reduce the "hammering effect" of a large number of users updating DuckDNS simultaneously.
126
+
127
+
Standard output and standard error are redirected to `/dev/null` which is appropriate in this instance. When DuckDNS is working correctly (which is most of the time), the only output from the `curl` command is "OK". Logging that every five minutes would add wear and tear to SD cards for no real benefit.
128
+
129
+
If you suspect DuckDNS is misbehaving, you can run the `duck.sh` command from a terminal session, in which case you will see all the `curl` output in the terminal window.
130
+
131
+
If you wish to keep a log of `duck.sh` activity, the following will get the job done:
132
+
133
+
1. Make a directory to hold log files:
134
+
135
+
```bash
136
+
$ mkdir -p ~/Logs
137
+
```
138
+
139
+
2. Edit the last line of the `crontab` like this:
140
+
141
+
```bash
142
+
*/5 * * * * duck.sh >>./Logs/duck.log 2>&1
143
+
```
144
+
145
+
Remember to prune the log from time to time. The generally-accepted approach is:
146
+
147
+
```
148
+
$ cat /dev/null >~/Logs/duck.log
149
+
```
150
+
151
+
## Virtual Private Network
152
+
153
+
### WireGuard
154
+
155
+
WireGuard is supplied as part of IOTstack. See [WireGuard documentation](https://sensorsiot.github.io/IOTstack/Containers/WireGuard.html).
156
+
157
+
### PiVPN
23
158
24
-
## PiVPN
25
159
pimylifeup.com has an excellent tutorial on how to install [PiVPN](https://pimylifeup.com/raspberry-pi-vpn-server/)
26
160
27
161
In point 17 and 18 they mention using noip for their dynamic DNS. Here you can use the DuckDNS address if you created one.
@@ -32,13 +166,15 @@ Once you activate your VPN (from your phone/laptop/work computer) you will effec
32
166
33
167
I personally use the VPN any time I'm on public wifi, all your traffic is secure.
34
168
35
-
## Zerotier
169
+
### Zerotier
170
+
36
171
https://www.zerotier.com/
37
172
38
173
Zerotier is an alternative to PiVPN that doesn't require port forwarding on your router. It does however require registering for their free tier service [here](https://my.zerotier.com/login).
39
174
40
175
Kevin Zhang has written a how to guide [here](https://iamkelv.in/blog/2017/06/zerotier.html). Just note that the install link is outdated and should be:
0 commit comments