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 det inte Àr sÀkert. Jag vill 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 som Àr begriplig för vanliga mÀnniskor, sÄ jag föreslÄr att du provar.
Det finns mycket onödig information i artikeln, men utan denna kunskap hade jag inte kunnat lösa de problem som jag ovÀntat fick 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 hjÀlper dem 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. Komma ihÄg.
De flesta IP-adresser har varit kraftigt förvirrade, sÄ om du ser en adress som 435.435.435.435 bör det finnas en normal IP dÀr, specifikt för ditt fall.
Jag har Ubuntu 18.04 april, men jag tror att guiden skulle kunna tillÀmpas pÄ andra distributioner med mindre justeringar. Men i den hÀr texten, Linux == Ubuntu.
Cisco Connect
De som sitter pÄ Windows eller MacOS kan ansluta till vÄrt företags-VPN via Cisco Connect, vilket krÀver att man anger gateway-adressen och anger ett lösenord som bestÄr av en fast del och en kod som genereras av Google Authenticator varje gÄng man ansluter.
NÀr det gÀller Linux gick det inte att starta Cisco Connect, men det gick att googla pÄ en rekommendation om att anvÀnda openconnect, gjord specifikt 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Àsta.
I Ubuntu installeras openconnect frÄn pakethanteraren.
apt install openconnectDu kan försöka ansluta till VPN direkt efter installationen
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 fungerade, grattis, kan du sĂ€kert hoppa över mittdelen, vilket Ă€r mycket smĂ€rtsamt, och gĂ„ vidare till punkten om att openconnect arbetar i bakgrunden. Om det inte fungerar kan du fortsĂ€tta. Ăven om det fungerade nĂ€r man ansluter till exempel frĂ„n en gĂ€st-Wi-Fi pĂ„ jobbet, sĂ„ 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 VPN-anslutningen inte intrÀffade, men Ä andra sidan Àr det i princip tydligt hur man ÄtgÀrdar detta problem.
HÀr skickade servern oss ett certifikat, genom vilket vi kan faststÀlla att anslutningen Àr gjord till servern för det inhemska företaget, 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 dÀrför, för sÀkerhets skull, slutar den att fungera.
För att openconnect ska kunna ansluta till servern mĂ„ste du uttryckligen tala om för den vilket certifikat som ska komma frĂ„n VPN-servern med nyckeln âservercert
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 progressDu kan försöka ansluta igen med det hÀr kommandot
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comKanske fungerar det nu, sen kan vi gÄ vidare till slutet. Men personligen visade Ubuntu mig fingret 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 komma Ät det. Adresser som jira.evilcorp.com löses inte alls.
Jag förstÄr inte vad som hÀnde hÀr. Men experiment visar att om du lÀgger till en rad till /etc/resolv.conf
nameserver 192.168.430.534dÄ kommer adresserna inuti VPN magiskt att börja lösas och du kan navigera genom dem, det vill sÀga det som letar efter vilken DNS som ska lösa adresserna ser specifikt i /etc/resolv.conf, och inte nÄgon annanstans.
Du kan verifiera att VPN-anslutningen finns dÀr och att den fungerar utan att redigera /etc/resolv.conf. För att göra detta anger du helt enkelt inte det symboliska namnet pÄ resursen frÄn VPN i webblÀsaren utan dess IP-adress.
Som ett resultat finns det tvÄ problem.
- nÀr du ansluter till VPN plockas inte dess DNS upp
- all trafik gÄr via en vpn, som inte tillÄter dig att gÄ online
Jag ska berÀtta vad du ska göra nu, men först lite automatisering.
Automatisk inmatning av en fast del av lösenordet
Vid det hÀr laget har du förmodligen angett ditt lösenord minst fem gÄnger och denna procedur har redan tröttat ut dig en hel del. För det första för att lösenordet Àr lÄngt, och för det andra för att nÀr du anger det mÄste du passa in i en fast tidsperiod.
Den slutliga lösningen pÄ problemet fanns inte med i artikeln, men det gÄr att göra sÄ att den fasta delen av lösenordet inte behöver anges mÄnga gÄnger.
LÄt oss sÀga att den fasta delen av lösenordet Àr fixedPassword och delen frÄn Google Authenticator Àr 567 987. Hela openconnect-lösenordet kan skickas 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 bara Àndra den del av Google Authenticator dÀr.
Företags-VPN tillÄter dig inte att komma Ät Internet.
Det Àr inte alls sÀrskilt bekvÀmt nÀr man mÄste anvÀnda en separat dator för att Äka till Habr. OförmÄgan att kopiera och klistra frÄn stackoverfow kan helt förlama arbetet, sÄ nÄgot mÄste göras.
Vi mÄste pÄ nÄgot sÀtt organisera det sÄ att nÀr vi behöver komma Ät en resurs frÄn det interna nÀtverket gÄr Linux till VPN och nÀr vi behöver komma Ät 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 vid ingÄngen och det konfigurerar VPN. TyvÀrr kunde jag inte ta reda pÄ hur jag skulle dela upp trafikflöden mellan företagets vpn och resten av internet med hjÀlp av det inbyggda skriptet.
Uppenbarligen har VPN-Slice-verktyget utvecklats speciellt för mÀnniskor som mig, vilket gör att du kan dirigera 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.
Dela upp trafik med vpn-slice
Först mÄste du installera vpn-slice, du mÄste ta reda pÄ detta sjÀlv. Om det finns nÄgra frÄgor i kommentarerna kommer jag att skriva ett separat inlÀgg om detta. Men det hÀr Àr ett vanligt pythonprogram, sÄ det borde inte vara nÄgra svÄrigheter. Jag installerade det med virtualenv.
Och sedan mÄste verktyget appliceras med nyckeln -script, vilket indikerar openconnect att istÀllet för standardskriptet mÄste vpn-slice anvÀndas
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script skickar en strĂ€ng med ett kommando som ska 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 betyder det att om adressen börjar med 192.168.430 sĂ„ mĂ„ste resursen med denna adress sökas in i vpn:n
Situationen borde nu vara nÀstan normal. NÀstan. Nu kan du gÄ till Habr och du kan gÄ till den interna företagsresursen via IP, men du kan inte gÄ till den interna företagsresursen med symboliskt namn. Om du registrerar överensstÀmmelsen mellan det symboliska namnet och adressen i vÀrdar borde allt fungera. Och jobba tills IP:n Àndras. Linux kan nu komma Ät Internet eller företagets intranÀt beroende pÄ IP. Men icke-företags-DNS anvÀnds fortfarande för att faststÀlla adressen.
Problemet kan ocksÄ yttra sig pÄ detta sÀtt: allt Àr bra pÄ jobbet, men hemma kan du bara komma Ät företagets resurser 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 komma Ät en sÄdan adress utan att anvÀnda ett VPN.
Automatisk modifiering av hosts-filen
Om du frÄgar vpn-slice artigt kan den, efter att ha höjt VPN, gÄ till dess DNS, hitta IP-adresserna för de nödvÀndiga resurserna dÀr med deras symboliska namn och ange dem i vÀrdar. Efter att ha inaktiverat 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 adresser till alla underdomÀner i DNS, som gavs av VPN
Om det finns fÄ adresser inom nÀtverket Àr tillvÀgagÄngssÀttet med automatisk modifiering av vÀrdfilen ganska fungerande. 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 vad som Àr vad kan detta behov elimineras.
Om du tittar i /etc/hosts efter att du har höjt VPN, kan du se följande rad
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 finns.
Nu mÄste vi göra det sÄ 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 ett bra tag och fann att den hÀr funktionen À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 det gÄr att göra sÄ att Linux alltid gÄr till en lokal DNS-server för IP-adresser, som i sin tur, beroende pÄ domÀnnamn, kommer att leta efter IP:n pÄ motsvarande externa DNS-server.
Ubuntu anvÀnder NetworkManager för att hantera allt som har med nÀtverk och nÀtverksanslutningar att göra, och det grafiska grÀnssnittet för att vÀlja till exempel en Wi-Fi-anslutning Àr bara en frontend till den.
Vi mÄste experimentera med dess konfiguration.
- Skapa fil i /etc/NetworkManager/dnsmasq.d/evilcorp
adress=/.evilcorp.com/192.168.430.534
LÀgg mÀrke till pricken före evilcorp. Det signalerar dnsmasq att alla underdomÀner av evilcorp.com bör letas efter 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:
[Huvud]
dns=dnsmasq
- Starta om NetworkManager
service network-manager restartNu, efter att ha anslutit till VPN med kombinationen 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 nöjd i tvÄ dagar, och sedan visade det sig att om man ansluter till VPN frÄn utanför kontorsnÀtverket sÄ fungerar inte mailen. Symptomet lÄter bekant, eller hur?
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 via offentlig DNS.
Tja, pÄ kontoret anvÀnder de fortfarande DNS, som innehÄller den hÀr adressen. Det var vad 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 senare, nÀr jag grÀvde djupare 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 ett VPN
Jag anvÀnder vpn-slice för att gÄ igenom VPN till adresser som börjar med 192.168.430. Och inte nog med att e-postserverns symboliska adress inte utgör en underdomÀn till evilcorp, dess IP-adress börjar inte heller med 192.168.430. Och naturligtvis slÀpper han inte in nÄgon frÄn det allmÀnna nÀtverket i sitt omrÄde.
För att Linux ska gÄ via VPN och till e-postservern mÄste du lÀgga till den i vpn-delen. 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~ sÄ kan du bara skriva i konsolen
connect_evil_corp 567987Men nu mÄste jag 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. Vi behöver egentligen inga loggar, men man vet aldrig. openconnect kan vidarebefordra dem till syslog, dĂ€r de kommer att lagras sĂ€kert och sĂ€kert. du mĂ„ste lĂ€gga till nyckeln âsyslog 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 det Àr pÄ nÄgot sÀtt trÄkigt. Tack till författarna som ocksÄ tÀnkt pÄ detta. openconnect har en --pid-file-vÀxel som kan anvÀndas för att instruera openconnect att skriva sitt process-ID 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 processen med ett kommando
kill $(cat ~/vpn-pid)Om det inte finns nÄgon process kommer kill att klaga, men kommer inte att ge ett fel. Om filen inte finns kommer inget hemskt 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
Att komma pÄ hur man kan leva utan en vpn-slice visade sig vara vÀldigt svÄrt. Jag var tvungen att lÀsa och googla mycket. Lyckligtvis, efter att ha tillbringat sÄ mycket tid med problemet, lÀste tekniska manualer och till och med man openconnect som gripande romaner.
Till slut fick jag reda pÄ att vpn-slice, liksom det ursprungliga skriptet, modifierar routingtabellen till separata nÀtverk.
Routningstabell
Detta Àr, för att uttrycka det enkelt, en tabell vars första kolumn innehÄller vad adressen som Linux vill gÄ igenom ska börja med, och den andra kolumnen innehÄller 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 en viss adress. Den första Àr en beskrivning av vad adressen ska börja med. För att förstÄ hur man avgör att 192.168.0.0/16 betyder att adressen mÄste börja med 192.168 mÄste du googla vad en IP-adressmask Àr. Efter dev Àr namnet pÄ adaptern som meddelandet ska skickas till.
För VPN gjorde Linux en virtuell adapter - tun0. Linjen ansvarar för att trafiken för alla adresser som börjar med 192.168 gÄr igenom den.
192.168.0.0/16 dev tun0 scope link Du kan ocksÄ se det aktuella tillstÄndet för routingtabellen med kommandot rutt -n (IP-adresser Àr skickligt 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.
Vad IP-adressen för rutten ska börja med 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 Àr 192.168.0.0 men Genmask Àr 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 förstÄ 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 Àr klart att om du inte anvÀnder vpn-slice, sÄ skriver openconnect tydligt att alla adresser, förutom de specifikt angivna, mÄste nÄs via vpn.
HÀr Àr den:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Det finns en annan sökvÀg indikerad precis bredvid den som bör anvÀndas om adressen som Linux försöker gÄ till inte matchar nÄgon av maskerna i tabellen.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Det Àr redan skrivet hÀr att du i det hÀr fallet mÄste gÄ igenom en vanlig Wi-Fi-adapter.
Jag antar 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Ä det Àr möjligt att klara sig utan en VPN-slice, men du mÄste veta 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 avsÀndaren 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
