Color-code Nebula and regular IPs

docs/config/firewall.mdx

@@ -59,11 +59,11 @@ The possible fields of a firewall rule are:
 - `groups`: Same as `group` but accepts a list of values. Multiple values are AND'd together and a certificate must
   contain all groups to pass.
 
-- `cidr`: a CIDR, `0.0.0.0/0` is any. This restricts which Nebula IP addresses the rule allows.
+- `cidr`: a CIDR, `0.0.0.0/0` is any. This restricts which <OverlayIP>Nebula IP</OverlayIP> addresses the rule allows.
 
-- `local_cidr`: a local CIDR, `0.0.0.0/0` is any. This restricts which destination IP addresses, when using
-  unsafe_routes, the rule allows. If unset, the rule will allow access to the specified ports on both the node itself as
-  well as any IP addresses it routes to.
+- `local_cidr`: a local CIDR, `0.0.0.0/0` is any. This restricts which <UnderlayIP>destination IP
+  addresses</UnderlayIP>, when using unsafe_routes, the rule allows. If unset, the rule will allow access to the
+  specified ports on both the node itself as well as any <UnderlayIP>IP addresses</UnderlayIP> it routes to.
 
 :::note
 

docs/config/lighthouse.mdx

@@ -58,14 +58,15 @@ name resolution by external DNS hosts. To enable listening on IPv6 in addition t
 The DNS listener can only respond to requests about hosts it's aware of. For this reason, it can only be enabled on
 Lighthouses.
 
-`A` records contain the Nebula IP for a host name and can be queried by any host that can reach the DNS listener,
-regardless of whether it is communicating over the Nebula network.
+`A` records contain the <OverlayIP>Nebula IP</OverlayIP> for a host name and can be queried by any host that can reach
+the DNS listener, regardless of whether it is communicating over the Nebula network.
 
 `TXT` records can only be queried over the Nebula network, and contain certificate information for the requested host IP
 address.
 
-For example, if `192.168.100.1` was your Lighthouse node running a DNS server and you wanted to find the Nebula IP
-address of a host named `web01`:
+For example, if `192.168.100.1` was your Lighthouse node running a DNS server and you wanted to find the
+
+<OverlayIP>Nebula IP</OverlayIP> address of a host named `web01`:
 
 ```shell
 $ dig @192.168.100.1 +short web01 A
@@ -101,8 +102,9 @@ firewall:
 ## lighthouse.dns
 
 `dns` is used to configure the address (`host`) and port (`port`) the DNS server should listen on. By listening on the
-host's Nebula IP, you can make the DNS server accessible only on the Nebula network. Alternatively, listening on
-`0.0.0.0` will allow anyone that can reach the host to make queries.
+host's <OverlayIP>Nebula IP</OverlayIP>, you can make the DNS server accessible only on the Nebula network.
+Alternatively, listening on <UnderlayIP>`0.0.0.0`</UnderlayIP> will allow anyone that can reach the host to make
+queries.
 
 The default value for `dns.port` is `53` but you must set an IP address.
 
@@ -135,7 +137,8 @@ This should be empty on lighthouse nodes
 :::
 
 `hosts` is a list of lighthouse hosts this node should report to and query from. The lighthouses listed here should be
-referenced by their **nebula IP**, not by the IPs of their physical network interfaces.
+referenced by their <OverlayIP>**nebula IP**</OverlayIP>, not by the <UnderlayIP>IPs</UnderlayIP> of their physical
+network interfaces.
 
 ```yml
 lighthouse:
@@ -147,11 +150,12 @@ lighthouse:
 
 <Pill className="mb-24">Reloadable</Pill>
 
