家庭网络搭建_家庭网络

家庭网络搭建

I spent some time overhauling my home network. There was no way I was going to settle for the default WiFi access point you get from an internet service provider. (Verizon in my case) My house is big enough to need more than one access point anyway and I run some local servers so I needed a bit more flexibility. Additionally, I’ve started to deploy some IoT devices, mostly related to home automation, so I wanted some isolation from my user network should a device spiral out of control. (flooding the network / general security issues) All of these things and the fact that we moved to a new house acted as my excuse to entirely rethink my home network. This post covers where I’ am now and attempts to rationalize to myself the unnecessarily large mindshare I’ve devoted. Don’t blame me if I send you off on a similarly unreasonable direction!

我花了一些时间检查我的家庭网络。 我没有办法解决从互联网服务提供商那里获得的默认WiFi接入点。 (以Verizon为例)，我的房子足够大，无论如何都需要一个以上的接入点，而且我要运行一些本地服务器，因此我需要更大的灵活性。 此外，我已经开始部署一些IoT设备，大多数与家庭自动化有关，因此如果设备失控，我希望与用户网络隔离。 (淹没网络/一般安全问题)所有这些事情以及我们搬到新家的事实，成为我重新思考家庭网络的借口。 这篇文章涵盖了我现在所处的位置，并试图使我自己投入的不必要的大量心智合理化。 如果我将您送往同样不合理的方向，请不要怪我！

The goal: reliable, flexible and (reasonably) cost effective Internet infrastructure. In my experience, however, “because I’m already working on it” ended up to be rationale enough to make it a bit more feature-full. You’ll see.

目标：可靠，灵活和(合理地)具有成本效益的Internet基础结构。 但是，根据我的经验，“因为我已经在研究它”最终足以使它具有更多功能。 你会看到的。

硬体 (The Hardware)

WiFi is the dead-center of everything in a network these days, be it home or enterprise. The choice here needs to be very solid and overbuilt enough to support future realities. I think you can take the number of expected WiFi clients and multiply it by 10, for example, because IoT is invading. Realizing that every light switch and even many power receptacles are becoming WiFi clients, you can see where 10x might be conservative. Therefore something more enterprise oriented is where I started.

无论是家庭还是企业，WiFi如今已成为网络中所有事物的中心。 这里的选择必须非常扎实，并且要充分构建以支持未来的现实。 我认为您可以将预期的WiFi客户端数量乘以10，例如，因为物联网正在入侵。 意识到每个电灯开关甚至许多电源插座都已成为WiFi客户端，您可以看到10倍的保守度。 因此，我更着眼于面向企业。

As you move into enterprise class, you start to get the unbundling of features. For example, the home WiFi access point is typically much more than that. It is a WiFi access point, a DHCP server, a NAT device and usually a switch and some kind of terminal adapter all rolled up into one device. So it is no surprise that a device like that might not have the rock solid quality you might need in all areas — compromises have been made. So as you move up and those parts get unbundled, you can start building out only what you actually need and at whatever level of quality your situation and resources demand.

当您进入企业级时，就开始获得功能的捆绑。 例如，家庭WiFi接入点通常远不止于此。 它是一个WiFi接入点，一个DHCP服务器，一个NAT设备，通常是一个交换机和某种类型的终端适配器，它们都汇总为一个设备。 因此，这样的设备可能无法在所有领域都达到您所需要的坚如磐石的质量，这已经不足为奇了。 因此，当您向上移动而这些部件不捆绑在一起时，您可以只开始构建实际需要的内容，并满足您的情况和资源需求的质量级别。

UniFi nanoHD WiFi Access Point — $160

UniFi nanoHD WiFi接入点— 160美元

I landed on Ubiquiti’s UniFi nanoHD WiFi access points for the center of the network. Ubiquity is one of those companies that release ridiculously good products that lure you in. If all you want is an access point, this will do it. If you want to get a few and have them work together, this will do it. If you want to centrally manage them, some freely downloadable software on a Linux instance will do it. If you want a complete solution that runs that software for you on a dedicated device, you can do that too. If you want to integrate it with an entire enterprise including switches, routers, security cameras, etc. this will do it. You’ll see Ubiquity hardware popping up all over the place in this project. That’s not because I looked there first. I started with a bunch of requirements and continually ended up with a Ubiquity product. Go figure. No, I’m not being paid to say this — they just win on delivering exactly what I needed.

我登陆了Ubiquiti的UniFi nanoHD WiFi接入点，成为网络的中心。 Ubiquity是发布引人入胜的可笑产品的公司之一。如果您想要的只是接入点，那就可以做到。 如果您想得到一些并让他们一起工作，那就可以了。 如果要集中管理它们，可以在Linux实例上使用一些可免费下载的软件。 如果您想要一个在专用设备上为您运行该软件的完整解决方案，您也可以这样做。 如果您要将其与包括交换机，路由器，安全摄像机等的整个企业集成在一起，则可以这样做。 您会看到Ubiquity硬件在此项目的各处弹出。 那不是因为我先看那里。 我从一堆需求开始，然后一直以Ubiquity产品告终。 去搞清楚。 不，我没有得到这么多的报酬–他们只是在提供我所需要的东西上获胜。

The hardware choice here has to be extremely reliable. I also like “minimal” in the sense that the hardware does exactly what it needs to do and nothing else. Ubiquity “gets” that. In this case, all I wanted was an access point that could take several VLANs and vend them out to clients as different SSIDs. (a main and a guest network, for example) I also wanted seamless handoff of clients as they move around. The nanoHD does this exceptionally well. They also support 200 concurrent users which addresses my expandability woes. I got two of these which covers our needs fairly well. Added bonus, they are powered over Ethernet via standard PoE. (as is much of the Ubiquity product line)

这里的硬件选择必须非常可靠。 我也喜欢“最小”，因为硬件完全可以完成其所需的工作，而没有其他任何事情。 无处不在的“得到”。 在这种情况下，我所需要的只是一个接入点，它可以采用多个VLAN，并将它们作为不同的SSID出售给客户端。 (例如，一个主网络和一个来宾网络)我还希望在客户四处移动时进行无缝切换。 nanoHD的出色表现。 他们还支持200个并发用户，这解决了我的可扩展性问题。 我有两个可以很好地满足我们的需求。 此外，它们还通过标准PoE通过以太网供电。 (和Ubiquity产品系列一样)

Cisco SG300 Managed Switch — $200

Cisco SG300网管型交换机— 200美元

A bit of a confession here, I have ~20 years experience with Cisco’s “ios” from my router programming days so the fact that Cisco’s small business managed switches run it gave this hardware an advantage. I might investigate further if I didn’t have this background to fall back on. If you don’t already know it, “ios” isn’t straightforward. Back in the day, these Cisco routers cost several thousand dollars each so having those capabilities (mostly just VLAN trunking and link aggregation) in a $350 device with two SFP ports was hard to pass up.

在这里，我有点自白，在路由器编程的那一天，我在Cisco的“ ios”方面已有大约20年的经验，因此Cisco的小型企业管理型交换机运行它的事实为该硬件带来了优势。 如果没有这个背景，我可能会做进一步调查。 如果您还不知道，那么“ ios”就不是那么简单。 过去，这些思科路由器每台售价数千美元，因此在具有两个SFP端口的价格为350美元的设备中具有这些功能(主要是VLAN中继和链路聚合)很难被淘汰。

We have 4 floors (basement, main floor, upstairs and a newly finished attic) so there is either a 24 port (pictured above) or a 10 port version of the Cisco SG300 on each floor. They are arranged in a star configuration with the 24 port in the basement at the center. Each floor is connected through a trunk (either Ethernet or fiber) which carries all VLANs. Several ports are nailed as trunk ports for devices like the nanoHD access points and some linux machines which can take several networks through one physical interface.

我们共有4层(地下室，主层，楼上和新近建成的阁楼)，因此每层都有Cisco SG300的24端口(如上图)或10端口版本。 它们以星形配置排列，中心地下室有24个端口。 每个楼层通过承载所有VLAN的中继线(以太网或光纤)连接。 几个端口被钉为设备的中继端口，例如nanoHD接入点和一些Linux机器，这些设备可以通过一个物理接口连接多个网络。

Protectli Vault 2 Port Mini PC — $200

Protectli Vault 2端口迷你电脑-200美元

This is the real heart of the network from a packet perspective. The brand is unimportant. What I wanted was a solid state device (no moving parts such as a fan) that had at least two physical Ethernet ports and consumed minimal power. (~11 watts) I also needed to be able to torch whatever software was on it and replace it with a clean Linux install. They sell versions with better processors and more ports which I may consider if performance becomes an issue. (hasn’t happened yet)

从数据包的角度来看，这是网络的真正核心。 该品牌并不重要。 我想要的是一种固态设备(没有风扇等活动部件)，该固态设备至少具有两个物理以太网端口，并且功耗最低。 (〜11瓦)我还需要能够割炬其中的任何软件，并用干净的Linux安装取代它。 他们出售具有更好处理器和更多端口的版本，如果性能成为问题，我可能会考虑。 (尚未发生)

When I say this thing is the center of the packet network, I mean the Internet is plugged into the WAN port and all of the internal networks flow through the LAN port via VLANs. (it is a trunk port) All communication between LANs happens within this device so it has to have at least enough processing power to saturate a Gigabit Ethernet port or two. In practice, this thing usually easily bests purpose built “WiFi routers” especially when transferring small packets. As it happens, very little traffic actually crosses VLAN boundaries so the workload is currently very minimal.

当我说这件事是分组网络的中心时，是指将Internet插入WAN端口，并且所有内部网络都通过VLAN通过LAN端口。 (这是中继端口)LAN之间的所有通信都在此设备内进行，因此它必须至少具有足够的处理能力才能使一个或两个千兆位以太网端口饱和。 实际上，这东西通常很容易击败专用的“ WiFi路由器”，尤其是在传输小数据包时。 碰巧的是，实际上很少有流量越过VLAN边界，因此当前的工作量很小。

This device also does NAT, DHCP and DNS for all networks as well as act as a VPN concentrator. (Wireguard — more on that later) The only thing amongst these that could push the processor is the crypto for the VPN traffic. This is an area of active exploration right now but hasn’t yet posed a performance issue.

该设备还为所有网络执行NAT，DHCP和DNS，并充当VPN集中器。 (Wireguard –稍后会详细介绍)其中唯一可以推动处理器的是VPN流量的加密。 目前，这是一个活跃的探索领域，但尚未引起性能问题。

Ubiquiti UniFi G3 Bullet Camera — $135

Ubiquiti UniFi G3子弹头相机— 135美元

