Vil du bruke Linux på jobben, men bedriftens VPN lar deg ikke? Da kan denne artikkelen hjelpe, selv om dette ikke er sikkert. Jeg vil advare deg på forhånd om at jeg ikke forstår problemer med nettverksadministrasjon godt, så det er mulig jeg har gjort alt feil. På den annen side er det mulig jeg kan skrive en guide på en slik måte at den blir forståelig for vanlige folk, så jeg råder deg til å prøve den.
Artikkelen inneholder mye unødvendig informasjon, men uten denne kunnskapen hadde jeg ikke klart å løse problemene som uventet dukket opp for meg med å sette opp en VPN. Jeg tror at alle som prøver å bruke denne veiledningen vil få problemer som jeg ikke hadde, og jeg håper at denne ekstra informasjonen vil bidra til å løse disse problemene på egenhånd.
De fleste av kommandoene som brukes i denne veiledningen må kjøres via sudo, som har blitt fjernet for korthets skyld. Husk.
De fleste IP-adresser har blitt alvorlig tilslørt, så hvis du ser en adresse som 435.435.435.435, må det være en normal IP der, spesifikt for ditt tilfelle.
Jeg har Ubuntu 18.04, men jeg tror med mindre endringer guiden kan brukes på andre distribusjoner. Men i denne teksten Linux == Ubuntu.
Cisco Connect
De som er på Windows eller MacOS kan koble til bedriftens VPN via Cisco Connect, som må spesifisere gateway-adressen og, hver gang du kobler til, angi et passord som består av en fast del og en kode generert av Google Authenticator.
Når det gjelder Linux, kunne jeg ikke få Cisco Connect til å kjøre, men jeg klarte å google en anbefaling om å bruke openconnect, laget spesielt for å erstatte Cisco Connect.
Åpne tilkobling
I teorien har Ubuntu et spesielt grafisk grensesnitt for openconnect, men det fungerte ikke for meg. Kanskje det er til det bedre.
På Ubuntu installeres openconnect fra pakkebehandlingen.
apt install openconnectUmiddelbart etter installasjonen kan du prøve å koble til en VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com er adressen til en fiktiv VPN
poxvuibr - fiktivt brukernavn
openconnect vil be deg om å skrive inn et passord, som, la meg minne deg, består av en fast del og en kode fra Google Authenticator, og så vil den prøve å koble til vpn. Hvis det fungerer, gratulerer, kan du trygt hoppe over midten, som er mye smerte, og gå videre til punktet om openconnect som kjører i bakgrunnen. Hvis det ikke fungerer, kan du fortsette. Selv om det fungerte når du koblet til, for eksempel fra en gjest Wi-Fi på jobben, kan det være for tidlig å glede seg; du bør prøve å gjenta prosedyren hjemmefra.
sertifikat
Det er stor sannsynlighet for at ingenting vil starte, og openconnect-utgangen vil se omtrent slik ut:
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 progressPå den ene siden er dette ubehagelig, fordi det ikke var noen tilkobling til VPN, men på den annen side er det i prinsippet klart hvordan du løser dette problemet.
Her sendte serveren oss et sertifikat, som vi kan fastslå at tilkoblingen gjøres til serveren til vårt opprinnelige selskap, og ikke til en ond svindel, og dette sertifikatet er ukjent for systemet. Og derfor kan hun ikke sjekke om serveren er ekte eller ikke. Og så, i tilfelle, slutter den å fungere.
For at openconnect skal koble seg til serveren, må du eksplisitt fortelle den hvilket sertifikat som skal komme fra VPN-serveren ved å bruke —servercert-nøkkelen
Og du kan finne ut hvilket sertifikat serveren sendte oss direkte fra det openconnect skrev ut. Her er fra dette stykket:
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 progressMed denne kommandoen kan du prøve å koble til igjen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comKanskje fungerer det nå, så kan du gå videre til slutten. Men personlig viste Ubuntu meg en fiken i denne formen
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 vil løse seg, men du vil ikke kunne gå dit. Adresser som jira.evilcorp.com er ikke løst i det hele tatt.
Hva som skjedde her er ikke klart for meg. Men eksperimentet viser at hvis du legger til linjen til /etc/resolv.conf
nameserver 192.168.430.534så vil adressene inne i VPN-en begynne å løse seg på magisk vis, og du kan gå gjennom dem, det vil si at det DNS leter etter for å løse adresser ser spesifikt ut i /etc/resolv.conf, og ikke et annet sted.
Du kan bekrefte at det er en tilkobling til VPN og den fungerer uten å gjøre noen endringer i /etc/resolv.conf; for å gjøre dette, skriv bare inn i nettleseren ikke det symbolske navnet på ressursen fra VPN, men IP-adressen.
Som et resultat er det to problemer
- Når du kobler til en VPN, blir ikke dns-en hentet
- all trafikk går gjennom VPN, som ikke tillater tilgang til Internett
Jeg skal fortelle deg hva du skal gjøre nå, men først litt automatisering.
Automatisk inntasting av den faste delen av passordet
Nå har du mest sannsynlig allerede skrevet inn passordet ditt minst fem ganger, og denne prosedyren har allerede slitt deg ut. For det første fordi passordet er langt, og for det andre fordi du når du går inn må passe innenfor en fastsatt tidsperiode
Den endelige løsningen på problemet var ikke inkludert i artikkelen, men du kan sørge for at den faste delen av passordet ikke må skrives inn mange ganger.
La oss anta at den faste delen av passordet er fixedPassword, og delen fra Google Authenticator er 567 987. Hele passordet kan sendes til openconnect via standardinndata ved å bruke --passwd-on-stdin argumentet.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNå kan du hele tiden gå tilbake til den sist angitte kommandoen og endre bare deler av Google Authenticator der.
En bedrifts-VPN lar deg ikke surfe på Internett.
Generelt er det ikke veldig upraktisk når du må bruke en separat datamaskin for å gå til Habr. Manglende evne til å kopiere og lime fra stackoverfow kan generelt lamme arbeidet, så noe må gjøres.
Vi må på en eller annen måte organisere det slik at når du trenger tilgang til en ressurs fra det interne nettverket, går Linux til VPN, og når du trenger å gå til Habr, går det til Internett.
openconnect, etter å ha startet og opprettet en forbindelse med vpn, kjører et spesielt skript, som ligger i /usr/share/vpnc-scripts/vpnc-script. Noen variabler sendes til skriptet som input, og det konfigurerer VPN. Dessverre kunne jeg ikke finne ut hvordan jeg skulle dele trafikkstrømmer mellom en bedrifts-VPN og resten av Internett ved å bruke et innebygd skript.
Tilsynelatende ble vpn-slice-verktøyet utviklet spesielt for folk som meg, som lar deg sende trafikk gjennom to kanaler uten å danse med en tamburin. Vel, det vil si at du må danse, men du trenger ikke å være sjaman.
Trafikkseparasjon ved hjelp av vpn-slice
For det første må du installere vpn-slice, du må finne ut av dette selv. Hvis det er spørsmål i kommentarfeltet, vil jeg skrive et eget innlegg om dette. Men dette er et vanlig Python-program, så det burde ikke være noen problemer. Jeg installerte ved hjelp av virtualenv.
Og så må verktøyet brukes ved å bruke -script-bryteren, som indikerer for openconnect at i stedet for standardskriptet, må du bruke 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 sendes en streng med en kommando som må kalles i stedet for skriptet. ./bin/vpn-slice - bane til den kjørbare vpn-slice-filen 192.168.430.0/24 - maske med adresser å gå til i vpn. Her mener vi at hvis adressen starter med 192.168.430, må ressursen med denne adressen søkes i VPN-en
Situasjonen skal nå være tilnærmet normal. Nesten. Nå kan du gå til Habr og du kan gå til den interne ressursen med ip, men du kan ikke gå til den interne ressursen med symbolsk navn. Hvis du spesifiserer samsvar mellom det symbolske navnet og adressen i verter, skal alt fungere. Og jobb til ip-en endres. Linux kan nå få tilgang til Internett eller intranettet, avhengig av IP. Men ikke-bedrifts-DNS brukes fortsatt til å bestemme adressen.
Problemet kan også manifestere seg i denne formen - på jobb er alt bra, men hjemme kan du bare få tilgang til interne bedriftsressurser via IP. Dette er fordi når du er koblet til bedriftens Wi-Fi, brukes også bedriftens DNS, og symbolske adresser fra VPN løses i den, til tross for at det fortsatt er umulig å gå til en slik adresse uten å bruke en VPN.
Automatisk endring av vertsfilen
Hvis vpn-slice blir spurt høflig, kan den, etter å ha hevet VPN, gå til DNS, finne IP-adressene til de nødvendige ressursene ved deres symbolske navn og skrive dem inn i verter. Etter å ha slått av VPN, vil disse adressene bli fjernet fra verter. For å gjøre dette, må du sende symbolske navn til vpn-slice som argumenter. Som dette.
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 Nå skal alt fungere både på kontoret og på stranden.
Søk etter adressene til alle underdomener i DNS gitt av VPN
Hvis det er få adresser i nettverket, fungerer tilnærmingen med å automatisk modifisere vertsfilen ganske bra. Men hvis det er mange ressurser på nettverket, så vil du hele tiden måtte legge til linjer som zoidberg.test.evilcorp.com til skriptet zoidberg er navnet på en av testbenkene.
Men nå som vi forstår litt hvorfor dette behovet kan elimineres.
Hvis du, etter å ha hevet VPN, ser i /etc/hosts, kan du se denne linjen
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOLAGET
Og en ny linje ble lagt til resolv.conf. Kort sagt, vpn-slice bestemte på en eller annen måte hvor dns-serveren for vpn-en er plassert.
Nå må vi sørge for at for å finne ut IP-adressen til et domenenavn som slutter på evilcorp.com, går Linux til bedriftens DNS, og hvis noe annet er nødvendig, så til standard.
Jeg googlet en stund og fant ut at slik funksjonalitet er tilgjengelig i Ubuntu ut av esken. Dette betyr muligheten til å bruke den lokale DNS-serveren dnsmasq for å løse navn.
Det vil si at du kan sørge for at Linux alltid går til den lokale DNS-serveren for IP-adresser, som igjen, avhengig av domenenavnet, vil lete etter IP-en på den tilsvarende eksterne DNS-serveren.
For å administrere alt relatert til nettverk og nettverkstilkoblinger bruker Ubuntu NetworkManager, og det grafiske grensesnittet for å velge for eksempel Wi-Fi-tilkoblinger er bare en frontend til det.
Vi må klatre i konfigurasjonen.
- Opprett en fil i /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Vær oppmerksom på punktet foran evilcorp. Det signaliserer dnsmasq at alle underdomener til evilcorp.com bør søkes i bedriftens dns.
- Fortell NetworkManager å bruke dnsmasq for navneoppløsning
Network-manager-konfigurasjonen er plassert i /etc/NetworkManager/NetworkManager.conf Du må legge til der:
[main] dns=dnsmasq
- Start NetworkManager på nytt
service network-manager restartNå, etter å ha koblet til en VPN ved hjelp av openconnect og vpn-slice, vil ip-en bli bestemt normalt, selv om du ikke legger til symbolske adresser til argumentene til vpnslice.
Hvordan få tilgang til individuelle tjenester via VPN
Etter at jeg klarte å koble til VPN var jeg veldig fornøyd i to dager, og så viste det seg at hvis jeg kobler til VPN fra utenfor kontornettverket, så fungerer ikke mail. Symptomet er kjent, er det ikke?
Vår post ligger på mail.publicevilcorp.com, noe som betyr at den ikke faller inn under regelen i dnsmasq og e-postserveradressen søkes gjennom offentlig DNS.
Vel, kontoret bruker fortsatt DNS, som inneholder denne adressen. Det er det jeg tenkte. Faktisk, etter å ha lagt til linjen i dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
situasjonen har ikke endret seg i det hele tatt. ip forble den samme. Jeg måtte på jobb.
Og først senere, da jeg gikk dypere inn i situasjonen og forsto problemet litt, fortalte en smart person meg hvordan jeg skulle løse det. Det var nødvendig å koble til e-postserveren ikke bare slik, men via VPN
Jeg bruker vpn-slice for å gå gjennom VPN til adresser som starter med 192.168.430. Og e-postserveren har ikke bare en symbolsk adresse som ikke er et underdomene til evilcorp, den har heller ikke en IP-adresse som starter med 192.168.430. Og selvfølgelig lar han ingen fra det generelle nettverket komme til ham.
For at Linux skal gå gjennom VPN og til e-postserveren, må du legge den til i vpn-slice også. La oss si at avsenderens adresse er 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 Skript for å heve VPN med ett argument
Alt dette er selvfølgelig ikke veldig praktisk. Ja, du kan lagre teksten til en fil og kopiere og lime den inn i konsollen i stedet for å skrive den for hånd, men det er fortsatt ikke veldig hyggelig. For å gjøre prosessen enklere, kan du pakke kommandoen inn i et skript som vil bli plassert i PATH. Og da trenger du bare å skrive inn koden mottatt fra 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 Hvis du legger skriptet i connect~evilcorp~ kan du ganske enkelt skrive i konsollen
connect_evil_corp 567987Men nå må du fortsatt holde konsollen der openconnect kjører åpen av en eller annen grunn
Kjører openconnect i bakgrunnen
Heldigvis tok forfatterne av openconnect seg av oss og la til en spesiell nøkkel til programmet -bakgrunn, som får programmet til å fungere i bakgrunnen etter lansering. Hvis du kjører det slik, kan du lukke konsollen etter lansering
#!/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 Nå er det bare ikke klart hvor loggene går. Generelt trenger vi egentlig ikke logger, men du vet aldri. openconnect kan omdirigere dem til syslog, hvor de vil holdes trygge. du må legge til –syslog-bryteren til kommandoen
#!/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 Og så viser det seg at openconnect fungerer et sted i bakgrunnen og ikke plager noen, men det er ikke klart hvordan man stopper det. Det vil si at du selvfølgelig kan filtrere ps-utgangen ved å bruke grep og se etter en prosess hvis navn inneholder openconnect, men dette er på en eller annen måte kjedelig. Takk til forfatterne som også tenkte på dette. Openconnect har en nøkkel -pid-fil, som du kan instruere openconnect til å skrive prosessidentifikatoren til en fil.
#!/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-pidNå kan du alltid drepe en prosess med kommandoen
kill $(cat ~/vpn-pid)Hvis det ikke er noen prosess, vil kill forbanne, men vil ikke gi en feil. Hvis filen ikke er der, vil det heller ikke skje noe vondt, så du kan trygt drepe prosessen i den første linjen i skriptet.
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-pidNå kan du slå på datamaskinen, åpne konsollen og kjøre kommandoen, gi den koden fra Google Authenticator. Konsollen kan deretter spikres fast.
Uten VPN-slice. I stedet for et etterord
Det viste seg å være veldig vanskelig å forstå hvordan man kan leve uten VPN-slice. Jeg måtte lese og google mye. Heldigvis, etter å ha brukt så mye tid med et problem, ble tekniske manualer og til og med man openconnect lest som spennende romaner.
Som et resultat fant jeg ut at vpn-slice, som det opprinnelige skriptet, endrer rutingtabellen til separate nettverk.
Rutingtabell
For å si det enkelt er dette en tabell i den første kolonnen som inneholder hva adressen som Linux ønsker å gå gjennom skal begynne med, og i den andre kolonnen hvilken nettverksadapter som skal gå gjennom på denne adressen. Faktisk er det flere høyttalere, men dette endrer ikke essensen.
For å se rutetabellen må du kjøre ip-rutekommandoen
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 Her er hver linje ansvarlig for hvor du må gå for å sende en melding til en adresse. Den første er en beskrivelse av hvor adressen skal begynne. For å forstå hvordan du finner ut at 192.168.0.0/16 betyr at adressen skal starte med 192.168, må du google hva en IP-adressemaske er. Etter dev er det navnet på adapteren som meldingen skal sendes til.
For VPN laget Linux en virtuell adapter - tun0. Linjen sørger for at trafikk for alle adresser som starter med 192.168 går gjennom den
192.168.0.0/16 dev tun0 scope link Du kan også se på gjeldende status for rutingtabellen ved å bruke kommandoen rute -n (IP-adresser er smart anonymisert) Denne kommandoen produserer resultater i en annen form og er generelt utdatert, men dens utdata finnes ofte i håndbøker på Internett, og du må kunne lese den.
Hvor IP-adressen for en rute skal starte kan forstås fra kombinasjonen av Destinasjon og Genmask-kolonnene. De delene av IP-adressen som tilsvarer tallene 255 i Genmask er tatt i betraktning, men de der det er 0 er det ikke. Det vil si at kombinasjonen av destinasjon 192.168.0.0 og Genmask 255.255.255.0 betyr at hvis adressen starter med 192.168.0, vil forespørselen til den gå langs denne ruten. Og hvis destinasjon 192.168.0.0 men Genmask 255.255.0.0, vil forespørsler til adresser som starter med 192.168 gå langs denne ruten
For å finne ut hva vpn-slice faktisk gjør, bestemte jeg meg for å se på tilstandene til tabellene før og etter
Før du satte på VPN var det slik
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 wlp3s0Etter å ha ringt openconnect uten vpn-slice ble det slik
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 tun0Og etter å ha ringt openconnect i kombinasjon med vpn-slice som dette
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 tun0Det kan sees at hvis du ikke bruker vpn-slice, så skriver openconnect eksplisitt at alle adresser, bortsett fra de spesifikt angitt, må nås gjennom vpn.
Akkurat her:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Der, ved siden av, vises en annen sti umiddelbart, som må brukes hvis adressen som Linux prøver å passere gjennom ikke samsvarer med noen maske fra tabellen.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Det er allerede skrevet her at i dette tilfellet må du bruke en standard Wi-Fi-adapter.
Jeg tror at VPN-banen brukes fordi den er den første i rutetabellen.
Og teoretisk sett, hvis du fjerner denne standardbanen fra rutingtabellen, bør i forbindelse med dnsmasq openconnect sikre normal drift.
jeg prøvde
route del defaultOg alt fungerte.
Ruting forespørsler til en e-postserver uten vpn-slice
Men jeg har også en e-postserver med adressen 555.555.555.555, som også må nås via VPN. Ruten til den må også legges til manuelt.
ip route add 555.555.555.555 via dev tun0Og nå er alt bra. Så du kan klare deg uten vpn-slice, men du må vite godt hva du gjør. Jeg tenker nå på å legge til den siste linjen i det opprinnelige openconnect-skriptet fjerning av standardruten og legge til en rute for maileren etter å ha koblet til VPN-en, bare slik at det er færre bevegelige deler på sykkelen min.
Sannsynligvis vil dette etterordet være nok til at noen forstår hvordan man setter opp en VPN. Men mens jeg prøvde å forstå hva og hvordan jeg skulle gjøre, leste jeg ganske mange slike guider som fungerer for forfatteren, men som av en eller annen grunn ikke fungerer for meg, og jeg bestemte meg for å legge til alle bitene jeg fant her. Jeg ville blitt veldig glad for noe sånt.
Kilde: www.habr.com