Update on Overleaf.

0_Proforma/proforma.tex

@@ -6,7 +6,7 @@
     Candidate Number:    & 2373A \\
     Project Title:       & A Multi-Path Bidirectional Layer 3 Proxy \\
     Examination:         & Computer Science Tripos - Part II, 2021 \\
-    Word Count:          & 12740 \\
+    Word Count:          & 13716 \\
     Line Count:          & 2705 \\
     Project Originator:  & The dissertation author \\
     Supervisor:          & Michael Dodson

3_Implementation/implementation.tex

@@ -339,14 +339,14 @@ FreeBSD:
 
 \inputminted{shell-session}{3_Implementation/Samples/shell/freebsd_remote_routing.sh}
 
-These settings combined will provide the proxying effect via the TUN interface configured in software. It is also likely worth firewalling much more aggressively at the remote portal side, as dropping packets before saturating the low bandwidth connections between the local and remote portal improves resilience to denial of service attacks. This can be completed either with similar routing and firewall rules to those above, or externally with many cloud providers.
+These settings combined will provide the proxying effect via the TUN interface configured in software. It is also likely worth firewalling much more aggressively at the remote proxy side, as dropping packets before saturating the low bandwidth connections between the local and remote proxy improves resilience to denial of service attacks. This can be completed either with similar routing and firewall rules to those above, or externally with many cloud providers.
 
-\subsection{Local Portal Routing}
+\subsection{Local Proxy Routing}
-\label{section:implementation-local-portal-routing}
+\label{section:implementation-local-proxy-routing}
 
-Routing within the local portal expects $1+N$ interfaces: one connected to the client device expecting the public IP, and $N$ connected to the wider Internet for communication with the other node. Referring to figure \ref{fig:dataflow-overview}, it can be seen that no complex rules are required to achieve this routing, as each interface serves a different role. As such, there are three goals: ensure the packets for the remote IP are routed from the TUN to the client device and vice versa, ensuring that packets destined for the remote portal are not routed to the client, and ensuring each connection is routed via the correct WAN connection. The first two will be covered in this section, with a discussion on the latter in the next section.
+Routing within the local proxy expects $1+N$ interfaces: one connected to the client device expecting the public IP, and $N$ connected to the wider Internet for communication with the other node. Referring to figure \ref{fig:dataflow-overview}, it can be seen that no complex rules are required to achieve this routing, as each interface serves a different role. As such, there are three goals: ensure the packets for the remote IP are routed from the TUN to the client device and vice versa, ensuring that packets destined for the remote proxy are not routed to the client, and ensuring each connection is routed via the correct WAN connection. The first two will be covered in this section, with a discussion on the latter in the next section.
 
-Routing the packets from/for the local portal is pleasantly easy. Firstly, enable IP forwarding for Linux or gateway mode for FreeBSD, as seen previously. Secondly, routes must be setup. Fortunately, these routes are far simpler than those for the remote portal. The routing for the local portal client interface is as follows on Linux:
+Routing the packets from/for the local proxy is pleasantly easy. Firstly, enable IP forwarding for Linux or gateway mode for FreeBSD, as seen previously. Secondly, routes must be setup. Fortunately, these routes are far simpler than those for the remote proxy. The routing for the local proxy client interface is as follows on Linux:
 
 \inputminted{shell-session}{3_Implementation/Samples/shell/linux_local_interface.sh}
 
@@ -355,7 +355,7 @@ Or on FreeBSD:
 
 \inputminted{shell-session}{3_Implementation/Samples/shell/freebsd_local_interface.sh}
 
-Then, on the client device, simply set the IP address statically to the remote portal address, and the gateway to \verb'192.168.1.1'. Now the local portal can send and receive packets to the remote portal, but some further routing rules are needed to ensure that the packets from the proxy reach the remote portal, and that forwarding works correctly. This falls to routing tables and \verb'pf(4)', so for Linux:
+Then, on the client device, simply set the IP address statically to the remote proxy address, and the gateway to \verb'192.168.1.1'. Now the local proxy can send and receive packets to the remote proxy, but some further routing rules are needed to ensure that the packets from the proxy reach the remote proxy, and that forwarding works correctly. This falls to routing tables and \verb'pf(4)', so for Linux:
 
 \inputminted{shell-session}{3_Implementation/Samples/shell/linux_local_routing.sh}
 
@@ -364,7 +364,7 @@ FreeBSD:
 
 \inputminted{shell-session}{3_Implementation/Samples/shell/freebsd_local_routing.sh}
 
-These rules achieve both the listed criteria, of communicating with the remote portal while also forwarding the packets necessary to the client. The local portal can be extended with more functionality, such as NAT and DHCP. This allows plug and play for the client, while also allowing multiple clients to take advantage of the connection without another router present. 
+These rules achieve both the listed criteria, of communicating with the remote proxy while also forwarding the packets necessary to the client. The local proxy can be extended with more functionality, such as NAT and DHCP. This allows plug and play for the client, while also allowing multiple clients to take advantage of the connection without another router present. 
 
 \subsection{Multi-Homed Behaviour}
 \label{section:implementation-multi-interface-routing}
@@ -384,4 +384,4 @@ sysctl -w net.ipv4.conf.all.arp_ignore=1
 
 \end{minted}
 
-The final discovery I made is that many of these problems can be solved by changing the question. In my real world testing, explained in section \ref{section:real-world-testing}, the local portal lies behind a dual WAN router. This router allows the same port to be accessible via two WAN IPs, and avoids any routing complication as the router itself handles the NAT perfectly. Prior to this I was attempting to route outbound, similar to the situation described above, with some difficulty. Hence it is worth considering whether an architecture modification can make the routing simpler for the task you are trying to achieve.
+The final discovery I made is that many of these problems can be solved by changing the question. In my real world testing, explained in section \ref{section:real-world-testing}, the local proxy lies behind a dual WAN router. This router allows the same port to be accessible via two WAN IPs, and avoids any routing complication as the router itself handles the NAT perfectly. Prior to this I was attempting to route outbound, similar to the situation described above, with some difficulty. Hence it is worth considering whether an architecture modification can make the routing simpler for the task you are trying to achieve.

thesis.tex

@@ -1,7 +1,7 @@
 % ******************************* PhD Thesis Template **************************
 % Please have a look at the README.md file for info on how to use the template
 
-\documentclass[a4paper,12pt,times,numbered,print,index]{PhDThesisPSnPDF}
+\documentclass[a4paper,12pt,times,oneside,numbered,print,index]{PhDThesisPSnPDF}
 
 % ******************************************************************************
 % ******************************* Class Options ********************************