Cameras are controversial. There is obvious utility in being able to see if you have packages at your doorstep but you can easily get into ethical quandaries pointing them where society quite rightly deems unacceptable. The way I have chosen to navigate this is to have no cameras indoors and keep all outdoor cameras pointed only at our property. (this usually means pointing them down from higher places)

相机是有争议的。 能够看到您家门口是否有包裹是很明显的实用工具，但是您可以轻松地进入道德困境，将它们指向社会完全认为不可接受的地方。 我选择的导航方式是在室内没有摄像头，并使所有室外摄像头仅对准我们的住所。 (这通常意味着将他们从较高的地方指向下方)

All I really want from a camera is a standard RTMP H.264 stream. I specifically don’t want a cloud service that sends streams off premisis. Cameras also need to be wired if you want them to be reliable in severe environments. They need power too so because you have to run wire anyway you might as well run Ethernet with PoE. Again, the UniFi devices tick all these boxes. I think 1080p cameras are good enough but if you want 4K, look at the G4 Pro.

我真正想要的是摄像机的标准RTMP H.264流。 我特别不想让云服务从预置中发送流。 如果您希望摄像机在恶劣的环境中可靠，则还需要对其进行接线。 它们也需要电源，因为您无论如何都必须进行布线，因此最好还是通过PoE运行以太网。 同样，UniFi设备在所有这些框中打勾。 我认为1080p相机已经足够了，但是如果您想要4K，请看看G4 Pro。

I have stories about wiring these things. Let’s just say I bought a 0.5 meter drill bit and found myself at the top of a ladder poking holes through to the attic of my house and leave it at that. Actually, no, more color is required. One adventure involved mistakenly punching a hole through the ceiling and wall of my office from the attic. (my wife is currently unaware of this) A bit of spackle and a newly painted wall later and you can’t even tell. I digress.

我有关于接线这些东西的故事。 假设我买了一个0.5米的钻头，发现自己在梯子的顶端，钻了洞到我家的阁楼，然后放在那里。 实际上，不需要，需要更多的颜色。 一次冒险涉及错误地在阁楼的办公室天花板和墙壁上打了一个洞。 (我的妻子目前不知道这一点)稍稍散布些斑点，然后重新粉刷一面墙，您甚至无法分辨。 我离题了。

Ubiquiti F-POE Fiber — $40

Ubiquiti F-POE光纤— 40美元

While we are on the topic of wired cameras outdoors and harsh environments, there is a little wrinkle worth considering. For cameras not on the house, (cameras on poles) I wanted some lightning protection so I backhaul the data via fiber with the above Ubiquiti F-POE Fiber device. Here’s an inside view which is more illustrative of what this does.

虽然我们在户外和恶劣环境下使用有线摄像机，但仍有一些值得考虑的问题。 对于不在屋子里的摄像机(两极摄像机)，我需要防雷保护，因此我要使用上面的Ubiquiti F-POE光纤设备通过光纤回传数据。 这是一个内部视图，可以更清楚地说明其功能。

Inside the Ubiquiti F-POE Fiber

在Ubiquiti F-POE光纤内部

On the far right you have PoE Ethernet out and on the far left you have an SFP port into which you probably put a fiber module. The ports in the middle power the F-POE via either 24V DC over copper (the green terminal block) or PoE. (the other Ethernet port with no networking capability)

最右边是PoE以太网，最左边是SFP端口，您可能在其中插入了光纤模块。 中间的端口通过铜缆上的24V DC(绿色接线盒)或PoE为F-POE供电。 (另一个没有网络功能的以太网端口)

I trench 24V DC over copper together with armored direct burial LC fiber. Up on the pole, the camera plugs into the F-POE via a short Ethernet patch cable and the backhaul to the house goes over the fiber. Inside the house, the 24V DC power supply is physically very distant from my networking equipment, giving me the desired isolation.

我将24V DC与铠装直接埋藏LC光纤一起开挖到铜上。 在极点上，摄像机通过一条短的以太网跳线插入F-POE，并且房屋的回程通过光纤。 在房子内部，24V DC电源与我的网络设备物理距离很远，从而为我提供了所需的隔离。

1 Gigabit SFP Fiber Modules - UF-MM-1G — $17

1个千兆SFP光纤模块-UF-MM-1G — $ 17

The pictured SFP modules are multi-mode. Not that I need it but the ones I use outside are single-mode. This has more to do with the fact that the direct burial fiber I was able to get delivered in a reasonable timeframe happened to be single-mode, not because I needed to trench several kilometers! The fiber within the house though (connecting the attic switch to the basement switch) is multi-mode.

如图所示的SFP模块是多模式的。 不是我需要它，而是我在外面使用的是单模的。 这更多与以下事实有关：我能够在合理的时间内交付的直接埋葬光纤恰好是单模的，而不是因为我需要挖开几公里！ 尽管房屋内的光纤(将阁楼交换机连接到地下室交换机)是多模的。

While I was in the midst of this project, we had a bathroom added to some unfinished space in our attic. This gave me all the excuse I needed to run fiber from the basement switch to a new rack installation in the attic. I ran two pair of fiber because why not? They operate in a link aggregation group so should one fiber fail, there will be no interruption in service. Practically though, if someone takes a saw to the wall in the right place, both pair of fibers are going to be cut. I just did it for the fun of it, ok?!

在我进行此项目的过程中，我们在阁楼中的一些未完成的空间中增加了一个浴室。 这为我提供了从地下室交换机到阁楼上新机架安装光纤所需的所有借口。 我跑了两对光纤，因为为什么不呢？ 它们在链路聚合组中运行，因此如果一根光纤出现故障，服务将不会中断。 但是实际上，如果有人在正确的地方用锯子锯墙壁，那么这两对纤维都将被切断。 我只是为了好玩而已，好吗？

Mac Mini and Intel NUC

Mac Mini和Intel NUC

“Servers” on my network all run Linux and are selected for their power consumption to performance ratio. (loud fans are a detractor as well) I’ve settled on a mix of Mac Minis running Linux and Intel NUCs in various flavors although this is somewhat out of scope for this writeup. I run 4 or 5 of these.

我网络上的“服务器”全部运行Linux，并选择了它们的功耗与性能之比。 (大声喧fans也是反对者)我选择了混合运行Linux的Mac Mini和各种口味的Intel NUC，尽管这超出了本文的范围。 我运行其中的4或5。

CyberPower OR700LCDRM1U — $216

Cyber​​Power OR700LCDRM1U — 216美元

I don’t yet have house-wide UPS (waiting on some Powerwalls) so I had to have something to keep the core functionality operational. Thanks to a relatively low power footprint, one of these at each switch effectivly keeps me going indefinately. I don’t love them but they work for now.

我还没有全屋式UPS(正在等待某些Powerwall)，所以我必须要有一些东西来保持核心功能的正常运行。 由于功耗相对较低，因此每个开关中的其中一个有效地使我保持不确定的状态。 我不爱他们，但他们现在工作了。

Neewer 12U Rack — $120

Neewer 12U机架-$ 120

I hate that I have enough stuff to warrant a rack but these are the realities of my home network. What doesn’t support rack mount sits on rack shelves. I have this rack in the basement and a 9U one in the attic. The main floor and second floor remain un-racked at the moment.

我讨厌我有足够的东西来保证机架，但这是我家庭网络的现实。 不支持机架安装的设备位于机架架子上。 我在地下室有这个机架，在阁楼上有一个9U机架。 目前，主层和第二层保持原样。

Leviton DH1KD-1BZ 1000W Decora Smart Dimmer with HomeKit — $50

带有HomeKit的Leviton DH1KD-1BZ 1000W Decora智能调光器— 50美元

I picked HomeKit early on. It was mostly driven by the desire to have everything in the native Home app on my phone. Having a zillion vendor-specific control apps with disaster level user experiences was a non-starter. It was also driven by a general desire for a privacy sensitive alternative although no company has a sterling record on this. (Google Home seems Ok but Amazon represents an abject disaster in this regard) I can’t wait for an open unified standard here. (that’s in the works)

我很早就选择了HomeKit。 主要原因是希望将所有内容都存储在手机上的本地Home应用程序中。 拥有大量具有灾难级别用户体验的特定于供应商的控制应用程序是初学者。 尽管没有一家公司对此有任何记录，但人们普遍希望获得对隐私敏感的替代方案。 (Google Home似乎还可以，但是Amazon在这方面代表了一场灾难。)我等不及这里开放的统一标准了。 (正在制作中)

When we bought our house it had Lutron dimmers everywhere. I looked at the “smart” Lutron devices but they didn’t work like normal switches for the uninitiated user. I didn’t want to have to teach everyone that enters the house how to turn the lights on. There’s like 4 buttons on a Lutron smart switch - I still don’t know what they all do. Leviton was literally the only reasonable option. They had just come out with their HomeKit dimmers and switches when I overhauled the place and in practice they are fairly good. I do have one or two that randomly loose connectivity (it is as if the software locked up although they are still pingable) but the fix is a simple 7 second reset. That’s about a once every 3 months occurrence. I’m hoping for a firmware update but not crossing my fingers.

当我们买房子时，到处都有路创调光器。 我查看了“智能” Lutron设备，但对于未启动的用户而言，它们不像普通开关那样工作。 我不想教每个进入屋子的人如何打开灯。 路创智能开关上有大约4个按钮-我仍然不知道它们的作用。 列维顿实际上是唯一合理的选择。 当我对这个地方进行大修时，他们才带上HomeKit调光器和开关，实际上它们还算不错。 我确实有一个或两个随机松动的连接(尽管软件仍然可以ping通，但好像该软件被锁定了)，但修复方法是简单的7秒钟重置。 这大约每3个月发生一次。 我希望进行固件更新，但不要指责。

iDevices Wall Outlet — $93

iDevices墙上插座-93美元

I have several things that ideally are controllable (lamps / Christmas tree) but I don’t like the look of “wall wart” adapters. Leviton doesn’t (yet?) have a HomeKit wall outlet so I opted for the (relatively far more expensive) iDevices Wall Outlet. I’d rather not have the nightlight (it always defaults to “on”) but this gets the job done. It does have a handy pull out that shows the HomeKit code without having to unscrew the wall plate though. (taking whatever wins I can)

我有几件理想的东西是可以控制的(灯/圣诞树)，但我不喜欢“壁疣”适配器的外观。 Leviton还没有HomeKit壁装电源插座，因此我选择了(相对昂贵得多)iDevices壁装电源插座。 我宁愿没有夜灯(它始终默认为“开”)，但这可以完成工作。 它确实具有方便的拉出功能，可显示HomeKit代码，而无需拧开墙板。 (尽我所能赢得胜利)

Apple HomePod — $300

Apple HomePod — 300美元

