Deseja usar o Linux no trabalho, mas uma VPN corporativa não? Este artigo pode ajudar, embora isso não seja preciso. Quero avisar com antecedência que entendo mal os problemas de administração de rede, para que seja possível que eu tenha feito tudo errado. Por outro lado, é possível que eu possa escrever o manual de tal maneira que seja compreensível para as pessoas comuns, por isso aconselho você a tentar.
O artigo tem muitas informações extras, mas sem esse conhecimento, eu não seria capaz de resolver os problemas que de repente tive com a configuração de vpn. Acho que qualquer pessoa que tentar aplicar este manual terá problemas que eu não tive e espero que essas informações extras ajudem a resolver esses problemas por conta própria.
A maioria dos comandos usados no manual precisa ser executada no sudo, que é removido por questões de brevidade. Tenha em mente.
A maioria dos endereços IP foi ofuscada severamente; portanto, se você vir um endereço como 435.435.435.435, deve haver algum IP normal específico para o seu caso.
Eu tenho o Ubuntu 18.04, mas acho que com algumas alterações o guia pode ser aplicado a outras distribuições. No entanto, neste texto, Linux == Ubuntu.
Cisco connect
Aqueles que estão sentados no Windows ou MacOS podem se conectar à VPN corporativa através do Cisco Connect, que precisa especificar o endereço do gateway e inserir uma senha sempre que conectada, consistindo em uma parte fixa e um código gerado pelo Google Authenticator.
No caso do Linux, não foi possível obter o Cisco Connect, mas a recomendação do Google foi usar o openconnect, feito especificamente para substituir o Cisco Connect.
Openconnect
Em teoria, no ubunt, existe uma interface gráfica especial para o openconnect, mas não funcionou para mim. Talvez seja o melhor.
No ubunt, o openconnect é instalado a partir do gerenciador de pacotes.
apt install openconnect
Imediatamente após a instalação, você pode tentar se conectar à VPN
openconnect --user poxvuibr vpn.evilcorp.com
vpn.evilcorp.com é o endereço VPN fictício \
poxvuibr - nome de usuário fictício
O openconnect solicitará que você digite uma senha, que, lembro-me, consiste em uma parte e código fixos do Google Authenticator e tente conectar-se ao vpn. Se acabou, parabéns, você pode pular com segurança o meio, o que é muito doloroso e ir direto ao ponto sobre a conexão aberta em segundo plano. Se não funcionar, você pode continuar. Embora, se ele acabou sendo conectado, por exemplo, a partir de um Wi-Fi convidado no trabalho, é possível se alegrar e cedo, tente repetir o procedimento em casa.
Certificado
Com alta probabilidade, nada será iniciado e o escape do openconnect será mais ou menos assim:
POST https://vpn.evilcorp.com/ Connected to 777.777.777.777:443 SSL negotiation with vpn.evilcorp.com Server certificate verify failed: signer not found Certificate from VPN server "vpn.evilcorp.com" failed verification. Reason: signer not found To trust this server in future, perhaps add this to your command line: --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
Por um lado, isso é desagradável, porque não havia conexão com a VPN, mas por outro lado, como corrigir esse problema é, em princípio, compreensível.
Em seguida, o servidor nos enviou um certificado, segundo o qual pode ser determinado que a conexão é feita com o servidor da empresa nativa, e não com o fraudador malicioso, e esse certificado é desconhecido para o sistema. E, portanto, ela não pode verificar se o servidor real é ou não. E assim, apenas no caso, ele pára de funcionar.
Para que o openconnect ainda se conecte ao servidor, você precisa informar explicitamente qual certificado deve vir do servidor VPN usando a chave --servercert
E você pode descobrir qual certificado o servidor nos enviou diretamente a partir do que o openconnect imprimiu. Aqui a partir desta peça:
To trust this server in future, perhaps add this to your command line: --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progress
Com este comando, você pode tentar se conectar novamente
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com
Talvez esteja funcionando agora, então você pode ir até o fim. Mas Ubunta pessoalmente me mostrou um figo nesta forma
POST https://vpn.evilcorp.com/ Connected to 777.777.777.777:443 SSL negotiation with vpn.evilcorp.com Server certificate verify failed: signer not found Connected to HTTPS on vpn.evilcorp.com XML POST enabled Please enter your username and password. POST https://vpn.evilcorp.com/ Got CONNECT response: HTTP/1.1 200 OK CSTP connected. DPD 300, Keepalive 30 Set up DTLS failed; using SSL instead Connected as 192.168.333.222, using SSL NOSSSSSHHHHHHHDDDDD 3 NOSSSSSHHHHHHHDDDDD 3 RTNETLINK answers: File exists /etc/resolvconf/update.d/libc: Warning: /etc/resolv.conf is not a symbolic link to /run/resolvconf/resolv.conf
/etc/resolv.conf
# Generated by NetworkManager search gst.evilcorpguest.com nameserver 127.0.0.53
/run/resolvconf/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN # 127.0.0.53 is the systemd-resolved stub resolver. # run "systemd-resolve --status" to see details about the actual nameservers. nameserver 192.168.430.534 nameserver 127.0.0.53 search evilcorp.com gst.publicevilcorp.com
O habr.com será resolvido, mas não será possível entrar lá. Endereços como jira.evilcorp.com não são resolvidos.
O que aconteceu aqui não está claro para mim. Mas o experimento mostra que se você adicionar a linha ao /etc/resolv.conf
nameserver 192.168.430.534
os endereços dentro da VPN serão resolvidos magicamente e será possível analisá-los, ou seja, o que o DNS procura para resolver endereços é visualizado no /etc/resolv.conf e não em outro lugar.
Se existe uma conexão com a VPN e ela funciona, você pode ter certeza de que, sem alterações no /etc/resolv.conf, basta digitar o nome simbólico do recurso de vpn no navegador e seu endereço IP
O resultado são dois problemas
- na conexão com a VPN, o DNS não é captado
- todo o tráfego passa pela VPN, o que não permite que você acesse a Internet
O que vou fazer agora, vou lhe contar, mas primeiro um pouco de automação.
Entrada automática da parte fixa da senha
No momento atual, você provavelmente já digitou a senha pelo menos cinco vezes e esse procedimento já o cansou bastante. Em primeiro lugar, porque a senha é longa e, em segundo lugar, porque, ao entrar, você precisa se manter dentro de um período fixo
A solução final para o problema não foi incluída no artigo, mas pode ser feita para que a parte fixa da senha não precise ser inserida várias vezes.
Suponha que a parte fixa da senha seja FixedPassword e parte do Google Authenticator 567 987. A senha inteira do openconnect pode ser passada através da entrada padrão usando o argumento --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin
Agora você pode retornar constantemente ao último comando inserido e alterar apenas parte do Google Authenticator lá.
A VPN corporativa não permite acesso à Internet.
Em geral, não é muito inconveniente quando, para acessar um hub, você precisa usar um computador separado. A falta da capacidade de copiar e colar com o stackoverfow geralmente paralisa o trabalho, portanto, algo precisa ser feito.
É necessário organizar de alguma forma, para que, quando você precise acessar o recurso da rede interna, o Linux vá para vpn e, quando você precise acessar o hub, vá para a Internet.
O openconnect após iniciar e estabelecer uma conexão com o vpn, executa um script especial, localizado em / usr / share / vpnc-scripts / vpnc-script. Algumas variáveis são transferidas para o script de entrada e fazem a configuração de vpn. Infelizmente, não consegui descobrir como dividir os fluxos de tráfego entre a VPN corporativa e o restante da Internet usando um script nativo.
Aparentemente, especialmente para pessoas como eu, foi desenvolvido o utilitário vpn-slice, que permite direcionar o tráfego por dois canais sem dançar com um pandeiro. Bem, você tem que dançar, mas um xamã não é necessário.
Dividir o tráfego com vpn-slice
Primeiramente, o vpn-slice terá que ser instalado, você terá que descobrir por si mesmo. Se houver perguntas nos comentários, escreverei um post separado sobre isso. Mas este é um programa python regular, portanto não deve haver dificuldades. Eu configurei usando virtualenv.
E então você precisa usar o utilitário, usando a tecla --script indicando openconnect que, em vez do script padrão, você precisa usar vpn-slice
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin \ --script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com
Em --script, uma linha é passada com o comando que precisa ser chamado em vez do script. ./bin/vpn-slice - caminho para o arquivo executável vpn-slice 192.168.430.0/24 - máscara de endereços a serem visitados na vpn. Aqui, quero dizer que, se o endereço começar com 192.168.430, o recurso com esse endereço deverá ser pesquisado dentro de vpn
Agora a situação deve estar quase normal. Quase. Agora você pode efetuar login no hub e efetuar logon no recurso corporativo interno por ip, mas não pode fazer login no recurso corporativo interno por nome simbólico. Se você registrar a correspondência do nome e endereço simbólicos nos hosts, tudo deverá funcionar. E trabalhe até que o ip mude. O Linux agora pode acessar a Internet ou a rede corporativa, dependendo do ip. Mas o DNS não corporativo ainda é usado para determinar o endereço.
O problema ainda pode se manifestar desta forma - está tudo bem no trabalho e em casa você pode acessar recursos corporativos internos apenas por IP. Isso ocorre porque quando você está conectado ao Wi-Fi corporativo, o DNS corporativo também é usado, e nele os endereços simbólicos da VPN são resolvidos, embora ainda seja impossível acessar um endereço desse tipo sem usar uma VPN.
Modificação automática do arquivo hosts
Se você educadamente pedir ao vpn-slice, depois de aumentar a VPN, ele poderá acessar o DNS, encontrar os endereços IP dos recursos necessários por seus nomes simbólicos e inseri-los nos hosts. Depois que a VPN é desativada, esses endereços serão removidos dos hosts. Para fazer isso, passe nomes simbólicos para vpn-slice como argumentos. Lá vai você.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Agora tudo deve funcionar tanto no escritório quanto na praia.
Procure endereços de todos os subdomínios no DNS que a VPN forneceu
Se houver poucos endereços na rede, a abordagem para modificar automaticamente o arquivo hosts estará funcionando. Mas se houver muitos recursos na rede, você precisará constantemente adicionar linhas como zoidberg.test.evilcorp.com ao script zoidberg, este é o nome de uma das bancas de teste.
Mas agora que temos um pouco de entendimento de por que essa necessidade pode ser eliminada.
Se, depois de aumentar a VPN, procure em / etc / hosts, você pode ver, aqui está uma linha
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Sim, e uma nova linha foi adicionada ao resolv.conf. Em resumo, o vpn-slice determinou de alguma forma onde o servidor DNS para vpn está localizado.
Agora precisamos ter certeza de que, para descobrir o endereço IP do nome de domínio que termina em evilcorp.com, o Linux foi para o DNS corporativo e, se algo mais for necessário, o padrão será o padrão.
Pesquisei no Google por um longo tempo e descobri que essa funcionalidade está pronta para uso imediato. Isso se refere à capacidade de usar o servidor dns dnsmasq local dnsmasq para resolver nomes.
Ou seja, você pode fazer com que o Linux sempre vá para o servidor DNS local para obter endereços IP, que, por sua vez, dependendo do nome do domínio, procurarão IP no servidor DNS externo correspondente.
Para gerenciar tudo relacionado a redes e conexões de rede, o Ubunt usa o NetworkManager, e a interface gráfica para selecionar, por exemplo, uma conexão Wi-Fi é apenas a frente para ela.
Precisamos escalar em sua configuração.
- Crie um arquivo no /etc/NetworkManager/dnsmasq.d/evilcorp
endereço = /. evilcorp.com/192.168.430.534
Preste atenção ao ponto antes de evilcorp. Ele sinaliza ao dnsmasq que todos os subdomínios evilcorp.com devem ser pesquisados no dns corporativo.
- Diga ao NetworkManager para usar o dnsmasq para resolver nomes
A configuração do gerenciador de rede está localizada em /etc/NetworkManager/NetworkManager.conf. Você precisa adicionar lá:
[principal]
dns = dnsmasq
- Reinicie o NetworkManager
service network-manager restart
Agora, depois de conectar-se a uma VPN usando um monte de openconnect e vpn-slice, o ip será detectado normalmente, mesmo se você não adicionar endereços simbólicos aos argumentos do vpnslice.
Como passar pela VPN para separar serviços
Após a conexão com a VPN, fiquei muito feliz por dois dias e, em seguida, verificou-se que, se você se conectar à VPN e não a partir da rede do escritório, o correio não funcionará. Um sintoma familiar, não é?
Nosso email está em mail.publicevilcorp.com, o que significa que ele não se enquadra na regra do dnsmasq e o endereço do servidor de email é pesquisado através do DNS público.
Bem, o escritório ainda usa o DNS no qual esse endereço está. Ou seja, eu pensei que sim. De fato, depois de adicionar uma linha ao dnsmasq
endereço = / mail.publicevilcorp.com / 192.168.430.534
a situação não mudou. ip permaneceu o mesmo. Eu tive que ir trabalhar.
E só então, quando mergulhei na situação e resolvi um pouco o problema, uma pessoa inteligente me disse como resolvê-lo. Era necessário conectar-se ao servidor de correio não apenas assim, mas através do vpn
Eu uso o vpn-slice para passar pela VPN para endereços que começam com 192.168.430. E no servidor de correio, não apenas o endereço simbólico não é um subdomínio da evilcorp, mas também possui um endereço IP que não inicia com 192.168.430. E é claro que ele não deixa ninguém sair da rede em geral.
Para que o Linux passe pela VPN e pelo servidor de email, você precisa adicioná-lo ao vpn-slice. Suponha que o endereço do remetente seja 555.555.555.555
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin --script "./bin/vpn-slice 555.555.555.555 192.168.430.0/24" vpn.evilcorp.com
Script para aumentar uma VPN com um argumento
Tudo isso, é claro, não é muito conveniente. Sim, você pode salvar o texto em um arquivo e copiá-lo e colá-lo no console, em vez de digitar com as mãos, mas ainda não é agradável o suficiente. Para facilitar o processo, você pode agrupar o comando em um script que estará localizado no PATH. E então você só precisa digitar o código obtido no Google Authenticator
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Se você colocar o script em connect ~ evilcorp ~, basta escrever no console
connect_evil_corp 567987
Mas agora, de qualquer forma, por algum motivo, você precisa manter o console em que o openconnect está sendo aberto
Lançamento do Openconnect em segundo plano
Felizmente, os autores do openconnect cuidaram de nós e adicionaram uma chave especial - background ao programa, que faz com que o programa funcione em segundo plano após o lançamento. Se você executá-lo assim, após o lançamento, você pode fechar o console
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com
Agora não está claro para onde os logs vão. Geralmente, os logs não são realmente necessários para nós, mas você nunca sabe. O openconnect pode redirecioná-los para o syslog, onde eles serão mantidos intactos. você precisa adicionar a chave --syslog ao comando
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \
E assim, verifica-se que o openconnect está funcionando em algum lugar em segundo plano e não incomoda ninguém, mas como parar isso não está claro. Ou seja, você pode, é claro, filtrar o escape do ps com um grep e procurar um processo em nome do qual é openconnect, mas é de alguma forma sombrio. Obrigado aos autores que pensaram sobre isso. O Openconnect possui a chave --pid-file, com a qual você pode instruir o openconnect para gravar seu ID do processo em um arquivo.
#!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \ --pid-file ~/vpn-pid
Agora você sempre pode definir o processo com o comando
kill $(cat ~/vpn-pid)
Se não houver processo, o kill jura, mas não gera um erro. Se não houver arquivo, nada de ruim também acontecerá, para que você possa matar o processo com segurança na primeira linha do script.
kill $(cat ~/vpn-pid) #!/bin/sh echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 \ --user poxvuibr \ --passwd-on-stdin \ --background \ --syslog \ --script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com \ --pid-file ~/vpn-pid
Agora você pode ligar o computador, abrir o console e executar o comando, passando o código do Google Authenticator. O console pode ser pregado.
Sem vpn-slice. Em vez de um posfácio
Era muito difícil entender como viver sem o vpn-slice. Eu tive que ler muito e google. Felizmente, quando passei tanto tempo com o problema, os manuais técnicos e até o homem openconnect pareciam romances emocionantes.
Como resultado, descobri que o vpn-slice, como o script nativo, modifica a tabela de roteamento para separar redes.
Tabela de roteamento
Em termos simples, essa tabela na primeira coluna contém onde o endereço para onde o Linux deseja ir deve começar e na segunda através do adaptador de rede para esse endereço. De fato, existem mais colunas, mas isso não muda a essência.
Para ver a tabela de roteamento, você precisa executar o comando ip route
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600 192.168.430.0/24 dev tun0 scope link 192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600 192.168.430.534 dev tun0 scope link
Aqui, cada linha é responsável por onde ir para enviar uma mensagem para algum endereço. A primeira é uma descrição de onde o endereço deve começar. Para entender como determinar que 192.168.0.0/16 significa que o endereço deve começar com 192.168, é necessário pesquisar no Google qual é a máscara do endereço IP. After dev é o nome do adaptador para o qual a mensagem deve ser enviada.
Para VPN, o Linux criou um adaptador virtual - tun0. Para que o tráfego de todos os endereços começando com 192.168 passe por ele, a linha responde
192.168.0.0/16 dev tun0 scope link
Você também pode observar o estado atual da tabela de roteamento usando o comando route -n (os endereços IP são talentos anonimamente) Este comando produz resultados de uma forma diferente e geralmente é preterido, mas seu escape geralmente se depara com manuais on-line e você precisa lê-lo.
Onde o endereço IP da rota deve começar pode ser entendido a partir da combinação das colunas Destination e Genmask. As partes do endereço IP às quais os números 255 correspondem no Genmask são levadas em consideração e aquelas onde 0 não é. Ou seja, a combinação de Destino 192.168.0.0 e Genmask 255.255.255.0 significa que, se o endereço começar com 192.168.0, uma solicitação para ele seguirá essa rota. E se Destination for 192.168.0.0 mas Genmask for 255.255.0.0, as solicitações para endereços que começam com 192.168 seguirão essa rota
Para descobrir o que o vpn-slice realmente faz, decidi examinar o estado das tabelas antes e depois
Antes de ligar a VPN, era assim
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
Depois de chamar openconnect sem vpn-slice, ficou tão
route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0 192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
E depois de chamar openconnect em combinação com vpn-slice assim
Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0 222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0 333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0 192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
Pode-se observar que, se você não usar vpn-slice, o openconnect gravará explicitamente que você deve passar pelo vpn em todos os endereços, exceto se indicado separadamente.
Aqui:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0
Nas proximidades, indicava imediatamente outro caminho que deveria ser usado se o endereço que o Linux está tentando percorrer não corresponder a nenhuma máscara da tabela.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
Já foi escrito aqui que, nesse caso, você precisa passar pelo adaptador Wi-Fi padrão.
Eu acredito que o caminho para a VPN é usado porque é o primeiro na tabela de roteamento.
E, teoricamente, se você remover esse caminho padrão da tabela de roteamento, em conjunto com o dnsmasq openconnect deverá garantir a operação normal.
Eu tentei
route del default
E funcionou.
Encaminhando solicitações para um servidor de correio sem vpn-slice
Mas também tenho um servidor de email com o endereço 555.555.555.555, que você também precisa passar por vpn. A rota para ele também deve ser adicionada à mão.
ip route add 555.555.555.555 via dev tun0
E agora todas as regras. Então você pode fazer sem vpn-slice, mas você já precisa saber bem o que está fazendo. Agora, estou pensando em adicionar a remoção da rota padrão e adicionar a rota para a mala direta depois de conectar-se ao vpn na última linha do script nativo do openconnect, apenas para diminuir o número de partes móveis na minha bicicleta.
Provavelmente, alguém para entender como configurar uma VPN teria o suficiente desse posfácio. Mas enquanto eu tentava entender o que e como fazê-lo, li muitos desses manuais que funcionam para o autor, mas por algum motivo não funciona para mim e decidi adicionar aqui todas as peças que encontrei. Eu ficaria muito feliz com algo assim.