JakeHillion/dissertation-4-dissertation
1
0
Fork 0
Code Issues Pull Requests Releases 1 Wiki Activity

Update on Overleaf.

Browse Source
This commit is contained in:
jsh77 2021-05-13 23:34:46 +00:00 committed by overleaf
parent 7c545edaf1
commit 5abb8fc0c9
2 changed files with 17 additions and 60 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

5
3_Implementation/implementation.tex
View File

@ -269,7 +269,7 @@ This demonstrates the flexibility of combining the exchange interface with other
% ------------------------ Repository Overview ----------------------------- %
\subsection{Repository Overview}
A directory tree of the repository is provided in Figure \ref{fig:repository-structure}. The top level is split between \verb'code' and \verb'evaluation', where \verb'code' is compiled into the application binary, and \verb'evaluation' is used to verify the performance characteristics and generate graphs.
A directory tree of the repository is provided in Figure \ref{fig:repository-structure}. The top level is split between \verb'code' and \verb'evaluation', where \verb'code' is compiled into the application binary, and \verb'evaluation' is used to verify the performance characteristics and generate graphs. The Go code is built with the Go modules system, the Java code built with Gradle, and the Python code runs in an iPython notebook. Go tests are interspersed with the code, for example in a file named \texttt{flow\_test.go}, providing tests for \texttt{flow.go} in the same directory.
\begin{figure}
\dirtree{%
@ -278,14 +278,15 @@ A directory tree of the repository is provided in Figure \ref{fig:repository-str
.3 config\DTcomment{Configuration management}.
.3 crypto\DTcomment{Cryptographic methods}.
.4 sharedkey\DTcomment{Shared key MACs}.
.3 flags\DTcomment{Command line flag processing}.
.3 mocks\DTcomment{Mocks to enable testing}.
.3 proxy\DTcomment{The central proxy controller}.
.3 replay\DTcomment{Replay protection}.
.3 shared\DTcomment{Shared errors}.
.3 tcp\DTcomment{TCP flow transport}.
.3 tun\DTcomment{TUN adapter}.
.3 udp\DTcomment{UDP datagram transport}.
.4 congestion\DTcomment{Congestion control methods}.
.3 utils\DTcomment{Common data structures}.
.2 evaluation\DTcomment{Result gathering and graph generation}.
.3 java\DTcomment{Java automated result gathering}.
.3 python\DTcomment{Python graph generation}.

72
4_Evaluation/evaluation.tex
View File

@ -11,7 +11,7 @@
\graphicspath{{4_Evaluation/Figs/Vector/}{4_Evaluation/Figs/}}
\fi
This chapter will discuss the methods used to evaluate my project and the results gained. The results will be discussed in the context of the success criteria laid out in the Project Proposal.
This chapter will discuss the methods used to evaluate my project and the results gained. The results will be discussed in the context of the success criteria laid out in the Project Proposal (Appendix \ref{appendix:project-proposal}).
This evaluation shows that a network using my method of combining Internet connections can see vastly superior network performance to one without. It will show the benefits to throughput, availability, and adaptability.
@ -42,8 +42,8 @@ To generate these results, a fresh set of VMs (Virtual Machines) are created and
% Nodes
\node[squarednode] at (0,0) (speedtest) {Speed Test Server};
\node[squarednode] at (4,0) (remoteportal) {Remote Portal};
\node[squarednode] at (8,0) (localportal) {Local Portal};
\node[squarednode] at (4,0) (remoteportal) {Remote Proxy};
\node[squarednode] at (8,0) (localportal) {Local Proxy};
\node[squarednode] at (11,0) (client) {Client};
% Edges
@ -65,7 +65,7 @@ To generate these results, a fresh set of VMs (Virtual Machines) are created and
\label{fig:standard-network-structure}
\end{figure}
The network structure of all standard tests is shown in figure \ref{fig:standard-network-structure}. Any deviations from this structure will be mentioned. The Local Portal has as many interfaces as referenced in any test, plus one to connect to the client. All Virtual Machines also have an additional interface for management, but this has no effect on the tests.
The network structure of all standard tests is shown in figure \ref{fig:standard-network-structure}. Any deviations from this structure will be mentioned. The Local proxy has as many interfaces as referenced in any test, plus one to connect to the client. All Virtual Machines also have an additional interface for management, but this has no effect on the tests.
\section{Success Criteria}
@ -118,9 +118,9 @@ Figure \ref{fig:bidirectional-gains} shows two graphs of the same set of tests -
\subsection{IP Spoofing}
\label{section:ip-spoofing-evaluation}
To demonstrate that the IP of the client can be set to the IP of the remote portal, the network structure shown in figure \ref{fig:standard-network-structure}, used for most of these tests, can be examined further. This will demonstrate that it is possible to set the IP as such, as all of the tests in this section did so.
To demonstrate that the IP of the client can be set to the IP of the remote proxy, the network structure shown in figure \ref{fig:standard-network-structure}, used for most of these tests, can be examined further. This will demonstrate that it is possible to set the IP as such, as all of the tests in this section did so.
In the given network structure, the speed test server, remote portal and local portal are each connected to one virtual switch, which acts as a mock Internet. There is then a separate virtual switch, which connects an additional interface of the local portal to the client. The IP addresses of the interfaces shown in figure \ref{fig:standard-network-structure} are listed in figure \ref{fig:standard-network-structure-ips}. The IP addresses of the public interfaces are represented by letters, as they use arbitrary public IP addresses to ensure no local network firewall rules impact the configuration.
In the given network structure, the speed test server, remote proxy and local proxy are each connected to one virtual switch, which acts as a mock Internet. There is then a separate virtual switch, which connects an additional interface of the local proxy to the client. The IP addresses of the interfaces shown in figure \ref{fig:standard-network-structure} are listed in figure \ref{fig:standard-network-structure-ips}. The IP addresses of the public interfaces are represented by letters, as they use arbitrary public IP addresses to ensure no local network firewall rules impact the configuration.
\begin{figure}
\centering
@ -129,9 +129,9 @@ In the given network structure, the speed test server, remote portal and local p
\hline
Speed Test Server & eth0 & \emph{A} \\
\hline
Remote Portal & eth0 & \emph{B} \\
Remote Proxy & eth0 & \emph{B} \\
\hline
\multirow{5}{*}{Local Portal} & eth0 & \emph{C0} \\
\multirow{5}{*}{Local Proxy} & eth0 & \emph{C0} \\
& eth1 & \emph{C1} \\
& \vdots & \vdots \\
& ethN & \emph{CN} \\
@ -143,13 +143,15 @@ In the given network structure, the speed test server, remote portal and local p
\label{fig:standard-network-structure-ips}
\end{figure}
It is shown that the client in this testing setup shares an IP address with the remote portal. To achieve this, the client configuration is particularly simple. A static route is added for 192.168.1.1 from the eth0 interface, and this then set as the default gateway. The IP address is set as the IP address of the remote portal. The details of this configuration are provided in figure \ref{section:implementation-system-configuration}.
It is shown that the client in this testing setup shares an IP address with the remote proxy. To achieve this, the client configuration is particularly simple. A static route is added for 192.168.1.1 from the eth0 interface, and this then set as the default gateway. The IP address is set as the IP address of the remote proxy. The details of this configuration are provided in figure \ref{section:implementation-system-configuration}.
Given that the client shares the IP address of the remote portal in these cases, it is demonstrated that this success criteria is met. Sharing the IP of the remote portal allows most routers to be configured behind the local portal as a client, allowing it to act as a standard Internet connection. An alternative approach, where the local portal acts as a router, is detailed in section \ref{section:real-world-testing}.
Given that the client shares the IP address of the remote proxy in these cases, it is demonstrated that this success criteria is met. Sharing the IP of the remote proxy allows most routers to be configured behind the local proxy as a client, allowing it to act as a standard Internet connection. An alternative approach, where the local proxy acts as a router, is detailed in section \ref{section:real-world-testing}.
\subsection{Security}
Success in terms of security involves providing security no worse than a standard connection. To demonstrate that this is satisfied, I refer back to section \ref{section:layered-security}, in which I describe the ability for this proxy to be layered with other security software. Specifically, the ability to run this proxy behind the VPN solution Wireguard. By setting up a Wireguard tunnel for each connection and using a separate IP range in each, configuring the proxy to run behind Wireguard is no more complicated than the IP routing necessary. Section \label{section:layered-security} provides an argument that the proxying of packets is made secure by operating in a secure overlay network.
Success for security involves providing security no worse than a standard connection.
Success in terms of security involves providing security no worse than a standard connection. To demonstrate that this is satisfied, I refer back to Section \ref{section:layered-security}, in which I describe the ability for this proxy to be layered with other security software. Specifically, the ability to run this proxy behind the VPN solution Wireguard. By setting up a Wireguard tunnel for each connection and using a separate IP range in each, configuring the proxy to run behind Wireguard is no more complicated than the IP routing necessary. Section \ref{section:layered-security} provides an argument that the proxying of packets is made secure by operating in a secure overlay network.
Therefore, to provide security no worse than a standard connection, it is sufficient to show that the security provided is better than a standard connection. If Wireguard provides security better than a standard connection, then it is possible for this proxy to be configured such that it provides security no worse than a standard connection. Further, if any solution which this can be configured behind, such as IPsec Authentication Headers, provides the correct security guarantees, then the security is no worse.
@ -266,7 +268,7 @@ The proxy only supports TCP and UDP flows for carrying the proxied data.
\section{Performance Evaluation}
\label{section:performance-evaluation}
The discussion of success criteria above used relatively slow network connections to test scaling in certain situations. This section will focus on testing how the solution scales, in terms of faster individual connections, and with many more connections. Further, all of the above tests were automated and carried out entirely on virtual hardware. This section will show some `real-world' data, using a Raspberry Pi 4B and real Internet connections.
The discussion of success criteria above used relatively slow network connections to test scaling in certain situations. This section will focus on testing how the solution scales, in terms of faster individual connections, and with many more connections.
\subsection{Faster Connections Scaling}
@ -276,49 +278,3 @@ The discussion of success criteria above used relatively slow network connection
\label{section:number-of-connections-scaling}
\mynote{Needs more data.}
\subsection{Real World Testing}
\label{section:real-world-testing}
Although the success criteria of this project revolve around virtual hardware, it extends into the real world. This section will describe the application of this proxy to my network, including the considerations made in network design.
\begin{figure}
\centering
\begin{tikzpicture}[
rednode/.style={rectangle, draw=black!60, fill=red!5, very thick, minimum size=5mm},
bluenode/.style={rectangle, draw=black!60, fill=blue!5, very thick, minimum size=5mm},
]
% Nodes
\node[rednode] at (0,2) (modema) {Modem A};
\node[rednode] at (0,0) (modemb) {Modem B};
\node[bluenode] at (4,1) (router) {Multi-WAN Router};
\node[rednode] at (8,2.5) (laptop) {Laptop};
\node[bluenode] at (8,1) (portal) {Local Portal};
\node[rednode] at (8,-0.5) (tablet) {Tablet};
\node[rednode] at (12,2) (server) {Server};
\node[rednode] at (12,0) (phone) {Desk Phone};
% Edges
\draw[->] (modema.east) -- (router.west);
\draw[->] (modemb.east) -- (router.west);
\draw[->] (router.east) -- (laptop.west);
\draw[->] (router.east) -- (portal.west);
\draw[->] (router.east) -- (tablet.west);
\draw[->] (portal.east) -- (server.west);
\draw[->] (portal.east) -- (phone.west);
\end{tikzpicture}
\caption{Real world proxy implementation.}
\label{fig:real-world-network-diagram}
\end{figure}
Figure \ref{fig:real-world-network-diagram} presents the real world deployment as setup in my network. It begins with two modems providing two Internet connections to the multi-WAN router. The multi-WAN router uses session based load balancing to achieve usage of both connections simultaneously, across multiple devices. For some devices, such as laptops and tablets, this is sufficient. To avoid the extra cost of proxying traffics, such devices access the Internet directly via the multi-WAN router. Thus far, the configuration is standard for a multi-ISP setup.
Behind the multi-WAN router lies the local portal. Using a multi-WAN router here simplifies the configuration of the local portal. By forwarding a port from both WANs on the router to the local portal's internal host, it can receive connections via both WANs with a single IP address. The remote portal is then configured to connect via both IP addresses. The flexibility of the system allows either portal to listen for or initiate connections, which simplifies setup in this use case.
The local portal in this configuration runs FreeBSD\footnote{\url{https://www.freebsd.org/}} 13 on a Raspberry Pi 4. To make the most use of the proxied IP address, the local portal is configured as a NAT router. Source NAT is configured to translate the source address of outgoing packets to the address of the remote portal, allowing them to be proxied. Destination NAT is used to forward ports from the remote portal's IP address to the devices on the internal network.