Hi, I think many of you are aware that I, amongst others on this list, volunteer at the Wimborne Model Town. Back in 2016 & 2017, I installed a Webserver on a Raspberry Pi connected to a private network so that Visitors could access an Audio Guide and Kiddies Quiz. To cut a long story short we needed to link this network to the big wide (wild) world so that Android phones wouldn't refuse to connect. To prevent Visitors from slurping the WMTs limited download quota I used nodogsplash to achieve this. (There several discussions about how we could achieve this at the time, but nodogsplash proved to be the best approach. (I reversed the normal functionality so that once Visitors were authorised, I blocked Internet access instead of enabling it.))
In the present situation, the WMT is closed but there will be limited opening in July. Even then though, some of us are shielding so are unlikely to be able to go in to the site. It has been decided therefore that we should install a VPN Server on the Webserver Pi and I've just spent a few days trying to get it to work with a simulated network here at home. There is a detailed description of what we are trying to do and what I have done at: https://wmtprojectsforum.altervista.org/forum/viewforum.php?f=38 To cut another long story short, the VPN Server and nodogsplash don't co-exist too well. I posted a query on the Raspberry Pi Forums and a very helpful user there installed the two packages on his own Pi. However, I feel that his setup isn't quite what we have at WMT and in any case, I've been struggling to restore the nodogsplash functionality. I may have to start again with a clean installation of Raspberry Pi OS. One thing he did suggest was the use of macvlan interfaces: <Quote> Another option could be to use macvlan interfaces. Very much like a extra physical interfaces, does not require special router support, but cannot be added to a bridge. (you can however build a macvlan interface off a bridge interface.) root@sun:~# for i in 0 1; do ip l add mcv$i address b8:27:eb:0$i:1$i:2$i link eth0 type macvlan mode private; done root@sun:~# ip r default via 172.17.0.1 dev eth0 src 172.17.255.10 metric 202 default via 172.17.0.1 dev mcv0 proto dhcp src 172.17.255.241 metric 205 default via 172.17.0.1 dev mcv1 proto dhcp src 172.17.255.92 metric 206 10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1 169.254.0.0/16 dev eth0.314 scope link src 169.254.94.218 metric 204 172.17.0.0/16 dev eth0 proto dhcp scope link src 172.17.255.10 metric 202 172.17.0.0/16 dev mcv0 proto dhcp scope link src 172.17.255.241 metric 205 172.17.0.0/16 dev mcv1 proto dhcp scope link src 172.17.255.92 metric 206 </Quote> Before I try this out, I'm going to need to understand more about what is going on. In particular, what does his line "but cannot be added to a bridge. (you can however build a macvlan interface off a bridge interface.)" mean? The bottom line: Can macvlan interfaces be used in this instance? -- Terry Coles -- Next meeting: Online, Jitsi, Tuesday, 2020-07-07 20:00 Check to whom you are replying Meetings, mailing list, IRC, ... http://dorset.lug.org.uk New thread, don't hijack: mailto:dorset@mailman.lug.org.uk
