Mnyb wrote:
> Plan is an ethernet conected player to not abuse wifi to much . And
> ofcourse some Xmas fun building this projekt
I use a few Pis (2 or 3) as openvpn tunnel endpoints in bridge mode. OS
is raspbian lite. Over domestic internet links I consider Pi can run an
OVPN tunnel transparently: at full tilt (1 core loaded 100%) you can
move 30-35 Mbps over the encrypted tunnel, and that is more than the
typical upload bandwidth of a domestic internet connection.
Reliability/robustness are very good if you don't mess with the node too
much (lock the Pi in a closet otherwise someone will inadvertently shut
down power or data connections...)
I always use OVPN in bridge mode, "old style bridging" they call it
these days, ie a simple p2p OVPN config, and bridging + DHCP and other
services handled outside openvpn.
I don't use it regularly for my SBs, but I have tested it with remote
SB3s and menu control and discovery are perfectly fine. YMMV but the
tunnel should be ok for MP3s, and a bit slow for raw or hi-res FLAC
files. But then of course you can add a local LMS server and some sort
of mirroring service if you'd like...
I thought -even began- of writing some how-to for SB users who want to
bring a Squeezebox to the cabin in summer and would like to keep using
their server and collection at home. There is a lot of details to
consider so I did not go through with it.
But here is the skinny on the architecture for a Pi as OpenVPN endpoint
in bridged mode, feel free to ask:
Code:
--------------------
LAN
------------------
|eth0 [DHCP] (†)|
------------------
LAN<->VPN routing + iptables masq./filtering (*)
Your options for VPN clients:
1. default gw through eth0 ("split vpn") or,
2. default gw through the tunnel ("full vpn" aka "hide my ass") --useless and
costly IMHO.
VPN
--------------------------
|br0 (fixed IP *)|
| wlan0|
| tap0|
| usb0 (†)|
| ebtables filtering (+)|
--------------------------
--------------------
Ethernet clients on the VPN network with Pi (†) :
- If the LAN router groks VLANs, then use eth0.1234 as the LAN
interface, and bridge the tagless eth0 to br0 to allow VLAN-unaware
clients to participate in the VPN. A dumb switch is needed between Pi
and router.
- If the LAN router doesn't handle VLANs, add an interface like an usb
ethernet adapter (usb0) and dedicate that to VPN ethernet client(s).
(FYI, a giga ether usb adapter has a throughput of ~200Mbps on Pi 3)
L2 or L3 bridge (*) : L2 provides isolation, it is useful in case LAN
and VPN networks use the same IP range. Aside that unfortunate and
easily solved case (you need to administer the VPN network range
anyways, ie define IP ranges per site), L3 is more flexible IMHO.
- If you give the bridge an IP address on the VPN network, you can
host services on Pi, eg ssh, web server, LMS. Requires routing on the
Pi, probably masquerading and possibly iptables filtering.
- Don't give the bridge an address and you get an L2 bridge. Dnsmasq,
hostapd or openvpn don't mind (they know how to listen by interface)
but other service might. With this setup no routing is necessary
-possible- between eth0 and br0 but VPN clients can't use the local
default gw, so clients are in "hide my ass" mode and depending on
their behavior this can load the VPN tunnel needlessly.
Local NTP service: a good clock is highly recommended. Won't help audio
quality any ;) but the Pi lacks an RTC clock and certificates used for
authentication in the VPN might not validate until the machine has
acquired an accurate date (eg 1 jan 1970 -> invalid certificate: issue
date in the future)
Local DNS cache/resolver listening on br0: dnsmasq. Always useful unless
the admin at the remote site is a security freak ;)
Option: Local dhcp service on br0 for VPN clients this side of the
bridge. The need for it depends on the reliability+latency of the link
to the remote site hosting services. Creates a second administration
point on the network so it makes more sense to give the Pi an IP on the
VPN network (*) to be able to access it from either site.
Requirements/strong reco:
a
- filtering DHCP leases sent by the server at the remote end of the
VPN network (+)
- reserving a small IP range for clients at local site (eg .150 to
.160)
- dnsmasq can "no-dhcp" on specific interfaces, and deliver info
tailored per client (default gw, static routes, ...)
Option: Hostapd running in bridge mode and listening to wlan0. To make
your iPeng controller happy, and generally have wireless clients
participate in the VPN network. Pi 3 can handle 25 clients max,
practically 5-10 clients are fine IMHO. Using the default local gw is
probably a good idea if there are many wireless clients.
I think that's about it. HTH.
3 SB 3 Libratone Loop, Zipp Mini iPeng (iPhone + iPad) LMS 7.9
(linux) with plugins: CD Player, WaveInput, Triode's BBC iPlayer by bpa
IRBlaster by Gwendesign (Felix) Server Power Control by Gordon
Harris Smart Mix, Music Walk With Me, What Was That Tune? by Michael
Herger PowerSave by Jason Holtzapple Song Info, Song Lyrics by
Erland Isaksson AirPlay Bridge by philippe_44 WeatherTime by Martin
Rehfeld Auto Dim Display, SaverSwitcher, ContextMenu by Peter Watkins.
------------------------------------------------------------------------
epoch1970's Profile: http://forums.slimdevices.com/member.php?userid=16711
View this thread: http://forums.slimdevices.com/showthread.php?t=106413
_______________________________________________
plugins mailing list
plugins@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/plugins