Amazon was at least a lightyear ahead when they released the Echo but after having tested it a bit I disqualified it on privacy grounds. I’d rather pay up front so as not to require the device / service be subsidized by the sale of my data. Apple has by far the best (but not perfect) track record on privacy so although the recognition isn’t nearly as good as other alternatives, I standardized on HomePods. The sound quality, however, is off the charts on these things!

亚马逊发布Echo至少比我们快了一年，但经过一番测试之后，我出于隐私理由取消了参赛资格。 我宁愿预先付款，以免设备/服务因销售我的数据而得到补贴。 到目前为止，苹果公司在隐私方面的记录是最好的(但不是完美的)，因此尽管识别度不及其他选择，但我在HomePods上进行了标准化。 但是，这些东西的音质都超出了图表！

AppleTv — $150

AppleTv — 150美元

While the remote is touchy, (to say the least) the AppleTv is a very good H.264 player. It also happens to hub the HomeKit devices. (as do the HomePods) This device straddles networks though. I think of it as an IoT device in its HomeKit hub duties but it clearly needs to be accessible on user networks for people to stream to it. (screencasts, playing music, etc.) An interesting solution to this dilemma is proposed below.

虽然遥控器很麻烦，但(至少可以说)AppleTv是一个非常好的H.264播放器。 它也恰巧是HomeKit设备的集线器。 (如HomePods一样)，该设备跨网络。 我将其视为其HomeKit集线器职责中的IoT设备，但显然需要在用户网络上对其进行访问，以便人们对其进行流式处理。 (截屏，播放音乐等)下面提出了一个解决此难题的有趣方法。

’90s era Bose Lifestyle Home Sound System — $Free with purchase of 1 house

90年代Bose Lifestyle家庭音响系统-购买1套房子免费

When we bought our house, it came with a Bose Lifestyle system with speakers built into the ceilings throughout the house and outside. It sounds awesome but has a wide array of input options only the late ’90s could envy. Thankfully though, it sports an AUX input. I splurged $35 on a Raspberry Pi and added this HiFiBerry:

当我们购买房屋时，它配备了Bose Lifestyle系统，整个房屋内外的天花板上都装有扬声器。 听起来很棒，但是有很多输入选项，只有90年代后期才能羡慕。 值得庆幸的是，它支持AUX输入。 我在Raspberry Pi上花了35美元，然后添加了这个HiFiBerry：

HiFiBerry DAC+ RCA Version — $50

HiFiBerry DAC + RCA版本-$ 50

This provides a high quality RCA output from the Raspberry Pi rather than the noisy onboard headphone jack they snuck in while keeping it under $35. I run shairport on the Pi which at this point is an abandoned codebase but it makes your Linux machine show up as an AirPlay device on the network. Here’s how it shows up on my iPhone:

这提供了Raspberry Pi的高质量RCA输出，而不是他们偷听的嘈杂的板载耳机插Kong，同时将其保持在35美元以下。 我在Pi上运行了shairport ，这是一个废弃的代码库，但是它使您的Linux计算机在网络上显示为AirPlay设备。 这是它在我的iPhone上的显示方式：

So playing to “House” makes it go through the Bose house system throughout the house. Playing some Bill Evans through my iPhone this way on the patio speakers for dinner under the stars is a highlight.

因此，在“ House”游戏中，它贯穿整个Bose房屋系统。 这样一来，我的iPhone上的一些比尔·埃文斯(Bill Evans)在天井下的露台扬声器上吃晚饭是一个亮点。

I also wanted another music player device that was ultra simple to use so I soldered up this ghetto rig on top of another Raspberry Pi with a HiFiBerry DAC.

我还想要另一台使用起来非常简单的音乐播放器设备，因此我将这个贫民窟装备焊接在了另一个带有HiFiBerry DAC的Raspberry Pi上。

“Musicbox” — $Priceless

“ Musicbox”-$ Priceless

Basically, you press a button and it plays a preset playlist. Press the red button and it stops. That’s it. I just wanted to be able to mindlessly mash a button and get music. I built it just before becoming a parent because I knew I’d need it and I’d never have the time to build something like this again!

基本上，您按下一个按钮，它将播放一个预设的播放列表。 按下红色按钮，它停止。 而已。 我只是想能够不加思索地捣碎按钮并获取音乐。 我在成为父母之前就建造了它，因为我知道我需要它，而且我再也没有时间再建造这样的东西了！

The breadboard is your basic GPIO button board but it has to convert 5V down to 3.3V because the HiFiBerry uses all the 3.3V pins. (they don’t get passed through) I also did a little debouncing and some conditioning with resistors. Basic stuff but it has worked reliably for many years.

面包板是您的基本GPIO按钮板，但由于HiFiBerry使用所有3.3V引脚，因此必须将5V转换为3.3V。 (它们没有通过)我还做了一些反跳操作，并使用电阻进行了一些调节。 基本的东西，但它已经可靠地工作了很多年。

Apple AirPort Express with AirTunes — $20 on eBay

带AirTunes的Apple AirPort Express —在eBay上为20美元

Another way to do the shairport thing is to just get an old AirPort Express which includes a high quality analog output. The downside on this is there is no way (as far as I’ve been able to tell) to access AirPlay through the Ethernet jack. You have to connect the WiFi radio to your access point before the AirTunes device (called “Attic” in my case) will show up. Not ideal but very cost effective and far less fiddly than shairport.

另一种方式做shairport事情是刚刚得到一个老的AirPort Express，其中包括高品质的模拟输出。 不利的一面是(据我所知)无法通过以太网插Kong访问AirPlay。 您必须先将WiFi无线电连接到接入点，然后AirTunes设备(在我的情况下称为“ Attic”)才会出现。 这不是理想的方法，但是非常具有成本效益，而且远不如shairport 。

Lepai LP1601S 200W Class D Stereo Amplifier — $120

Lepai LP1601S 200W D类立体声放大器— 120美元

I wanted a descent amplifier for the attic. I had the chance to do some installation as we put the bathroom in so in went this and the below ceiling speakers. It sounds great!

我想要阁楼的下降放大器。 当我们将浴室放进去时，我有机会进行一些安装，然后安装了这个和下面的吊顶扬声器。 听起来不错！

Polk Audio RC80i — $150

Polk Audio RC80i-150美元

There are any number of other hardware considerations but they are more mundane in my opinion. I’m continually upgrading and augmenting as well so over time I might add more to this post.

还有许多其他硬件考虑因素，但我认为它们更为平凡。 我也在不断地升级和扩充，所以随着时间的流逝，我可能会在这篇文章中添加更多内容。

I have pictures of how the above looks when installed on this Twitter thread.

我有安装在此Twitter线程上时上述外观的图片。

软体 (The Software)

Now on to the fun part. (Ok, the hardware is fun too but you can iterate so much faster in the software realm that it generally ends up being a little more refined) I’m heavily shell focused here. While you may be able to do some of this via GUI tools, I greatly prefer the unprotected buzz saw that is the shell because that’s where most of the power and new features can be found. You can also easily burn your operation to the ground with a few misplaced keystrokes. Educate yourself and wear your safety goggles.

现在开始有趣的部分。 (好吧，硬件也很有趣，但是您可以在软件领域中进行如此快速的迭代，以至于通常最终会变得更加精致)。 尽管您可以通过GUI工具执行某些操作，但我还是更喜欢无保护的蜂鸣器外壳，因为这是可以找到大多数功能和新功能的地方。 您也可以通过几次按键误将操作轻松烧毁。 教育自己并戴上安全眼镜。

固件 (FW)

The Internet comes to the house via fiber which is by far the best technology for delivering Internet for reasons. The premises equipment from the service provider terminates with an Ethernet port. I connect that to the fanless mini-PC called fw. (its not exactly a firewall — more of a router — but I don’t have a better term for a “center of the network” type box) The other Ethernet in that box as I mentioned before is a VLAN trunk. There are 4 networks that flow over that port:

互联网涉及到通过光纤的房子，这是迄今为止针对互联网提供最好的技术原因 。 服务提供商提供的房屋设备以以太网端口终止。 我将其连接到名为fw的无风扇微型PC上。 (它不完全是防火墙，更多的是路由器，但我对“网络中心”类型框没有更好的称呼)如前所述，该框中的另一个以太网是VLAN中继。 该端口上有4个网络：

• Servers — the 10 network (10.10.0.0/16)

  服务器10网络( 10.10.0.0/16 )

• User — the 20 network (10.20.0.0/16)

  用户20网络( 10.20.0.0/16 )

• IoT — the 30 network (10.30.0.0/16)

  物联网— 30网络( 10.30.0.0/16 )

• Guest — the 40 network (10.40.0.0/24)

  访客40网络( 10.40.0.0/24 )

These networks are all separated on VLANs tagged 10, 20, 30, 40 respectively. Any traffic crossing network boundaries, packets from 10.20.0.0/16 to 10.30.0.0/16 for example, are routed through fw. So fw has an IP on each network. 10.20.1.1, for example, is the gateway for 10.20.0.0/16 so machines on this network gateway packets to 10.20.1.1 to get to everything else. Here’s the output of ip a s (or “IP address show”)

这些网络上的VLAN都分离标记10 ， 20 ， 30 ， 40分别。 任何跨越网络边界的流量(例如，从10.20.0.0/16到10.30.0.0/16数据包)都将通过fw路由。 因此， fw在每个网络上都有一个IP。 例如， 10.20.1.1是10.20.0.0/16的网关，因此此网络上的计算机网关将数据包发送到10.20.1.1以访问其他所有内容。 这是ip as的输出ip as (或“ IP地址显示”)

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:e0:67:05:29:6a brd ff:ff:ff:ff:ff:ff
    inet XXX.XXX.XXX.XXX/24 brd XXX.XXX.XXX.255 scope global enp1s0
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:67ff:fe05:296a/64 scope link
       valid_lft forever preferred_lft forever3: enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:e0:67:05:29:6b brd ff:ff:ff:ff:ff:ff
    inet6 fe80::2e0:67ff:fe05:296b/64 scope link
       valid_lft forever preferred_lft forever4: enp2s0.10@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:e0:67:05:29:6b brd ff:ff:ff:ff:ff:ff
    inet 10.10.1.1/16 brd 10.10.255.255 scope global enp2s0.20
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:67ff:fe05:296b/64 scope link
       valid_lft forever preferred_lft forever5: enp2s0.20@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:e0:67:05:29:6b brd ff:ff:ff:ff:ff:ff
    inet 10.20.1.1/16 brd 10.20.255.255 scope global enp2s0.20
       valid_lft forever preferred_lft forever
    inet 10.20.1.2/16 brd 10.20.255.255 scope global secondary enp2s0.20:0
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:67ff:fe05:296b/64 scope link
       valid_lft forever preferred_lft forever6: enp2s0.30@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:e0:67:05:29:6b brd ff:ff:ff:ff:ff:ff
    inet 10.30.1.1/16 brd 10.30.255.255 scope global enp2s0.30
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:67ff:fe05:296b/64 scope link
       valid_lft forever preferred_lft forever7: enp2s0.40@enp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 00:e0:67:05:29:6b brd ff:ff:ff:ff:ff:ff
    inet 10.40.1.1/16 brd 10.40.255.255 scope global enp2s0.40
       valid_lft forever preferred_lft forever
    inet6 fe80::2e0:67ff:fe05:296b/64 scope link
       valid_lft forever preferred_lft forever8: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.50.1.1/16 scope global wg0
       valid_lft forever preferred_lft forever

