members off campus.
# Note that part of this diagram appears in The Gate Machine, which
-# should be kept up-to-date with changes made to this diagram.
+# should be kept up-to-date with any changes made here.
#+BEGIN_EXAMPLE
=
| |
============== Gate ================================================
| Private
- +----Ethernet switch
+ +----(Ethernet switch)
|
+----Core
+----Servers (NAS, DVR, etc.)
#+BEGIN_SRC conf :tangle public/vars.yml :mkdirp yes
---
domain_name: small.example.org
-domain_priv: small.private
#+END_SRC
-The private version of the institute's domain name should end with one
-of the top-level domains expected for this purpose: ~.intranet~,
-~.internal~, ~.private~, ~.corp~, ~.home~ or ~.lan~.[fn:5]
+The institute's private domain is treated as sensitive information,
+and so is "tangled" into the example file [[file:private/vars.yml][=private/vars.yml=]] rather
+than [[file:public/vars.yml][=public/vars.yml=]]. The example file is used for testing, and
+serves as the template for an actual, private, =private/var.yml= file
+that customizes this Ansible code for an actual, private, small
+institute.
+
+The institute's private domain name should end with one of the
+top-level domains set aside for this purpose: ~.intranet~,
+~.internal~, ~.private~, ~.corp~, ~.home~ or ~.lan~.[fn:5] It is
+hoped that doing so will increase that chances that some abomination
+like DNS-over-HTTPS will pass us by.
+
+#+CAPTION: [[file:private/vars.yml][=private/vars.yml=]]
+#+BEGIN_SRC conf :tangle private/vars.yml :tangle-mode u=rw :mkdirp yes
+---
+domain_priv: small.private
+#+END_SRC
** Subnets
The four private networks are named and given example CIDRs in the
code block below. The small institute treats these addresses as
-sensitive information so the code block below "tangles" into
+sensitive information so again the code block below "tangles" into
[[file:private/vars.yml][=private/vars.yml=]] rather than [[file:public/vars.yml][=public/vars.yml=]]. Two of the
addresses are in ~192.168~ subnets because they are part of a test
configuration using mostly-default VirtualBoxes (described [[*Testing][here]]).
#+CAPTION: [[file:private/vars.yml][=private/vars.yml=]]
-#+BEGIN_SRC conf :tangle private/vars.yml :tangle-mode u=rw
----
+#+BEGIN_SRC conf :tangle private/vars.yml
+
private_net_cidr: 192.168.56.0/24
public_vpn_net_cidr: 10.177.86.0/24
campus_vpn_net_cidr: 10.84.138.0/24
The current network monitoring is rudimentary. It could use some
love, like intrusion detection via Snort or similar. Services on
Front are not monitored except that the =webupdate= script should be
-emailing ~sysadm~ whenever it cannot update Front.
+emailing ~sysadm~ whenever it cannot update Front (every 15 minutes!).
Pro-active monitoring might include notifying ~root~ of any vandalism
corrected by Monkey's quarter-hourly web update. This is a
-non-trivial task that must ignore intentional changes and save suspect
-changes.
+non-trivial task that must ignore intentional changes.
-Monkey's ~cron~ jobs on Core should presumably become ~systemd.timer~
-and ~.service~ units.
+Monkey's ~cron~ jobs on Core should be ~systemd.timer~ and ~.service~
+units.
The institute's private domain names (e.g. ~www.small.private~) are
not resolvable on Front. Reverse domains (~86.177.10.in-addr.arpa~)
The ~./inst client android dick-phone dick~ command generates =.ovpn=
files that require the member to remember to check the "Use this
-connection only for resources on its network" box in the IPv4 tab of
-the Add VPN dialog. The ~./inst client~ command should include a
-setting in the Debian =.ovpn= files that NetworkManager will recognize
-as the desired setting.
+connection only for resources on its network" box in the IPv4 (and
+IPv6) tab(s) of the Add VPN dialog. The command should include an
+OpenVPN setting that the NetworkManager file importer recognizes as
+the desired setting.
The VPN service is overly complex. The OpenVPN 2.4.7 clients allow
multiple server addresses, but the ~openvpn(8)~ manual page suggests
-per connection parameters are a restricted set that does /not/ include
-the essential ~verify-x509-name~. Use the same name on separate
-certificates for Gate and Front? Use the same certificate and key on
-Gate and Front?
+per connection parameters are restricted to a set that does /not/
+include the essential ~verify-x509-name~. Use the same name on
+separate certificates for Gate and Front? Use the same certificate
+and key on Gate and Front?
Nextcloud should really be found at ~https://CLOUD.small.private/~
rather than ~https://core.small.private/nextcloud/~, to ease
* Footnotes
+[fn:5] The recommended private top-level domains are listed in
+"Appendix G. Private DNS Namespaces" of RFC6762 (Multicast DNS). [[https://www.rfc-editor.org/rfc/rfc6762#appendix-G][link]]
+
[fn:1] Why not create a role named ~all~ and put these tasks that are
the same on all machines in that role? If there were more than a
stable handful, and no tangling mechanism to do the duplication, a
[fn:4] Front is accessible via Gate but routing from the host address
on ~vboxnet0~ through Gate requires extensive interference with the
routes on Front and Gate, making the simulation less... similar.
-
-[fn:5] The recommended private top-level domains are listed in
-"Appendix G. Private DNS Namespaces" of RFC6762 (Multicast DNS). [[https://www.rfc-editor.org/rfc/rfc6762#appendix-G][link]]
projects / Institute / commitdiff