This commit is contained in:
jelly Tomas
2026-04-29 20:34:13 +01:00
parent 9656c2bee4
commit c277f65fb5

View File

@@ -40,8 +40,8 @@ OpenVPN e Apache, e gerir certificados X.509 utilizando OCSP.
Decidimos utilizar apenas três máquinas virtuais: o cliente (ou \textit{road warrior}), Decidimos utilizar apenas três máquinas virtuais: o cliente (ou \textit{road warrior}),
a \textit{gateway} que utiliza OpenVPN e um servidor interno com OpenSSL e Apache. a \textit{gateway} que utiliza OpenVPN e um servidor interno com OpenSSL e Apache.
Isto simplifica a elaboração do projecto, mas por razões de segurança poderia querer Isto simplifica a elaboração do projecto, mas por razões de segurança poderia querer
separar a máquina de OpenSSL de outras máquinas destinadas a serviços da rede intera, separar a máquina de OpenSSL de outras máquinas destinadas a serviços da rede interna,
pois esta contém o \textit{certificate authority} CA. pois esta contém o \textit{certificate authority} (CA).
% Ambos o OpenVPN eo servidor Apache utilizam 2FA, % Ambos o OpenVPN eo servidor Apache utilizam 2FA,
% recebendo o utilizador, e uma password que é uma concatenação da palavra-passe do utilizador % recebendo o utilizador, e uma password que é uma concatenação da palavra-passe do utilizador
@@ -62,11 +62,12 @@ Os certificados utilizados foram auto-certificados por uma autoridade central qu
à máquina de OpenSSL. Esta mesma faz a gestão da lista de revogação. à máquina de OpenSSL. Esta mesma faz a gestão da lista de revogação.
Todas as chaves foram criadas no mesmo computador, com as variáveis que estão Todas as chaves foram criadas no mesmo computador, com as variáveis que estão
neste código, aspetos importantes para mais tarde serão os parâmetros de CN neste código. Aspetos importantes para mais tarde serão os parâmetros de Comon Name (CN)
que precisam de ser passados mais tarde para aceder ao Apache e ao gateway. pois servem para a validação do certificado ambos pelo OpenSSL e pelo browser.
Numa situação normal teríamos uma autoridade de certificação para enviar e
no fundo gerir todos, mas para este cenário podemos inicializar as máquinas Nós optamos por assumir que num cenario real, teriamos acesso fisico ás maquinas, por isso em vez
com as chaves, requests e certificados necessários. de utilizar, por exemplo SCP ou FTP, escolhemos partilhar os ficheiros a partir da maquina host. No entanto outra abordagem também estaria correta.
%John LIMBUS HIMSELF
\begin{codeblock}[bash]{create\_all\_keys.sh} \begin{codeblock}[bash]{create\_all\_keys.sh}
cert_ca="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=CoimbraVPN" cert_ca="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=CoimbraVPN"
@@ -109,6 +110,7 @@ commonName = supplied
\end{codeblock} \end{codeblock}
\subsection{Configuração geral} \subsection{Configuração geral}
Para evitar repetição e redundancia; e para garantir consistencia na elaboração do projeto criamos varios shell scripts, um destinado a cada maquina virtual.
Para configurar as VMs era preciso introduzir os mesmos comandos várias vezes, o que levava muitas vezes a erros de escrita, Para configurar as VMs era preciso introduzir os mesmos comandos várias vezes, o que levava muitas vezes a erros de escrita,
ou a correr o mesmo comando várias vezes, por isso criamos vários ficheiros .sh para conseguir facilitar o processo. ou a correr o mesmo comando várias vezes, por isso criamos vários ficheiros .sh para conseguir facilitar o processo.
@@ -360,10 +362,9 @@ auth SHA256
\end{codeblock} \end{codeblock}
\subsection{Testes} \subsection{Testes}
Verificamos que conseguimos correr o serviço, e que ao fazer if config temos a configuração, e que conseguimos dar ping, ao router e ao outro servidor. Para verificar que a autenticação foi corretamente implementada, inserimos a password de um utilizador sem os digitos do TOTP, e identificamos que utilizar somente a password não é suficiente para autenticar. Igualmente ao utilizar ambos a autenticação é bem sucedida.
Sudo if config %para a config e verificar os ips
ping ip address %para ver se consegue aceder. Para verificar que o tunel foi estabelecido, primeiro corremos na linha de comandos \texttt{ip a}. Observamos a existencia de uma nova interface tun0, ou seja o tunel foi corretamente establecido. Depois demos ping ao route e depois ao servidor interno, que resultou em pacotes devolvidos para ambos.
sudo systemctl start openvpn-client@config %para depois verificar se connecta