I haven’t had udev rename enp1s0 to eth0, etc. which would be more aesthetically pleasing but they are the same thing. Notice enp2s0 (which is my eth1) has no IP address but enp2s0.20@enp2s0, for example, does. (notice the 20 in there) Anything on theenp2s0.20@enp2s0 interface is tagged in the 20 VLAN. (granted the @enp2s0 at the end is a little redundant here — maybe that makes more sense if I had udev name the interface eth1 but I haven’t tried that) If I wanted to send packets without tagging, (which I don’t) I’d have added an IP to the root enp1s0 device. You can add VLANs and make them operational with:

我还没有udev将enp1s0重命名为eth0等，这在美学上会更令人满意，但它们是同一回事。 请注意， enp2s0 (这是我的eth1 )没有IP地址，但是enp2s0.20@enp2s0 。 (请注意其中的20 ) enp2s0.20@enp2s0接口上的enp2s0.20@enp2s0都标记在20 VLAN中。 (在@enp2s0处授予@enp2s0有点多余-如果我将udev命名为eth1接口，但我没有尝试过，也许更有意义)如果我想发送不带标签的数据包，(我不这样做) )我已经将IP添加到了根enp1s0设备。 您可以添加VLAN并使它们可通过以下方式运行：

ip link add link enp2s0 name enp2s0.20 type vlan id 20
ip link set dev enp2s0.20 up

You’ll also notice a 10.50.0.0/16 network but it’s not on a VLAN but rather a new wg0 interface. That’s a virtual interface that Wireguard creates for VPN connections. More on this later.

您还会注意到10.50.0.0/16网络，但它不在VLAN上，而是在新的wg0接口上。 这是Wireguard为VPN连接创建的虚拟接口。 稍后再详细介绍。

The rules for the most part are fairly straightforward. In plain English, fw NATs all networks to the Internet. I haven’t (yet) had a reason to selectivly deny that but that’s easily done. Machines on the 10.10.0.0/16 server network have some external ports forwarded in to them. They can also get to the 10.30.0.0/16 IoT network. Some of the servers do HomeKit stuff so they need to get over there but critically, connections initiated in the other direction (IoT -> server) won’t work. Machines on the 10.20.0.0/16 user network have fairly unfettered access to all networks. The 10.30.0.0/16 IoT network is fairly constrained. It can only initiate connections to the public Internet although the AppleTV is an exception. The 10.40.0.0/16 guest network is similar to the IoT network in that all it can do is get out — it has very limited internal access. The 10.50.0.0/16 VPN network is handled similarly to the 10.20.0.0/16 user network. Machines can either connect internally or externally (in fact Wireguard lets you migrate without dropping the connection) and “exist” internally as if they were locally connected regardless of location.

大部分规则非常简单。 用简单的英语来说， fw NAT将所有网络都连接到Internet。 我还没有理由选择性地否认这一点，但这很容易做到。 10.10.0.0/16服务器网络上的计算机将一些外部端口转发给它们。 他们还可以访问10.30.0.0/16 IoT网络。 一些服务器执行HomeKit任务，因此它们需要越过那里，但关键的是，在另一个方向(IoT->服务器)上启动的连接将无法工作。 10.20.0.0/16用户网络上的计算机具有对所有网络的相当不受限制的访问权限。 10.30.0.0/16 IoT网络受到10.30.0.0/16限制。 尽管AppleTV是一个例外，但它只能启动与公共Internet的连接。 10.40.0.0/16来宾网络与IoT网络类似，它所能做的就是出去-内部访问非常有限。 10.50.0.0/16 VPN网络的处理方式与10.20.0.0/16用户网络类似。 机器既可以内部连接，也可以外部连接(实际上，Wireguard允许您在不断开连接的情况下进行迁移)，并且可以在内部“存在”，就像它们在本地连接一样，无论位置如何。

Input and output tables default to ACCEPT and the forwarding table defaults to DROP. Internet access for all networks is provided by this masquerade rule:

输入和输出表默认为ACCEPT ，转发表默认为DROP 。 伪装规则可为所有网络提供Internet访问：

ifconfig -A POSTROUTING -s 10.0.0.0/8 ! -d 10.0.0.0/8 ! -i enp1s0 -o enp1s0 -j MASQUERADE

Notice I define both the IP range (source 10.0.0.0/8 and not destination 10.0.0.0/8) and the interfaces. (in via anything butenp1s0 and out viaenp1s0) Granted, this seems overkill but my standard is to specify both IP range and interface. If someone were able to spoof a packet’s addresses, I wanted to catch that on interface grounds and fall through to the default DROP rule.

请注意，我同时定义的IP范围(源10.0.0.0/8而不是目的地10.0.0.0/8 ) 和接口。 (通过enp1s0任何enp1s0以及通过enp1s0 )当然，这似乎enp1s0过分，但是我的标准是同时指定IP范围和接口。 如果有人能够欺骗数据包的地址，我想以接口为基础来捕获它，并遵循默认的DROP规则。

And because my default rule is DROP, I also have to allow packets to return from the Internet to each network:

而且由于我的默认规则是DROP ，所以我还必须允许数据包从Internet返回到每个网络：

iptables -A FORWARD -s 10.10.0.0/16 ! -d 10.0.0.0/8 -i enp2s0.10 -o enp1s0 -j ACCEPTiptables -A FORWARD -s 10.20.0.0/16 ! -d 10.0.0.0/8 -i enp2s0.20 -o enp1s0 -j ACCEPTiptables -A FORWARD -s 10.30.0.0/16 ! -d 10.0.0.0/8 -i enp2s0.30 -o enp1s0 -j ACCEPTiptables -A FORWARD -s 10.40.0.0/16 ! -d 10.0.0.0/8 -i enp2s0.40 -o enp1s0 -j ACCEPTiptables -A FORWARD -s 10.50.0.0/16 ! -d 10.0.0.0/8 -i wg0 -o enp1s0 -j ACCEPT

That completes Internet access although I also use tc (traffic control) to shape the 10.30.0.0/16 IoT network to limit its bandwidth. (explained later)

尽管我还使用tc (流量控制)来塑造10.30.0.0/16 IoT网络以限制其带宽，但这完成了Internet访问。 (稍后说明)

Diving into the 10.10.0.0/16 server network, I have a few port forwards defined in the PREROUTING table:

进入10.10.0.0/16服务器网络，我在PREROUTING表中定义了一些端口转发：

iptables -A PREROUTING ! -s 10.0.0.0/8 -i enp1s0 -p tcp -m tcp --dport 3000 -j DNAT --to-destination 10.20.2.201:2000iptables -A PREROUTING ! -s 10.0.0.0/8 -i enp1s0 -p udp -m udp --dport 60000:61000 -j DNAT --to-destination 10.20.2.8

I have many forwards but these two demonstrate forwarding a simple TCP port and a range of UDP ports. The first line shows how to forward TCP port 3000 to 10.20.2.201:2000. (notice the altered port on the destination as well) The second rule forwards all the UDP ports from 60000 to 61000 to 10.20.2.8. (these are used bymosh, an absolutely indispensable tool)

我有很多转发，但是这两个演示了转发一个简单的TCP端口和一系列UDP端口。 第一行显示了如何将TCP端口3000转发到10.20.2.201:2000 。 (还要注意目标上更改的端口)第二条规则将所有UDP端口从60000转发到61000到10.20.2.8 。 (这些是绝对必要的工具mosh使用的)

I also need to allow these ports in the FORWARD table:

我还需要在FORWARD表中允许这些端口：

iptables -A FORWARD ! -s 10.0.0.0/8 -d 10.10.0.0/16 -i enp1s0 -o enp2s0.10 -p tcp -m tcp --dport 3000 -m state --state NEW -j ACCEPTiptables -A FORWARD ! -s 10.0.0.0/8 -d 10.10.0.0/16 -i enp1s0 -o enp2s0.10 -p udp -m udp --dport 60000:61000 -m state --state NEW -j ACCEPT

Moving on to the 10.20.0.0/16 user network, packets are pretty much allowed to go anywhere.

转到10.20.0.0/16用户网络，几乎可以将数据包发送到任何地方。

iptables -A FORWARD -s 10.20.0.0/16 -d 10.10.0.0/16 -i enp2s0.20 -o enp2s0.10 -j ACCEPTiptables -A FORWARD -s 10.20.0.0/16 -d 10.30.0.0/16 -i enp2s0.20 -o enp2s0.30 -j ACCEPTiptables -A FORWARD -s 10.20.0.0/16 -d 10.40.0.0/16 -i enp2s0.20 -o enp2s0.40 -j ACCEPTiptables -A FORWARD -s 10.20.0.0/16 -d 10.50.0.0/16 -i enp2s0.20 -o wg0 -j ACCEPT

Fairly straightforward there. The reverse direction is really interesting though. Moving on to the 10.30.0.0/16 IoT network, I really don’t want devices there opening connections to machines on other internal networks. I do, however, want them to be able to respond to incoming requests.

那里很简单。 相反的方向确实很有趣。 转到10.30.0.0/16 IoT网络，我真的不希望那里的设备打开与其他内部网络上的计算机的连接。 但是，我确实希望他们能够响应传入的请求。

iptables -A FORWARD -s 10.30.0.0/16 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -m state --state RELATED,ESTABLISHED -j ACCEPT

Here, the 10.30.0.0/16 IoT network can send packets to the 10.20.0.0/16 user network but only if they are in response to an established connection or related to one. (isn’t connection tracking awesome?!)

在这里， 10.30.0.0/16 IoT网络可以将数据包发送到10.20.0.0/16用户网络，但10.20.0.0/16是它们是对已建立的连接的响应或与某个连接有关。 (连接跟踪很棒吗？！)

I mentioned earlier that the AppleTV seems to straddle both the 10.30.0.0/16 IoT network where it hubs the HomeKit devices and the 10.20.0.0/16 user network where it should be available for streaming music, screencasts and video. We can easily make just the AppleTV at 10.30.2.4 on the 10.30.0.0/16 IoT network initiate connections to all machines in the 10.20.0.0/16 user network via the ports it’s known to use:

我在前面提到过，AppleTV似乎跨越了10.30.0.0/16 IoT网络(它是HomeKit设备的枢纽)和10.20.0.0/16用户网络(应该可以将其用于流音乐，截屏和视频)。 我们可以轻松地使IoT网络10.30.2.4上位于10.30.0.0/16的AppleTV通过已知使用的端口启动与10.20.0.0/16用户网络中所有计算机的连接：

iptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 3689 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 5000 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 7000 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 7001 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 7100 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 7010 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 7011 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m multiport --dports 49152:65535 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 32400 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 1900 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 3005 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 5353 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p tcp -m tcp --dport 32469 -m state --state NEW -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 32410 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 32412 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 32413 -j ACCEPTiptables -A FORWARD -s 10.30.2.4/32 -d 10.20.0.0/16 -i enp2s0.30 -o enp2s0.20 -p udp -m udp --dport 32414 -j ACCEPT

There are some TCP ports in there that include state and UDP ports which obviously do not. I have found this collection of ports works for all services I use. Some may eventually become legacy as they seem to only be used by the older iTunes application. tcpdump is your friend when trying to discover why things aren’t working.

那里有一些TCP端口，其中包括状态端口，而UDP端口显然没有。 我发现此端口集合适用于我使用的所有服务。 有些似乎最终只能由较旧的iTunes应用程序使用，因此最终可能成为旧版。 当试图发现事情为什么不起作用时， tcpdump是您的朋友。

域名解析 (mDNS)

This brings up a curious quandary. AppleTV uses mDNS (multicast DNS) to discover services. How do machines in the 10.20.0.0/16 user network find the AppleTV on the 10.30.0.0/16 IoT network? The gateways for these networks (10.20.1.1 and 10.30.1.1 respectively) are on different interfaces so multicast traffic won’t jump that divide.

这带来了一个奇怪的难题。 AppleTV使用mDNS(多播DNS)发现服务。 10.20.0.0/16用户网络中的机器如何在10.30.0.0/16 IoT网络上找到AppleTV？ 这些网络的网关(分别为10.20.1.1和10.30.1.1 )位于不同的接口上，因此多播流量不会跨越该鸿沟。

The answer is mdns-repeater which listens to interfaces copying mDNS packets from one onto all the others. (the link is to my very minimal logging change) I run this on fw like this:

答案是mdns-repeater ，它侦听将mDNS数据包从一个复制到所有其他的接口。 (链接指向我的最小日志记录更改)我在fw像这样运行：

mdns-repeater -f enp2s0.20 enp2s0.30

and logging looks like this:

并记录如下：

10.30.2.4 (238 bytes) -> enp2s0.20
10.30.2.4 (555 bytes) -> enp2s0.20
10.20.1.11 (1357 bytes) -> enp2s0.30
10.20.1.11 (743 bytes) -> enp2s0.30

suggesting the AppleTV is jumping the divide and responses are coming back. I’m currently working on getting the wg0 interface included in this list so VPN clients also get multicast but haven’t worked through the particulars yet. More to come on this.

暗示AppleTV正在跨越鸿沟，而回应又回来了。 我目前正在努力将wg0接口包含在此列表中，以便VPN客户端也可以进行多播，但尚未进行详细操作。 更多内容。

The 10.40.0.0/16 guest network is fairly locked down. It can’t get to any of the internal networks directly because the default FORWARD rule is DROP so we’re all set there without adding more rules. However, the 10.50.0.0/16 VPN network should act very similarly to the 10.20.0.0/16 user network so the rules there are almost identical but I won’t bore you with a rehash of that.

10.40.0.0/16来宾网络已相当锁定。 它不能直接进入任何内部网络，因为默认的FORWARD规则是DROP所以我们都在这里设置而没有添加更多规则。 但是， 10.50.0.0/16 VPN网络的行为应与10.20.0.0/16用户网络非常相似，因此那里的规则几乎相同，但我不会为您10.20.0.0/16 。

tc (tc)

As mentioned earlier, I use tc (traffic control) to limit the total Internet bandwidth of the guest network. That is done via:

如前所述，我使用tc (流量控制)来限制访客网络的总Internet带宽。 通过以下方式完成：

tc qdisc add dev enp2s0.40 root tbf rate 1mbit burst 2mbit latency 400ms

• qdisc: modify the queuing discipline (aka the scheduler for this interface)
  qdisc：修改排队规则(也就是此接口的调度程序)
• add: add a new rule
  添加：添加新规则
• dev enp2s0.40: rules will be applied to the enp2s0.40 (guest) interface
  dev enp2s0.40：规则将应用于enp2s0.40(guest)接口
• root: modify the outbound traffic scheduler (aka known as the egress qdisc)
  root：修改出站流量调度程序(也称为出口qdisc)
• tbf: use the token buffer filter to manipulate traffic rates
  tbf：使用令牌缓冲区过滤器来控制流量速率
• rate 1mbit: sustained maximum rate (1 megabit)
  速率1兆比特：持续最大速率(1兆比特)
• burst 2mbit: maximum allowed burst (2 megabits)
  突发2兆位：允许的最大突发数(2兆位)
• latency 400ms: packets with higher than 400ms latency get dropped
  延迟400毫秒：延迟高于400毫秒的数据包将被丢弃

See your traffic control rules for the enp2s0.40 interface with:

请使用以下命令查看您的enp2s0.40接口的流量控制规则：

tc qdisc show dev enp2s0.40

and delete them with:

并使用以下命令删除它们：

tc qdisc del dev enp2s0.40 root

tc is extremely powerful — this only scratches the surface. You can do fun things like randomly dropping or delaying packets to simulate flaky Internet. This is hugely helpful when battle hardening services for the real-world.

tc非常强大-仅能刮擦表面。 您可以做一些有趣的事情，例如随机丢弃或延迟数据包以模拟不稳定的Internet。 在为现实世界提供强化服务时，这非常有用。

DHCP服务器 (DHCP)

As I mentioned before, I also run other services on fw including DHCP and DNS. Let’s look at DHCP first. I rundhcpd, the ISC daemon. To be clear, this is the authoritative DHCP server for the 10.0.0.0/8 networks. (not dhcpcd, the client daemon that manages the public Internet address my ISP assigns) In my case, I only listen on the internal interfaces so as not to mess all of that up. The dhcpd.conf file looks something like this:

如前所述，我还在fw上运行其他服务，包括DHCP和DNS。 首先让我们看一下DHCP。 我运行ISC守护程序dhcpd 。 需要明确的是，这是用于10.0.0.0/8网络的权威DHCP服务器。 (不是dhcpcd ，它是管理ISP分配的公共Internet地址的客户端守护程序)就我而言，我仅侦听内部接口，以免将所有内容弄乱。 dhcpd.conf文件如下所示：

authoritative;
default-lease-time 86400;
max-lease-time 864000;option domain-name “internal.example.com”;subnet 10.10.0.0 netmask 255.255.0.0 {
  range 10.10.1.10 10.10.1.254;
  option routers 10.10.1.1;
  option domain-name-servers 10.10.1.1;
}subnet 10.20.0.0 netmask 255.255.0.0 {
  range 10.20.1.10 10.20.1.254;
  option routers 10.20.1.1;
  option domain-name-servers 10.20.1.1;
}subnet 10.30.0.0 netmask 255.255.0.0 {
  range 10.30.1.10 10.30.1.254;
  option routers 10.30.1.1;
  option domain-name-servers 10.30.1.1;
}subnet 10.40.0.0 netmask 255.255.0.0 {
  range 10.40.1.10 10.40.1.254;
  option routers 10.40.1.1;
  option domain-name-servers 10.40.1.1;
}#
# hard-coded addresses
#
host imac {
  hardware ethernet 10:dd:b1:c3:b2:a1; # ethernet
  fixed-address 10.20.2.10;
}host imac5k {
  hardware ethernet 0c:4d:e9:c3:b2:a1; # ethernet
  fixed-address 10.20.2.18;
}host macbookair {
  hardware ethernet 28:37:37:a1:b2:c3;
  fixed-address 10.20.2.11;
}host macbookpro {
  hardware ethernet 78:4f:43:a1:b2:c3;
  fixed-address 10.20.2.19;
}# ...host ap1 {
  hardware ethernet b4:fb:e4:a1:b2:c3;
  fixed-address 10.30.2.11;
}host ap2 {
  hardware ethernet 18:e8:29:a1:b2:c3;
  fixed-address 10.30.2.12;
}host hdtivo {
  hardware ethernet 00:11:d9:a1:b2:c3;
  fixed-address 10.30.2.2;
}host appletv {
  hardware ethernet c8:69:cd:a1:b2:c3;
  fixed-address 10.30.2.4;
}# ... lots more here - cut for brevity

You’ll notice each range leaves a few IPs ( 10.*.1.2 through 10.*.1.9 as well as everything not 10.*.1.*) open for known MAC addresses to get predictable IP addresses. Especially in the case of laptops that come up on both my network and elsewhere in the world, it is nice for them to always get the same IP internally so I can reliably scp files to them by name, for example.

您会注意到，每个范围都为已知的MAC地址保留了几个IP( 10.*.1.2至10.*.1.9以及所有非10.*.1.* )开放的IP，以获取可预测的IP地址。 尤其是在拿出我的两个网络，并在世界其他地区在笔记本电脑的情况下，它是很好的为他们总是得到相同的IP内部这样我就可以可靠地scp文件，他们的名字，例如。

The 10.50.0.0/16 VPN network is assigned manually. I suppose I could use DHCP but haven’t (yet?) looked into this. This remains an area of active development for me.

10.50.0.0/16 VPN网络是手动分配的。 我想我可以使用DHCP，但尚未(尚未？)对此进行调查。 对我来说，这仍然是积极发展的领域。

域名解析 (DNS)

I love DNS — I don’t know why. I use tinydns and dnscache from djbdns, the ancient yet absolutely rock solid and minimal DNS package. I suppose I like it so much because it it hues to the Internet ethos of super simple building blocks that you combine to make complex things. Not surprisingly, it has a fantastic security record because it is so simple. I mean, it does exactly what it says and nothing else. tinydns is an authoritative-only name server (usually only caches use these) and dnscache is a non-authoritative-only DNS cacheing resolver. (this is what most devices on the network use)

我爱DNS-我不知道为什么。 我使用了来自djbdns的 tinydns和dnscache ，这是古老但绝对坚如磐石的最小DNS软件包。 我想我非常喜欢它，因为它符合超级简单构建基元的互联网精神，您可以将它们组合起来以制造复杂的事物。 毫不奇怪，它是如此简单，因此拥有出色的安全记录。 我的意思是，它完全按照其说的去做，仅此而已。 tinydns是一个仅权威的名称服务器(通常只有缓存使用它们)，而dnscache是一个非权威的DNS缓存解析器。 (这是网络上大多数设备使用的)

