Vuoi usare Linux al lavoro, ma la VPN aziendale non ti permette di farlo? Allora questo articolo potrebbe aiutarti, anche se non è garantito. Vorrei avvertirti in anticipo che non comprendo bene le questioni di amministrazione delle reti, quindi non è escluso che io abbia fatto tutto in modo errato. D'altra parte, non escludo di poter redigere una guida che sia comprensibile per le persone comuni, quindi ti consiglio di provare.
Nell'articolo ci sono molte informazioni superflue, ma senza queste conoscenze non sarei riuscito a risolvere i problemi che sono emersi inaspettatamente durante la configurazione della VPN. Penso che chiunque tenti di applicare questa guida incontrerà problemi che non ho avuto, e spero che queste informazioni superflue possano aiutare a risolverli autonomamente.
La maggior parte dei comandi utilizzati nella guida devono essere eseguiti tramite sudo, che per brevità è stato omesso. Tieni presente.
La maggior parte degli indirizzi IP sono stati pesantemente offuscati, quindi se vedi un indirizzo simile a 435.435.435.435, dovrebbe esserci un indirizzo IP normale, specifico per il tuo caso.
Ho Ubuntu 18.04, ma penso che con qualche piccola modifica la guida possa essere applicata ad altre distribuzioni. Tuttavia in questo testo Linux == Ubuntu.
Cisco Connect
Coloro che usano Windows o MacOS possono connettersi alla nostra VPN aziendale tramite Cisco Connect, per il quale è necessario specificare l'indirizzo del gateway e, ad ogni connessione, inserire una password composta da una parte fissa e da un codice generato da Google Authenticator.
Nel caso di Linux, non sono riuscito a installare Cisco Connect, ma ho trovato la raccomandazione di utilizzare openconnect, progettato appositamente per sostituire Cisco Connect.
Openconnect
In teoria, su Ubuntu esiste un'interfaccia grafica specifica per openconnect, ma a me non ha funzionato. Può darsi che sia anche meglio così.
In Ubuntu, openconnect si installa tramite il gestore pacchetti.
apt install openconnectSubito dopo l'installazione, puoi provare a connetterti alla VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com è l'indirizzo di una VPN fittizia
poxvuibr è un nome utente fittizio
openconnect chiederà di inserire una password, che, ricordo, è composta da una parte fissa e da un codice di Google Authenticator, e poi tenterà di connettersi al vpn. Se funziona, congratulazioni, potete saltare la parte centrale piena di difficoltà e passare al punto sul funzionamento di openconnect in background. Se non funziona, si può continuare. Anche se se è riuscito a connettersi, ad esempio, da una rete wifi ospite al lavoro, forse è troppo presto per gioire, bisogna ripetere la procedura da casa.
Certificato
Con elevata probabilità nulla si avvierà e l'output di openconnect apparirà in questo modo:
POST https://vpn.evilcorp.com/
Connesso a 777.777.777.777:443
Negoziazione SSL con vpn.evilcorp.com
Verifica del certificato del server fallita: firmatario non trovato
Certificato dal server VPN "vpn.evilcorp.com" fallito nella verifica.
Motivo: firmatario non trovato
Per fidarti di questo server in futuro, forse aggiungi questo alla tua riga di comando:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Inserisci 'yes' per accettare, 'no' per annullare; qualsiasi altra cosa per visualizzare: fgets (stdin): Operazione ora in corsoDa un lato è sgradevole, perché non c'è stata connessione al VPN, ma dall'altro lato è chiaro come risolvere questo problema.
Qui il server ci ha inviato un certificato da cui possiamo determinare che stiamo realmente collegandoci al server dell'azienda madre e non a un malintenzionato, ma il sistema non riconosce questo certificato. E quindi non può verificare se il server è legittimo o meno. E quindi, per precauzione, interrompe l'operazione.
Per fare in modo che openconnect si connetta al server, è necessario indicargli esplicitamente quale certificato deve arrivare dal server VPN usando il flag --servercert
E conoscere quale certificato ci ha inviato il server possiamo direttamente da ciò che ha stampato openconnect. Ecco da questo pezzo:
Per fidarti di questo server in futuro, forse aggiungi questo alla tua riga di comando:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Inserisci 'yes' per accettare, 'no' per annullare; qualsiasi altra cosa per visualizzare: fgets (stdin): Operazione ora in corsoCon questo comando puoi provare a connetterti di nuovo
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comForse ora ha funzionato, allora si può passare alla fine. Ma personalmente, Ubuntu mi ha mostrato il medio in questo modo
POST https://vpn.evilcorp.com/
Connesso a 777.777.777.777:443
Negoziazione SSL con vpn.evilcorp.com
Verifica del certificato del server fallita: firmatario non trovato
Connesso a HTTPS su vpn.evilcorp.com
POST XML abilitato
Inserisci il tuo nome utente e password.
POST https://vpn.evilcorp.com/
Ricevuta risposta CONNECT: HTTP/1.1 200 OK
CSTP connesso. DPD 300, Keepalive 30
Configurazione di DTLS fallita; utilizzo di SSL invece
Connesso come 192.168.333.222, utilizzando SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK risponde: File esistente
/etc/resolvconf/update.d/libc: Avviso: /etc/resolv.conf non è un collegamento simbolico a /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 verrà risolto, ma non sarà possibile accedervi. Indirizzi come jira.evilcorp.com non vengono affatto risolti.
Non capisco cosa sia successo. Ma l'esperimento mostra che se aggiungi la riga a /etc/resolv.conf
nameserver 192.168.430.534gli indirizzi all'interno della VPN inizieranno magicamente a risolversi e potranno essere raggiunti, cioè ciò che cerca di risolvere gli indirizzi DNS guarda proprio in /etc/resolv.conf, e non altrove.
Puoi verificare che la connessione VPN esista e funzioni anche senza modifiche a /etc/resolv.conf, basta inserire nel browser non un nome simbolico risorsa dalla vpn, ma il suo indirizzo ip.
Alla fine si presentano due problemi
- nella connessione alla VPN non viene catturato il suo DNS
- tutto il traffico passa attraverso la vpn, che non consente di navigare in internet
Cosa fare lo spiegherò ora, ma prima un po' di automazione.
Inserimento automatico della parte fissa della password
A questo punto, probabilmente hai già inserito la password almeno cinque volte e questa procedura ti ha già stancato. Innanzitutto, perché la password è lunga, in secondo luogo perché durante l'inserimento devi rispettare un intervallo di tempo fisso.
La soluzione definitiva al problema non è stata inclusa nell'articolo, ma si può fare in modo che la parte fissa della password non debba essere inserita molte volte.
Supponiamo che la parte fissa della password sia fixedPassword, e la parte da Google Authenticator 567 987. L'intera password openconnect può essere passata tramite stdin con l'argomento --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinOra puoi tornare costantemente all'ultimo comando inserito e modificare solo la parte di Google Authenticator.
La VPN aziendale non consente di navigare in internet.
Non è molto comodo dover usare un computer separato per accedere a habr. L'assenza della possibilità di copiare e incollare da stackoverflow può realmente paralizzare il lavoro, quindi bisogna fare qualcosa.
È necessario organizzarsi in modo che, quando si deve accedere alla risorsa dalla rete interna, Linux si colleghi al VPN, e quando si deve accedere a Habr, vada su Internet.
Openconnect, dopo il lancio e l'installazione della connessione con il VPN, esegue uno script speciale, che si trova in /usr/share/vpnc-scripts/vpnc-script. Allo script vengono passate delle variabili, e questo si occupa della configurazione del VPN. Purtroppo, non sono riuscito a capire come separare i flussi di traffico tra il VPN aziendale e il resto di Internet usando lo script fornito.
Sembra che sia stata sviluppata appositamente per persone come me l'utilità vpn-slice, che consente di indirizzare il traffico attraverso due canali senza troppe complicazioni. Cioè, dovrò comunque fare un po' di fatica, ma non è necessario essere uno sciamano.
Separazione del traffico con vpn-slice
Innanzitutto, dovrai installare vpn-slice, e questo dovrai gestirlo da solo. Se ci saranno domande nei commenti, scriverò un post a riguardo. Ma è un programma normale in Python, quindi non dovrebbero esserci difficoltà. Io l'ho installato tramite virtualenv.
Dopo di che, sarà necessario utilizzare l'utilità, passando l'opzione --script per indicare a openconnect che deve usare vpn-slice invece dello script standard.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script ".\/bin\/vpn-slice 192.168.430.0\/24 " vpn.evilcorp.com Nell'opzione --script viene passata una stringa con il comando che deve essere eseguito al posto dello script. .\/bin\/vpn-slice è il percorso del file eseguibile vpn-slice e 192.168.430.0\/24 è la maschera degli indirizzi per cui si deve accedere al VPN. Qui si intende che, se l'indirizzo inizia con 192.168.430, allora la risorsa con quell'indirizzo deve essere cercata all'interno del VPN.
Ora la situazione dovrebbe essere quasi normale. Quasi. Ora si può accedere a Habr e anche a una risorsa interna tramite IP, ma non si può accedere a una risorsa interna tramite nome simbolico. Se si scrive la corrispondenza tra nome simbolico e indirizzo nel file hosts, tutto dovrebbe funzionare. E funzionerà, finché l'IP non cambierà. Ora Linux può accedere a Internet o alla rete interna a seconda dell'IP. Ma per determinare l'indirizzo viene ancora utilizzato un DNS non aziendale.
Il problema potrebbe manifestarsi anche in questo modo: al lavoro tutto funziona, ma a casa si può accedere alle risorse interne solo tramite IP. Questo perché, quando sei connesso al Wi-Fi aziendale, i DNS utilizzati sono anche aziendali e lì gli indirizzi simbolici del VPN vengono risolti, nonostante il fatto che non si possa accedere a tali indirizzi senza utilizzare il VPN.
Modifica automatica del file hosts
Se si chiede gentilmente a vpn-slice, dopo aver attivato il VPN, può andare nel suo DNS, trovare gli indirizzi IP delle risorse necessarie con i loro nomi simbolici e scriverli in hosts. Dopo che il VPN è disattivato, questi indirizzi verranno rimossi da hosts. Per farlo, è necessario passare i nomi simbolici a vpn-slice come argomenti. Ecco come.
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 Ora tutto dovrebbe funzionare sia in ufficio che in spiaggia.
Cercare gli indirizzi di tutti i sottodomini nel DNS fornito dal VPN
Se gli indirizzi all'interno della rete sono pochi, il metodo con la modifica automatica del file hosts è decisamente praticabile. Ma se ci sono molte risorse in rete, sarà necessario aggiungere continuamente al ciclo script righe come zoidberg.test.evilcorp.com, dove zoidberg è il nome di uno degli ambienti di prova.
Ma ora, quando iniziamo a capire meglio la situazione, possiamo eliminare questa necessità.
Se dopo aver attivato il VPN si guarda in \/etc\/hosts, si può vedere una riga come questa
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Inoltre, è stata aggiunta una nuova riga in resolv.conf. Insomma, vpn-slice ha in qualche modo determinato dove si trova il server DNS per il VPN.
Ora bisogna fare in modo che, per conoscere l'indirizzo IP di un nome di dominio che termina con evilcorp.com, Linux utilizzi il DNS aziendale, mentre per tutto il resto utilizzi il DNS predefinito.
Ho cercato a lungo su Google e ho scoperto che questa funzionalità è presente in Ubuntu di default. Si intendono le possibilità di utilizzare un server DNS locale, dnsmasq, per la risoluzione dei nomi.
Quindi si può impostare in modo che Linux vada sempre al server DNS locale per gli indirizzi IP, che a sua volta, a seconda del nome di dominio, cercherà l'IP sul corrispondente server DNS esterno.
Per gestire tutto ciò che riguarda le reti e le connessioni di rete, in Ubuntu si utilizza NetworkManager, e l'interfaccia grafica per la selezione, ad esempio, della connessione Wi-Fi è semplicemente un front-end per esso.
Dobbiamo esplorare le sue configurazioni.
- Creare un file in /etc/NetworkManager/dnsmasq.d/evilcorp
address=/evilcorp.com/192.168.430.534
Fai attenzione al punto prima di evilcorp. Indica a dnsmasq che tutti i sottodomini di evilcorp.com devono essere cercati proprio nel DNS aziendale.
- Comunicare a NetworkManager che per la risoluzione dei nomi è necessario utilizzare dnsmasq
La configurazione di network-manager si trova in /etc/NetworkManager/NetworkManager.conf Dobbiamo aggiungere:
[main]
dns=dnsmasq
- Riavviare NetworkManager
service network-manager restartOra, dopo aver effettuato la connessione al VPN utilizzando la combinazione openconnect e vpn-slice, l'IP sarà correttamente riconosciuto, anche se non si aggiungono indirizzi simbolici agli argomenti di vpnslice.
Come accedere a servizi specifici tramite VPN
Dopo essere riuscito a connettermi al VPN, per un paio di giorni ero molto felice, ma poi ho scoperto che se mi collego al VPN non dalla rete dell'ufficio, la posta non funziona. Un sintomo familiare, vero?
La nostra posta si trova in mail.publicevilcorp.com, e quindi non rientra nella regola in dnsmasq e l'indirizzo del server di posta viene cercato tramite il DNS pubblico.
Beh, in ufficio viene comunque utilizzato il DNS in cui questo indirizzo è presente. Così pensavo. In realtà, dopo aver aggiunto a dnsmasq la riga
address=/mail.publicevilcorp.com/192.168.430.534
la situazione non è cambiata. L'IP è rimasto lo stesso. Ho dovuto andare al lavoro.
E solo dopo, quando mi sono immerso nella situazione e ho capito un po' il problema, una persona intelligente mi ha suggerito come risolverlo. Dovevo connettermi al server di posta non in modo semplice, ma attraverso il VPN.
Utilizzo vpn-slice per accedere tramite VPN a indirizzi che iniziano con 192.168.430. Ma per il server di posta non solo l'indirizzo simbolico non è un sottodominio di evilcorp, ma anche l'indirizzo IP non inizia con 192.168.430. E dalla rete generale non permette naturalmente a nessuno di accedervi.
Per fare in modo che Linux acceda tramite VPN e al server di posta, è necessario aggiungerlo a vpn-slice. Supponiamo che l'indirizzo del server di posta sia 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 per avviare il VPN con un argomento
Tutto ciò, ovviamente, non è molto comodo. Sì, è possibile salvare il testo in un file e copiarlo nella console, invece di digitarlo a mano, ma non è comunque piacevole. Per facilitare il processo, si può incapsulare il comando in uno script che si troverà nel PATH. E allora basterà solo inserire il codice ottenuto da 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 si colloca lo script in connect~evilcorp~, sarà possibile semplicemente scriverlo nella console.
connect_evil_corp 567987Ma ora bisogna comunque tenere aperta la console in cui è stato avviato openconnect per qualche motivo.
Avvio di openconnect in background.
Fortunatamente gli autori di openconnect si sono preoccupati di noi e hanno aggiunto un'opzione speciale al programma: --background, che fa sì che il programma lavori in background dopo il lancio. Se lo si avvia in questo modo, la console può essere chiusa dopo l'avvio.
#!/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 Ora resta solo da capire dove vanno i log. In effetti, i log non ci servono molto, ma chi lo sa. openconnect può reindirizzarli nel syslog, dove saranno conservati intatti. Per fare ciò, bisogna aggiungere l'opzione --syslog al 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 Ecco che quindi openconnect funziona da qualche parte in background e non dà fastidio a nessuno, ma come fermarlo non è chiaro. Certo, è possibile filtrare l'output di ps con grep e cercare il processo il cui nome contiene openconnect, ma è un po' laborioso. Grazie agli autori che hanno pensato anche a questo. In openconnect c'è un'opzione --pid-file, con la quale si può istruire openconnect a scrivere l'identificativo del proprio processo in un file.
#!/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-pidOra è sempre possibile terminare il processo con il comando.
kill $(cat ~/vpn-pid)Se il processo non esiste, kill restituirà un messaggio di errore, ma non lancerà un'eccezione. Se il file non esiste, non succederà nulla di grave, quindi si può tranquillamente terminare il processo nella prima riga dello 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-pidOra si può accendere il computer, aprire la console e avviare il comando, passando il codice da Google Authenticator. La console può poi essere terminata.
Senza vpn-slice. Invece di una postfazione.
Capire come vivere senza vpn-slice si è rivelato molto difficile. Ho dovuto leggere molto e cercare su Google. Fortunatamente, dopo aver passato così tanto tempo con il problema, i manuali tecnici e anche man openconnect si leggono come romanzi avvincenti.
Alla fine ho scoperto che vpn-slice, proprio come lo script nativo, modifica la tabella di routing per separare le reti.
Tabella di routing
In parole semplici, si tratta di una tabella in cui la prima colonna contiene l'inizio dell'indirizzo che Linux deve utilizzare, mentre nella seconda colonna è indicato attraverso quale adattatore di rete passare per questo indirizzo. In realtà ci sono più colonne, ma questo non cambia il concetto.
Per visualizzare la tabella di routing, è necessario eseguire il 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 Ogni riga qui indica come raggiungere un certo indirizzo per inviare un messaggio. La prima parte è la descrizione di dove deve iniziare l'indirizzo. Per capire cosa significa 192.168.0.0/16, che indica che l'indirizzo deve iniziare con 192.168, è necessario cercare cosa sia una maschera di indirizzo IP. Dopo dev si trova il nome dell'adattatore verso cui inviare il messaggio.
Per il VPN, Linux ha creato un adattatore virtuale — tun0. La riga che fa sì che il traffico per tutti gli indirizzi che iniziano con 192.168 passi attraverso di esso è
192.168.0.0/16 dev tun0 scope link È possibile inoltre controllare lo stato attuale della tabella di routing utilizzando il comando route -n (gli indirizzi IP sono abilmente anonimizzati) Questo comando restituisce i risultati in un altro formato ed è deprecato, ma la sua uscita appare spesso nei manuali online, quindi è importante saperla interpretare.
Da cosa deve iniziare l'indirizzo IP per il routing si può capire dalla combinazione delle colonne Destination e Genmask. Le parti dell'indirizzo IP per cui in Genmask si trovano i numeri 255 vengono considerate, mentre quelle in cui ci sono 0 non lo sono. Pertanto, la combinazione Destination 192.168.0.0 e Genmask 255.255.255.0 significa che se l'indirizzo inizia con 192.168.0, la richiesta andrà tramite questo route. Se invece Destination è 192.168.0.0 ma Genmask è 255.255.0.0, le richieste degli indirizzi che iniziano con 192.168 passeranno per questo route.
Per capire realmente cosa faccia vpn-slice ho deciso di esaminare lo stato delle tabelle prima e dopo
Prima di attivare il VPN era così
route -n
Tabella di routing IP del 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 wlp3s0Dopo la chiamata a openconnect, senza vpn-slice, è diventato così
route -n
Tabella di routing IP del kernel
Destinazione 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 dopo la chiamata a openconnect in combinazione con vpn-slice in questo modo
Tabella di routing IP del kernel
Destinazione 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È evidente che se non si utilizza vpn-slice, openconnect scrive esplicitamente che per tutti gli indirizzi, tranne quelli specificamente indicati, bisogna passare attraverso il vpn.
Qui:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Accanto è specificato un altro percorso da utilizzare nel caso in cui l'indirizzo a cui cerca di accedere Linux non corrisponda a nessuna maschera della tabella.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Qui viene già indicato che in tal caso bisogna passare attraverso l'adattatore Wi-Fi standard.
Ritengo che il percorso per il VPN sia utilizzato perché è il primo nella tabella di routing.
E teoricamente, se si rimuove questo percorso predefinito dalla tabella di routing, openconnect dovrebbe garantire un buon funzionamento in combinazione con dnsmasq.
Ho provato
route del defaultE ha funzionato tutto.
Routing delle richieste al server di posta senza vpn-slice
Ma ho anche un server di posta con indirizzo 555.555.555.555, a cui è necessario accedere tramite VPN. È necessario aggiungere manualmente anche il percorso per questo.
ip route add 555.555.555.555 via dev tun0E ora va tutto bene. Quindi è possibile fare a meno di vpn-slice, ma è necessario sapere bene cosa si fa. Sto pensando di non aggiungere nell'ultima riga dello script originale di openconnect l'eliminazione del percorso predefinito e l'aggiunta del percorso per il server di posta dopo la connessione al VPN, solo per ridurre le parti mobili nella mia configurazione.
Forse a qualcuno sarebbe bastato questo epilogo per capire come configurare un VPN. Ma io, mentre cercavo di capire cosa fare e come, ho letto molti di questi manuali che funzionano per l'autore, ma stranamente non funzionano per me e ho deciso di aggiungere qui tutti i pezzi che ho trovato. Mi sarei molto rallegrato di qualcosa del genere.
Fonte: habr.com