-`remote_allow_list` allows you to control ip ranges that this node will consider when handshaking to another node. By
-default, any remote IPs are allowed. You can provide CIDRs here with `true` to allow and `false` to deny. The most
-specific CIDR rule applies to each remote. If all rules are "allow", the default will be "deny", and vice-versa. If both
-"allow" and "deny" rules are present, then you MUST set a rule for "0.0.0.0/0" as the default. Similarly if both "allow"
-and "deny" IPv6 rules are present, then you MUST set a rule for "::/0" as the default.
+`remote_allow_list` allows you to control <UnderlayIP>ip ranges</UnderlayIP> that this node will consider when
+handshaking to another node. By default, any <UnderlayIP>remote IPs</UnderlayIP> are allowed. You can provide CIDRs here
+with `true` to allow and `false` to deny. The most specific CIDR rule applies to each remote. If all rules are "allow",
+the default will be "deny", and vice-versa. If both "allow" and "deny" rules are present, then you MUST set a rule for
+"0.0.0.0/0" as the default. Similarly if both "allow" and "deny" IPv6 rules are present, then you MUST set a rule for
+"::/0" as the default.
 
 ```yml
 lighthouse:
@@ -168,10 +172,11 @@ lighthouse:
 
 <Pill className="mb-24">Reloadable</Pill>
 
-`local_allow_list` allows you to filter which local IP addresses we advertise to the lighthouses. This uses the same
-logic as `remote_allow_list`, but additionally, you can specify an `interfaces` map of regular expressions to match
-against interface names. The regexp must match the entire name. All interface rules must be either true or false (and
-the default will be the inverse). CIDR rules are matched after interface name rules. Default is all local IP addresses.
+`local_allow_list` allows you to filter which <UnderlayIP>local IP addresses</UnderlayIP> we advertise to the
+lighthouses. This uses the same logic as `remote_allow_list`, but additionally, you can specify an `interfaces` map of
+regular expressions to match against interface names. The regexp must match the entire name. All interface rules must be
+either true or false (and the default will be the inverse). CIDR rules are matched after interface name rules. Default
+is all <UnderlayIP>local IP addresses</UnderlayIP>.
 
 ```yml
 lighthouse:
@@ -188,11 +193,11 @@ lighthouse:
 
 <Pill className="mb-24">Reloadable</Pill>
 
-`advertise_addrs` are routable addresses that will be included along with discovered addresses to report to the
-lighthouse. The format is "ip:port". `port` can be `0`, in which case the actual listening port will be used in its
-place, useful if `listen.port` is set to `0`. This option is mainly useful when there are static IP addresses the host
-can be reached at that nebula can not typically discover on its own (e.g. when port forwarding or when the node has
-multiple paths to the internet.)
+`advertise_addrs` are <UnderlayIP>routable addresses</UnderlayIP> that will be included along with discovered addresses
+to report to the lighthouse. The format is "ip:port". `port` can be `0`, in which case the actual listening port will be
+used in its place, useful if `listen.port` is set to `0`. This option is mainly useful when there are <UnderlayIP>static
+IP addresses</UnderlayIP> the host can be reached at that nebula can not typically discover on its own (e.g. when port
+forwarding or when the node has multiple paths to the internet.)
 
 ## lighthouse.calculated_remotes
 
@@ -205,9 +210,11 @@ might be for a host while it waits for the lighthouse response.
 
 :::
 