DNS is one of those things that ISPs tend to provide because they have to. Their implementations either fall over all the time causing customers to think the internet is down, or if they put resources into it they corrupt it by answering with a catchall webserver’s IP. When names can’t be found, they sell ads via that catchall server. (not to mention the security lapses that sometimes make it into URL bars like the mistakenly pasted password from a password manager) There is no excuse for this. DNS is very simple and should either be run by you or a trustworthy source. (some use Google’s 8.8.8.8)

DNS是ISP倾向于提供的东西之一，因为它们必须这样做。 他们的实现总是在下降，导致客户认为互联网已关闭，或者如果他们将资源放入其中，则会通过使用全面的Web服务器的IP进行响应来破坏互联网。 如果找不到名字，他们就会通过该多功能服务器出售广告。 (更不用说有时会使其进入URL栏的安全漏洞，例如密码管理器错误粘贴的密码)。这没有任何借口。 DNS非常简单，应该由您或可信赖的来源来运行。 (有些使用Google的8.8.8.8 )

</rant>

</ rant>

I use a more modern version of the daemontools package called runit to keep services running. It is also very simple and operates like a buzz saw without a safety cover. It is absolutely relentless if you use it wrong. It simply runs an executable file called run in the foreground until it quits, and then it immediately runs it again, over and over. Usually that executable is a shell script. Don’t make the mistake of having that shell script run something in the background and return because your machine will quickly run out of resources spawning untold numbers of sub processes.

我使用名为daemontools软件包的更新版本来保持服务运行。 它也非常简单，操作就像没有安全罩的蜂鸣器一样。 如果使用错误，那将是无情的。 它只是运行名为可执行文件run在前台，直到它退出，然后立即再次运行它，一遍又一遍。 通常，该可执行文件是外壳脚本。 不要让该Shell脚本在后台运行某些东西并返回错误，因为您的计算机将很快耗尽资源，从而产生无数个子进程。

It also handles logging fairly nicely. Whatever comes from STDOUT is written by a logging process into a set of circular logs. This is fairly nice because if something spins out of control spewing gigabytes of logs, it doesn’t eat up your filesystem, yet you can still see whats going on.

它还可以很好地处理日志记录。 无论来自STDOUT内容如何，​​都会通过日志记录过程写入一组循环日志中。 这是相当不错的，因为如果某些事情失控地喷出了数十亿字节的日志，它不会耗尽您的文件系统，但是您仍然可以看到发生了什么。

I run a split horizon DNS setup. This means the result for a lookup by a machine on one network might not be the same as a machine on another network. This used to be fairly controversial but I think resolving a name to an internal IP in some limited cases is now accepted practice. I do this by running an authoritative tinydns instance for the IPs in my internal network. Here’s a snip of the root/data file:

我运行水平分割DNS安装程序。 这意味着一个网络上的计算机查找结果可能与另一网络上的计算机查找结果不同。 以前这一直是有争议的，但是我认为在某些有限的情况下将名称解析为内部IP已经成为公认的做法。 我通过为内部网络中的IP运行权威的tinydns实例来做到这一点。 这是root/data文件的片段：

########################################
# internal dns
########################################.ns.internal.example.com:10.20.1.2:a
.1.10.10.in-addr.arpa:10.20.1.2
.1.20.10.in-addr.arpa:10.20.1.2
.2.20.10.in-addr.arpa:10.20.1.2
.1.30.10.in-addr.arpa:10.20.1.2
.2.30.10.in-addr.arpa:10.20.1.2
.1.40.10.in-addr.arpa:10.20.1.2
.1.50.10.in-addr.arpa:10.20.1.2########################################
# example.com
########################################.example.com:10.20.1.2@example.com::mx.planettelex.com:0:
'example.com:v=spf1 mx -all:
+example.com:1.2.3.4:86400
+www.example.com:1.2.3.4:86400
+pictures.example.com:2.3.4.5:86400# ... skipping a bunch of stuff here########################################
# 10.20.1.x
########################################=fw.internal.example.com:10.20.1.1
=ns.internal.example.com:10.20.1.2
=ip10-20-1-3.internal.example.com:10.20.1.3
=ip10-20-1-4.internal.example.com:10.20.1.4
=ip10-20-1-5.internal.example.com:10.20.1.5
=ip10-20-1-6.internal.example.com:10.20.1.6
=ip10-20-1-7.internal.example.com:10.20.1.7
=ip10-20-1-8.internal.example.com:10.20.1.8
=ip10-20-1-9.internal.example.com:10.20.1.9

I run authoritative DNS on 10.20.1.2. You can also run that on 127.0.0.1 because usually only dnscache needs access to this server but I had the IP and it is nice to be able to directly query from off box when testing.

我在10.20.1.2上运行权威DNS。 您也可以在127.0.0.1上运行该命令，因为通常只有dnscache需要访问该服务器，但我拥有IP，因此在测试时能够直接从现成的查询中感到很高兴。

Lines beginning with a # are ignored. Lines starting with a . define nameservers. .ns.internal.example.com:10.20.1.2:a says 10.20.1.2 is authoritative for internal.example.com. All the reverses are there too so 1.10.10.in-addr.arpa allows the server to answer reverse queries authoritatively as well. (IP to name resolution)@ defines mail records so @example.com::mx.planettelex.com:0: designates mx.planettelex.com as the 0 preference mailserver. Lines beginning with= defines an A record (which are your standard IP -> name record) and a PTR record for the reverse IP -> name direction. Lines beginning with + add only the A record so you might see something like this normally:

以#开头的#被忽略。 以开头的行. 定义名称服务器。 .ns.internal.example.com:10.20.1.2:a表示10.20.1.2是internal.example.com权威。 所有反向查询也都存在，因此1.10.10.in-addr.arpa允许服务器也权威地回答反向查询。 (IP到名称解析) @定义邮件记录，因此@example.com::mx.planettelex.com:0:将mx.planettelex.com指定为0首选项邮件服务器。 以=开头的行定义了A记录(这是您的标准IP->名称记录)和反向IP->名称方向的PTR记录。 以+开头的行仅添加A记录，因此您通常会看到以下内容：

=example.com:1.2.3.4
+www.example.com:1.2.3.4
+web.example.com:1.2.3.4
+dev.example.com:4.5.6.7
+dev.example.com:5.6.7.8
+dev.example.com:6.7.8.9

so when you look up1.2.3.4 you get example.com but looking up any of example.com, www.example.com or web.example.com all return 1.2.3.4. Lastly, dev.example.com will return 4.5.6.7, 5.6.7.8 and 6.7.8.9. Very concise.

因此，当您查找1.2.3.4将获得example.com但查找example.com ， www.example.com或web.example.com任何一个都将返回1.2.3.4 。 最后， dev.example.com将返回4.5.6.7 ， 5.6.7.8和6.7.8.9 。 非常简洁。

I reply authoritatively for all the IPs on the internal network, but what about resolving google.com? For that we turn to dnscache. There is one caching resolver for each of the VLANs. I decided to go this way rather than having everything use one IP and punching UDP 53 holes for all the networks in the iptables setup because it just looks a little cleaner. Here’s the dnscache setup:

我会为内部网络上的所有IP权威地答复，但是解析google.com呢？ 为此，我们转向dnscache 。 每个VLAN都有一个缓存解析器。 我决定采用这种方式，而不是让所有内容都使用一个IP并在iptables设置中为所有网络打UDP 53Kong，因为它看起来更加干净。 这是dnscache设置：

