diff --git a/relatorio/relatorio.pdf b/relatorio/relatorio.pdf
index 7b9c456..2c86b89 100644
Binary files a/relatorio/relatorio.pdf and b/relatorio/relatorio.pdf differ
diff --git a/relatorio/relatorio.synctex.gz b/relatorio/relatorio.synctex.gz
new file mode 100644
index 0000000..2645e9d
Binary files /dev/null and b/relatorio/relatorio.synctex.gz differ
diff --git a/relatorio/relatorio.tex b/relatorio/relatorio.tex
index 236e739..2615ef8 100644
--- a/relatorio/relatorio.tex
+++ b/relatorio/relatorio.tex
@@ -38,16 +38,10 @@
 
 \section{Introdução}
 
-Este projecto tem como âmbito implementar uma rede virtual privada (VPN) em um cenário de road-warrior,
-ou seja, onde o administrador de acesso da rede é o cliente ou tem acesso a ele.
+Este projecto tem como âmbito implementar, uma rede virtual privada (VPN) num cenário de road-warrior,
+configurar two-factor authentication com os serviços OpenVPN e Apache, e gerir certificados X.509 utilizando OCSP.
 
-Para tal, foi implementado um servidor e um cliente OpenVPN, certificados por uma autoriadade central (CA)
-que em si é self-signed. Para além disto, foi implementado um sistema de autenticação de dois factores
-através do plugin google-authenticator para o OpenVPN.
-
-Existe ainda um servidor Apache e um servidro de OpenSSL OCSP. Para simpliflicar, a elaboração do 
-projecto foram colocados na mesma maquina virtual, mas por razoes de seguranca poderia querer ter 
-estes serviços separados. 
+O nosso cenario vai envolver três maquinas, o cliente (road warrior), a gateway que utiliza OpenVPN e um servidor interno com OpenSSL e Apache. O OpenVPN utiliza two-factor authentication, recebendo o utilizador, e uma password que é uma junção de uma fixa, e de uma gerada pelo plugin google-authenticator. O servidor de Apache implementa a mesma authenticação.
 
 Temos então três máquinas virtuais:
 
@@ -59,12 +53,20 @@ Temos então três máquinas virtuais:
    OpenSSL / Apache & VM\_OPENSSL\_APACHE.sh & Reder Interna 10.60.0.0/24 \\
 \end{tabular}
 
+Os certificados utilizados foram certificados por uma autoridade central que não está no nosso cenario. A gestão da lista de revogação está a ser gerido pelo serviço OpenSSL que está na mesma maquina que o Apache. Num cenario real seria melhor dividir estes serviços por outras maquinas, mas os computadores que temos acesso estão limitados na quantidade de maquinas virtuais que consegue simular simultaniamente.
+
+
+
+
 
 
 
 \section{Criação de certificados}
 Criar chaves com 2048 bits.
 
+Todas as chaves foram criadas no mesmo computador, com as variaveis que está neste codigo, aspetos importantes para mais tarde serão os parametros de CN que precisam de ser passados mais tarde para aceder ao Apache e ao gateway. Numa situação normal teriamos uma autoridade de certificação para enviar e no fundo gerir todos, mas para este cenario podemos inicializar as maquinas com as chaves, requests e certificados necessarios.
+
+O codigo para gerar os certificados X.509: 
 \begin{lstlisting}[language=bash]
 cert_ca="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=CoimbraVPN"
 cert_vpn="/C=PT/ST=Coimbra/L=Coimbra/O=UC/CN=gateway"
@@ -86,14 +88,43 @@ openssl req -new -key apache.key -out apache.csr -subj "$cert_apache" -addext "s
 openssl ca -batch -in "apache.csr" -cert "ca.crt" -keyfile "ca.key" -out "apache.crt" -config cheese.cfg
 \end{lstlisting}
 
+Porque é que precisamos de uma chave secreta?
 Criar chave secreta.
 \begin{lstlisting}[language=bash]
 openssl --genkey secret ta.key
 \end{lstlisting}
+\section{Configuração geral}
+Para configurar as VM's era preciso introduzir os mesmos comandos varias vezes, o que levava muitas vezes a erros de escrita, ou a correr o mesmo comando varias vezes, por isso criamos varios ficheiros .sh para conseguir facilitar o processo. A utilização de ficheiros .sh também vem com outros positivos pois facilita a testagem, e a recriação do cenario rapidamente.
 
+No entanto para os serviços que configuramos, instalar, desativar e dar flush ás iptables não foi suficiente, tivemos que criar pastas e sincronizar os relogios de todas as VMs visto que elas estarem ligeiramente atrasadas nunca conseguiamos acertar na password do google-authenticator que utiliza o tempo local para calcular a sua chave.
+\begin{lstlisting}[language=bash]
+yum install -y epel-release
+yum install -y openvpn iptables-services dhcp-client
+systemctl stop firewalld
+systemctl disable firewalld
+systemctl mask firewalld
+systemctl enable iptables
+iptables -F
+
+CA_DIR="/etc/pki/CA"
+mkdir -p "${CA_DIR}/newcerts"
+mkdir -p "${CA_DIR}/private"
+touch "${CA_DIR}/index.txt"
+cp ca/serial "${CA_DIR}/serial"
+
+mkdir -p /etc/openvpn/server
+mkdir -p /etc/openvpn/client
+
+# NOTE(vasco): tive problemas com a sincronização de tempo
+# se nao tiver sincronizado, o TOTP nao funciona
+systemctl stop chronyd
+ntpdate pool.ntp.org
+systemctl start chronyd
+\end{lstlisting}
 
 \section{Configuração da \textit{Gateway} VPN}
 
+
 \section{Configurar TOTP}
 
 
@@ -131,5 +162,15 @@ google-authenticator
 
 \section{Conclusion}
 Conclusão!!!
+Atingimos o objetivo deste trabalho, conseguimos configurar o VPN tunnel, o two-factor authentication e conseguimos criar e retirar acesso aos certificados que emitimos. Utilizar mais maquinas para simular um cenario maior seria redundante, teriamos que emitir mais certificados mas não iamos aprender muito mais. Para aprofundar (???)
+
 
 \end{document}
+Para tal, foi implementado um servidor e um cliente OpenVPN, certificados por uma autoriadade central (CA)
+que em si é self-signed. Para além disto, foi implementado um sistema de autenticação de dois factores
+através do plugin google-authenticator para o OpenVPN.
+
+Existe ainda um servidor Apache e um servidro de OpenSSL OCSP. Para simpliflicar, a elaboração do 
+projecto foram colocados na mesma maquina virtual, mas por razoes de seguranca poderia querer ter 
+estes serviços separados. 
+