Ønsker du at bruge Linux på arbejdet, men giver virksomhedens VPN ikke mulighed for det? Så kan denne artikel være til hjælp, selvom det ikke er sikkert. Jeg vil gerne advare på forhånd, at jeg ikke forstår meget omkring netværksadministration, så det er muligt, at jeg har gjort noget forkert. På den anden side kan det være, at jeg kan skrive en vejledning, der er forståelig for almindelige mennesker, så jeg anbefaler at prøve.
Artiklen indeholder meget unødvendig information, men uden disse oplysninger ville jeg ikke have kunnet løse de problemer, jeg pludselig stødte på med VPN-opsætningen. Jeg tænker, at enhver, der prøver at anvende denne vejledning, vil opleve problemer, som jeg ikke havde, og jeg håber, at disse ekstra oplysninger kan hjælpe med at løse problemerne selvstændigt.
De fleste kommandoer, der bruges i vejledningen, skal udføres med sudo, som for korthedens skyld er fjernet. Vær opmærksom på det.
De fleste IP-adresser er udsat for kraftig obfuskering, så hvis du ser en adresse som 435.435.435.435, skal der være en normal IP-adresse, som er specifik for din situation.
Jeg har Ubuntu 18.04, men jeg tror, at vejledningen kan anvendes med små ændringer til andre distributioner. I denne tekst er Linux dog lig med Ubuntu.
Cisco Connect
Dem, der bruger Windows eller MacOS, kan tilslutte til vores firmavpn via Cisco Connect, hvor der skal angives gateway-adresse, og ved hver tilslutning skal der indtastes en adgangskode, der består af en fast del og en kode genereret af Google Authenticator.
I tilfælde af Linux kunne jeg ikke få Cisco Connect til at fungere, men jeg fandt anbefalingen om at bruge openconnect, som er lavet specielt til at erstatte Cisco Connect.
Openconnect
Teoretisk set skulle der være en speciel grafisk grænseflade til openconnect i Ubuntu, men den fungerede ikke for mig. Måske er det til det bedre.
I Ubuntu installeres openconnect fra pakkemanageren.
apt install openconnectUmiddelbart efter installationen kan du prøve at tilslutte til VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com er adressen til en fiktiv VPN
poxvuibr er et fiktivt brugernavn
openconnect vil bede om at indtaste en adgangskode, som jeg minder om, består af en fast del og en kode fra Google Authenticator, og derefter vil det forsøge at oprette forbindelse til vpn. Hvis det lykkedes, tillykke, så kan I roligt springe over den smertefulde del og gå til punktet om, hvordan openconnect fungerer i baggrunden. Hvis det ikke lykkedes, kan I fortsætte. Selvom hvis det lykkedes at oprette forbindelse fra f.eks. gæste-WiFi på arbejdet, kan det være tidligt at juble, det er nødvendigt at forsøge at gentage proceduren derhjemme.
Certifikat
Der er stor sandsynlighed for, at der ikke startes noget, og outputtet fra openconnect vil se nogenlunde sådan ud:
POST https://vpn.evilcorp.com/
Forbundet til 777.777.777.777:443
SSL-forhandling med vpn.evilcorp.com
Servercertifikat validering fejlede: signer ikke fundet
Certifikat fra VPN-serveren "vpn.evilcorp.com" fejlede validering.
Årsag: signer ikke fundet
For at stole på denne server i fremtiden, kan du muligvis tilføje dette til din kommandolinje:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Indtast 'yes' for at acceptere, 'no' for at annullere; alt andet for at se: fgets (stdin): Operation er nu i gangPå den ene side er det ubehageligt, fordi VPN-forbindelsen ikke blev etableret, men på den anden side er det i det store hele klart, hvordan man retter denne problematik.
Her sendte serveren os et certifikat, som gør det muligt at afgøre, at forbindelsen sker til serveren i den hjemmehørende virksomhed og ikke til en ondskabsfuld svindler, men systemet kender ikke dette certifikat. Og derfor kan det ikke bekræfte, om det er en ægte server eller ej. Derfor stopper det arbejdet som precaution.
For at openconnect stadig kan oprette forbindelse til serveren, skal man eksplicit angive, hvilket certifikat der skal komme fra VPN-serveren ved hjælp af nøglen —servercert
Og man kan finde ud af, hvilket certifikat serveren har sendt os, direkte fra det, openconnect har udskrevet. Herfra:
For at stole på denne server i fremtiden, kan du muligvis tilføje dette til din kommandolinje:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Indtast 'yes' for at acceptere, 'no' for at annullere; alt andet for at se: fgets (stdin): Operation er nu i gangMed følgende kommando kan man forsøge at oprette forbindelse igen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMåske virker det nu, så kan man gå videre til slutningen. Men personligt viste Ubuntu mig fingeren i denne form.
POST https://vpn.evilcorp.com/
Forbundet til 777.777.777.777:443
SSL forhandling med vpn.evilcorp.com
Servercertifikat verifikation mislykkedes: signer ikke fundet
Forbundet til HTTPS på vpn.evilcorp.com
XML POST aktiveret
Indtast venligst dit brugernavn og adgangskode.
POST https://vpn.evilcorp.com/
Fik CONNECT svar: HTTP/1.1 200 OK
CSTP forbundet. DPD 300, Hold aktiv 30
Opsætning af DTLS mislykkedes; bruger i stedet SSL
Forbundet som 192.168.333.222, bruger SSL
NOSSSSSHHHHHHHDDDDD
3
NOSSSSSHHHHHHHDDDDD
3
RTNETLINK svar: Fil findes
/etc/resolvconf/update.d/libc: Advarsel: /etc/resolv.conf er ikke et symbolsk link til /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 blive løst, men det vil ikke være muligt at få adgang til det. Adresser som jira.evilcorp.com bliver slet ikke løst.
Hvad der er sket her, er jeg ikke helt klar over. Men eksperimentet viser, at hvis man tilføjer linjen til /etc/resolv.conf
nameserver 192.168.430.534så begynde adresserne inde i VPN magisk at blive løst, og man kan få adgang til dem, dvs. det, der søger at løse adresser med DNS, ser netop i /etc/resolv.conf og ikke et andet sted.
At forbindelsen til VPN findes og fungerer, kan man sikre sig uden at ændre i /etc/resolv.conf; det er nok at indtaste ip-adressen i stedet for det symbolske navn på ressourcen fra vpn i browseren.
Så der er to problemer
- ved tilslutning til VPN hentet dens DNS ikke.
- al trafik går gennem VPN, som ikke tillader at få adgang til internettet.
Hvad man skal gøre, vil jeg nu fortælle, men først lidt automatisering.
Automatisk indtastning af den faste del af adgangskoden
Indtil nu har du sandsynligvis allerede indtastet adgangskoden mindst fem gange, og denne procedure har været temmelig trættende for dig. For det første, fordi adgangskoden er lang, for det andet fordi man skal nå at indtaste den inden for en fast tidsramme.
Den endelige løsning på problemet kom ikke med i artiklen, men man kan gøre det sådan, at den faste del af adgangskoden ikke skal indtastes mange gange.
Lad os sige, at den faste del af adgangskoden er fixedPassword, og delen fra Google Authenticator er 567 987. Hele adgangskoden til openconnect kan sendes gennem standard input ved hjælp af argumentet —passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNu kan man konstant gå tilbage til den sidst indtastede kommando og kun ændre delen fra Google Authenticator.
Det virksomhedsmæssige VPN tillader ikke at få adgang til internettet.
Det er overhovedet ikke særlig praktisk, når man skal til habr, at man skal bruge en separat computer. Manglen på mulighed for at kopiere og indsætte fra stackoverflow kan virkelig lamme arbejdet, så der er noget, der skal gøres.
Der skal gøres noget, så når man skal tilgå ressourcen fra det interne netværk, går Linux gennem VPN'en, men når man skal besøge Habr, går det direkte på internettet.
Openconnect, efter at være startet og have oprettet forbindelse til VPN, kører et specielt script, der findes i /usr/share/vpnc-scripts/vpnc-script. Nogle variabler gives skriptet, og det konfigurerer VPN. Desværre har jeg ikke været i stand til at finde ud af, hvordan man opdeler trafikstrømme mellem virksomhedens VPN og internettet ved hjælp af det originale script.
Åbenbart blev der udviklet et værktøj, vpn-slice, specielt til folk som mig, som gør det muligt at dirigere trafik over to kanaler uden for mange besvær. Altså, der skal danses lidt, men man behøver ikke være shaman.
Opdeling af trafik ved hjælp af vpn-slice
Først skal vpn-slice installeres, og det må man selv finde ud af. Hvis der er spørgsmål i kommentarerne, skriver jeg et separat indlæg om det. Men det er et almindeligt Python-program, så der skulle ikke være nogen problemer. Jeg installerede det ved hjælp af virtualenv.
Herefter skal værktøjet bruges, ved at angive openconnect med nøglen —script, så man i stedet for standard scriptet bruger 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 I —script sendes en streng med kommandoen, der skal kaldes i stedet for scriptet. .\/bin\/vpn-slice er stien til den eksekverbare fil vpn-slice, 192.168.430.0\/24 er adressen, der skal benyttes for at gå igennem VPN. Det menes, at hvis adressen starter med 192.168.430, så skal ressourcen med denne adresse findes inden for VPN.
Nu burde situationen være næsten normal. Næsten. Nu kan man besøge Habr og interne ressourcer via IP, men man kan ikke besøge interne ressourcer via det symbolske navn. Hvis man skriver den tilsvarende forbindelse mellem det symbolske navn og adressen i hosts, skulle alt virke. Og det vil fungere, indtil IP'en ændres. Linux kan nu gå på internettet eller på det interne netværk afhængigt af IP. Men til at bestemme adressen bruges stadig ikke virksomhedens DNS.
Problematikken kan også vise sig på denne måde - på arbejdet fungerer alt fint, men derhjemme kan man kun få adgang til interne ressourcer via IP. Det skyldes, at når du er tilsluttet virksomhedens Wi-Fi, så bruges også virksomhedens DNS, og i den opløses de symboliske adresser fra VPN, selvom man stadig ikke kan tilgå sådan en adresse uden at bruge VPN.
Autolog modifikation af hosts-filen
Hvis vpn-slice bliver bedt pænt, kan den efter oprettelsen af VPN gå over i dens DNS, finde IP-adresserne til de nødvendige ressourcer ud fra deres symboliske navne og indtaste dem i hosts. Efter VPN er de adresser vil bliver fjernet fra hosts. For at gøre dette skal de symboliske navne sendes til vpn-slice som argumenter. Sådan her.
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 skal alt fungere både på kontoret og på stranden.
Søge adresserne til alle underdomæner i DNS, som blev givet af VPN
Hvis der er få adresser i netværket, så er tilgangen med automatisk modifikation af hosts-filen ganske effektiv. Men hvis der er mange ressourcer i netværket, skal du konstant tilføje linjer som zoidberg.test.evilcorp.com til skriptet, da Zoidberg er navnet på en af teststandene.
Men nu, hvor vi har lidt bedre forståelse af situationen, kan vi fjerne denne nødvendighed.
Hvis du ser i \/etc\/hosts efter oprettelsen af VPN, vil du kunne se en linje som denne
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Derudover blev der tilføjet en ny linje i resolv.conf. Kort sagt, vpn-slice har på en eller anden måde identificeret, hvor DNS-serveren for VPN er placeret.
Nu skal der gøres sådan, at for at finde IP-adressen på et domænenavn, der ender på evilcorp.com, skal Linux gå til virksomhedens DNS, og hvis det er noget andet, så til den standard DNS.
Jeg har brugt lang tid på at søge og opdaget, at denne funktionalitet er tilgængelig i Ubuntu som standard. Dette refererer til muligheden for at bruge en lokal DNS-server dnsmasq til navneopslag.
Det betyder, at man kan sætte op, så Linux altid går til IP-adresserne i den lokale DNS-server, som i sin tur, afhængigt af domænenavnet, søger IP på den relevante eksterne DNS-server.
Til at administrere alt, der relaterer sig til netværk og netværksforbindelser i Ubuntu, bruges NetworkManager, og den grafiske grænseflade til at vælge for eksempel WiFi-forbindelsen er blot et frontend til den.
Vi skal kigge i dens konfigurationer.
- Opret en fil i /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Bemærk punktummet før evilcorp. Det signalerer til dnsmasq, at alle underdomæner af evilcorp.com skal søges i virksomhedens DNS.
- Fortæl NetworkManager, at dnsmasq skal bruges til navneopslag.
Konfigurationen for network-manager findes i /etc/NetworkManager/NetworkManager.conf. Der skal tilføjes:
[main]
dns=dnsmasq
- Genstart NetworkManager.
service network-manager restartNu, efter at have tilsluttet til VPN ved hjælp af openconnect og vpn-slice, vil IP'en blive korrekt identificeret, selvom man ikke tilføjer symboliske adresser som argumenter til vpnslice.
Hvordan man bruger VPN til at tilgå specifikke tjenester.
Efter at have fået forbindelse til VPN, var jeg glad i et par dage, men så fandt jeg ud af, at hvis man tilslutter til VPN uden for kontorets netværk, så fungerer mailen ikke. Symptomatisk, ikke sandt?
Vores mail ligger på mail.publicevilcorp.com, så den falder ikke ind under reglen i dnsmasq, og adressen til mailserveren søges gennem offentlig DNS.
Men på kontoret bruges der stadig DNS, hvor denne adresse findes. Det troede jeg. I virkeligheden ændrede situationen sig ikke efter at have tilføjet linjen til dnsmasq:
address=/mail.publicevilcorp.com/192.168.430.534
Situationen forblev den samme. IP'en var stadig den samme. Jeg måtte tage på arbejde.
Og først senere, da jeg dykkede mere ned i situationen og lidt satte mig ind i problemet, foreslog en klog person mig, hvordan jeg skulle løse det. Jeg skulle tilslutte til mailserveren ikke bare sådan, men gennem VPN.
Jeg bruger vpn-slice til at tilgå adresser, der begynder med 192.168.430. Og mailserveren har ikke kun et symbolsk navn, der ikke er en underdomæne af evilcorp, den har også en IP-adresse, der ikke starter med 192.168.430. Og fra det offentlige netværk tillader den selvfølgelig ikke nogen adgang.
For at Linux kan tilgå VPN og mailserveren, skal den også tilføjes til vpn-slice. Lad os antage, at mailserverens 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 Script til at oprette VPN med et argument.
Alt dette er selvfølgelig ikke særlig praktisk. Ja, man kan gemme teksten i en fil og kopiere den ind i konsollen i stedet for at skrive den manuelt, men det er stadig ikke en behagelig situation. For at lette processen kan man pakke kommandoen ind i et script, der ligger i PATH. Så er det kun nødvendigt at indtaste koden, der kommer 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 man placerer scriptet i connect~evilcorp~, kan man bare skrive i konsollen.
connect_evil_corp 567987Men nu skal man stadig holde konsollen åben, hvor openconnect kører.
Kørsel af openconnect i baggrunden
Heldigvis har forfatterne af openconnect tænkt på os og tilføjet en særlig nøgle til programmet —background, som gør, at programmet kører i baggrunden efter opstart. Hvis man starter det på denne måde, kan konsollen lukkes efter opstart.
#!/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 er det bare uklart, hvor logfilerne går hen. Logfilerne er ikke nødvendigvis vigtige for os, men man ved aldrig. Openconnect kan omdirigere dem til syslog, hvor de vil blive gemt sikkert. Det kræver dog, at man tilføjer nøglen —syslog 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åledes viser det sig, at openconnect kører et sted i baggrunden uden at genere nogen, men hvordan stopper man det er uklart. Man kan selvfølgelig filtrere output fra ps med grep og lede efter processen, der har openconnect i sit navn, men det er noget besværligt. Tak til forfatterne, der også har tænkt på dette. I openconnect er der en nøgle —pid-file, som gør det muligt at instruere openconnect til at skrive sin proces-id 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-pidNu kan man altid dræbe processen med kommandoen.
kill $(cat ~/vpn-pid)Hvis processen ikke findes, vil kill give en fejl, men den kaster ikke en fejl. Hvis filen ikke findes, sker der heller ikke noget slemt, så man kan roligt dræbe processen i første linje af scriptet.
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 tænde computeren, åbne konsollen og køre kommandoen med koden fra Google Authenticator. Konsollen kan derefter lukkes.
Uden vpn-slice. I stedet for et efterord.
At forstå, hvordan man lever uden vpn-slice, viste sig at være meget svært. Jeg måtte læse en hel del og google. Heldigvis, efter at have brugt så meget tid på problemet, læses tekniske manualer og endda man openconnect som spændende romaner.
Jeg fandt ud af, at vpn-slice, ligesom det oprindelige script, modificerer routetabellen for at opdele netværk.
Routetabel
For at forklare det kort, er det en tabel, hvor den første kolonne indeholder startadressen, som Linux skal bruge for at komme igennem, og den anden kolonne angiver, hvilket netværksadapter der skal bruges til denne adresse. Faktisk er der flere kolonner, men det ændrer ikke essensen.
For at se routetabellen skal du køre kommandoen 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 Her svarer hver linje til, hvor man skal gå hen for at sende en besked til en given adresse. Først står beskrivelsen af, hvad adressen skal starte med. For at forstå, hvad 192.168.0.0/16 betyder, skal man google hvad en IP-adresse maske er. Efter 'dev' kommer navnet på den adapter, som beskeden skal sendes til.
For VPN har Linux oprettet en virtuel adapter — tun0. Linjen
192.168.0.0/16 dev tun0 scope link Du kan også se den nuværende tilstand af routetabellen ved hjælp af kommandoen route -n (IP-adresser anonymiseret) Denne kommando giver resultater i et andet format og er generelt deprecated, men dens output findes ofte i manualer på internettet, så det er vigtigt at kunne læse det.
Hvad IP-adressen skal starte med for ruten kan forstås ved at kombinere kolonnerne Destination og Genmask. De dele af IP-adressen, der har tallet 255 i Genmask, tages i betragtning, og dem med 0 — ikke. Så kombinationen af Destination 192.168.0.0 og Genmask 255.255.255.0 betyder, at hvis adressen starter med 192.168.0, vil anmodningen gå gennem denne rute. Og hvis Destination er 192.168.0.0, men Genmask er 255.255.0.0, så vil anmodninger til adresser, der starter med 192.168, gå gennem denne rute.
For at finde ud af, hvad vpn-slice faktisk gør, besluttede jeg at se på tilstanden af tabellerne før og efter.
Før VPN blev aktiveret var det sådan her
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 at have kaldt openconnect uden vpn-slice så det sådan ud
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 efter at have kaldt openconnect i kombination med vpn-slice ser det sådan ud
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 er tydeligt, at hvis man ikke bruger vpn-slice, så skriver openconnect eksplicit, at alle adresser, undtagen de specifikt nævnte, skal anvendes gennem vpn.
Her:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Der er umiddelbart angivet en anden rute, der skal bruges, hvis adressen, som Linux forsøger at nå, ikke svarer til nogen af maskerne i tabellen.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Her står der allerede, at i så fald skal man gå gennem den standard wifi-adapter.
Jeg antager, at ruten til VPN bruges, fordi den er den første i routingtabellen.
Og teoretisk set, hvis man fjerner denne standardrute fra routingtabellen, bør openconnect i kombination med dnsmasq sikre normal drift.
Jeg prøvede
route del defaultOg det hele fungerede.
Ruting af anmodninger til mailserveren uden vpn-slice
Men jeg har også en mailserver med adressen 555.555.555.555, som også skal nås via vpn. Ruten dertil skal også tilføjes manuelt.
ip route add 555.555.555.555 via dev tun0Og nu fungerer alt normalt. Så man kan undvære vpn-slice, men man skal vide, hvad man laver. Jeg overvejer nu at tilføje i den sidste linje af openconnect-scriptet, at den default rute skal slettes og ruten til mailserveren skal tilføjes efter tilslutning til vpn, bare for at have færre bevægelige dele i min cykel.
Måske ville dette efterskrift være tilstrækkeligt for nogen til at forstå, hvordan man konfigurerer en VPN. Men mens jeg forsøgte at forstå, hvad jeg skulle gøre, læste jeg en del guides, der fungerede for forfatteren, men underligt nok ikke for mig, og derfor besluttede jeg at samle alle de informationer, jeg fandt, her. Jeg ville have været meget glad for noget sådant.
Kilde: habr.com