root@fw:/service/dnscache-10.20.1.1$ ls -la root/*
root/ip:
total 8
drwxr-xr-x 2 root root 4096 Jul  4  2019 .
drwxr-xr-x 4 root root 4096 Jun 27  2019 ..
-rw-r--r-- 1 root root    0 Jun 27  2019 10
-rw-r--r-- 1 root root    0 Jun 27  2019 127
-rw-r--r-- 1 root root    0 Jul  4  2019 172.16
-rw-r--r-- 1 root root    0 Jun 27  2019 192.168root/servers:
total 48
drwxr-xr-x 2 root root 4096 Jun 19 09:12 .
drwxr-xr-x 4 root root 4096 Jun 27  2019 ..
-rw-r--r-- 1 root root  168 Jun 27  2019 @
-rw-r--r-- 1 root root   10 Jul  3  2019 1.20.10.in-addr.arpa
-rw-r--r-- 1 root root   10 Jul  3  2019 1.30.10.in-addr.arpa
-rw-r--r-- 1 root root   10 Jul 18  2019 1.40.10.in-addr.arpa
-rw-r--r-- 1 root root   10 Jun 19 09:10 1.50.10.in-addr.arpa
-rw-r--r-- 1 root root   10 Jul  3  2019 2.20.10.in-addr.arpa
-rw-r--r-- 1 root root   10 Jul  3  2019 2.30.10.in-addr.arpa
-rw-r--r-- 1 root root   10 Jul  3  2019 example.com
-rw-r--r-- 1 root root   10 Jul  3  2019 internal.example.com
root@fw:/service/dnscache-10.20.1.1$

I deploy services in directories who’s name includes the IP from which the service runs.

我在名称包括该服务运行IP的目录中部署服务。

Files in the root/ip directory define what source addresses will be served so the file root/ip/10 says any IP starting with a 10 (10.0.0.0/8) will be served. I allow localhost and all private networks. Everything else will just be ignored. The file contents are meaningless. (I used touch to make the files)

root/ip目录中的文件定义了将提供哪些源地址，因此文件root/ip/10表示将提供以10 ( 10.0.0.0/8 )开头的任何IP。 我允许本地主机和所有专用网络。 其他所有内容都将被忽略。 文件内容没有意义。 (我用touch制作文件)

Files in root/servers define which IPs to query for a given request with @ being the catchall. If you cat root/servers/example.com you will see 10.20.1.2 which is the tinydns instance authoritativly answering for example.com. The in-addr.arpa files work the same way for reverse lookups. All files in this directory except for @ contain 10.20.1.2 so we’re going there for everything internal. The contents of the @ file are essentially the root nameservers so we’ll go there for google.com or anything else we don’t already know about. No ISP nameservers here although you can see how you could easily add something else if you wanted.

root/servers文件定义了要查询给定请求的IP，其中@是全部。 如果您使用root/servers/example.com ，则将看到10.20.1.2 ，这是tinydns实例对example.com权威回答。 in-addr.arpa文件的工作方式与反向查找相同。 此目录中除@以外的所有文件都包含10.20.1.2因此我们将在其中查找所有内部文件。 @文件的内容实际上是根名称服务器，因此我们将前往google.com或我们尚不了解的其他内容。 尽管您可以看到如何根据需要轻松添加其他内容，但这里没有ISP名称服务器。

root@fw:/service/dnscache-10.20.1.1$ cat root/servers/@
192.112.36.4
192.203.230.10
192.33.4.12
192.36.148.17
192.5.5.241
192.58.128.30
193.0.14.129
198.41.0.4
198.97.190.53
199.7.83.42
199.7.91.13
199.9.14.201
202.12.27.33
root@fw:/service/dnscache-10.20.1.1$

You get the idea.

你明白了。

虚拟专用网 (VPN)

The 10.50.0.0/16 network, as mentioned before, is used for Wireguard VPN connections. If you aren’t already up to speed, Wireguard is a modern, (ChaCha20, Curve25519) fast and lightweight VPN solution. All connectivity is connection-less over UDP so if you move to a different IP and start sending validly encrypted packets, things just continue to work. (just like mosh) Plus, there are clients for all major operating systems including Android and iOS. What’s not to love?

10.50.0.0/16 ， 10.50.0.0/16网络用于Wireguard VPN连接。 如果您还不适应最新技术，那么Wireguard是一款现代化的(ChaCha20，Curve25519)快速，轻便的VPN解决方案。 所有连接都是基于UDP的无连接，因此，如果您移动到其他IP并开始发送经过有效加密的数据包，事情将继续进行。 (just like mosh ) Plus, there are clients for all major operating systems including Android and iOS. What's not to love?

The easiest way to understand how Wireguard is set up via the command line is to watch the side by side video on the Wireguard quick start page. To compress some of those steps, run wg-quick which consumes /etc/wireguard/wg0.conf:

The easiest way to understand how Wireguard is set up via the command line is to watch the side by side video on the Wireguard quick start page . To compress some of those steps, run wg-quick which consumes /etc/wireguard/wg0.conf :

[Interface]
PrivateKey = MOCz2oukn+Q2GCeseIc1/FO+EsD1blQMh/OfQMLU3VU=
Address = 10.50.1.1/24
ListenPort = 51820
SaveConfig = false[Peer]
# macbookpro
PublicKey = PMJtmzspPplziybrZQYGqv0jdNLsUdEcXcTWXhq+hEs=
AllowedIPs = 10.50.1.2/32[Peer]
# iphone
PublicKey = J++Q1ie6ikkl5xUJujX5qOMnMRqpQ0CdSwiDHx3ScWQ=
AllowedIPs = 10.50.1.3/32

Now we’ll run wg-quick and set up the wg0 interface:

Now we'll run wg-quick and set up the wg0 interface:

wg-quick up wg0

We can see that things are working with wg show or simply wg:

We can see that things are working with wg show or simply wg :

interface: wg0
  public key: S6BDIue/LqipFebHVa6ArFvbouEynLtGeD16KDqnpXU=
  private key: (hidden)
  listening port: 51820peer: PMJtmzspPplziybrZQYGqv0jdNLsUdEcXcTWXhq+hEs=
  endpoint: 10.20.1.10:51280
  allowed ips: 10.50.1.3/32
  latest handshake: 37 seconds ago
  transfer: 8.89 MB received, 229.58 KiB sentpeer: J++Q1ie6ikkl5xUJujX5qOMnMRqpQ0CdSwiDHx3ScWQ=
  allowed ips: 10.50.1.2/32

Grab the Wireguard client for another system and set it up similarly. You can generate private keys with:

Grab the Wireguard client for another system and set it up similarly. You can generate private keys with:

wg genkey

and find the associated public key by sending the private key to STDIN of:

and find the associated public key by sending the private key to STDIN of:

wg pubkey

although most user tools do this automatically for you.

although most user tools do this automatically for you.

Once a peer is connected, there isn’t really a reason to disconnect. If you have a mobile client that reappears on another IP, things will just shift over to the new address. IPSec/L2TP has nothing on this!

Once a peer is connected, there isn't really a reason to disconnect. If you have a mobile client that reappears on another IP, things will just shift over to the new address. IPSec/L2TP has nothing on this!

HomeKit (HomeKit)

I’ve already touched on the AppleTV network ambiguity issue but what I didn’t cover is how to get the Ubiquity G3 camera streams into HomeKit. (there is no native support) The solution here is Homebridge which is a node.js project that makes a HomeKit bridge device available on the network. You can add anything that “connects” to this bridge to the Home iOS app. I make the G3 camera’s RTMP streams available using the Camera-ffmpeg module. Here’s the (abbriviated) config:

I've already touched on the AppleTV network ambiguity issue but what I didn't cover is how to get the Ubiquity G3 camera streams into HomeKit. (there is no native support) The solution here is Homebridge which is a node.js project that makes a HomeKit bridge device available on the network. You can add anything that “connects” to this bridge to the Home iOS app. I make the G3 camera's RTMP streams available using the Camera-ffmpeg module. Here's the (abbriviated) config:

{
  "bridge": {
    "name": "Homebridge",
    "username": "12:34:56:78:9a:bc",
    "port": 51820,
    "pin":"094-54-921"
  },
  "platforms": [ {
    "platform": "Camera-ffmpeg",
    "cameras": [ {
      "name": "Front Door",
      "videoConfig": {
        "source":"-rtsp_transport http -re -i rtsp://10.30.2.10:4774/hk6Ag9x2miGn31eq",
        "mapaudio": "0:0",
        "mapvideo": "0:1",
        "maxStreams": 4,
        "maxWidth": 1920,
        "maxHeight": 1080,
        "maxFPS": 20,
        "debug": false
      }
    },
    {
      "name": "Side Door",
      "videoConfig": {
        "source":"-rtsp_transport http -re -i rtsp://10.30.2.11:2843/DcD18np72no7xk8lK",
        "mapaudio": "0:0",
        "mapvideo": "0:1",
        "maxStreams": 4,
        "maxWidth": 1920,
        "maxHeight": 1080,
        "maxFPS": 20,
        "debug": false
      }
    }]
  }]
}

The net result of all of this is a Home app screen that looks like this:

The net result of all of this is a Home app screen that looks like this:

Home app on iOS

Home app on iOS

If you tap one of the camera tiles it brings up a player that lets you watch and listen to live video. This works both on the home network and elsewhere over the internet. No silly privacy compromising “cloud” service necessary.

If you tap one of the camera tiles it brings up a player that lets you watch and listen to live video. This works both on the home network and elsewhere over the internet. No silly privacy compromising “cloud” service necessary.

I also use a Homebridge module named AwayMode which creates any number of virtual triggers (think of them like motion sensors) that fire randomly at configurable cadences. You can then use them in automations that, for example, turn lights on. Then you turn theAwayMode switch on when you leave and your lights continue to go on and off throughout the evening thwarting would be burglars in droves.

I also use a Homebridge module named AwayMode which creates any number of virtual triggers (think of them like motion sensors) that fire randomly at configurable cadences. You can then use them in automations that, for example, turn lights on. Then you turn the AwayMode switch on when you leave and your lights continue to go on and off throughout the evening thwarting would be burglars in droves.

Here’s the pertinent section of the Homebridge config.json file. "accessories" go on the same level as "bridge" and "platforms".

Here's the pertinent section of the Homebridge config.json file. "accessories" go on the same level as "bridge" and "platforms" .

...
  "accessories": [ {
    "accessory": "AwayMode",
    "name": "Away Mode",
    "sensors": [ {
      "name": "Random Trigger A"
    }, {
      "name": "Random Trigger B"
    } ],
    "minOffTime": 300,
    "maxOffTime": 1200,
    "minOnTime": 600,
    "maxOnTime": 3600
  } ],
...

That gives you two triggers to work with. Make more if you need them. There are also options like only firing after sunset and before sunrise but the Home app already has a concept of that and I prefer the “simple building block” approach.

That gives you two triggers to work with. Make more if you need them. There are also options like only firing after sunset and before sunrise but the Home app already has a concept of that and I prefer the “simple building block” approach.

Switches (Switches)

I mentioned I use the Cisco switches because I have already spent the 10,000 hours babysitting them in a past life. Sadly I only really do two things with them — configuring switch ports between access and trunk with assigned VLANs and configuring link aggregation. (LACP) I use link aggregation in the very unlikely case that I loose one pair of fibers to my attic and not the other. Let’s be frank here, I’m using link aggregation for the fun of it. Here’s the pertinent config:

I mentioned I use the Cisco switches because I have already spent the 10,000 hours babysitting them in a past life. Sadly I only really do two things with them — configuring switch ports between access and trunk with assigned VLANs and configuring link aggregation. (LACP) I use link aggregation in the very unlikely case that I loose one pair of fibers to my attic and not the other. Let's be frank here, I'm using link aggregation for the fun of it. Here's the pertinent config:

interface gigabitethernet9
 spanning-tree link-type point-to-point
 channel-group 1 mode on
 switchport mode access
 macro description "lag-1-port-1"
!
interface gigabitethernet10
 spanning-tree link-type point-to-point
 channel-group 1 mode on
 switchport mode access
 macro description "lag-1-port-2"
!
interface port-channel 1
 description fiber-trunk
 spanning-tree link-type point-to-point
 switchport trunk allowed vlan add 10,30,40
 macro description "lag-1"
 switchport default-vlan tagged
!

The names are slightly confusing — the gigabitethernet ports are SFP fiber ports. Here, ports gigabitethernet9 and gigabitethernet10 both have channel-group 1 mode on which make them part of port-channel number 1. Do that on both sides and the new virtual interface namedport-channel can be given IP addresses or made part of VLAN trunks. (which is what I’m doing here) Now I can go pop the fibers off of one of the SFP ports and the network doesn’t miss a beat. Old skool fun right there, huh?

The names are slightly confusing — the gigabitethernet ports are SFP fiber ports. Here, ports gigabitethernet9 and gigabitethernet10 both have channel-group 1 mode on which make them part of port-channel number 1 . Do that on both sides and the new virtual interface named port-channel can be given IP addresses or made part of VLAN trunks. (which is what I'm doing here) Now I can go pop the fibers off of one of the SFP ports and the network doesn't miss a beat. Old skool fun right there, huh?

WiFi (WiFi)

The one note on the software side of the nanoHD access points (I have 2) is the fact that you can’t set them up in trunk mode. You have to bring them up on an access port, set them up or “assimilate” them (if you already have others running) and then push them into trunk mode later. Curiously they will still send non-tagged packets as well which I guess is a nice to have when trying to recover them.

The one note on the software side of the nanoHD access points (I have 2) is the fact that you can't set them up in trunk mode. You have to bring them up on an access port, set them up or “assimilate” them (if you already have others running) and then push them into trunk mode later. Curiously they will still send non-tagged packets as well which I guess is a nice to have when trying to recover them.

These things work fine on their own but you can also download and run the free management package on a spare Linux instance if you want. Or get an Ubiquity appliance that does the same thing — this is how Ubiquiti sucks you in. Regardless, they are very effective. Most of the ancellary “features” can be switched off (such as the DHCP server in my case) so it flexes to most situations you might find. While I’m not a fan of radio backhaul, they do have two radios so you can do that too if you want. As I say — very flexible.

These things work fine on their own but you can also download and run the free management package on a spare Linux instance if you want. Or get an Ubiquity appliance that does the same thing — this is how Ubiquiti sucks you in. Regardless, they are very effective. Most of the ancellary “features” can be switched off (such as the DHCP server in my case) so it flexes to most situations you might find. While I'm not a fan of radio backhaul, they do have two radios so you can do that too if you want. As I say — very flexible.

I was never a huge fan of “enterprise-y” administration features but in this case, adopting another AP to add capacity is alluring. It is not that I will suddenly get 100 more users — it has more to do with the ability to roll upgrades and swap in new hardware should one of the older ones die. Let’s just say it is better than your entire network being down while you scramble to remember how to configure things. I know, I know, I’ve drunk the cool aid.

I was never a huge fan of “enterprise-y” administration features but in this case, adopting another AP to add capacity is alluring. It is not that I will suddenly get 100 more users — it has more to do with the ability to roll upgrades and swap in new hardware should one of the older ones die. Let's just say it is better than your entire network being down while you scramble to remember how to configure things. I know, I know, I've drunk the cool aid.

Traffic Analysis (Traffic Analysis)

One of the keys to a performant network is to be aware of where the next bottlenecks will be. It changes all the time so knowing what individual components need as they function and what their capacity is so you can plan around them is essential.

One of the keys to a performant network is to be aware of where the next bottlenecks will be. It changes all the time so knowing what individual components need as they function and what their capacity is so you can plan around them is essential.

A key tool in the toolbox is runningiftop on fw. iftop, as the name implies, is top for interfaces instead of processes. Here’s what it looks like while running iftop -i enp2s0.20:

A key tool in the toolbox is running iftop on fw . iftop , as the name implies, is top for interfaces instead of processes. Here's what it looks like while running iftop -i enp2s0.20 :

iftop on enp2s0.20

iftop on enp2s0.20

Let’s look at an example. The AppleTV is always an interesting case due to its unique position in this network. I decided early on to connect it via Ethernet rather than WiFi. I didn’t want to be clogging the WiFi up with high bitrate H.264 streams, especially in an access point controlled network. The concern was copying all data twice over the air. Packets first flow to the access point which would retransmit them to the AppleTV. That seemed like a bad idea.

让我们来看一个例子。 The AppleTV is always an interesting case due to its unique position in this network. I decided early on to connect it via Ethernet rather than WiFi. I didn't want to be clogging the WiFi up with high bitrate H.264 streams, especially in an access point controlled network. The concern was copying all data twice over the air. Packets first flow to the access point which would retransmit them to the AppleTV. That seemed like a bad idea.

Upon closer inspection though, it depends on what you are doing. If you are playing an audio or video stream available on the Internet from a computer to the AppleTV, in some cases the handling is much more efficient. The AppleTV can request streams directly so rather than the stream coming from the Internet to a computer over WiFi, going back over WiFi and then to the AppleTV via Ethernet, the AppleTV just requests it directly from the Internet to the AppleTV.

Upon closer inspection though, it depends on what you are doing. If you are playing an audio or video stream available on the Internet from a computer to the AppleTV, in some cases the handling is much more efficient. The AppleTV can request streams directly so rather than the stream coming from the Internet to a computer over WiFi, going back over WiFi and then to the AppleTV via Ethernet, the AppleTV just requests it directly from the Internet to the AppleTV.

If you are screen casting, obviously that just goes over WiFi to the wired network — that seems fairly unavoidably straightforward. Same is true for audio / video files on your local computer. However, there is still quite a bit of infrastructure required. Let’s just look at the screencast scenario. The computer sends a stream to the WiFi access point. That then goes over a tagged VLAN from the access point to a satellite switch. As the computer is on the 10.20.0.0/16 network and the AppleTV is on10.30.0.0/16, the packet’s destination (fw) is on another switch. So the tagged packets go out another trunk port to the main switch and finally to fw over another trunk port. After they pass the iptables rues and forwarded, they are sent, re-tagged, back through the same trunk port to the main switch. Again we go over a trunk port to (possibly another) satellite switch and then finally over an untagged (access) port to the AppleTV. There are a fair amount of possible bottlenecks in this architecture. Clearly if the AppleTV were connected via WiFi, this would be far worse, but it is something to be aware of and watch.

If you are screen casting, obviously that just goes over WiFi to the wired network — that seems fairly unavoidably straightforward. Same is true for audio / video files on your local computer. However, there is still quite a bit of infrastructure required. Let's just look at the screencast scenario. The computer sends a stream to the WiFi access point. That then goes over a tagged VLAN from the access point to a satellite switch. As the computer is on the 10.20.0.0/16 network and the AppleTV is on 10.30.0.0/16 , the packet's destination ( fw ) is on another switch. So the tagged packets go out another trunk port to the main switch and finally to fw over another trunk port. After they pass the iptables rues and forwarded, they are sent, re-tagged, back through the same trunk port to the main switch. Again we go over a trunk port to (possibly another) satellite switch and then finally over an untagged (access) port to the AppleTV. There are a fair amount of possible bottlenecks in this architecture. Clearly if the AppleTV were connected via WiFi, this would be far worse, but it is something to be aware of and watch.

Possible Upgrades (Possible Upgrades)

I don’t really think I need a bandwidth upgrade although that seems to be the simplest option. (swap all the Gigabit trunk SFPs with 10 Gigabit ones) The bottlenecks would just move to switch backplane capacity at that point. I’m also not clear these switches can take advantage of 10 Gigabit ports anyway.

I don't really think I need a bandwidth upgrade although that seems to be the simplest option. (swap all the Gigabit trunk SFPs with 10 Gigabit ones) The bottlenecks would just move to switch backplane capacity at that point. I'm also not clear these switches can take advantage of 10 Gigabit ports anyway.

There are a million home automation upgrades I could make but I am sticking to the basics there rather than the fad-y.

There are a million home automation upgrades I could make but I am sticking to the basics there rather than the fad-y.

I could use some better logging and monitoring. Sadly I don’t think you can get much from HomeKit hubs about what was turned on or off when and things like that — I think you have to read current state somehow and compare it to what you last saw. That might be an interesting direction.

I could use some better logging and monitoring. Sadly I don't think you can get much from HomeKit hubs about what was turned on or off when and things like that — I think you have to read current state somehow and compare it to what you last saw. That might be an interesting direction.

I am also working on a number of environmental monitors from the mundane (humidity / temperature sensors) to the esoteric. (nuclear radiation detectors) I have been testing a solid state chip for the latter called the BG51 from Advatech UK Limited.

I am also working on a number of environmental monitors from the mundane (humidity / temperature sensors) to the esoteric. (nuclear radiation detectors) I have been testing a solid state chip for the latter called the BG51 from Advatech UK Limited.

I have a fairly extensive Software Defined Radio collection mostly based around the Ettus Research devices, particularly the N210. Most of the use there has been research related to GSM base stations and precision timing for location purposes. However, I am a helicopter pilot so I had to test out listening for ADSB. It turns out to work extremely well, especially from my relatively high perch of a house. With a fairly lackluster antenna, I’m able to decode broadcasts from airplanes more than 50 miles away.

I have a fairly extensive Software Defined Radio collection mostly based around the Ettus Research devices, particularly the N210 . Most of the use there has been research related to GSM base stations and precision timing for location purposes. However, I am a helicopter pilot so I had to test out listening for ADSB. It turns out to work extremely well, especially from my relatively high perch of a house. With a fairly lackluster antenna, I'm able to decode broadcasts from airplanes more than 50 miles away.

I’d love to do a weather station at some point — haven’t looked into options — but it would have to be fairly robust. I don’t like the idea of having to replace something like that a year or two down the road. (nor do I like having to change batteries) Any suggestions of rugged options are welcome.

I'd love to do a weather station at some point — haven't looked into options — but it would have to be fairly robust. I don't like the idea of having to replace something like that a year or two down the road. (nor do I like having to change batteries) Any suggestions of rugged options are welcome.

I have also been quite a fan of goTenna and their “mesh networking without the Internet” ethos. I have the consumer devices but would love to run a repeater. I know a bunch of people do this but they seem to take the consumer product and ruggedize it by putting it in a weatherproof box with a solar cell and a big USB battery. I’d rather run a board without the consumer-y bits. This remains in the research stage for me.

I have also been quite a fan of goTenna and their “mesh networking without the Internet” ethos. I have the consumer devices but would love to run a repeater. I know a bunch of people do this but they seem to take the consumer product and ruggedize it by putting it in a weatherproof box with a solar cell and a big USB battery. I'd rather run a board without the consumer-y bits. This remains in the research stage for me.

There are plenty of other ideas I’ve been mulling over that haven’t made this list but they do strain the line around what the common person might consider a “home network” so I’ll stop here. If you have suggestions though, leave a comment.

There are plenty of other ideas I've been mulling over that haven't made this list but they do strain the line around what the common person might consider a “home network” so I'll stop here. If you have suggestions though, leave a comment.

结论 (Conclusion)

You can go anywhere from basic to full-on bonkers with this stuff. Many companies sell “solutions” that go beyond the garbage access point you tend to get from ISPs so I get the feeling this is an area people are becoming more aware of and therefore demanding better options. I have always preferred a little deeper control than most of these solutions tend to provide so I head toward the enterprise class but try to do so on a comparably shoestring budget. (although I don’t skimp one super core things like WiFi)

You can go anywhere from basic to full-on bonkers with this stuff. Many companies sell “solutions” that go beyond the garbage access point you tend to get from ISPs so I get the feeling this is an area people are becoming more aware of and therefore demanding better options. I have always preferred a little deeper control than most of these solutions tend to provide so I head toward the enterprise class but try to do so on a comparably shoestring budget. (although I don't skimp one super core things like WiFi)

I hope this treatise has sparked some ideas. If you do things differently, especially if you have strong opinions loosely held as I do, I’d like to hear from you. Please drop a comment with your experiences. I’m also very open to suggestions for improvements. This is a live and evolving system; it gets better with cross pollination.

I hope this treatise has sparked some ideas. If you do things differently, especially if you have strong opinions loosely held as I do, I'd like to hear from you. Please drop a comment with your experiences. I'm also very open to suggestions for improvements. This is a live and evolving system; it gets better with cross pollination.

Thanks and happy hacking!

Thanks and happy hacking!

翻译自: https://medium.com/swlh/a-home-network-8049bf5fe886

家庭网络搭建