Quer usar Linux no trabalho, mas a VPN corporativa não permite? Então este artigo pode ajudar, embora não seja certo. Quero avisar com antecedência que entendo pouco sobre administração de redes, portanto é possível que eu tenha feito tudo errado. Por outro lado, é possível que consiga escrever um guia que seja compreensível para pessoas comuns, então recomendo que você tente.
O artigo contém muita informação desnecessária, mas sem esse conhecimento, eu não teria conseguido resolver os problemas que surgiram inesperadamente na configuração da VPN. Acredito que qualquer um que tentar aplicar este guia enfrentará problemas que eu não tive e espero que essas informações extras ajudem a resolvê-los de forma independente.
A maioria dos comandos usados no guia precisa ser executada via sudo, que foi omitido por brevidade. Tenha isso em mente.
A maioria dos endereços IP foi duramente ofuscada, então se você vê um endereço como 435.435.435.435 — lá deve haver algum IP normal, específico para o seu caso.
Eu tenho o Ubuntu 18.04, mas acredito que com algumas pequenas alterações, o guia pode ser aplicado a outras distribuições. Porém, neste texto, Linux == Ubuntu.
Cisco Connect
Aqueles que usam Windows ou MacOS podem se conectar à nossa VPN corporativa através do Cisco Connect, que precisa ter o endereço do gateway especificado e, a cada conexão, inserir uma senha composta por uma parte fixa e um código gerado pelo Google Authenticator.
No caso do Linux, não consegui configurar o Cisco Connect, mas consegui encontrar uma recomendação para usar o openconnect, que foi criado especificamente para substituir o Cisco Connect.
Openconnect
Teoricamente, no Ubuntu existe uma interface gráfica especial para o openconnect, mas não funcionou para mim. Pode ser para melhor.
No Ubuntu, o openconnect é instalado através do gerenciador de pacotes.
apt install openconnectLogo após a instalação, você pode tentar se conectar à VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com é o endereço de uma VPN fictícia
poxvuibr é um 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 depois tentará se conectar ao vpn. Se conseguir, parabéns, você pode pular a parte difícil e ir para o ponto sobre como o openconnect funciona em segundo plano. Se não funcionar, você pode continuar. Embora, se funcionou ao se conectar, por exemplo, de um Wi-Fi convidado no trabalho, é talvez cedo demais para comemorar, você deve tentar repetir o procedimento de casa.
Certificado
Com grande probabilidade, nada funcionará, e a saída do openconnect será algo assim:
POST https://vpn.evilcorp.com/
Conectado a 777.777.777.777:443
Negociação SSL com vpn.evilcorp.com
Falha na verificação do certificado do servidor: signatário não encontrado
O certificado do servidor VPN "vpn.evilcorp.com" falhou na verificação.
Razão: signatário não encontrado
Para confiar neste servidor no futuro, talvez adicione isso à sua linha de comando:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Digite 'yes' para aceitar, 'no' para abortar; qualquer outra coisa para visualizar: fgets (stdin): Operação agora em andamentoPor um lado, isso é desagradável, porque a conexão VPN não ocorreu, mas, por outro lado, a forma de corrigir esse problema está clara.
Aqui o servidor nos enviou um certificado, pelo qual podemos determinar que a conexão está realmente ocorrendo com o servidor da corporação, e não com um malfeitor, mas esse certificado não é conhecido pelo sistema. Portanto, ele não pode verificar se o servidor é real ou não. E por isso, por precaução, interrompe a operação.
Para que o openconnect realmente se conecte ao servidor, é necessário dizer explicitamente a ele qual certificado deve ser recebido do servidor VPN usando a chave —servercert
E para descobrir qual certificado o servidor nos enviou, podemos olhar diretamente na saída do openconnect. Veja este trecho:
Para confiar neste servidor no futuro, talvez adicione isso à sua linha de comando:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Digite 'yes' para aceitar, 'no' para abortar; qualquer outra coisa para visualizar: fgets (stdin): Operação agora em andamentoCom este comando, você pode tentar se conectar novamente
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comTalvez agora funcione, então você pode ir para o final. Mas pessoalmente, o Ubuntu me mostrou uma negativa dessa forma.
POST https://vpn.evilcorp.com/
Conectado a 777.777.777.777:443
Negociação SSL com vpn.evilcorp.com
Falha na verificação do certificado do servidor: signatário não encontrado
Conectado ao HTTPS em vpn.evilcorp.com
XML POST habilitado
Por favor, insira seu nome de usuário e senha.
POST https://vpn.evilcorp.com/
Resposta CONNECT recebida: HTTP/1.1 200 OK
CSTP conectado. DPD 300, Keepalive 30
Configuração do DTLS falhou; usando SSL em vez disso
Conectado como 192.168.333.222, usando SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK responde: O arquivo existe
/etc/resolvconf/update.d/libc: Aviso: /etc/resolv.conf não é um link simbólico para /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 irá resolver, mas não será possível acessá-lo. Endereços como jira.evilcorp.com não resolvem de forma alguma.
O que aconteceu aqui, não está claro para mim. Mas o experimento mostra que se adicionar a linha em /etc/resolv.conf
nameserver 192.168.430.534então os endereços dentro da VPN começarão a resolver magicamente e poderão ser acessados, ou seja, o que busca como DNS para resolver endereços, verifica exatamente em /etc/resolv.conf, e não em outro lugar.
Que a conexão com a VPN existe e funciona, pode ser verificado sem edições em /etc/resolv.conf. Para isso, basta inserir no navegador o endereço IP, e não o nome simbólico do recurso da vpn.
Assim, surgem dois problemas
- ao conectar-se à VPN, seu DNS não é capturado
- todo o tráfego passa pela vpn, que não permite acesso à internet
O que fazer vou explicar agora, mas primeiro um pouco de automação.
Entrada automática da parte fixa da senha
Nesse momento, você provavelmente já digitou sua senha pelo menos cinco vezes e esse procedimento já o cansou muito. Primeiro, porque a senha é longa, e segundo, porque ao digitar é preciso se encaixar em um intervalo de tempo fixo.
A solução definitiva para o problema não foi incluída no artigo, mas é possível fazer com que a parte fixa da senha não precise ser digitada várias vezes.
Digamos que a parte fixa da senha seja fixedPassword, e a parte do Google Authenticator 567 987. A senha inteira 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-stdinAgora você pode retornar constantemente ao último comando digitado e mudar apenas a parte do Google Authenticator.
A VPN corporativa não permite acesso à internet.
Não é muito conveniente que, para acessar o habr, você precise usar um computador separado. A falta de possibilidade de copiar e colar do stackoverflow pode paralisar todo o trabalho, então é necessário fazer algo.
É necessário organizar de alguma forma para que, ao acessar o recurso da rede interna, o Linux use o VPN, e quando for necessário acessar o Habr, ele use a internet.
O openconnect, após ser iniciado e estabelecer a conexão com o VPN, executa um script especial que está em /usr/share/vpnc-scripts/vpnc-script. O script recebe algumas variáveis como entrada e faz a configuração do VPN. Infelizmente, não consegui entender como dividir o fluxo de tráfego entre o VPN corporativo e o restante da internet usando o script padrão.
Aparentemente, uma ferramenta chamada vpn-slice foi desenvolvida especialmente para pessoas como eu, que permite direcionar o tráfego por dois canais sem grandes complicações. Ou seja, será necessário fazer algumas manobras, mas não é preciso ser um xamã.
Divisão de tráfego com vpn-slice.
Primeiramente, será necessário instalar o vpn-slice, isso terá que ser resolvido por conta própria. Se houver perguntas nos comentários, posso escrever um post separado sobre isso. Mas é um programa comum em Python, então não devem haver dificuldades. Eu instalei usando o virtualenv.
Em seguida, você deve aplicar a ferramenta, utilizando a chave —script, informando ao openconnect que deve-se usar o vpn-slice em vez do script padrão.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script ".\/bin\/vpn-slice 192.168.430.0\/24 " vpn.evilcorp.com Na —script, é passada uma string com o comando que deve ser chamado em vez do script. .\/bin\/vpn-slice é o caminho para o arquivo executável vpn-slice, e 192.168.430.0\/24 é a máscara de endereços que devem ser acessados via VPN. Isso significa que, se o endereço começar com 192.168.430, o recurso com esse endereço deve ser buscado dentro do VPN.
Agora a situação deve ser quase normal. Quase. Agora é possível acessar o Habr e também acessar o recurso corporativo por IP, mas não é possível acessar o recurso corporativo pelo nome simbólico. Se você definir a correspondência entre o nome simbólico e o endereço em hosts, tudo deve funcionar. E funcionará, até que o IP mude. O Linux agora pode acessar a internet ou a rede corporativa dependendo do IP. Mas a resolução de endereços ainda usa um DNS que não é corporativo.
O problema também pode se manifestar da seguinte forma — no trabalho tudo funciona normalmente, mas em casa, os recursos corporativos só podem ser acessados por IP. Isso acontece porque, quando você está conectado ao Wi-Fi corporativo, o DNS utilizado também é o corporativo, e nele os endereços simbólicos do VPN são resolvidos, mesmo que ainda não seja possível acessar esses endereços sem usar o VPN.
Modificação automática do arquivo hosts
Se o vpn-slice pedir educadamente, ele pode, após a conexão do VPN, acessar seu DNS, encontrar os endereços IP dos recursos necessários pelos seus nomes simbólicos e registrá-los no hosts. Após desligar o VPN, esses endereços serão removidos do hosts. Para isso, é necessário passar os nomes simbólicos para o 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.
Buscar endereços de todos os subdomínios no DNS fornecido pelo VPN
Se houver poucos endereços dentro da rede, a abordagem de modificação automática do arquivo hosts é bastante viável. Mas se houver muitos recursos na rede, você precisará constantemente adicionar ao script linhas como zoidberg.test.evilcorp.com, onde zoidberg é o nome de um dos ambientes de teste.
Mas agora, quando entendemos um pouco mais sobre o que está acontecendo, podemos eliminar essa necessidade.
Se após a conexão do VPN você olhar em \/etc\/hosts, poderá ver esta linha:
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
E também foi adicionada uma nova linha no resolv.conf. Em resumo, o vpn-slice de alguma forma determinou onde está o servidor DNS para o VPN.
Agora, é necessário fazer com que, para descobrir o endereço IP de um nome de domínio que termina em evilcorp.com, o Linux consulte o DNS corporativo, e para qualquer outra coisa, o DNS padrão.
Eu pesquisei bastante e descobri que essa funcionalidade está disponível no Ubuntu por padrão. Refere-se à possibilidade de usar um servidor DNS local, o dnsmasq, para resolver nomes.
Ou seja, podemos configurar para que o Linux sempre consulte o servidor DNS local para endereços IP, que, por sua vez, de acordo com o nome de domínio, buscará o IP no servidor DNS externo correspondente.
Para gerenciar tudo relacionado a redes e conexões de rede no Ubuntu, usa-se o NetworkManager, e a interface gráfica para escolher, por exemplo, uma conexão Wi-Fi, é apenas uma fachada para isso.
Precisaremos explorar sua configuração.
- Criar um arquivo em /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Note o ponto antes de evilcorp. Isso sinaliza ao dnsmasq que todos os subdomínios evilcorp.com devem ser buscados exatamente no DNS corporativo.
- Dizer ao NetworkManager que deve usar o dnsmasq para resolver nomes
A configuração do network-manager está em /etc/NetworkManager/NetworkManager.conf. Devemos adicionar lá:
[main]
dns=dnsmasq
- Reiniciar o NetworkManager
service network-manager restartAgora, após conectar ao VPN usando o openconnect e vpn-slice, o IP será corretamente determinado, mesmo se não adicionarmos endereços simbólicos nos argumentos do vpnslice.
Como acessar serviços individuais através do VPN
Depois que consegui me conectar ao vpn, fiquei muito feliz por dois dias, até descobrir que, se eu me conectasse ao VPN fora da rede do escritório, o e-mail não funcionava. Sintoma familiar, não é?
Nosso e-mail está em mail.publicevilcorp.com, portanto, não está sujeito à regra no dnsmasq e o endereço do servidor de e-mail é buscado através do DNS público.
Bem, no escritório ainda usamos o DNS em que esse endereço está presente. Ou assim pensei. Na verdade, após adicionar a linha no dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
a situação não mudou. O IP permaneceu o mesmo. Tive que ir trabalhar.
E já depois, quando investiguei a situação e entendi melhor o problema, uma pessoa inteligente me sugeriu como resolvê-lo. Eu precisava me conectar ao servidor de e-mail não simplesmente, mas através do VPN.
Eu uso o vpn-slice para acessar endereços que começam com 192.168.430. Mas o servidor de e-mail não apenas não tem um endereço simbólico que seja um subdomínio do evilcorp, mas seu endereço IP também não começa com 192.168.430. E ele, é claro, não permite acesso da rede geral.
Para que o Linux acesse o VPN e o servidor de e-mail, é necessário adicioná-lo ao vpn-slice também. Suponha que o endereço do servidor de e-mail 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 subir o VPN com um argumento
Tudo isso, é claro, não é muito conveniente. Sim, é possível salvar o texto em um arquivo e copiar e colar no console, em vez de digitá-lo manualmente, mas ainda assim não é nada agradável. Para facilitar o processo, você pode embrulhar o comando em um script que ficará no PATH. Assim, você só precisará inserir o código gerado pelo 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~, poderá simplesmente digitar no console.
connect_evil_corp 567987Mas agora ainda será necessário manter o console onde o openconnect está em execução aberto.
Executando openconnect em segundo plano.
Felizmente, os autores do openconnect se preocuparam conosco e adicionaram uma chave especial ao programa —background, que faz com que o programa funcione em segundo plano após a execução. Se você iniciar assim, poderá fechar o console após a execução.
#!/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, só não está claro para onde vão os logs. Os logs não são realmente muito necessários, mas, não se sabe. O openconnect pode redirecioná-los para o syslog, onde ficarão seguros e intactos. Para isso, você precisa adicionar ao comando a chave —syslog.
#!/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 funciona em segundo plano e não atrapalha ninguém, mas não está claro como interrompê-lo. Você pode, claro, usar o comando ps e filtrá-lo com grep para procurar o processo que contém openconnect no nome, mas isso é meio trabalhoso. Obrigado aos autores que pensaram nisso também. O openconnect tem uma chave —pid-file, com a qual você pode instruir o openconnect a escrever o identificador de seu 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ê pode sempre interromper o processo com o comando.
kill $(cat ~/vpn-pid)Se não houver processo, o kill reclamará, mas não dará erro. Se não houver arquivo, também não acontecerá nada de grave, então você pode 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-pidAgora você pode ligar o computador, abrir o console e executar o comando, passando o código do Google Authenticator. Depois, o console pode ser fechado.
Sem vpn-slice. Em vez de um epílogo.
Entender como viver sem o vpn-slice foi muito difícil. Tive que ler muito e pesquisar no Google. Felizmente, após passar tanto tempo com o problema, manuais técnicos e até mesmo o man openconnect se lêem como romances cativantes.
No final, descobri que o vpn-slice, assim como o script original, modifica a tabela de roteamento para dividir redes.
Tabela de Roteamento
Simplificando, é uma tabela cuja primeira coluna contém o ponto de partida do endereço que o Linux deseja percorrer, e a segunda coluna indica qual adaptador de rede deve ser usado para esse endereço. Na verdade, há mais colunas, mas isso não altera a essência.
Para visualizar a tabela de roteamento, é preciso 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 indica como enviar uma mensagem para um determinado endereço. Primeiro, vem a descrição do ponto de partida do endereço. Para entender como determinar que 192.168.0.0/16 significa que o endereço deve começar com 192.168, é preciso pesquisar o que é uma máscara de endereço IP. Após 'dev' está o nome do adaptador para o qual a mensagem deve ser enviada.
Para a VPN, o Linux criou um adaptador virtual — tun0. A linha
192.168.0.0/16 dev tun0 scope link Para verificar o estado atual da tabela de roteamento, pode-se usar o comando route -n (os endereços IP foram habilidosamente anonimizados) Este comando fornece resultados em um formato diferente e, na verdade, está obsoleto, mas sua saída frequentemente aparece em manuais na internet e é necessário saber lê-la.
A combinação das colunas Destination e Genmask indica como deve começar o IP para a rota. As partes do endereço IP que correspondem a 255 em Genmask são consideradas, enquanto as que correspondem a 0 não são. Portanto, a combinação Destination 192.168.0.0 e Genmask 255.255.255.0 significa que se o endereço começa com 192.168.0, a solicitação será encaminhada por 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 por essa rota.
Para entender o que o vpn-slice realmente faz, decidi verificar o estado das tabelas antes e depois
Antes de ativar a VPN, estava assim
route -n
Tabela de Roteamento IP do Kernel
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 wlp3s0Após a chamada do openconnect sem o vpn-slice, ficou assim
rota -n
Tabela de encaminhamento de IP do Kernel
Destino Gateway Máscara Gen Flags Métrica Ref Uso Interface
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 após chamar o openconnect em combinação com o vpn-slice, assim:
Tabela de encaminhamento de IP do Kernel
Destino Gateway Máscara Gen Flags Métrica Ref Uso Interface
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É evidente que, se não usar o vpn-slice, o openconnect informa explicitamente que, para todos os endereços, exceto os especificados, deve-se utilizar o vpn.
Aqui:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Lá está imediatamente especificado mais um caminho que deve ser usado se o endereço pelo qual o Linux tenta passar 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 wlp3s0Aqui já está escrito que, nesse caso, deve-se passar pelo adaptador padrão de Wi-Fi.
Eu considero que o caminho para o VPN é utilizado porque ele é o primeiro na tabela de roteamento.
E teoricamente, se remover este caminho padrão da tabela de roteamento, então, em conjunto com o dnsmasq, o openconnect deve garantir um funcionamento adequado.
Eu tentei
route del defaultE tudo funcionou.
Roteamento de pedidos ao servidor de e-mail sem vpn-slice
Mas eu ainda tenho outro servidor de e-mail com o endereço 555.555.555.555, que também precisa ser acessado via VPN. A rota até ele também precisa ser adicionada manualmente.
ip route add 555.555.555.555 via dev tun0E agora tudo está normal. Portanto, é possível ficar sem o vpn-slice, mas é necessário saber bem o que fazer. Estou pensando em não adicionar na última linha do script original do openconnect a remoção da rota padrão e a adição da rota para o e-mail após a conexão com o VPN, apenas para que as partes móveis na minha bicicleta fiquem menores.
Talvez, para algumas pessoas, este pós-escrito seria suficiente para entender como configurar uma VPN. Mas eu, enquanto tentava compreender o que e como fazer, li muitos guias que funcionam para o autor, mas que, por algum motivo, não funcionam para mim e decidi adicionar aqui todos os fragmentos que encontrei. Fiquei realmente satisfeito com algo assim.
Fonte: habr.com
