Queres usar Linux no traballo, pero a túa VPN corporativa non che deixa? Entón, este artigo pode axudar, aínda que isto non é certo. Gustaríame avisar de antemán de que non entendo ben os problemas de administración da rede, polo que é posible que fixera todo mal. Por outra banda, é posible que poida escribir unha guía de tal xeito que sexa comprensible para a xente común, polo que aconsello que a probedes.
O artigo contén moita información innecesaria, pero sen este coñecemento non tería sido capaz de resolver os problemas que me apareceron inesperadamente coa configuración dunha VPN. Creo que calquera que intente utilizar esta guía terá problemas que eu non tiven, e espero que esta información adicional axude a resolver estes problemas por si mesmo.
A maioría dos comandos utilizados nesta guía deben executarse a través de sudo, que foi eliminado por motivos de brevidade. Ten presente.
A maioría dos enderezos IP foron gravemente ofuscados, polo que se ves un enderezo como 435.435.435.435, debe haber algunha IP normal, específica para o teu caso.
Teño Ubuntu 18.04, pero creo que con pequenos cambios a guía pódese aplicar a outras distribucións. Non obstante, neste texto Linux == Ubuntu.
Cisco Connect
Os que estean en Windows ou MacOS poden conectarse á nosa VPN corporativa a través de Cisco Connect, que precisa especificar o enderezo da pasarela e, cada vez que se conecte, introducir un contrasinal composto por unha parte fixa e un código xerado por Google Authenticator.
No caso de Linux, non puiden facer funcionar Cisco Connect, pero conseguín buscar en Google unha recomendación para usar openconnect, feita especificamente para substituír a Cisco Connect.
Openconnect
En teoría, Ubuntu ten unha interface gráfica especial para openconnect, pero non me funcionou. Quizais sexa para mellor.
En Ubuntu, openconnect instálase desde o xestor de paquetes.
apt install openconnectInmediatamente despois da instalación, podes tentar conectarte a unha VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com é o enderezo dunha VPN ficticia
poxvuibr - nome de usuario ficticio
openconnect pedirache que introduzas un contrasinal, que, permíteme lembralo, consta dunha parte fixa e un código de Google Authenticator, e despois intentará conectarse á VPN. Se funciona, parabéns, podes saltar con seguridade o medio, que é moita dor, e pasar ao punto de que openconnect se execute en segundo plano. Se non funciona, podes continuar. Aínda que se funcionou ao conectarse, por exemplo, desde unha wifi de hóspede no traballo, quizais sexa demasiado cedo para alegrarse; debes tentar repetir o procedemento desde a casa.
Certificado
Hai unha alta probabilidade de que non se inicie nada e a saída de openconnect terá un aspecto así:
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 unha banda, isto é desagradable, porque non había conexión coa VPN, pero, por outra banda, como solucionar este problema está, en principio, claro.
Aquí o servidor enviounos un certificado, polo que podemos determinar que a conexión se está a facer co servidor da nosa corporación nativa, e non cun malvado defraudador, e este certificado é descoñecido para o sistema. E polo tanto non pode comprobar se o servidor é real ou non. E así, por se acaso, deixa de funcionar.
Para que openconnect se conecte ao servidor, debes indicarlle explícitamente que certificado debe proceder do servidor VPN usando a chave —servercert
E podes saber que certificado nos enviou o servidor directamente desde o que imprimiu openconnect. Aquí está desta peza:
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 progressCon este comando pode tentar conectarse de novo
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comQuizais agora funcione, entón podes pasar ata o final. Pero persoalmente, Ubuntu mostroume un figo desta 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.comhabr.com resolverase, pero non poderás ir alí. Enderezos como jira.evilcorp.com non están resoltos en absoluto.
O que pasou aquí non me queda claro. Pero o experimento mostra que se engades a liña a /etc/resolv.conf
nameserver 192.168.430.534entón os enderezos dentro da VPN comezarán a resolverse de xeito máxico e podes percorrelos, é dicir, o que o DNS está a buscar para resolver os enderezos mira especificamente en /etc/resolv.conf, e non noutro lugar.
Podes verificar que existe unha conexión coa VPN e que funciona sen facer ningún cambio en /etc/resolv.conf; para facelo, só tes que introducir no navegador non o nome simbólico do recurso da VPN, senón o seu enderezo IP
Como resultado, hai dous problemas
- Cando se conecta a unha VPN, o seu dns non se recolle
- todo o tráfico pasa por VPN, que non permite o acceso a Internet
Vouche dicir que facer agora, pero primeiro un pouco de automatización.
Introdución automática da parte fixa do contrasinal
A estas alturas, probablemente xa introduciu o seu contrasinal polo menos cinco veces e este procedemento xa o cansou. En primeiro lugar, porque o contrasinal é longo e, en segundo lugar, porque ao entrar cómpre encaixar nun período de tempo determinado
A solución final ao problema non se incluíu no artigo, pero podes asegurarte de que a parte fixa do contrasinal non teña que introducir moitas veces.
Supoñamos que a parte fixa do contrasinal é fixedPassword e que a parte de Google Authenticator é 567. Pódese pasar todo o contrasinal a openconnect mediante a entrada estándar usando o argumento --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinAgora podes volver constantemente ao último comando introducido e cambiar alí só parte de Google Authenticator.
Unha VPN corporativa non che permite navegar por Internet.
En xeral, non é moi inconveniente cando tes que usar un ordenador separado para ir a Habr. A incapacidade de copiar e pegar desde stackoverfow xeralmente pode paralizar o traballo, polo que hai que facer algo.
Temos que organizalo dalgún xeito para que cando necesites acceder a un recurso desde a rede interna, Linux vaia á VPN e, cando teñas que ir a Habr, vaia a Internet.
openconnect, despois de iniciar e establecer unha conexión con vpn, executa un script especial, que se atopa en /usr/share/vpnc-scripts/vpnc-script. Algunhas variables pásanse ao script como entrada e configura a VPN. Desafortunadamente, non puiden descubrir como dividir os fluxos de tráfico entre unha VPN corporativa e o resto de Internet mediante un script nativo.
Ao parecer, a utilidade vpn-slice foi desenvolvida especialmente para persoas coma min, que che permite enviar tráfico por dúas canles sen bailar cunha pandeireta. Ben, é dicir, terás que bailar, pero non tes que ser chamán.
Separación de tráfico mediante vpn-slice
En primeiro lugar, terás que instalar vpn-slice, terás que descubrir isto ti mesmo. Se hai preguntas nos comentarios, escribirei unha publicación separada sobre isto. Pero este é un programa normal de Python, polo que non debería haber dificultades. Instalei usando virtualenv.
E entón debe aplicarse a utilidade, usando o interruptor -script, indicando para abrir conexión que en lugar do script estándar, cómpre 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 pásase unha cadea cunha orde que debe chamarse en lugar do script. ./bin/vpn-slice - camiño ao ficheiro executable vpn-slice 192.168.430.0/24 - máscara de enderezos aos que ir en vpn. Aquí, queremos dicir que se o enderezo comeza con 192.168.430, entón o recurso con este enderezo debe buscarse dentro da VPN
Agora a situación debería ser case normal. Case. Agora podes ir a Habr e podes ir ao recurso intracorporativo por ip, pero non podes ir ao recurso intracorporativo por nome simbólico. Se especificas unha coincidencia entre o nome e o enderezo simbólicos nos hosts, todo debería funcionar. E traballa ata que cambie a ip. Linux agora pode acceder a Internet ou á intranet, dependendo da IP. Pero aínda se usa DNS non corporativo para determinar o enderezo.
O problema tamén se pode manifestar desta forma: no traballo todo está ben, pero na casa só podes acceder aos recursos corporativos internos a través de IP. Isto ocorre porque cando estás conectado á wifi corporativa, tamén se utiliza o DNS corporativo e nel resólvense os enderezos simbólicos da VPN, a pesar de que aínda é imposible ir a ese enderezo sen usar unha VPN.
Modificación automática do ficheiro hosts
Se vpn-slice se lle pide educadamente, despois de aumentar a VPN, pode ir ao seu DNS, atopar alí os enderezos IP dos recursos necesarios polos seus nomes simbólicos e introducilos nos hosts. Despois de desactivar a VPN, estes enderezos eliminaranse dos hosts. Para iso, cómpre pasar nomes simbólicos a vpn-slice como argumentos. Como isto.
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 todo debería funcionar tanto na oficina como na praia.
Busca os enderezos de todos os subdominios no DNS dado pola VPN
Se hai poucos enderezos dentro da rede, entón o enfoque de modificar automaticamente o ficheiro hosts funciona bastante ben. Pero se hai moitos recursos na rede, terás que engadir constantemente liñas como zoidberg.test.evilcorp.com ao script zoidberg é o nome dun dos bancos de proba.
Pero agora que entendemos un pouco por que se pode eliminar esta necesidade.
Se, despois de aumentar a VPN, buscas en /etc/hosts, podes ver esta liña
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREADO
E engadiuse unha nova liña a resolv.conf. En resumo, vpn-slice determinou dalgún xeito onde se atopa o servidor dns para a VPN.
Agora temos que asegurarnos de que para descubrir o enderezo IP dun nome de dominio que remata en evilcorp.com, Linux vai ao DNS corporativo e, se se precisa algo máis, ao predeterminado.
Busquei en Google durante bastante tempo e descubrín que esta funcionalidade está dispoñible en Ubuntu fóra da caixa. Isto significa a posibilidade de usar o servidor DNS local dnsmasq para resolver nomes.
É dicir, pode asegurarse de que Linux vai sempre ao servidor DNS local para os enderezos IP, que á súa vez, dependendo do nome de dominio, buscará a IP no servidor DNS externo correspondente.
Para xestionar todo o relacionado coas redes e conexións de rede, Ubuntu usa NetworkManager, e a interface gráfica para seleccionar, por exemplo, conexións Wi-Fi é só un front end.
Teremos que subir na súa configuración.
- Cree un ficheiro en /etc/NetworkManager/dnsmasq.d/evilcorp
enderezo=/.evilcorp.com/192.168.430.534
Preste atención ao punto fronte ao evilcorp. Indica a dnsmasq que todos os subdominios de evilcorp.com deben buscarse no dns corporativo.
- Diga a NetworkManager que use dnsmasq para a resolución de nomes
A configuración do xestor de rede atópase en /etc/NetworkManager/NetworkManager.conf Debe engadir alí:
[principal] dns=dnsmasq
- Reinicie NetworkManager
service network-manager restartAgora, despois de conectarse a unha VPN usando openconnect e vpn-slice, a ip determinarase normalmente, aínda que non engada enderezos simbólicos aos argumentos de vpnslice.
Como acceder a servizos individuais mediante VPN
Despois de que conseguín conectarme á VPN, quedei moi feliz durante dous días, e despois resultou que se me conecto á VPN desde fóra da rede da oficina, o correo non funciona. O síntoma é familiar, non?
O noso correo atópase en mail.publicevilcorp.com, o que significa que non cae baixo a regra de dnsmasq e que o enderezo do servidor de correo se busca a través do DNS público.
Ben, a oficina aínda usa DNS, que contén este enderezo. Iso é o que pensei. De feito, despois de engadir a liña a dnsmasq
enderezo=/mail.publicevilcorp.com/192.168.430.534
a situación non cambiou en absoluto. ip permaneceu igual. Tiven que ir traballar.
E só despois, cando afondei na situación e entendín un pouco o problema, unha persoa intelixente díxome como resolvelo. Era necesario conectarse ao servidor de correo non só así, senón a través da VPN
Eu uso vpn-slice para pasar pola VPN a enderezos que comezan con 192.168.430. E o servidor de correo non só ten un enderezo simbólico que non é un subdominio de evilcorp, senón que tampouco ten un enderezo IP que comece por 192.168.430. E claro que non permite que ninguén da rede xeral acuda a el.
Para que Linux pase pola VPN e ao servidor de correo, tamén debes engadilo a vpn-slice. Digamos que o enderezo do correo é 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 crear VPN cun argumento
Todo isto, por suposto, non é moi conveniente. Si, pode gardar o texto nun ficheiro e copialo e pegalo na consola en lugar de tecleo a man, pero aínda así non é moi agradable. Para facilitar o proceso, pode envolver o comando nun script que se localizará en PATH. E entón só terás que introducir o código recibido de 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 pon o script en connect~evilcorp~ pode simplemente escribir na consola
connect_evil_corp 567987Pero agora aínda tes que manter aberta a consola na que se está executando openconnect por algún motivo
Executando openconnect en segundo plano
Afortunadamente, os autores de openconnect coidaron de nós e engadiron unha clave especial ao programa -background, que fai que o programa funcione en segundo plano despois do lanzamento. Se o executas así, podes pechar a consola despois do lanzamento
#!/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 non está claro onde van os rexistros. En xeral, realmente non necesitamos rexistros, pero nunca se sabe. openconnect pode redirixilos a syslog, onde estarán seguros e protexidos. cómpre engadir o interruptor –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 así, resulta que openconnect funciona nalgún lugar en segundo plano e non molesta a ninguén, pero non está claro como detelo. É dicir, pode, por suposto, filtrar a saída de ps usando grep e buscar un proceso cuxo nome conteña openconnect, pero isto é algo tedioso. Grazas aos autores que tamén pensaron nisto. Openconnect ten unha clave -pid-file, coa que podes indicar a openconnect que escriba o seu identificador de proceso nun ficheiro.
#!/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 sempre podes matar un proceso co comando
kill $(cat ~/vpn-pid)Se non hai proceso, kill maldicirá, pero non lanzará un erro. Se o ficheiro non está alí, tampouco pasará nada malo, polo que pode matar o proceso con seguridade na primeira liña 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 podes acender o teu ordenador, abrir a consola e executar o comando, pasándolle o código de Google Authenticator. A consola pode entón ser cravada.
Sen VPN-slice. No canto dun epílogo
Resultou moi difícil entender como vivir sen VPN-slice. Tiven que ler e buscar moito en Google. Afortunadamente, despois de pasar tanto tempo cun problema, os manuais técnicos e ata o home openconnect len como novelas emocionantes.
Como resultado, descubrín que vpn-slice, como o script nativo, modifica a táboa de enrutamento para separar redes.
Táboa de enrutamento
Para dicilo simplemente, esta é unha táboa na primeira columna que contén o enderezo polo que Linux quere pasar, e na segunda columna que adaptador de rede debe pasar neste enderezo. De feito, hai máis falantes, pero isto non cambia a esencia.
Para ver a táboa de enrutamento, cómpre 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 Aquí, cada liña é responsable de onde precisa ir para enviar unha mensaxe a algún enderezo. O primeiro é unha descrición de onde debe comezar o enderezo. Para entender como determinar que 192.168.0.0/16 significa que o enderezo debe comezar por 192.168, cómpre buscar en Google cal é unha máscara de enderezo IP. Despois de dev hai o nome do adaptador ao que se debe enviar a mensaxe.
Para VPN, Linux fixo un adaptador virtual: tun0. A liña garante que o tráfico de todos os enderezos que comezan por 192.168 pasa por ela
192.168.0.0/16 dev tun0 scope link Tamén podes ver o estado actual da táboa de enrutamento usando o comando ruta -n (Os enderezos IP están intelixentemente anónimos) Este comando produce resultados nunha forma diferente e xeralmente está en desuso, pero a súa saída atópase a miúdo nos manuais en Internet e cómpre poder lelo.
Onde debería comezar o enderezo IP dunha ruta pódese entender a partir da combinación das columnas Destino e Genmask. Téñense en conta aquelas partes do enderezo IP que se corresponden cos números 255 en Genmask, pero as onde hai 0 non. É dicir, a combinación de Destino 192.168.0.0 e Genmask 255.255.255.0 significa que se o enderezo comeza por 192.168.0, a súa solicitude irá por esta ruta. E se o destino 192.168.0.0 pero Genmask 255.255.0.0, as solicitudes a enderezos que comecen por 192.168 irán por esta ruta
Para descubrir o que realmente fai vpn-slice, decidín mirar os estados das táboas antes e despois.
Antes de activar a VPN foi así
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 wlp3s0Despois de chamar a openconnect sen vpn-slice quedou así
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 despois de chamar a openconnect en combinación con vpn-slice como este
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 tun0Pódese ver que se non usa vpn-slice, entón openconnect escribe explícitamente que todos os enderezos, excepto os indicados especificamente, deben accederse a través de vpn.
Xusto aquí:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Alí, ao seu carón, indícase inmediatamente outro camiño, que se debe empregar se o enderezo polo que está tentando pasar Linux non coincide con ningunha máscara da táboa.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Xa está escrito aquí que neste caso cómpre usar un adaptador Wi-Fi estándar.
Creo que se usa a ruta VPN porque é a primeira da táboa de enrutamento.
E, teoricamente, se eliminas este camiño predeterminado da táboa de enrutamento, en conxunto con dnsmasq openconnect debería garantir o funcionamento normal.
intenteino
route del defaultE todo funcionou.
Enrutamento de solicitudes a un servidor de correo sen vpn-slice
Pero tamén teño un servidor de correo co enderezo 555.555.555.555, ao que tamén hai que acceder mediante VPN. A ruta ata ela tamén debe engadirse manualmente.
ip route add 555.555.555.555 via dev tun0E agora todo está ben. Así que podes prescindir de vpn-slice, pero cómpre saber ben o que estás facendo. Agora estou pensando en engadir á última liña do script openconnect nativo a eliminación da ruta predeterminada e engadir unha ruta para o correo despois de conectarme á VPN, só para que haxa menos pezas móbiles na miña bicicleta.
Probablemente, este epílogo sería suficiente para que alguén entenda como configurar unha VPN. Pero mentres intentaba entender o que e como facer, lin moitas guías deste tipo que funcionan para o autor, pero por algún motivo non me funcionan, e decidín engadir aquí todas as pezas que atopei. Estaría moi feliz con algo así.
Fonte: www.habr.com