-For any Nebula IPs in the range, it will apply the mask and add the calculated IP as the initial remote (while it waits
-for the response from the lighthouse). Both CIDRs must have the same mask size. For example, Nebula IP 10.0.10.123 will
-have a calculated remote of 192.168.1.123.
+For any <OverlayIP>Nebula IPs</OverlayIP> in the range, it will apply the mask and add the <UnderlayIP>calculated
+IP</UnderlayIP> as the initial remote (while it waits for the response from the lighthouse). Both CIDRs must have the
+same mask size. For example, <OverlayIP>Nebula IP 10.0.10.123</OverlayIP> will have a calculated remote of
+
+<UnderlayIP>192.168.1.123</UnderlayIP>.
 
 ```yml
 calculated_remotes:

docs/config/listen.mdx

@@ -22,8 +22,9 @@ listen:
 
 <Pill className="mb-24">Default: 0.0.0.0</Pill>
 
-`host` is the ip of the interface to use when binding the listener. The default is `0.0.0.0` for all IPv4 interfaces. To
-enable IPv6, use `'[::]'` instead. `host` may also contain a hostname.
+`host` is the ip of the interface to use when binding the listener. The default is <UnderlayIP>`0.0.0.0`</UnderlayIP>
+for all IPv4 interfaces. To enable IPv6, use <UnderlayIP>`'[::]'`</UnderlayIP> instead. `host` may also contain a
+hostname.
 
 ## listen.port
 

docs/config/preferred-ranges.mdx

@@ -9,10 +9,12 @@ import { Pill } from '@components/Pill/Pill';
 
 <Pill className="mb-24">Reloadable</Pill>
 
-`preferred_ranges` sets the priority order for underlay IP addresses. Two hosts on the same LAN would likely benefit
-from having their tunnels use the LAN IP addresses rather than the public IP addresses the lighthouse may have learned
-for them. `preferred_ranges` accepts a list of [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing)
-ranges admitted as a set of preferred ranges of IP addresses.
+`preferred_ranges` sets the priority order for <UnderlayIP>underlay IP addresses</UnderlayIP>. Two hosts on the same LAN
+would likely benefit from having their tunnels use the <UnderlayIP>LAN IP addresses</UnderlayIP> rather than the
+
+<UnderlayIP>public IP addresses</UnderlayIP> the lighthouse may have learned for them. `preferred_ranges` accepts a list
+of [CIDR](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) ranges admitted as a set of preferred ranges of
+<UnderlayIP>IP addresses</UnderlayIP>.
 
 > An underlay network is the network that a nebula [overlay network](https://en.wikipedia.org/wiki/Overlay_network) maps
 > onto. It is the LAN network that a host is connected to in addition to the wider internet.

docs/config/relay.mdx

@@ -26,8 +26,8 @@ relay:
 
 In order to act as a relay for other hosts, `am_relay` must be set to true (default false.) In order to use relays, a
 host must have `use_relays` set to true (default true.) Any host can be a relay; it does not need to be a lighthouse.
-However, like lighthouses, relay nodes should be deployed with a public internet IP and firewall rules that permit
-Nebula's UDP traffic inbound.
+However, like lighthouses, relay nodes should be deployed with a <UnderlayIP>public internet IP</UnderlayIP> and
+firewall rules that permit Nebula's UDP traffic inbound.
 
 Hosts specify which other hosts may act as a relay when connecting to them via the `relays` option in the config. This
 allows hosts to specify relays that are "close" to them. For example, if you have some Nebula hosts in a private AWS
@@ -40,8 +40,10 @@ their own config.
 
 <Pill className="mb-24">Reloadable</Pill>
 
-`relays` is a list of Nebula IPs that peers can use to relay packets to this host. IPs in this list must have `am_relay`
-set to `true` in their configs, otherwise they will reject relay requests.
+`relays` is a list of <OverlayIP>Nebula IPs</OverlayIP> that peers can use to relay packets to this host.
+
+<OverlayIP>IPs</OverlayIP> in this list must have `am_relay` set to `true` in their configs, otherwise they will reject
+relay requests.
 
 ```yml
 relays:
@@ -50,7 +52,7 @@ relays:
 ```
 
 This list of relays is reported to the Lighthouse. When other nodes attempt to handshake with this host, the Lighthouse
-will indicate its supported relays in addition to its known IP addresses.
+will indicate its supported relays in addition to its <UnderlayIP>known IP addresses</UnderlayIP>.
 
 ## relay.am_relay
 

docs/config/sshd.mdx

@@ -38,8 +38,8 @@ See also the [Debugging with Nebula SSH commands](/docs/guides/debug-ssh-command
 
 <Pill className="mb-24">Reloadable</Pill>
 
-`listen` is used to specify the host ip and port number for the nebula debug console to listen on, port 22 is not
-allowed for your safety.
+`listen` is used to specify the <UnderlayIP>host ip</UnderlayIP> and port number for the nebula debug console to listen
+on, port 22 is not allowed for your safety.
 
 ## sshd.host_key
 

docs/config/static-host-map.mdx

@@ -5,8 +5,9 @@ description: Define the static host map to enable peer discovery on the Nebula n
 
 # static_host_map
 
-The static host map defines a set of hosts with fixed IP addresses on the internet (or any network). A host can have
-multiple fixed IP addresses defined here, and nebula will try each when establishing a tunnel. The syntax is:
+The static host map defines a set of hosts with <UnderlayIP>fixed IP addresses</UnderlayIP> on the internet (or any
+network). A host can have multiple <UnderlayIP>fixed IP addresses</UnderlayIP> defined here, and nebula will try each
+when establishing a tunnel. The syntax is:
 
 `"<nebula ip>": ["<routable ip/dns name>:<routable port>"]`
 

docs/config/tun.mdx

@@ -66,8 +66,8 @@ Default MTU for every packet, safe setting is (and the default) 1300 for interne
 
 <Pill className="mb-24">Reloadable</Pill>
 
-Route based MTU overrides. If you have known VPN IP paths that can support larger MTUs you can increase/decrease them
-here.
+Route based MTU overrides. If you have known VPN <UnderlayIP>IP paths</UnderlayIP> that can support larger MTUs you can
+increase/decrease them here.
 
 ```yml
 tun:

src/components/Highlight.tsx

@@ -0,0 +1,21 @@
+import React from 'react';
+
+type Props = {
+  children: React.ReactNode;
+  color: string;
+};
+
+export default function Highlight({ children, color }: Props) {
+  return (
+    <span
+      style={{
+        backgroundColor: color,
+        borderRadius: '2px',
+        color: '#fff',
+        padding: '0.2rem',
+      }}
+    >
+      {children}
+    </span>
+  );
+}

src/components/OverlayIP.tsx

@@ -0,0 +1,16 @@
+import Highlight from './Highlight';
+
+export function OverlayIP({ children }) {
+  return (
+    <span
+      style={{
+        textDecorationColor: 'purple',
+        textDecorationLine: 'underline',
+        textDecorationStyle: 'solid',
+        textDecorationThickness: '2px',
+      }}
+    >
+      {children}
+    </span>
+  );
+}

src/components/UnderlayIP.tsx

@@ -0,0 +1,16 @@
+import Highlight from './Highlight';
+
+export function UnderlayIP({ children }) {
+  return (
+    <span
+      style={{
+        textDecorationColor: 'green',
+        textDecorationLine: 'underline',
+        textDecorationStyle: 'solid',
+        textDecorationThickness: '2px',
+      }}
+    >
+      {children}
+    </span>
+  );
+}

src/css/utility.css

@@ -1,3 +1,11 @@
 .mb-24 {
   margin-bottom: 24px;
 }
+
+.underlay-ip {
+  color: green;
+}
+
+.overlay-ip {
+  color: purple;
+}

src/theme/MDXComponents.tsx

@@ -0,0 +1,16 @@
+// Import the original mapper
+import MDXComponents from '@theme-original/MDXComponents';
+import React from 'react';
+import Highlight from '@src/components/Highlight';
+import { OverlayIP } from '@src/components/OverlayIP';
+import { UnderlayIP } from '@src/components/UnderlayIP';
+
+export default {
+  // Re-use the default mapping
+  ...MDXComponents,
+  // Map the "<Highlight>" tag to our Highlight component
+  // `Highlight` will receive all props that were passed to `<Highlight>` in MDX
+  Highlight,
+  OverlayIP,
+  UnderlayIP,
+};