Você quer usar Linux no trabalho, mas sua VPN corporativa não permite? Então este artigo pode ajudar, embora isso não seja certo. Gostaria de avisar com antecedência que não entendo bem de questões de administração de rede, então é possível que tenha feito tudo errado. Por outro lado, é possível que eu escreva um guia de forma que seja compreensível para as pessoas comuns, por isso aconselho que experimente.
O artigo contém muitas informações desnecessárias, mas sem esse conhecimento eu não teria conseguido resolver os problemas que surgiram inesperadamente com a configuração de uma VPN. Acho que qualquer pessoa que tentar usar este guia 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 neste guia precisam ser executados via sudo, que foi removido por questões de brevidade. Tenha em mente.
A maioria dos endereços IP foram gravemente ofuscados, portanto, se você vir um endereço como 435.435.435.435, deve haver algum IP normal, específico para o seu caso.
Tenho o Ubuntu 18.04, mas acho que com pequenas alterações o guia pode ser aplicado a outras distribuições. Porém, neste texto Linux == Ubuntu.
Cisco Connect
Quem está em Windows ou MacOS pode se conectar à nossa VPN corporativa via Cisco Connect, que precisa especificar o endereço do gateway e, cada vez que se conectar, inserir uma senha composta por uma parte fixa e um código gerado pelo Google Authenticator.
No caso do Linux, não consegui colocar o Cisco Connect em execução, mas consegui pesquisar no Google uma recomendação para usar o openconnect, feito especificamente para substituir o Cisco Connect.
Conexão aberta
Em teoria, o Ubuntu possui uma interface gráfica especial para openconnect, mas não funcionou para mim. Talvez seja para melhor.
No Ubuntu, o openconnect é instalado a partir do gerenciador de pacotes.
apt install openconnectImediatamente após a instalação, você pode tentar conectar-se a uma VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com é o endereço de uma VPN fictícia
poxvuibr - nome de usuário fictício
O openconnect solicitará que você insira uma senha, que, lembre-se, consiste em uma parte fixa e um código do Google Authenticator, e então tentará se conectar à VPN. Se funcionar, parabéns, você pode pular com segurança o meio, que é muito trabalhoso, e passar ao ponto sobre o openconnect rodando em segundo plano. Se não funcionar, você pode continuar. Embora tenha funcionado ao conectar-se, por exemplo, a partir de um Wi-Fi de convidado no trabalho, talvez seja muito cedo para se alegrar; você deve tentar repetir o procedimento em casa.
Certificado
Há uma grande probabilidade de que nada comece e a saída do openconnect seja semelhante a esta:
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 progressPor um lado, isto é desagradável, porque não havia ligação à VPN, mas por outro lado, como resolver este problema é, em princípio, claro.
Aqui o servidor nos enviou um certificado, pelo qual podemos determinar que a conexão está sendo feita com o servidor de nossa empresa nativa, e não com um fraudador malvado, e este certificado é desconhecido do sistema. E, portanto, ela não pode verificar se o servidor é real ou não. E então, por precaução, ele para de funcionar.
Para que o openconnect 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 do que o openconnect imprimiu. Aqui está esta 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 progressCom este comando você pode tentar se conectar novamente
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comTalvez agora esteja funcionando, então você pode seguir até o fim. Mas pessoalmente, Ubunta me mostrou um figo neste formato
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.comhabr.com resolverá, mas você não poderá acessá-lo. Endereços como jira.evilcorp.com não foram resolvidos de forma alguma.
O que aconteceu aqui não está claro para mim. Mas a experiência mostra que se você adicionar a linha ao /etc/resolv.conf
nameserver 192.168.430.534então os endereços dentro da VPN começarão a ser resolvidos magicamente e você poderá percorrê-los, ou seja, o que o DNS está procurando para resolver endereços aparece especificamente em /etc/resolv.conf, e não em outro lugar.
Você pode verificar se há conexão com a VPN e funciona sem fazer nenhuma alteração em /etc/resolv.conf; para isso, basta inserir no navegador não o nome simbólico do recurso da VPN, mas seu endereço IP
Como resultado, existem dois problemas
- Ao conectar-se a uma VPN, seu DNS não é captado
- todo o tráfego passa por VPN, que não permite acesso à Internet
Vou te dizer o que fazer agora, mas primeiro um pouco de automação.
Entrada automática da parte fixa da senha
Até agora, provavelmente você já digitou sua senha pelo menos cinco vezes e esse procedimento já o cansou. Em primeiro lugar, porque a senha é longa e, em segundo lugar, porque ao entrar é necessário enquadrar-se num período de tempo fixo
A solução final para o problema não foi incluída no artigo, mas você pode ter certeza de que a parte fixa da senha não precisará ser digitada muitas vezes.
Digamos que a parte fixa da senha seja fixaPassword e a parte do Google Authenticator seja 567 987. A senha inteira pode ser passada para openconnect por meio de entrada padrão usando o argumento --passwd-on-stdin .
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAgora você pode retornar constantemente ao último comando digitado e alterar apenas parte do Google Authenticator.
Uma VPN corporativa não permite navegar na Internet.
Em geral, não é muito inconveniente quando você precisa usar um computador separado para ir ao Habr. A incapacidade de copiar e colar do stackoverfow geralmente pode paralisar o trabalho, então algo precisa ser feito.
Precisamos organizá-lo de alguma forma para que quando você precisar acessar um recurso da rede interna, o Linux vá para a VPN, e quando você precisar ir para o Habr, ele vá para a Internet.
openconnect, após iniciar e estabelecer uma conexão com vpn, executa um script especial, que está localizado em /usr/share/vpnc-scripts/vpnc-script. Algumas variáveis são passadas para o script como entrada e ele configura a VPN. Infelizmente, não consegui descobrir como dividir os fluxos de tráfego entre uma VPN corporativa e o resto da Internet usando um script nativo.
Aparentemente, o utilitário vpn-slice foi desenvolvido especialmente para pessoas como eu, que permite enviar tráfego por dois canais sem dançar com pandeiro. Bem, isto é, você terá que dançar, mas não precisa ser xamã.
Separação de tráfego usando VPN-slice
Em primeiro lugar, você terá que instalar o vpn-slice, você terá que descobrir isso sozinho. Se houver dúvidas nos comentários, escreverei um post separado sobre isso. Mas este é um programa Python normal, então não deve haver dificuldades. Eu instalei usando virtualenv.
E então o utilitário deve ser aplicado, usando a opção -script, indicando ao 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 --script recebe uma string com um comando que precisa ser chamado em vez do script. ./bin/vpn-slice - caminho para o arquivo executável do vpn-slice 192.168.430.0/24 - máscara de endereços para acessar na VPN. Aqui queremos dizer que se o endereço começar com 192.168.430, então o recurso com este endereço precisa ser pesquisado dentro da VPN
A situação agora deve estar quase normal. Quase. Agora você pode ir para Habr e pode ir para o recurso intracorporativo por ip, mas não pode ir para o recurso intracorporativo por nome simbólico. Se você especificar uma correspondência entre o nome simbólico e o endereço nos hosts, tudo deverá funcionar. E trabalhe até o ip mudar. O Linux agora pode acessar a Internet ou a intranet, dependendo do IP. Mas o DNS não corporativo ainda é usado para determinar o endereço.
O problema também pode se manifestar desta forma - no trabalho está tudo bem, mas em casa você só pode acessar recursos corporativos internos via IP. Isso ocorre porque quando você está conectado ao Wi-Fi corporativo, o DNS corporativo também é usado, e nele são resolvidos endereços simbólicos da VPN, apesar de ainda ser impossível ir para tal endereço sem usar uma VPN.
Modificação automática do arquivo hosts
Se o VPN-slice for solicitado educadamente, depois de acionar a VPN, ele poderá acessar seu DNS, encontrar lá os endereços IP dos recursos necessários por seus nomes simbólicos e inseri-los nos hosts. Após desligar a VPN, esses endereços serão removidos dos hosts. Para fazer isso, você precisa passar nomes simbólicos para vpn-slice como argumentos. Assim.
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.
Pesquise os endereços de todos os subdomínios no DNS fornecido pela VPN
Se houver poucos endereços na rede, a abordagem de modificação automática do arquivo hosts funciona muito bem. Mas se houver muitos recursos na rede, você precisará adicionar constantemente linhas como zoidberg.test.evilcorp.com ao script. zoidberg é o nome de um dos bancos de teste.
Mas agora que entendemos um pouco porque essa necessidade pode ser eliminada.
Se, depois de aumentar a VPN, você olhar em /etc/hosts, poderá ver esta linha
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCRIADO
E uma nova linha foi adicionada ao resolv.conf. Resumindo, o VPN-slice determinou de alguma forma onde o servidor DNS da VPN está localizado.
Agora precisamos ter certeza de que, para descobrir o endereço IP de um nome de domínio que termina em evilcorp.com, o Linux vai para o DNS corporativo e, se algo mais for necessário, para o padrão.
Pesquisei no Google por algum tempo e descobri que essa funcionalidade está disponível no Ubuntu imediatamente. Isso significa a capacidade de usar o servidor DNS local dnsmasq para resolver nomes.
Ou seja, você pode garantir que o Linux sempre vá ao servidor DNS local em busca de endereços IP, que por sua vez, dependendo do nome de domínio, procurará o IP no servidor DNS externo correspondente.
Para gerenciar tudo relacionado a redes e conexões de rede, o Ubuntu usa NetworkManager, e a interface gráfica para selecionar, por exemplo, conexões Wi-Fi é apenas um front end para isso.
Precisaremos subir em sua configuração.
- Crie um arquivo em /etc/NetworkManager/dnsmasq.d/evilcorp
endereço=/.evilcorp.com/192.168.430.534
Preste atenção ao ponto diante da evilcorp. Sinaliza ao DNSmasq que todos os subdomínios de evilcorp.com devem ser pesquisados no DNS corporativo.
- Diga ao NetworkManager para usar dnsmasq para resolução de 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 restartAgora, após conectar-se a uma VPN usando openconnect e vpn-slice, o ip será determinado normalmente, mesmo que você não adicione endereços simbólicos aos argumentos do vpnslice.
Como acessar serviços individuais via VPN
Depois que consegui me conectar à VPN, fiquei muito feliz por dois dias, e então descobri que se eu me conectar à VPN de fora da rede do escritório, o e-mail não funciona. O sintoma é familiar, não é?
Nosso e-mail está localizado em mail.publicevilcorp.com, o que significa que não se enquadra na regra do dnsmasq e o endereço do servidor de e-mail é pesquisado através de DNS público.
Bom, o escritório ainda usa DNS, que contém esse endereço. Isso é o que eu pensei. Na verdade, depois de adicionar a linha ao dnsmasq
endereço=/mail.publicevilcorp.com/192.168.430.534
a situação não mudou em nada. ip permaneceu o mesmo. Eu tive que ir trabalhar.
E só mais tarde, quando me aprofundei na situação e entendi um pouco o problema, uma pessoa esperta me disse como resolvê-lo. Foi necessário conectar-se ao servidor de e-mail não apenas assim, mas através de VPN
Eu uso o vpn-slice para passar pela VPN para endereços que começam com 192.168.430. E o servidor de e-mail não possui apenas um endereço simbólico que não seja um subdomínio da evilcorp, mas também não possui um endereço IP que comece com 192.168.430. E é claro que ele não permite que ninguém da rede geral venha até ele.
Para que o Linux passe pela VPN e chegue ao servidor de e-mail, você também precisa adicioná-lo ao vpn-slice. Digamos 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 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 digitá-lo manualmente, mas ainda não é muito agradável. Para facilitar o processo, você pode agrupar o comando em um script que estará localizado em PATH. E então você só precisará inserir o código recebido do 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~ você pode simplesmente escrever no console
connect_evil_corp 567987Mas agora você ainda precisa manter o console no qual o openconnect está rodando aberto por algum motivo
Executando o openconnect em segundo plano
Felizmente, os autores do openconnect cuidaram de nós e adicionaram uma chave especial ao programa -background, que faz com que o programa funcione em segundo plano após o lançamento. Se você executá-lo assim, poderá fechar o console após o lançamento
#!/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 vão os registros. Em geral, não precisamos realmente de logs, mas nunca se sabe. openconnect pode redirecioná-los para o syslog, onde serão mantidos seguros e protegidos. você precisa adicionar a opção –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, acontece que o openconnect está funcionando em algum lugar em segundo plano e não incomoda ninguém, mas não está claro como pará-lo. Ou seja, você pode, é claro, filtrar a saída ps usando grep e procurar um processo cujo nome contenha openconnect, mas isso é um tanto tedioso. Obrigado aos autores que pensaram nisso também. Openconnect possui uma chave -pid-file, com a qual você pode instruir o openconnect a gravar seu identificador de 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-pidAgora você sempre pode encerrar um processo com o comando
kill $(cat ~/vpn-pid)Se não houver processo, kill irá amaldiçoar, mas não gerará um erro. Se o arquivo não estiver lá, nada de ruim acontecerá, então você pode encerrar 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-pidAgora você pode ligar o computador, abrir o console e executar o comando, passando para ele o código do Google Authenticator. O console pode então ser pregado.
Sem fatia VPN. Em vez de um posfácio
Acabou sendo muito difícil entender como viver sem VPN-slice. Tive que ler e pesquisar muito no Google. Felizmente, depois de passar tanto tempo com um problema, os manuais técnicos e até mesmo o man openconnect parecem romances emocionantes.
Como resultado, descobri que o VPN-slice, como o script nativo, modifica a tabela de roteamento para redes separadas.
Tabela de roteamento
Simplificando, esta é uma tabela na primeira coluna que contém por onde deve começar o endereço que o Linux deseja passar, e na segunda coluna qual adaptador de rede deve passar neste endereço. Na verdade, existem mais oradores, mas isso não muda a essência.
Para visualizar 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 você precisa 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, você precisa pesquisar no Google o que é uma máscara de endereço IP. Depois de dev vem o nome do adaptador para o qual a mensagem deve ser enviada.
Para VPN, o Linux criou um adaptador virtual - tun0. A linha garante que o tráfego de todos os endereços começando com 192.168 passe por ela
192.168.0.0/16 dev tun0 scope link Você também pode observar o estado atual da tabela de roteamento usando o comando rota -n (Os endereços IP são habilmente anonimizados) Este comando produz resultados de uma forma diferente e geralmente está obsoleto, mas sua saída é frequentemente encontrada em manuais na Internet e você precisa ser capaz de lê-lo.
O local onde o endereço IP de uma rota deve começar pode ser entendido a partir da combinação das colunas Destino e Genmask. São levadas em consideração aquelas partes do endereço IP que correspondem aos números 255 no Genmask, mas aquelas onde há 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, a solicitação para ele seguirá essa rota. E se Destino 192.168.0.0 mas Genmask 255.255.0.0, então as solicitações para endereços que começam com 192.168 seguirão esta rota
Para descobrir o que o VPN-slice realmente faz, decidi observar os estados 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 wlp3s0Depois de chamar o openconnect sem vpn-slice ficou assim
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 tun0E 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 tun0Pode-se observar que se você não usar vpn-slice, o openconnect escreve explicitamente que todos os endereços, exceto aqueles especificamente indicados, devem ser acessados por meio de vpn.
Aqui está:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Ali, ao lado dele, é imediatamente indicado outro caminho, que deve ser utilizado caso o endereço que o Linux está tentando passar não corresponda a nenhuma máscara da tabela.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Já está escrito aqui que neste caso você precisa usar um adaptador Wi-Fi padrão.
Acredito que o caminho VPN seja utilizado 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 defaultE tudo funcionou.
Roteando solicitações para um servidor de e-mail sem VPN-slice
Mas também tenho um servidor de e-mail com endereço 555.555.555.555, que também precisa ser acessado via VPN. A rota para ele também precisa ser adicionada manualmente.
ip route add 555.555.555.555 via dev tun0E agora está tudo bem. Então você pode ficar sem VPN-slice, mas precisa saber bem o que está fazendo. Agora estou pensando em adicionar à última linha do script openconnect nativo a remoção da rota padrão e adicionar uma rota para o mailer após conectar-se à VPN, apenas para que haja menos peças móveis na minha bicicleta.
Provavelmente, este posfácio seria suficiente para alguém entender como configurar uma VPN. Mas enquanto tentava entender o que e como fazer, li muitos desses guias que funcionam para o autor, mas por algum motivo não funcionam para mim, e decidi adicionar aqui todas as peças que encontrei. Eu ficaria muito feliz com algo assim.
Fonte: habr.com