Vill du anvÀnda Linux pÄ jobbet, men företags-VPN:et tillÄter det inte? DÄ kan denna artikel hjÀlpa, Àven om det inte Àr sÀkert. Jag vill förvarna att jag har dÄlig förstÄelse för nÀtverksadministration, sÄ det Àr möjligt att jag har gjort allt fel. à andra sidan kan jag kanske skriva en guide som Àr förstÄelig för vanliga mÀnniskor, sÄ jag rekommenderar att du prövar.
Artikeln innehÄller mycket överflödig information, men utan dessa kunskaper skulle jag inte ha kunnat lösa de problem som plötsligt dök upp med VPN-instÀllningarna. Jag tror att alla som försöker anvÀnda denna guide kommer att stöta pÄ problem som jag inte hade, och jag hoppas att denna överflödiga information hjÀlper dem att lösa problemen sjÀlva.
De flesta kommandon som anvÀnds i guiden mÄste utföras via sudo, som förkortning har tagits bort. TÀnk pÄ det.
De flesta IP-adresser har utsatts för kraftig obfuskerings, sĂ„ om du ser en adress som 435.435.435.435 â dĂ€r borde det finnas en normal IP som Ă€r specifik för ditt fall.
Jag har Ubuntu 18.04, men jag tror att guiden kan tillÀmpas pÄ andra distributioner med smÄ justeringar. Men i denna text betyder Linux == Ubuntu.
Cisco Connect
De som anvÀnder Windows eller MacOS kan ansluta till vÄrt företags-VPN via Cisco Connect, dÀr man mÄste ange gateway-adressen och vid varje anslutning 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 fungera, men jag lyckades hitta en rekommendation att anvÀnda openconnect, som Àr avsedd att ersÀtta Cisco Connect.
Openconnect
Teoretiskt har Ubuntu ett speciellt grafiskt grÀnssnitt för openconnect, men det fungerade inte för mig. Kanske Àr det till det bÀttre.
I Ubuntu installeras openconnect frÄn paketförvaltaren.
apt install openconnectStrax efter installationen kan du prova att ansluta till VPN.
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com Àr adressen till en pÄhittad VPN.
poxvuibr â ett pĂ„hittat anvĂ€ndarnamn
openconnect kommer att be om att ange ett lösenord, som jag pÄminner om bestÄr av en fast del och en kod frÄn Google Authenticator, och sedan försöker det ansluta till vpn. Om det lyckas, grattis, du kan smidigt hoppa över mitten dÀr det Àr mycket besvÀr och gÄ vidare till avsnittet om hur openconnect fungerar i bakgrunden. Om det inte fungerade kan du fortsÀtta. Men om det fungerade vid anslutning till exempelvis gÀstwifi pÄ jobbet, kan det vara för tidigt att fira; du bör försöka upprepa proceduren hemifrÄn.
Certifikat
Det Àr högst sannolikt att ingenting kommer att starta, och output frÄn openconnect kommer att se ut pÄ följande sÀtt:
POST https://vpn.evilcorp.com/
Ansluten till 777.777.777.777:443
SSL-förhandling med vpn.evilcorp.com
Servercertifikat verifiering misslyckades: signerare hittades inte
Certifikatet frÄn VPN-servern "vpn.evilcorp.com" misslyckades med verifieringen.
Orsak: signerare hittades inte
För att lita pÄ denna server i framtiden, kanske lÀgg till detta i din kommandorad:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Ange 'yes' för att acceptera, 'no' för att avbryta; allt annat för att visa: fgets (stdin): Ă
tgÀrden pÄgÄr nuà ena sidan Àr det trÄkigt eftersom VPN-anslutningen inte lyckades, men Ä andra sidan Àr det tydligt hur man kan ÄtgÀrda detta problem.
HÀr har servern skickat oss ett certifikat som gör det möjligt att avgöra att anslutningen faktiskt sker till servern frÄn den egna företaget, och inte till en ond bedragare; men systemet kÀnner inte igen detta certifikat. DÀrför kan det inte verifiera om servern Àr Àkta eller ej. Och av den anledningen slutar det att fungera som en sÀkerhetsÄtgÀrd.
För att openconnect ska kunna ansluta till servern mĂ„ste vi tydligt ange vilket certifikat som ska tas emot frĂ„n VPN-servern med hjĂ€lp av nyckeln âservercert.
Och för att ta reda pÄ vilket certifikat servern skickade till oss kan vi se direkt i den output som openconnect gav. Den hÀr delen:
För att lita pÄ denna server i framtiden kan du kanske lÀgga till detta i din kommandorad:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Ange 'yes' för att acceptera, 'no' för att avbryta; allt annat för att visa: fgets (stdin): Ă
tgÀrden pÄgÄr nuMed följande 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 en gest av ogillande i denna form.
POST https://vpn.evilcorp.com/
Ansluten till 777.777.777.777:443
SSL-förhandling med vpn.evilcorp.com
Verifiering av servercertifikat misslyckades: signatur hittades inte
Ansluten till HTTPS pÄ vpn.evilcorp.com
XML POST aktiverad
VÀnligen ange ditt anvÀndarnamn och lösenord.
POST https://vpn.evilcorp.com/
Fick CONNECT-svar: HTTP/1.1 200 OK
CSTP ansluten. DPD 300, Keepalive 30
Setup av DTLS misslyckades; anvÀnder istÀllet SSL
Ansluten som 192.168.333.222, anvÀnder SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK svarar: Fil finns
/etc/resolvconf/update.d/libc: Varning: /etc/resolv.conf Àr inte en symbolisk lÀnk till /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 kunna lösas, men det gÄr inte att komma Ät. Adresser som jira.evilcorp.com löses helt enkelt inte.
Vad som hÀnde hÀr Àr oklart för mig. Men experimentet visar att om man lÀgger till raden i /etc/resolv.conf
nameserver 192.168.430.534sÄ kommer adresser inom VPN att börja lösas magiskt, och man kommer att kunna gÄ dit, vilket innebÀr att det som söker efter vilket DNS som ska anvÀndas för att lösa adresser, tittar just i /etc/resolv.conf, och inte nÄgon annanstans.
Att anslutningen till VPN fungerar kan man Àven se utan att göra Àndringar i /etc/resolv.conf, det rÀcker att ange en numerisk IP-adress i webblÀsaren istÀllet för det symboliska resursnamnet frÄn VPN.
Resultatet blir tvÄ problem
- vid anslutning till VPN plockas dess DNS inte upp
- all trafik gÄr genom VPN, som inte tillÄter internetÄtkomst
Vad man ska göra kommer jag att berÀtta nu, men först lite automatisering.
Automatisk inmatning av fast del av lösenordet
Vid det hÀr laget har du förmodligen redan angett lösenordet minst fem gÄnger och denna procedur har tröttat ut dig ganska mycket. För det första, eftersom lösenordet Àr lÄngt, och för det andra, eftersom inmatningen mÄste ske inom en bestÀmd tidsram.
Det slutgiltiga lösningen pÄ problemet kom inte med i artikeln, men man kan göra sÄ att man inte behöver ange den fasta delen av lösenordet flera gÄnger.
Anta att den fasta delen av lösenordet Àr fixedPassword, och delen frÄn Google Authenticator Àr 567 987. Hela lösenordet kan skickas till openconnect via standardinmatning med hjÀlp av argumentet --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNu kan man alltid gÄ tillbaka till den senaste inmatade kommandot och bara Àndra delen frÄn Google Authenticator.
Det företags-VPN tillÄter inte internetÄtkomst.
Det Àr verkligen ganska opraktiskt nÀr man mÄste anvÀnda en separat dator för att besöka habr. Avsaknaden av att kunna kopiera och klistra in frÄn stackoverflow kan verkligen förlamar arbetet, dÀrför Àr det nÄgot man mÄste ÄtgÀrda.
Det behövs en lösning sÄ att nÀr man behöver komma Ät en resurs frÄn det interna nÀtverket, sÄ gÄr Linux genom VPN, och nÀr man behöver komma Ät Habr gÄr det direkt pÄ internet.
Openconnect kör efter att ha startat och anslutit till VPN ett speciellt skript som finns i /usr/share/vpnc-scripts/vpnc-script. NÄgra variabler skickas till skriptet för att göra VPN-instÀllningarna. TyvÀrr har jag inte kunnat lista ut hur man delar trafik mellan det företags-VPN och resten av internet med hjÀlp av det inbyggda skriptet.
Uppenbarligen för sÄdana som mig har verktyget vpn-slice utvecklats, vilket gör det möjligt att styra trafiken över tvÄ kanaler utan krÄngel. NÄvÀl, lite krÄngel kommer det att bli, men man behöver inte vara shaman för det.
Trafikdelning med hjÀlp av vpn-slice
Först mÄste vpn-slice installeras, och det fÄr man nog lista ut sjÀlv. Om det finns frÄgor i kommentarerna sÄ kan jag skriva ett separat inlÀgg om det. Men det Àr ett vanligt program i Python, sÄ det borde inte vara nÄgra svÄrigheter. Jag installerade det med virtualenv.
Och sedan mĂ„ste verktyget anvĂ€ndas, med nyckeln âscript för att ange openconnect, sĂ„ att vpn-slice anvĂ€nds istĂ€llet för standard-skriptet.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script ".\/bin\/vpn-slice 192.168.430.0\/24 " vpn.evilcorp.com I âscript skickas en strĂ€ng med kommandot som ska anropas istĂ€llet för skriptet. .\/bin\/vpn-slice â sökvĂ€gen till det körbara filen vpn-slice 192.168.430.0\/24 â adressmasken för de adresser som ska gĂ„ genom VPN. HĂ€r avses att om adressen börjar med 192.168.430 â sĂ„ ska resurser med den adressen sökas inne i VPN.
Nu borde situationen vara nĂ€stan normal. NĂ€stan. Nu kan man komma Ă„t Habr och Ă„t interna resurser via IP, men man kan inte komma Ă„t interna resurser via det symboliska namnet. Om man skriver in motsvarigheten mellan det symboliska namnet och adressen i hosts â sĂ„ borde allt fungera. Och det kommer att fungera tills IP:n Ă€ndras. Linux kan nu gĂ„ pĂ„ internet eller in i det interna nĂ€tverket beroende pĂ„ IP. Men för att bestĂ€mma adressen anvĂ€nds fortfarande inte det företags-DNS.
Problemet kan Ă€ven uppstĂ„ pĂ„ detta sĂ€tt â pĂ„ jobbet fungerar allt bra, men hemma kan man endast nĂ„ interna företagsresurser via IP. Detta beror pĂ„ att nĂ€r du Ă€r ansluten till företags-Wi-Fi anvĂ€nds Ă€ven ett företags-DNS, vilket gör att symboliska adresser frĂ„n VPN fortfarande kan lösas, Ă€ven om man inte kan nĂ„ dem utan att anvĂ€nda VPN.
Automatisk modifiering av hosts-filen
Om vpn-slice artigt ber dig, kan den efter att VPN har aktiverats gÄ in i dess DNS, hitta IP-adresserna för de nödvÀndiga resurserna baserat pÄ deras symboliska namn och skriva dem i hosts. Efter att VPN har stÀngts av kommer dessa adresser att tas bort frÄn hosts. För detta mÄste du överlÀmna de symboliska namnen 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 bör allt fungera bÄde pÄ kontoret och pÄ stranden.
Sök adresser för alla subdomÀner i DNS som har tillhandahÄllits av VPN.
Om det finns fÄ adresser inom nÀtverket, sÄ fungerar metoden med automatisk modifiering av hosts-filen utmÀrkt. Men om det finns mÄnga resurser i nÀtverket, kommer du kontinuerligt att behöva lÀgga till rader i skriptet som zoidberg.test.evilcorp.com, dÀr zoidberg Àr namnet pÄ en av testmiljöerna.
Men nu nÀr vi har förstÄtt lite mer om situationen kan vi lösa denna nödvÀndighet.
Om du efter att VPN har aktiverats tittar i \/etc\/hosts, kan du se en sÄdan rad.
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Och dessutom har en ny rad lagts till i resolv.conf. Kort sagt, vpn-slice har pÄ nÄgot sÀtt identifierat var DNS-servern för VPN ligger.
Nu mÄste vi göra sÄ att Linux anvÀnder företags-DNS för att ta reda pÄ IP-adressen för domÀnnamn som slutar pÄ evilcorp.com, och för allt annat ska den anvÀnda standard-DNS.
Jag har googlat ganska lÀnge och upptÀckte att sÄdan funktionalitet finns i Ubuntu direkt. Det handlar om möjligheten att anvÀnda en lokal DNS-server, dnsmasq, för namnupplösning.
Det betyder att man kan konfigurera sÄ att Linux alltid gÄr till den lokala DNS-servern för IP-adresser, vilket i sin tur, beroende pÄ domÀnnamnet, kommer att söka IP pÄ den motsvarande externa DNS-servern.
För att hantera allt som rör nÀtverk och nÀtverksanslutningar i Ubuntu anvÀnds NetworkManager, och det grafiska grÀnssnittet för att vÀlja exempelvis wifi-anslutningar Àr helt enkelt ett front för detta.
Vi behöver grÀva lite i dess konfigurationer.
- Skapa en fil i /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Observera punkten före evilcorp. Den signalerar dnsmasq att alla subdomÀner av evilcorp.com ska sökas specifikt i det företags DNS.
- BerÀtta för NetworkManager att dnsmasq ska anvÀndas för namnupplösning.
Konfigurationen för nÀtverksförvaltaren finns i /etc/NetworkManager/NetworkManager.conf. Det Àr nödvÀndigt att lÀgga till detta.
[main]
dns=dnsmasq
- Starta om NetworkManager.
service network-manager restartNu, efter att ha kopplat upp mig till VPN med hjÀlp av openconnect och vpn-slice, kommer ip:en att kÀnnas igen korrekt, Àven utan att lÀgga till symboliska adresser i argumenten för vpnslice.
Hur man gÄr genom VPN till separata tjÀnster.
Efter att ha kunnat koppla upp mig mot VPN, var jag vÀldigt glad i tvÄ dagar, men dÄ upptÀckte jag att om jag kopplar upp mig till VPN utanför kontorsnÀtverket, sÄ fungerar inte mailen. Symtomet Àr bekant, eller hur?
VÄr mail ligger pÄ mail.publicevilcorp.com, vilket innebÀr att den inte omfattas av regeln i dnsmasq, och adressen till mailservern söks via offentlig DNS.
Men pÄ kontoret anvÀnds fortfarande DNS dÀr denna adress finns. Det trodde jag. I praktiken Àndrades ingenting efter att jag lagt till raden i dnsmasq.
address=/mail.publicevilcorp.com/192.168.430.534
Situationen förblev densamma. IP:n förblev densamma. Jag fick gÄ till jobbet.
Och först senare, nÀr jag fördjupade mig i situationen och började förstÄ problemet, tipsade en smart person mig om hur jag skulle lösa det. Jag behövde koppla upp mig mot mailservern inte bara sÄ, utan via VPN.
Jag anvÀnder vpn-slice för att gÄ genom VPN till adresser som börjar med 192.168.430. Adressen till mailservern Àr inte bara att den symboliska adressen inte Àr en subdomÀn till evilcorp, utan dess IP-adress börjar inte heller med 192.168.430. Och frÄn det allmÀnna nÀtverket slÀpper den naturligtvis inte in nÄgon.
För att Linux ska gÄ genom VPN och till mailservern behöver jag lÀgga till den i vpn-slice ocksÄ. LÄt oss sÀga att mailserverns 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 Script för att aktivera VPN med ett argument.
Allt detta Àr förstÄs inte sÀrskilt bekvÀmt. Ja, man kan spara texten i en fil och kopiera den till konsolen istÀllet för att skriva för hand, men det Àr fortfarande inte trevligt. För att underlÀtta processen kan man lÀgga kommandot i ett skript som ligger i PATH. DÄ behöver man bara mata in koden som man 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 man lÀgger skriptet i connect~evilcorp~ kan man enkelt skriva i konsolen.
connect_evil_corp 567987Men nu mÄste man ÀndÄ ha konsolen öppen dÀr openconnect Àr igÄng av nÄgon anledning.
Köra openconnect i bakgrunden.
Som tur Àr har författarna till openconnect tÀnkt pÄ oss och lagt till en speciell parameter -background i programmet, som gör att det kan köras i bakgrunden efter start. Om man startar det sÄ hÀr, kan man stÀnga konsolen efterÄt.
#!/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 vart loggarna gÄr. Loggar Àr i stort sett inte sÀrskilt viktiga för oss, men man vet ju aldrig. openconnect kan omdirigera dem till syslog, dÀr de hÄlls intakta och sÀkra. Det behöver man lÀgga till i kommandot med parametern -syslog.
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Och sÄ visar det sig att openconnect arbetar nÄgonstans i bakgrunden och stör ingen, men hur man stoppar det Àr oklart. Man kan förstÄs filtrera utgÄngen med ps och söka efter processen som har openconnect i namnet, men det Àr lite omstÀndigt. Tack till författarna som ocksÄ tÀnkt pÄ det. Det finns en parameter i openconnect -pid-file, med vilken man kan instruera openconnect att skriva processens 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 man alltid döda processen med kommandot.
kill $(cat ~/vpn-pid)Om processen inte finns kommer kill att klaga, men kasta inte ett fel. Om filen inte finns hÀnder inget farligt, sÄ man kan tryggt döda processen i första raden av 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 man slÄ pÄ datorn, öppna konsolen och köra kommandot, och ge den koden frÄn Google Authenticator. Konsolen kan man sedan döda.
Utan vpn-slice. IstÀllet för ett efterord.
Att förstÄ hur man lever utan vpn-slice visade sig vara mycket svÄrt. Jag var tvungen att lÀsa mycket och googla. Som tur Àr, efter att ha spenderat sÄ mycket tid med ett problem, lÀses tekniska manualer och till och med man openconnect som fÀngslande romaner.
Till slut kom jag fram till att vpn-slice, precis som det ursprungliga skriptet, modifierar routingtabeln för att segmentera nÀtverk.
Routingtabell
Detta, förenklat sagt, Àr en tabell dÀr den första kolumnen innehÄller vad adressen som Linux ska följa ska börja med, medan den andra kolumnen visar vilket nÀtverksgrÀnssnitt som ska anvÀndas för att nÄ den adressen. Det finns fler kolumner, men det förÀndrar inte essensen.
För att se routingtabeln mÄste man 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 Varje rad representerar vÀgen för att skicka ett meddelande till en viss adress. Den första delen beskriver vad adressen ska börja med. För att förstÄ hur man avgör att 192.168.0.0/16 betyder att adressen ska börja med 192.168, behöver man googla vad en IP-adressmask Àr. Efter dev finns namnet pÄ grÀnssnittet som meddelandet ska skickas till.
För VPN har Linux skapat en virtuell adapter â tun0. Raden
192.168.0.0/16 dev tun0 scope link Man kan ocksÄ se den aktuella statusen för routingtabeln med kommandot route -n (IP-adresser har skickligt anonymiserats) Det hÀr kommandot ger resultat i ett annat format och Àr överhuvudtaget deprecated, men dess utdata dyker ofta upp i manualer pÄ internet och man behöver kunna lÀsa den.
Vad IP-adressen för routen ska börja med, kan man förstÄ genom kombinationen av kolumnerna Destination och Genmask. De delar av IP-adressen som har siffror 255 i Genmask beaktas, medan de som har 0 inte gör det. SÄ kombinationen Destination 192.168.0.0 och Genmask 255.255.255.0 betyder att om adressen börjar med 192.168.0, sÄ gÄr förfrÄgningen den vÀgen. 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Ä den vÀgen.
För att förstÄ vad vpn-slice egentligen gör beslutade jag att titta pÄ tillstÄndet för tabellerna innan och efter.
Före VPN-anslutningen sÄg det ut 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 kört openconnect utan vpn-slice sÄg det ut 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 kört openconnect i kombination med vpn-slice ser det ut 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 tydligt att om man inte anvÀnder vpn-slice, sÄ skriver openconnect tydligt att man ska gÄ genom vpn för alla adresser utom de som anges speciellt.
HĂ€r:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0DÀr anges ocksÄ en annan vÀg som ska anvÀndas om adressen som Linux försöker nÄ inte matchar nÄgon mask frÄn tabellen.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0HÀr stÄr det att man i sÄ fall ska gÄ genom den standardiserade wifi-adaptern.
Jag tror att vÀgen för VPN anvÀnds eftersom den Àr först i routingtabellen.
Och teoretiskt, om man tar bort den hÀr standardvÀgen frÄn routingtabellen, sÄ ska openconnect tillsammans med dnsmasq fungera normalt.
Jag försökte
route del defaultOch allt fungerade.
Routing av förfrÄgningar till mailservern utan vpn-slice
Men jag har ju ocksÄ en mailserver med adress 555.555.555.555, som ocksÄ mÄste nÄs genom vpn. Jag mÄste ocksÄ lÀgga till rutten till den manuellt.
ip route add 555.555.555.555 via dev tun0Och nu fungerar allt bra. SÄ det gÄr att klara sig utan vpn-slice, men man behöver ÀndÄ veta vad man gör. Jag övervÀger att inte lÀgga till standardrouten i slutet av openconnects skript för att ta bort den efter att ha anslutit till vpn, bara för att det ska bli fÀrre rörliga delar i min cykel.
Kanske rÀcker det med den hÀr efterskriften för att nÄgon ska förstÄ hur man stÀller in en VPN. Men under tiden jag försökte förstÄ vad jag skulle göra, lÀste jag mÄnga sÄdana guider som fungerar för författaren, men av nÄgon anledning fungerar de inte för mig, och jag beslutade mig för att lÀgga till alla delar jag hittade hÀr. Jag skulle verkligen ha uppskattat nÄgot sÄdant.
KĂ€lla: habr.com
