vasco/FSI
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Cooked.

Browse Source
This commit is contained in:
jelly Tomas
2026-04-29 20:34:13 +01:00
parent 9656c2bee4
commit c277f65fb5
1 changed files with 12 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

23
relatorio/relatorio.tex
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}),
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
separar a máquina de OpenSSL de outras máquinas destinadas a serviços da rede intera,
pois esta contém o \textit{certificate authority} CA.
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).
% Ambos o OpenVPN eo servidor Apache utilizam 2FA,
% 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.
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
que precisam de ser passados mais tarde para aceder ao Apache e ao gateway.
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
com as chaves, requests e certificados necessários.
neste código. Aspetos importantes para mais tarde serão os parâmetros de Comon Name (CN)
pois servem para a validação do certificado ambos pelo OpenSSL e pelo browser.
Nós optamos por assumir que num cenario real, teriamos acesso fisico ás maquinas, por isso em vez
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}
cert_ca="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=CoimbraVPN"
@@ -109,6 +110,7 @@ commonName = supplied
\end{codeblock}
\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,
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}
\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.
Sudo if config %para a config e verificar os ips
ping ip address %para ver se consegue aceder.
sudo systemctl start openvpn-client@config %para depois verificar se connecta
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.
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.