Vill du anvÀnda Linux pÄ jobbet, men ditt företags VPN tillÄter dig inte? DÄ kan den hÀr artikeln hjÀlpa, Àven om detta inte Àr sÀkert. Jag skulle vilja varna dig i förvÀg att jag inte förstÄr problem med nÀtverksadministration sÄ bra, sÄ det Àr möjligt att jag gjorde allt fel. à andra sidan Àr det möjligt att jag kan skriva en guide pÄ ett sÄdant sÀtt att den blir begriplig för vanliga mÀnniskor, sÄ jag rÄder dig att prova den.
Artikeln innehÄller mycket onödig information, men utan denna kunskap hade jag inte kunnat lösa de problem som ovÀntat dök upp för mig med att sÀtta upp en VPN. Jag tror att alla som försöker anvÀnda den hÀr guiden kommer att fÄ problem som jag inte hade, och jag hoppas att denna extra information kommer att hjÀlpa till att lösa dessa problem pÄ egen hand.
De flesta av kommandona som anvÀnds i den hÀr guiden mÄste köras via sudo, som har tagits bort för korthetens skull. Kom ihÄg.
De flesta IP-adresser har blivit allvarligt förvirrade, sÄ om du ser en adress som 435.435.435.435 mÄste det finnas nÄgon normal IP dÀr, specifikt för ditt fall.
Jag har Ubuntu 18.04, men jag tror att med mindre Àndringar kan guiden appliceras pÄ andra distributioner. Men i denna text Linux == Ubuntu.
Cisco Connect
De som anvÀnder Windows eller MacOS kan ansluta till vÄrt företags VPN via Cisco Connect, som behöver ange gateway-adressen och, varje gÄng du ansluter, ange ett lösenord som bestÄr av en fast del och en kod som genereras av Google Authenticator.
NÀr det gÀller Linux kunde jag inte fÄ Cisco Connect att köra, men jag lyckades googla en rekommendation om att anvÀnda openconnect, gjord speciellt för att ersÀtta Cisco Connect.
Openconnect
I teorin har Ubuntu ett speciellt grafiskt grÀnssnitt för openconnect, men det fungerade inte för mig. Kanske Àr det till det bÀttre.
PÄ Ubuntu installeras openconnect frÄn pakethanteraren.
apt install openconnectDirekt efter installationen kan du försöka ansluta till ett VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com Àr adressen till en fiktiv VPN
poxvuibr - fiktivt anvÀndarnamn
openconnect kommer att be dig ange ett lösenord, som, lĂ„t mig pĂ„minna dig, bestĂ„r av en fast del och en kod frĂ„n Google Authenticator, och sedan försöker den ansluta till vpn. Om det fungerar, grattis, kan du sĂ€kert hoppa över mitten, vilket Ă€r mycket smĂ€rta, och gĂ„ vidare till punkten om openconnect som körs i bakgrunden. Om det inte fungerar kan du fortsĂ€tta. Ăven om det fungerade nĂ€r du ansluter, till exempel frĂ„n en gĂ€st-Wi-Fi pĂ„ jobbet, kan det vara för tidigt att glĂ€djas; du bör försöka upprepa proceduren hemifrĂ„n.
Certifikat
Det finns en stor sannolikhet att ingenting kommer att starta, och openconnect-utgÄngen kommer att se ut ungefÀr sÄ hÀr:
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 progressà ena sidan Àr detta obehagligt, eftersom det inte fanns nÄgon koppling till VPN, men Ä andra sidan Àr det i princip klart hur man ÄtgÀrdar detta problem.
HÀr skickade servern oss ett certifikat, genom vilket vi kan faststÀlla att anslutningen görs till servern för vÄrt inhemska företag, och inte till en ond bedragare, och detta certifikat Àr okÀnt för systemet. Och dÀrför kan hon inte kontrollera om servern Àr riktig eller inte. Och sÄ, utifall att det slutar fungera.
För att openconnect ska ansluta till servern mĂ„ste du uttryckligen tala om för den vilket certifikat som ska komma frĂ„n VPN-servern med hjĂ€lp av âservercert-nyckeln
Och du kan ta reda pÄ vilket certifikat servern skickade oss direkt frÄn vad openconnect skrev ut. HÀr Àr frÄn detta stycke:
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 detta kommando kan du försöka ansluta igen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comKanske fungerar det nu, dÄ kan du gÄ vidare till slutet. Men personligen visade Ubuntu mig ett fikon i denna form
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 kommer att lösas, men du kommer inte att kunna gÄ dit. Adresser som jira.evilcorp.com löses inte alls.
Vad som hÀnde hÀr Àr inte klart för mig. Men experiment visar att om du lÀgger till raden till /etc/resolv.conf
nameserver 192.168.430.534dÄ kommer adresserna inuti VPN att börja lösas magiskt och du kan gÄ igenom dem, det vill sÀga vad DNS letar efter för att lösa adresser ser specifikt ut i /etc/resolv.conf, och inte nÄgon annanstans.
Du kan verifiera att det finns en anslutning till VPN och det fungerar utan att göra nÄgra Àndringar i /etc/resolv.conf; för att göra detta anger du bara i webblÀsaren inte det symboliska namnet pÄ resursen frÄn VPN, utan dess IP-adress
Som ett resultat finns det tvÄ problem
- NĂ€r du ansluter till ett VPN plockas inte dess dns upp
- all trafik gÄr via VPN, som inte tillÄter Ätkomst till Internet
Jag ska berÀtta vad du ska göra nu, men först lite automatisering.
Automatisk inmatning av den fasta delen av lösenordet
Vid det hÀr laget har du med största sannolikhet redan angett ditt lösenord minst fem gÄnger och denna procedur har redan tröttnat ut dig. För det första för att lösenordet Àr lÄngt, och för det andra för att nÀr du gÄr in mÄste du passa inom en bestÀmd tidsperiod
Den slutliga lösningen pÄ problemet fanns inte med i artikeln, men du kan se till att den fasta delen av lösenordet inte behöver anges mÄnga gÄnger.
LÄt oss anta att den fasta delen av lösenordet Àr fixedPassword och att delen frÄn Google Authenticator Àr 567 987. Hela lösenordet kan skickas till openconnect via standardinmatning med argumentet --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNu kan du stÀndigt ÄtergÄ till det senast angivna kommandot och endast Àndra en del av Google Authenticator dÀr.
Ett företags VPN tillÄter dig inte att surfa pÄ Internet.
I allmÀnhet Àr det inte sÀrskilt obekvÀmt nÀr du mÄste anvÀnda en separat dator för att gÄ till Habr. OförmÄgan att kopiera och klistra frÄn stackoverfow kan generellt förlama arbetet, sÄ nÄgot mÄste göras.
Vi mÄste pÄ nÄgot sÀtt organisera det sÄ att nÀr du behöver komma Ät en resurs frÄn det interna nÀtverket gÄr Linux till VPN och nÀr du behöver gÄ till Habr gÄr det till Internet.
openconnect, efter att ha startat och upprÀttat en anslutning med vpn, kör ett speciellt skript, som finns i /usr/share/vpnc-scripts/vpnc-script. Vissa variabler skickas till skriptet som indata, och det konfigurerar VPN. TyvÀrr kunde jag inte ta reda pÄ hur jag skulle dela upp trafikflöden mellan ett företags VPN och resten av Internet med hjÀlp av ett inbyggt skript.
Uppenbarligen har vpn-slice-verktyget utvecklats speciellt för mÀnniskor som mig, vilket gör att du kan skicka trafik genom tvÄ kanaler utan att dansa med en tamburin. Tja, det vill sÀga, du mÄste dansa, men du behöver inte vara en shaman.
Trafikseparering med vpn-slice
Först mÄste du installera vpn-slice, du mÄste ta reda pÄ detta sjÀlv. Om det finns frÄgor i kommentarerna kommer jag att skriva ett separat inlÀgg om detta. Men det hÀr Àr ett vanligt Python-program, sÄ det borde inte vara nÄgra svÄrigheter. Jag installerade med virtualenv.
Och sedan mÄste verktyget appliceras med -script-vÀxeln, vilket indikerar att openconnect att istÀllet för standardskriptet mÄste du anvÀnda 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 skickas en strÀng med ett kommando som mÄste anropas istÀllet för skriptet. ./bin/vpn-slice - sökvÀg till den körbara filen vpn-slice 192.168.430.0/24 - mask av adresser att gÄ till i vpn. HÀr menar vi att om adressen börjar med 192.168.430 sÄ mÄste resursen med denna adress sökas i VPN
Situationen borde nu vara nÀstan normal. NÀstan. Nu kan du gÄ till Habr och du kan gÄ till den företagsinterna resursen via ip, men du kan inte gÄ till den företagsinterna resursen med symboliskt namn. Om du anger en matchning mellan det symboliska namnet och adressen i vÀrdar bör allt fungera. Och jobba tills ip:n Àndras. Linux kan nu komma Ät Internet eller intranÀtet, beroende pÄ IP. Men icke-företags-DNS anvÀnds fortfarande för att faststÀlla adressen.
Problemet kan ocksÄ visa sig i denna form - pÄ jobbet Àr allt bra, men hemma kan du bara komma Ät interna företagsresurser via IP. Detta beror pÄ att nÀr du Àr ansluten till företagets Wi-Fi anvÀnds Àven företagets DNS, och symboliska adresser frÄn VPN löses i den, trots att det fortfarande Àr omöjligt att gÄ till en sÄdan adress utan att anvÀnda ett VPN.
Automatisk modifiering av hosts-filen
Om vpn-slice tillfrÄgas artigt kan den, efter att ha höjt VPN, gÄ till dess DNS, dÀr hitta IP-adresserna för de nödvÀndiga resurserna med deras symboliska namn och ange dem i vÀrdar. Efter att ha stÀngt av VPN kommer dessa adresser att tas bort frÄn vÀrdarna. För att göra detta mÄste du skicka symboliska namn till vpn-slice som argument. SÄ hÀr.
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 Nu ska allt fungera bÄde pÄ kontoret och pÄ stranden.
Sök efter adresserna till alla underdomÀner i DNS som ges av VPN
Om det finns fÄ adresser inom nÀtverket fungerar metoden att automatiskt modifiera vÀrdfilen ganska bra. Men om det finns mycket resurser pÄ nÀtverket sÄ kommer du stÀndigt behöva lÀgga till rader som zoidberg.test.evilcorp.com till skriptet zoidberg Àr namnet pÄ en av testbÀnkarna.
Men nu nÀr vi förstÄr lite varför detta behov kan elimineras.
Om du, efter att ha höjt VPN, tittar i /etc/hosts, kan du se den hÀr raden
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Och en ny rad lades till i resolv.conf. Kort sagt, vpn-slice bestÀmde pÄ nÄgot sÀtt var dns-servern för vpn:n finns.
Nu mÄste vi se till att för att ta reda pÄ IP-adressen för ett domÀnnamn som slutar pÄ evilcorp.com, gÄr Linux till företagets DNS, och om nÄgot annat behövs, dÄ till standard.
Jag googlade ganska lÀnge och fann att sÄdan funktionalitet Àr tillgÀnglig i Ubuntu direkt. Detta innebÀr möjligheten att anvÀnda den lokala DNS-servern dnsmasq för att lösa namn.
Det vill sÀga att du kan se till att Linux alltid gÄr till den lokala DNS-servern för IP-adresser, som i sin tur, beroende pÄ domÀnnamnet, kommer att leta efter IP:n pÄ motsvarande externa DNS-server.
För att hantera allt som har med nÀtverk och nÀtverksanslutningar att göra anvÀnder Ubuntu NetworkManager, och det grafiska grÀnssnittet för att vÀlja till exempel Wi-Fi-anslutningar Àr bara en frontend till det.
Vi kommer att behöva klÀttra i dess konfiguration.
- Skapa en fil i /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Var uppmÀrksam pÄ punkten framför evilcorp. Det signalerar dnsmasq att alla underdomÀner av evilcorp.com ska sökas i företagets dns.
- Be NetworkManager att anvÀnda dnsmasq för namnupplösning
NÀtverkshanterarens konfiguration finns i /etc/NetworkManager/NetworkManager.conf Du mÄste lÀgga till dÀr:
[main] dns=dnsmasq
- Starta om NetworkManager
service network-manager restartNu, efter att ha anslutit till ett VPN med openconnect och vpn-slice, kommer ip:n att faststÀllas normalt, Àven om du inte lÀgger till symboliska adresser till argumenten till vpnslice.
Hur man kommer Ät enskilda tjÀnster via VPN
Efter att jag lyckats koppla upp mig till VPN var jag vÀldigt glad i tvÄ dagar, och sedan visade det sig att om jag ansluter till VPN frÄn utanför kontorsnÀtverket sÄ fungerar inte mail. Symptomet Àr vÀlbekant?
VÄr e-post finns pÄ mail.publicevilcorp.com, vilket innebÀr att den inte faller under regeln i dnsmasq och e-postserveradressen söks genom offentlig DNS.
Tja, kontoret anvÀnder fortfarande DNS, som innehÄller den hÀr adressen. Det var det jag trodde. Faktum Àr att efter att ha lagt till raden i dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
situationen har inte förÀndrats alls. ip förblev densamma. Jag var tvungen att gÄ till jobbet.
Och först senare, nÀr jag grÀvde djupare in i situationen och förstod problemet lite, berÀttade en smart person för mig hur jag skulle lösa det. Det var nödvÀndigt att ansluta till e-postservern inte bara sÄ, utan via VPN
Jag anvÀnder vpn-slice för att gÄ igenom VPN till adresser som börjar med 192.168.430. Och e-postservern har inte bara en symbolisk adress som inte Àr en underdomÀn till evilcorp, den har inte heller en IP-adress som börjar med 192.168.430. Och naturligtvis tillÄter han inte nÄgon frÄn det allmÀnna nÀtverket att komma till honom.
För att Linux ska kunna gÄ via VPN och till e-postservern mÄste du lÀgga till den i vpn-slice ocksÄ. LÄt oss sÀga att avsÀndarens adress Àr 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 för att höja VPN med ett argument
Allt detta Àr naturligtvis inte sÀrskilt bekvÀmt. Ja, du kan spara texten till en fil och kopiera och klistra in den i konsolen istÀllet för att skriva den för hand, men det Àr fortfarande inte sÀrskilt trevligt. För att göra processen enklare kan du slÄ in kommandot i ett skript som kommer att finnas i PATH. Och dÄ behöver du bara ange koden som du fÄtt frÄn 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 Om du lÀgger skriptet i connect~evilcorp~ kan du helt enkelt skriva i konsolen
connect_evil_corp 567987Men nu mÄste du fortfarande hÄlla konsolen dÀr openconnect körs öppen av nÄgon anledning
Kör openconnect i bakgrunden
Lyckligtvis tog författarna av openconnect hand om oss och la till en speciell nyckel till programmet -bakgrund, vilket gör att programmet fungerar i bakgrunden efter lanseringen. Om du kör det sÄ hÀr kan du stÀnga konsolen efter start
#!/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 Nu Ă€r det bara oklart var loggarna tar vĂ€gen. I allmĂ€nhet behöver vi egentligen inga loggar, men man vet aldrig. openconnect kan omdirigera dem till syslog, dĂ€r de kommer att förvaras sĂ€kra. du mĂ„ste lĂ€gga till âsyslog-vĂ€xeln till kommandot
#!/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 Och sÄ visar det sig att openconnect fungerar nÄgonstans i bakgrunden och inte stör nÄgon, men det Àr inte klart hur man stoppar det. Det vill sÀga, du kan naturligtvis filtrera ps-utgÄngen med grep och leta efter en process vars namn innehÄller openconnect, men detta Àr pÄ nÄgot sÀtt trÄkigt. Tack till författarna som ocksÄ tÀnkt pÄ detta. Openconnect har en nyckel -pid-fil, med vilken du kan instruera openconnect att skriva dess processidentifierare till 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-pidNu kan du alltid döda en process med kommandot
kill $(cat ~/vpn-pid)Om det inte finns nÄgon process kommer kill att förbanna, men kommer inte att ge ett fel. Om filen inte finns dÀr kommer inget dÄligt att hÀnda heller, sÄ du kan sÀkert döda processen i den första raden 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-pidNu kan du slÄ pÄ din dator, öppna konsolen och köra kommandot och skicka koden frÄn Google Authenticator. Konsolen kan sedan spikas fast.
Utan VPN-slice. IstÀllet för ett efterord
Det visade sig vara vÀldigt svÄrt att förstÄ hur man lever utan VPN-slice. Jag var tvungen att lÀsa och googla mycket. Lyckligtvis, efter att ha tillbringat sÄ mycket tid med ett problem, lÀste tekniska manualer och till och med man openconnect som spÀnnande romaner.
Som ett resultat fick jag reda pÄ att vpn-slice, liksom det ursprungliga skriptet, modifierar routingtabellen till separata nÀtverk.
Routningstabell
Enkelt uttryckt Àr detta en tabell i den första kolumnen som innehÄller vad adressen som Linux vill gÄ igenom ska börja med, och i den andra kolumnen vilken nÀtverksadapter som ska gÄ igenom pÄ denna adress. Faktum Àr att det finns fler talare, men det förÀndrar inte essensen.
För att se routingtabellen mÄste du köra kommandot 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 HÀr ansvarar varje rad för vart du behöver gÄ för att skicka ett meddelande till nÄgon adress. Den första Àr en beskrivning av var adressen ska börja. För att förstÄ hur man avgör att 192.168.0.0/16 betyder att adressen ska börja med 192.168 mÄste du googla vad en IP-adressmask Àr. Efter dev finns namnet pÄ adaptern som meddelandet ska skickas till.
För VPN gjorde Linux en virtuell adapter - tun0. Linjen ser till att trafik för alla adresser som börjar med 192.168 gÄr genom den
192.168.0.0/16 dev tun0 scope link Du kan ocksÄ titta pÄ det aktuella tillstÄndet för routingtabellen med kommandot rutt -n (IP-adresser Àr smart anonymiserade) Det hÀr kommandot ger resultat i en annan form och Àr i allmÀnhet förÄldrat, men dess utdata finns ofta i manualer pÄ Internet och du mÄste kunna lÀsa den.
Var IP-adressen för en rutt ska börja kan förstÄs frÄn kombinationen av kolumnerna Destination och Genmask. De delar av IP-adressen som motsvarar siffrorna 255 i Genmask beaktas, men de dÀr det finns 0 gör det inte. Det vill sÀga, kombinationen av Destination 192.168.0.0 och Genmask 255.255.255.0 betyder att om adressen börjar med 192.168.0, sÄ kommer förfrÄgan till den att gÄ lÀngs denna vÀg. Och om Destination 192.168.0.0 men Genmask 255.255.0.0, kommer förfrÄgningar till adresser som börjar med 192.168 att gÄ lÀngs denna vÀg
För att ta reda pÄ vad vpn-slice faktiskt gör bestÀmde jag mig för att titta pÄ tabellernas tillstÄnd före och efter
Innan du slog pÄ VPN var det sÄ hÀr
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 wlp3s0Efter att ha anropat openconnect utan vpn-slice blev det sÄ hÀr
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 tun0Och efter att ha anropat openconnect i kombination med vpn-slice sÄ hÀr
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 ses att om du inte anvÀnder vpn-slice, sÄ skriver openconnect uttryckligen att alla adresser, förutom de specifikt angivna, mÄste nÄs via vpn.
Precis hÀr:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0DÀr bredvid indikeras omedelbart en annan sökvÀg, som mÄste anvÀndas om adressen som Linux försöker passera inte matchar nÄgon mask frÄn tabellen.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Det har redan skrivits hÀr att du i det hÀr fallet mÄste anvÀnda en vanlig Wi-Fi-adapter.
Jag tror att VPN-sökvÀgen anvÀnds eftersom den Àr den första i routingtabellen.
Och teoretiskt sett, om du tar bort den hÀr standardsökvÀgen frÄn routingtabellen, bör i samband med dnsmasq openconnect sÀkerstÀlla normal drift.
jag försökte
route del defaultOch allt fungerade.
Routing förfrÄgningar till en e-postserver utan vpn-slice
Men jag har Àven en mailserver med adressen 555.555.555.555, som ocksÄ mÄste nÄs via VPN. Rutten till den mÄste ocksÄ lÀggas till manuellt.
ip route add 555.555.555.555 via dev tun0Och nu Àr allt bra. SÄ du kan klara dig utan vpn-slice, men du mÄste veta vÀl vad du gör. Jag funderar nu pÄ att lÀgga till den sista raden i det inbyggda openconnect-skriptet att ta bort standardrutten och lÀgga till en rutt för mailern efter att ha anslutit till vpn, bara sÄ att det finns fÀrre rörliga delar i min cykel.
Förmodligen skulle detta efterord vara tillrÀckligt för att nÄgon ska förstÄ hur man stÀller in en VPN. Men medan jag försökte förstÄ vad och hur jag skulle göra, lÀste jag ganska mÄnga sÄdana guider som fungerar för författaren, men som av nÄgon anledning inte fungerar för mig, och jag bestÀmde mig för att lÀgga till alla bitar som jag hittade hÀr. Jag skulle bli vÀldigt glad över nÄgot sÄdant.
KĂ€lla: will.com