Vuoi utilizzare Linux al lavoro, ma la tua VPN aziendale non te lo consente? Allora questo articolo potrebbe aiutarti, anche se questo non è certo. Vorrei avvisarti in anticipo che non capisco bene le questioni di amministrazione di rete, quindi è possibile che abbia sbagliato tutto. D'altra parte, è possibile che io riesca a scrivere una guida in modo tale che sia comprensibile alla gente comune, quindi ti consiglio di provarla.
L'articolo contiene molte informazioni non necessarie, ma senza queste conoscenze non sarei riuscito a risolvere i problemi che mi sono comparsi inaspettatamente durante la configurazione di una VPN. Penso che chiunque provi a utilizzare questa guida avrà problemi che io non ho avuto e spero che queste informazioni aggiuntive aiutino a risolvere questi problemi da soli.
La maggior parte dei comandi utilizzati in questa guida devono essere eseguiti tramite sudo, che è stato rimosso per brevità. Tieni a mente.
La maggior parte degli indirizzi IP sono stati gravemente offuscati, quindi se vedi un indirizzo come 435.435.435.435, deve esserci un IP normale, specifico per il tuo caso.
Ho Ubuntu 18.04, ma penso che con piccole modifiche la guida possa essere applicata ad altre distribuzioni. Tuttavia, in questo testo Linux == Ubuntu.
Cisco Connect
Chi utilizza Windows o macOS può connettersi alla nostra VPN aziendale tramite Cisco Connect, dove occorre 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 far funzionare Cisco Connect, ma sono riuscito a cercare su Google un consiglio per utilizzare openconnect, creato appositamente per sostituire Cisco Connect.
Apri connetti
In teoria Ubuntu ha un’interfaccia grafica speciale per openconnect, ma per me non ha funzionato. Forse è meglio così.
Su Ubuntu, openconnect viene installato dal gestore pacchetti.
apt install openconnectSubito dopo l'installazione, puoi provare a connetterti a una VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com è l'indirizzo di una VPN fittizia
poxvuibr - nome utente fittizio
openconnect ti chiederà di inserire una password che, ti ricordo, è composta da una parte fissa e da un codice di Google Authenticator, quindi tenterà di connettersi alla VPN. Se funziona, congratulazioni, puoi tranquillamente saltare la parte centrale, che è molto fastidiosa, e passare al punto relativo all'esecuzione di openconnect in background. Se non funziona, puoi continuare. Anche se ha funzionato durante la connessione, ad esempio, dal Wi-Fi ospite al lavoro, potrebbe essere troppo presto per rallegrarsi, dovresti provare a ripetere la procedura da casa.
certificato
C'è un'alta probabilità che non venga avviato nulla e l'output di openconnect sarà simile a questo:
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 progressDa un lato questo è spiacevole, perché non c'era connessione alla VPN, ma dall'altro è, in linea di principio, chiaro come risolvere questo problema.
Qui il server ci ha inviato un certificato dal quale possiamo determinare che la connessione viene stabilita al server della nostra società nativa e non a un truffatore malvagio, e questo certificato è sconosciuto al sistema. E quindi non può verificare se il server è reale o meno. E così, per ogni evenienza, smette di funzionare.
Affinché openconnect possa connettersi al server, è necessario dirgli esplicitamente quale certificato dovrebbe provenire dal server VPN utilizzando la chiave —servercert
E puoi scoprire quale certificato ci ha inviato il server direttamente da ciò che ha stampato openconnect. Ecco da questo pezzo:
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 questo comando puoi provare a connetterti nuovamente
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comForse ora funziona, quindi puoi andare avanti fino alla fine. Ma personalmente, Ubuntu mi ha mostrato un fico in questa 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 risolverà il problema, ma non potrai andarci. Indirizzi come jira.evilcorp.com non vengono affatto risolti.
Quello che è successo qui non mi è chiaro. Ma l'esperimento mostra che se aggiungi la riga a /etc/resolv.conf
nameserver 192.168.430.534quindi gli indirizzi all'interno della VPN inizieranno a risolversi magicamente e potrai esaminarli, ovvero ciò che il DNS sta cercando per risolvere gli indirizzi appare specificamente in /etc/resolv.conf e non altrove.
Puoi verificare che ci sia una connessione con la VPN e che funzioni senza apportare alcuna modifica a /etc/resolv.conf; per fare questo basta inserire nel browser non il nome simbolico della risorsa proveniente dalla VPN, ma il suo indirizzo IP
Di conseguenza, ci sono due problemi
- Quando ci si connette a una VPN, il suo DNS non viene rilevato
- tutto il traffico passa attraverso VPN, che non consente l'accesso a Internet
Ti dirò cosa fare ora, ma prima un po' di automazione.
Inserimento automatico della parte fissa della password
Ormai molto probabilmente avrai già inserito la password almeno cinque volte e questa procedura ti avrà già stancato. In primo luogo perché la password è lunga e in secondo luogo perché quando si accede è necessario rientrare in un periodo di tempo prestabilito
La soluzione definitiva al problema non è stata inclusa nell'articolo, ma potete assicurarvi che la parte fissa della password non debba essere inserita più volte.
Supponiamo che la parte fissa della password sia fixPassword e che la parte di Google Authenticator sia 567. L'intera password può essere passata a openconnect tramite input standard utilizzando 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 immesso e modificare lì solo una parte di Google Authenticator.
Una VPN aziendale non ti consente di navigare in Internet.
In generale, non è molto scomodo quando devi utilizzare un computer separato per andare su Habr. L'impossibilità di copiare e incollare da StackOverfow può generalmente paralizzare il lavoro, quindi è necessario fare qualcosa.
Dobbiamo in qualche modo organizzarlo in modo che quando devi accedere a una risorsa dalla rete interna, Linux vada alla VPN e quando devi andare a Habr, vada a Internet.
openconnect, dopo aver avviato e stabilito una connessione con VPN, esegue uno script speciale, che si trova in /usr/share/vpnc-scripts/vpnc-script. Alcune variabili vengono passate allo script come input e configura la VPN. Sfortunatamente, non sono riuscito a capire come suddividere i flussi di traffico tra una VPN aziendale e il resto di Internet utilizzando uno script nativo.
Apparentemente per persone come me è stata sviluppata l'utilità vpn-slice, che consente di inviare traffico attraverso due canali senza ballare con il tamburello. Bene, dovrai ballare, ma non devi essere uno sciamano.
Separazione del traffico tramite VPN-Slice
Innanzitutto, dovrai installare VPN-Slice, dovrai capirlo da solo. Se ci sono domande nei commenti, scriverò un post separato a riguardo. Ma questo è un normale programma Python, quindi non dovrebbero esserci difficoltà. Ho installato utilizzando virtualenv.
E poi è necessario applicare l'utilità, utilizzando l'opzione -script, indicando a openconnect che invece dello script standard, è necessario utilizzare 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 viene passata una stringa con un comando che deve essere chiamato al posto dello script. ./bin/vpn-slice - percorso del file eseguibile vpn-slice 192.168.430.0/24 - maschera degli indirizzi a cui accedere in vpn. Qui intendiamo che se l'indirizzo inizia con 192.168.430, allora la risorsa con questo indirizzo deve essere cercata all'interno della VPN
Adesso la situazione dovrebbe essere quasi normale. Quasi. Ora è possibile accedere a Habr e alla risorsa intra-aziendale tramite ip, ma non è possibile accedere alla risorsa intra-aziendale tramite nome simbolico. Se specifichi una corrispondenza tra il nome simbolico e l'indirizzo negli host, tutto dovrebbe funzionare. E lavora finché l'ip non cambia. Linux ora può accedere a Internet o Intranet, a seconda dell'IP. Ma per determinare l’indirizzo viene ancora utilizzato il DNS non aziendale.
Il problema può manifestarsi anche in questa forma: al lavoro va tutto bene, ma a casa è possibile accedere alle risorse aziendali interne solo tramite IP. Questo perché quando si è connessi al Wi-Fi aziendale, viene utilizzato anche il DNS aziendale e in esso vengono risolti gli indirizzi simbolici della VPN, nonostante sia ancora impossibile raggiungere tale indirizzo senza utilizzare una VPN.
Modifica automatica del file host
Se vpn-slice viene chiesto educatamente, dopo aver attivato la VPN, può accedere al suo DNS, trovare lì gli indirizzi IP delle risorse necessarie con i loro nomi simbolici e inserirli negli host. Dopo aver disattivato la VPN, questi indirizzi verranno rimossi dagli host. Per fare ciò, devi passare nomi simbolici a vpn-slice come argomenti. Come questo.
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 Adesso tutto dovrebbe funzionare sia in ufficio che in spiaggia.
Cerca gli indirizzi di tutti i sottodomini nel DNS fornito dalla VPN
Se nella rete sono presenti pochi indirizzi, l'approccio di modifica automatica del file host funziona abbastanza bene. Ma se ci sono molte risorse sulla rete, dovrai costantemente aggiungere righe come zoidberg.test.evilcorp.com allo script zoidberg è il nome di uno dei banchi di prova.
Ma ora capiamo un po’ perché questa necessità può essere eliminata.
Se, dopo aver attivato la VPN, guardi in /etc/hosts, puoi vedere questa riga
192.168.430.534 dns0.tun0 # vpn-slice-tun0 CREATO AUTOMATICAMENTE
Ed è stata aggiunta una nuova riga a resolv.conf. In breve, VPN-Slice ha in qualche modo determinato dove si trova il server DNS per la VPN.
Ora dobbiamo assicurarci che per scoprire l'indirizzo IP di un nome di dominio che termina con evilcorp.com, Linux vada al DNS aziendale e, se è necessario qualcos'altro, a quello predefinito.
Ho cercato su Google per un bel po' di tempo e ho scoperto che tale funzionalità è già disponibile in Ubuntu. Ciò significa la possibilità di utilizzare il server DNS locale dnsmasq per risolvere i nomi.
Cioè puoi assicurarti 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, Ubuntu utilizza NetworkManager e l'interfaccia grafica per selezionare, ad esempio, le connessioni Wi-Fi è solo un front-end.
Dovremo salire nella sua configurazione.
- Crea un file in /etc/NetworkManager/dnsmasq.d/evilcorp
indirizzo=/.evilcorp.com/192.168.430.534
Presta attenzione al punto davanti a evilcorp. Segnala a dnsmasq che tutti i sottodomini di evilcorp.com devono essere cercati nei dns aziendali.
- Di' a NetworkManager di utilizzare dnsmasq per la risoluzione dei nomi
La configurazione del gestore di rete si trova in /etc/NetworkManager/NetworkManager.conf È necessario aggiungere lì:
[principale] dns=dnsmasq
- Riavviare NetworkManager
service network-manager restartOra, dopo esserti connesso a una VPN utilizzando openconnect e vpn-slice, l'ip verrà determinato normalmente, anche se non aggiungi indirizzi simbolici agli argomenti di vpnslice.
Come accedere ai singoli servizi tramite VPN
Dopo essere riuscito a connettermi alla VPN, sono stato molto felice per due giorni, poi ho scoperto che se mi collegavo alla VPN dall'esterno della rete aziendale, la posta non funziona. Il sintomo è familiare, vero?
La nostra posta si trova in mail.publicevilcorp.com, il che significa che non rientra nella regola di dnsmasq e l'indirizzo del server di posta viene cercato tramite DNS pubblico.
Bene, l'ufficio usa ancora il DNS, che contiene questo indirizzo. Questo è quello che pensavo. Infatti, dopo aver aggiunto la riga a dnsmasq
indirizzo=/mail.publicevilcorp.com/192.168.430.534
la situazione non è cambiata affatto. l'ip è rimasto lo stesso. Dovevo andare a lavorare.
E solo più tardi, quando ho approfondito la situazione e ho capito un po' il problema, una persona intelligente mi ha detto come risolverlo. Era necessario connettersi al server di posta non solo così, ma tramite VPN
Utilizzo vpn-slice per passare attraverso la VPN agli indirizzi che iniziano con 192.168.430. E il server di posta non solo ha un indirizzo simbolico che non è un sottodominio di evilcorp, ma non ha nemmeno un indirizzo IP che inizi con 192.168.430. E ovviamente non permette a nessuno della rete generale di avvicinarsi a lui.
Affinché Linux possa passare attraverso la VPN e raggiungere il server di posta, è necessario aggiungerlo anche a vpn-slice. Diciamo che l'indirizzo del mittente è 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 aumentare la VPN con un argomento
Tutto questo, ovviamente, non è molto conveniente. Sì, puoi salvare il testo in un file e copiarlo e incollarlo nella console invece di digitarlo a mano, ma non è comunque molto piacevole. Per semplificare il processo, puoi racchiudere il comando in uno script che si troverà in PATH. E poi dovrai solo 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 inserisci lo script in connect~evilcorp~ puoi semplicemente scrivere nella console
connect_evil_corp 567987Ma ora per qualche motivo devi ancora mantenere aperta la console su cui è in esecuzione openconnect
Esecuzione di openconnect in background
Fortunatamente, gli autori di openconnect si sono presi cura di noi e hanno aggiunto una chiave speciale al programma - background, che fa funzionare il programma in background dopo il lancio. Se lo esegui in questo modo, puoi chiudere la console 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 non è chiaro dove vadano a finire i registri. In generale, non abbiamo davvero bisogno dei log, ma non si sa mai. openconnect può reindirizzarli a syslog, dove saranno mantenuti protetti e al sicuro. è necessario 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 E così si scopre che openconnect funziona da qualche parte in background e non dà fastidio a nessuno, ma non è chiaro come fermarlo. Cioè, puoi, ovviamente, filtrare l'output di ps usando grep e cercare un processo il cui nome contenga openconnect, ma questo è in qualche modo noioso. Grazie agli autori che hanno pensato anche a questo. Openconnect ha una chiave -pid-file, con la quale puoi istruire openconnect a scrivere il suo identificatore di 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 puoi sempre terminare un processo con il comando
kill $(cat ~/vpn-pid)Se non esiste alcun processo, kill imprecherà, ma non genererà un errore. Se il file non è presente, non accadrà nulla di male, quindi puoi 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 puoi accendere il computer, aprire la console ed eseguire il comando, passandogli il codice da Google Authenticator. La console può quindi essere inchiodata.
Senza VPN-Slice. Invece di una postfazione
Si è rivelato molto difficile capire come vivere senza VPN-Slice. Ho dovuto leggere e cercare su Google molto. Fortunatamente, dopo aver dedicato così tanto tempo a un problema, i manuali tecnici e persino Man OpenConnect si leggono come romanzi entusiasmanti.
Di conseguenza, ho scoperto che vpn-slice, come lo script nativo, modifica la tabella di routing in reti separate.
Tabella di instradamento
Per dirla semplicemente, questa è una tabella nella prima colonna che contiene con quale dovrebbe iniziare l'indirizzo che Linux vuole utilizzare e nella seconda colonna quale adattatore di rete utilizzare a questo indirizzo. In effetti ci sono più parlanti, ma questo non cambia l'essenza.
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 Qui, ogni riga è responsabile di dove devi andare per inviare un messaggio a un indirizzo. La prima è una descrizione di dove dovrebbe iniziare l'indirizzo. Per capire come determinare che 192.168.0.0/16 significa che l'indirizzo dovrebbe iniziare con 192.168, è necessario cercare su Google cos'è una maschera di indirizzo IP. Dopo dev c'è il nome dell'adattatore a cui deve essere inviato il messaggio.
Per VPN, Linux ha creato un adattatore virtuale: tun0. La linea garantisce che il traffico per tutti gli indirizzi che iniziano con 192.168 la attraversi
192.168.0.0/16 dev tun0 scope link Puoi anche controllare lo stato corrente della tabella di routing usando il comando percorso -n (Gli indirizzi IP sono abilmente resi anonimi) Questo comando produce risultati in una forma diversa ed è generalmente deprecato, ma il suo output si trova spesso nei manuali su Internet ed è necessario essere in grado di leggerlo.
Il punto in cui dovrebbe iniziare l'indirizzo IP per un percorso può essere compreso dalla combinazione delle colonne Destination e Genmask. Vengono prese in considerazione quelle parti dell'indirizzo IP che corrispondono ai numeri 255 in Genmask, ma quelle dove c'è 0 non lo sono. Cioè, la 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 ad esso seguirà questo percorso. E se la destinazione 192.168.0.0 ma Genmask 255.255.0.0, le richieste agli indirizzi che iniziano con 192.168 seguiranno questo percorso
Per capire cosa fa effettivamente vpn-slice, ho deciso di guardare gli stati delle tabelle prima e dopo
Prima di attivare la VPN era così
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 wlp3s0Dopo aver chiamato openconnect senza VPN-Slice è diventato così
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 dopo aver chiamato openconnect in combinazione con vpn-slice in questo modo
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 tun0Si può vedere che se non si utilizza vpn-slice, openconnect scrive esplicitamente che tutti gli indirizzi, tranne quelli specificatamente indicati, devono essere accessibili tramite VPN.
Eccolo:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Lì, accanto ad esso, viene immediatamente indicato un altro percorso, che deve essere utilizzato se l'indirizzo attraverso il quale Linux sta cercando di passare non corrisponde ad alcuna maschera della tabella.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0È già scritto qui che in questo caso è necessario utilizzare un adattatore Wi-Fi standard.
Credo che venga utilizzato il percorso VPN perché è il primo nella tabella di routing.
E in teoria, se rimuovi questo percorso predefinito dalla tabella di routing, insieme a dnsmasq openconnect dovrebbe garantire il normale funzionamento.
Ci ho provato
route del defaultE tutto ha funzionato.
Instradamento delle richieste a un server di posta senza VPN-Slice
Ma ho anche un server di posta con l'indirizzo 555.555.555.555, a cui bisogna accedere anche tramite VPN. Anche il percorso per raggiungerlo deve essere aggiunto manualmente.
ip route add 555.555.555.555 via dev tun0E ora va tutto bene. Quindi puoi fare a meno di VPN-Slice, ma devi sapere bene cosa stai facendo. Ora sto pensando se aggiungere all'ultima riga dello script nativo di openconnect per rimuovere il percorso predefinito e aggiungere un percorso per il mailer dopo la connessione alla VPN, così ci sono meno parti mobili nella mia bici.
Probabilmente basterebbe questa postfazione per far capire a qualcuno come impostare una VPN. Ma mentre cercavo di capire cosa e come fare, ho letto parecchie di queste guide che funzionano per l'autore, ma per qualche motivo non funzionano per me, e ho deciso di aggiungere qui tutti i pezzi che ho trovato. Sarei molto felice di una cosa del genere.
Fonte: habr.com