Vuoi utilizzare Linux al lavoro, ma la VPN aziendale non lo permette? Allora questo articolo potrebbe aiutarti, anche se non è sicuro. Voglio avvisarti in anticipo che capisco poco di amministrazione di rete, quindi non escludo di aver fatto tutto in modo sbagliato. D'altra parte, è possibile che io riesca a scrivere una guida sufficientemente chiara per le persone comuni, quindi ti consiglio di provare.
Nell'articolo c'è molta informazione superflua, ma senza queste conoscenze non sarei riuscito a risolvere i problemi che mi sono improvvisamente presentati con la configurazione della VPN. Penso che chiunque proverà ad applicare questa guida avrà problemi che io 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 è stata pesantemente offuscata, quindi se vedi un indirizzo come 435.435.435.435, ci deve essere un indirizzo IP normale specifico per il tuo caso.
Ho Ubuntu 18.04, ma penso che con alcune piccole modifiche la guida possa essere applicata anche ad altre distribuzioni. Tuttavia, in questo testo Linux è uguale a Ubuntu.
Cisco Connect
Coloro che utilizzano Windows o MacOS possono connettersi al nostro VPN aziendale tramite Cisco Connect, dove è necessario specificare l'indirizzo del gateway e digitare una password ad ogni connessione, composta da una parte fissa e da un codice generato da Google Authenticator.
Nel caso di Linux, non sono riuscito a far funzionare Cisco Connect, ma ho trovato la raccomandazione di usare openconnect, progettato appositamente per sostituire Cisco Connect.
Openconnect
In teoria, Ubuntu ha un'interfaccia grafica speciale per openconnect, ma la mia non ha funzionato. Forse è per il meglio.
In Ubuntu, openconnect si installa tramite il gestore pacchetti.
apt install openconnectSubito dopo l'installazione, puoi provare a connetterti al VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com è l'indirizzo di un VPN inventato
poxvuibr è il nome di un utente inventato
openconnect richiederà di inserire una password, che ricordo consiste in una parte fissa e in un codice di Google Authenticator, e poi proverà a connettersi al vpn. Se ha avuto successo, congratulazioni, potete tranquillamente saltare la parte in cui ci sono molti problemi e passare al punto su come openconnect funzioni in background. Se non ha funzionato, si può continuare. Anche se se ha funzionato, per esempio, collegandosi dal Wi-Fi ospite del lavoro, potrebbe essere presto per festeggiare; dovreste provare a ripetere la procedura da casa.
Certificato
Con alta probabilità, niente si avvierà, e l'output di openconnect apparirà più o meno così:
POST https://vpn.evilcorp.com/
Collegato a 777.777.777.777:443
Negoziazione SSL con vpn.evilcorp.com
Verifica del certificato del server non riuscita: firmatario non trovato
Il certificato del server VPN "vpn.evilcorp.com" ha fallito la 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 abortire; qualsiasi altra cosa per visualizzare: fgets (stdin): Operazione in corsoDa un lato è scomodo, perché non si è verificata la connessione VPN, ma dall'altro lato come risolvere questo problema è fondamentalmente chiaro.
Il server ci ha inviato un certificato che permette di verificare che la connessione sia effettuata proprio verso il server della società madre e non verso un malintenzionato. Tuttavia, questo certificato non è riconosciuto dal sistema, che quindi non può verificare se il server è autentico o meno. Per sicurezza, interrompe pertanto l'operazione.
Per fare in modo che openconnect riesca a collegarsi al server, è necessario specificare esplicitamente quale certificato deve essere ricevuto dal server VPN, utilizzando la chiave —servercert.
Per scoprire quale certificato ci ha inviato il server, possiamo vedere direttamente quello che ha stampato openconnect. Ecco ciò che ci interessa:
Per fidarsi di questo server in futuro, potresti aggiungere questo alla tua linea di comando:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Digita 'yes' per accettare, 'no' per annullare; qualsiasi altra cosa per visualizzare: fgets (stdin): Operazione in corso.Questa è la riga di comando che puoi provare per connetterti di nuovo.
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comForse ora funziona, allora possiamo passare alla fase finale. Ma personalmente, Ubuntu mi ha mostrato il dito 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
Si prega di inserire il nome utente e la password.
POST https://vpn.evilcorp.com/
Ricevuta risposta CONNECT: HTTP/1.1 200 OK
CSTP connesso. DPD 300, Keepalive 30
Impostazione DTLS fallita; si utilizza SSL invece
Connesso come 192.168.333.222, utilizzando SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
Le risposte RTNETLINK: 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 sarà risolto, ma non sarà possibile accedervi. Indirizzi come jira.evilcorp.com non vengono risolti.
Non capisco cosa sia successo. Ma l'esperimento mostra che se si aggiunge la riga a /etc/resolv.conf
nameserver 192.168.430.534gli indirizzi all'interno della VPN inizieranno a risolversi magicamente e sarà possibile accedervi, il che significa che ciò che cerca di risolvere gli indirizzi DNS guarda esattamente in /etc/resolv.conf, e non altrove.
È possibile verificare che la connessione alla VPN esiste e funziona anche senza modifiche a /etc/resolv.conf, basta inserire nel browser non un nome simbolico del risorsa da vpn, ma il suo indirizzo IP
Alla fine si presentano due problemi
- la VPN non acquisisce il suo DNS durante la connessione
- tutto il traffico passa attraverso la VPN, che non consente di accedere a Internet
Ora ti racconterò cosa fare, ma prima un po' di automazione.
Immissione automatica della parte fissa della password
A questo punto hai probabilmente 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 bisogna rispettare un intervallo di tempo fisso.
La soluzione definitiva al problema non è stata inclusa nell'articolo, ma possiamo 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 di Google Authenticator sia '567 987'. L'intera password 'openconnect' può essere trasmessa tramite l'input standard grazie all'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 cambiare solo la parte del Google Authenticator.
Il VPN aziendale non consente di navigare in Internet.
Non è affatto comodo dover usare un computer separato per accedere a Habr. L'assenza della possibilità di copiare e incollare da Stack Overflow può davvero paralizzare il lavoro, quindi bisogna trovare una soluzione.
È necessario organizzarsi in modo che quando si deve accedere a una risorsa dalla rete interna, Linux utilizzi il VPN, mentre quando si deve entrare su Habr — vada su Internet.
Openconnect, dopo l'avvio e la connessione al VPN, esegue uno script speciale che si trova in /usr/share/vpnc-scripts/vpnc-script. Al programma vengono passate alcune 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 utilizzando lo script predefinito.
A quanto pare, è stata sviluppata un'utilità chiamata vpn-slice proprio per persone come me, che consente di instradare il traffico tramite due canali senza complicazioni. Beh, insomma, dovrò comunque fare un po' di manovre, ma non è necessario essere uno sciamano al riguardo.
Separazione del traffico utilizzando vpn-slice
In primo luogo, è necessario installare vpn-slice, e dovrete gestirlo da soli. Se ci sono domande nei commenti, scriverò un post separato al riguardo. Ma è un programma normale in Python, quindi non dovrebbero esserci difficoltà. L'ho installato utilizzando virtualenv.
Poi, deve essere applicata l'utilità, usando il flag —script per specificare openconnect, in modo che si utilizzi 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 In —script viene passata la stringa con il comando da chiamare al posto dello script. ./bin/vpn-slice — percorso al file eseguibile vpn-slice 192.168.430.0/24 — maschera degli indirizzi da attraversare in vpn. Qui si intende che, se l'indirizzo inizia con 192.168.430, allora la risorsa con quell'indirizzo deve essere cercata all'interno della vpn.
Ora la situazione dovrebbe essere quasi normale. Quasi. Ora si può accedere a Habr e a una risorsa interna tramite IP, ma non si può accedere a una risorsa interna tramite nome simbolico. Se si scrive la corrispondenza tra il nome simbolico e l'indirizzo nel file hosts, tutto dovrebbe funzionare. E funzionare finché l'IP non cambia. Linux ora può connettersi a Internet o alla rete interna a seconda dell'IP. Ma per determinare l'indirizzo si utilizza ancora il DNS non aziendale.
Il problema potrebbe manifestarsi anche in questo modo: al lavoro tutto funziona normalmente, ma a casa si può accedere alle risorse interne solo tramite IP. Questo perché quando sei connesso al Wi-Fi aziendale, il DNS utilizzato è anche aziendale, e in esso gli indirizzi simbolici dal VPN vengono risolti, nonostante il fatto che accedere a tale indirizzo senza utilizzare VPN rimanga impossibile.
Modifica automatica del file hosts
Se vpn-slice viene gentilmente chiesto, può dopo l'avvio della VPN andare nel suo DNS, trovare gli indirizzi IP delle risorse necessarie in base ai loro nomi simbolici e inserirli in hosts. Dopo la disattivazione della VPN, quegli indirizzi verranno rimossi da hosts. Per fare ciò, è 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 dalla VPN.
Se ci sono pochi indirizzi nella rete, l'approccio con la modifica automatica del file hosts è abbastanza funzionale. Ma se ci sono molte risorse nella rete, dovrete continuamente aggiungere nel file script righe come zoidberg.test.evilcorp.com; zoidberg è come viene chiamato uno dei banchi di prova.
Ma ora, quando comprendiamo un po' meglio, questa necessità può essere rimossa.
Se dopo aver avviato la VPN controlli in /etc/hosts, potrai vedere una riga come questa.
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
In resolv.conf è stata aggiunta una nuova riga. Insomma, vpn-slice ha in qualche modo determinato dove si trova il server DNS per la VPN.
Ora dobbiamo fare in modo che, per scoprire l'indirizzo IP di un nome di dominio che finisce con evilcorp.com, Linux interroghi il DNS aziendale, mentre per qualcos'altro, il DNS di default.
Ho cercato a lungo su Google e ho scoperto che questa funzionalità è disponibile su Ubuntu out of the box. Si riferisce alla possibilità di utilizzare un server DNS locale dnsmasq per la risoluzione dei nomi.
È possibile configurare Linux in modo che si connette sempre al server DNS locale per ottenere gli indirizzi IP, il quale, a sua volta, cercherà l'IP sui corrispondenti server DNS esterni in base al nome di dominio.
Per gestire tutto ciò che riguarda le reti e le connessioni di rete, Ubuntu utilizza NetworkManager, e l'interfaccia grafica per selezionare, ad esempio, una connessione Wi-Fi è semplicemente un front-end per esso.
Dobbiamo dare un'occhiata alle sue configurazioni.
- Crea un file in /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Nota il punto prima di evilcorp. Esso segnala a dnsmasq che tutti i sottodomini di evilcorp.com devono essere cercati precisamente nel DNS aziendale.
- Dire a NetworkManager di utilizzare dnsmasq per la risoluzione dei nomi.
La configurazione del network-manager si trova in /etc/NetworkManager/NetworkManager.conf. È necessario aggiungere qui:
[main]
dns=dnsmasq
- Riavviare il NetworkManager
service network-manager restartOra, dopo essermi connesso al VPN usando il bundle openconnect e vpn-slice, l'IP viene identificato correttamente, anche se non aggiungo indirizzi simbolici agli argomenti di vpnslice.
Come accedere a servizi specifici tramite VPN
Dopo essermi connesso al VPN, sono stato molto contento per un paio di giorni, ma poi ho scoperto che se mi connettevo al VPN non dalla rete dell'ufficio, la posta non funzionava. Un sintomo familiare, non è vero?
La nostra posta si trova su mail.publicevilcorp.com, quindi non rientra nella regola di dnsmasq e l'indirizzo del server di posta viene cercato tramite DNS pubblico.
Ma in ufficio si utilizza comunque il DNS, in cui questo indirizzo è presente. Cioè, pensavo. In realtà, dopo aver aggiunto la riga in dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
la situazione non è cambiata. L'IP è rimasto lo stesso. Ho dovuto andare al lavoro.
E solo più tardi, quando mi sono immerso nella situazione e ho capito un po' meglio il problema, una persona intelligente mi ha suggerito come risolverlo. Dovevo collegarmi al server di posta non semplicemente, ma tramite VPN.
Uso vpn-slice per connettermi tramite VPN a indirizzi che iniziano con 192.168.430. Inoltre, il server di posta non solo ha un indirizzo simbolico che non è un sottodominio di evilcorp, ma ha anche un indirizzo IP che non inizia con 192.168.430. E dalla rete generale, ovviamente, non lascia entrare nessuno.
Per far sì che Linux si connetta tramite VPN e al server di posta, è necessario aggiungerlo in 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 l'attivazione del VPN con un singolo argomento.
Tutto ciò, ovviamente, non è molto comodo. Sì, si può salvare il testo in un file e copiarlo nella console invece di digitarlo a mano, ma non è comunque molto piacevole. Per semplificare il processo, si può avvolgere il comando in uno script che si trova nel PATH. Così basterà inserire il codice ricevuto 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 posiziona lo script in connect~evilcorp~, si potrà semplicemente scrivere nella console.
connect_evil_corp 567987.Ma ora sarà comunque necessario tenere aperta la console in cui è stato avviato openconnect.
Esecuzione di openconnect in background.
Fortunatamente, gli autori di openconnect si sono presi cura di noi e hanno aggiunto un'opzione speciale —background, che permette al programma di funzionare in background dopo l'avvio. Se lo avviamo in questo modo, possiamo chiudere il terminale 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 finiscono i log. In realtà, non ci servono molto, ma mai dire mai. openconnect può reindirizzarli in syslog, dove saranno conservati in modo sicuro. Questo va aggiunto alla riga di comando come opzione —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 Quindi, sembra che openconnect funzioni da qualche parte in background senza dare fastidio, ma non è chiaro come fermarlo. Certo, si può filtrare l'output di ps con grep per cercare il processo il cui nome contiene openconnect, ma è un po' laborioso. Grazie agli autori che hanno pensato anche a questo. In openconnect è disponibile l'opzione —pid-file, che consente di indirizzare openconnect a scrivere l'identificatore del suo 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, il comando kill restituirà un errore, ma non lanci a un'eccezione. Se il file non esiste, non succederà nulla di grave, quindi si può tranquillamente eliminare 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-pidAdesso puoi accendere il computer, aprire la console e avviare il comando, passando il codice da Google Authenticator. La console può poi essere chiusa.
Senza vpn-slice. Invece di un epilogo.
È risultato molto difficile capire come vivere senza vpn-slice. Ho dovuto leggere molto e cercare su Google. Per fortuna, dopo aver passato tanto tempo a risolvere il problema, i manuali tecnici e anche il man di openconnect si leggono come romanzi avvincenti.
Alla fine ho scoperto che vpn-slice, come lo script nativo, modifica la tabella di routing per separare le reti.
Tabella di routing
In parole povere, si tratta di una tabella nella cui prima colonna si trova da dove deve iniziare l'indirizzo che Linux vuole attraversare, e nella seconda attraverso quale interfaccia di rete passare per questo indirizzo. In realtà ci sono più colonne, ma questo non cambia il concetto.
Per vedere 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 Qui, ogni riga indica il percorso necessario per inviare un messaggio a un determinato indirizzo. La prima parte fornisce la descrizione da cui deve partire l'indirizzo. Per capire come definire che 192.168.0.0/16 significa che l'indirizzo deve iniziare con 192.168, bisogna cercare informazioni su cosa sia una subnet mask. Dopo 'dev' trovi il nome dell'adattatore a cui devi inviare il messaggio.
Per il VPN, Linux ha creato un adattatore virtuale — tun0. La riga che si occupa di indirizzare il traffico per tutti gli indirizzi che iniziano con 192.168 attraverso di esso è
192.168.0.0/16 dev tun0 scope link Puoi anche visualizzare lo stato attuale della tabella di routing utilizzando il comando route -n (gli indirizzi IP sono abilmente anonimizzati) Questo comando restituisce risultati in un altro formato ed è essenzialmente obsoleto, ma le sue output si trovano spesso nei manuali su Internet e bisogna saperlo leggere.
È possibile comprendere da quale parte dovrebbe iniziare l'indirizzo IP per la rotta, esaminando la combinazione delle colonne Destination e Genmask. Le parti dell'indirizzo IP corrispondenti ai numeri 255 nel Genmask vengono considerate, mentre quelle con 0 no. Quindi, una combinazione di Destination 192.168.0.0 e Genmask 255.255.255.0 significa che se l'indirizzo inizia con 192.168.0, la richiesta verrà instradata tramite questa rotta. Se invece la Destination è 192.168.0.0 ma il Genmask è 255.255.0.0, le richieste per gli indirizzi che iniziano con 192.168 passeranno tramite questa rotta.
Per comprendere cosa faccia realmente vpn-slice, ho deciso di analizzare gli stati 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 aver chiamato openconnect senza vpn-slice, è diventato così:
route -n
Tabella di routing IP del kernel
Destino 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 aver chiamato openconnect in combinazione con vpn-slice in questo modo
Tabella di routing IP del kernel
Destino 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 indica esplicitamente che per tutti gli indirizzi, tranne quelli specificamente indicati, è necessario connettersi tramite vpn.
Qui:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Vicino c'è un altro percorso che deve essere utilizzato se l'indirizzo a cui cerca di accedere Linux non corrisponde a nessuna maschera della tabella.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Qui è già scritto che in questo caso bisogna passare attraverso l'adattatore Wi-Fi standard.
Credo che il percorso per il VPN venga utilizzato perché è il primo nella tabella di routing.
E teoricamente, se si rimuove questo percorso predefinito dalla tabella di routing, openconnect dovrebbe garantire un corretto funzionamento in combinazione con dnsmasq.
Ho provato
route del defaultE tutto ha funzionato.
Routing delle richieste al server di posta senza vpn-slice
Ma ho anche un altro server di posta con l'indirizzo 555.555.555.555, al quale devo accedere tramite VPN. Dobbiamo anche aggiungere manualmente il percorso a questo.
ip route add 555.555.555.555 via dev tun0E ora tutto funziona correttamente. Quindi è possibile fare a meno di vpn-slice, ma bisogna sapere bene cosa si sta facendo. Sto pensando di aggiungere l'eliminazione del percorso predefinito e l'aggiunta del percorso per il server di posta nello script originale di openconnect dopo la connessione al VPN, semplicemente per ridurre le parti mobili nella mia configurazione.
For some people, this postscript might be enough to understand how to set up a VPN. However, while I was trying to figure out what I needed to do, I read quite a few guides that worked for the author but somehow didn't work for me. Therefore, I decided to compile all the bits and pieces I found here. I would have greatly appreciated something like this.
Fonte: habr.com
