Vil du bruge Linux på arbejdet, men vil din virksomheds VPN ikke lade dig? Så kan denne artikel måske hjælpe, selvom det ikke er sikkert. Jeg vil gerne advare dig på forhånd om, at jeg ikke forstår problemer med netværksadministration godt, så det er muligt, at jeg har gjort alt forkert. På den anden side er det muligt, at jeg kan skrive en guide på en sådan måde, at den vil være forståelig for almindelige mennesker, så jeg råder dig til at prøve den.
Artiklen indeholder en masse unødvendig information, men uden denne viden havde jeg ikke været i stand til at løse de problemer, der uventet dukkede op for mig med at oprette en VPN. Jeg tror, at alle, der forsøger at bruge denne guide, vil have problemer, som jeg ikke havde, og jeg håber, at denne ekstra information vil hjælpe med at løse disse problemer på egen hånd.
De fleste af de kommandoer, der bruges i denne vejledning, skal køres via sudo, som er blevet fjernet for kortheds skyld. Huske.
De fleste IP-adresser er blevet alvorligt sløret, så hvis du ser en adresse som 435.435.435.435, skal der være en normal IP der, specifik for dit tilfælde.
Jeg har Ubuntu 18.04, men jeg tror med mindre ændringer, at guiden kan anvendes på andre distributioner. Men i denne tekst Linux == Ubuntu.
Cisco Connect
De, der er på Windows eller MacOS, kan oprette forbindelse til vores virksomheds-VPN via Cisco Connect, som skal angive gateway-adressen og, hver gang du opretter forbindelse, indtaste en adgangskode bestående af en fast del og en kode genereret af Google Authenticator.
I tilfælde af Linux kunne jeg ikke få Cisco Connect til at køre, men det lykkedes mig at google en anbefaling om at bruge openconnect, lavet specifikt til at erstatte Cisco Connect.
Openconnect
I teorien har Ubuntu en speciel grafisk grænseflade til openconnect, men det virkede ikke for mig. Måske er det til det bedre.
På Ubuntu installeres openconnect fra pakkehåndteringen.
apt install openconnectUmiddelbart efter installationen kan du prøve at oprette forbindelse til en VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com er adressen på en fiktiv VPN
poxvuibr - fiktivt brugernavn
openconnect vil bede dig om at indtaste en adgangskode, som, lad mig minde dig om, består af en fast del og en kode fra Google Authenticator, og så vil den forsøge at oprette forbindelse til vpn. Hvis det virker, tillykke, kan du roligt springe midten over, hvilket er meget smerte, og gå videre til punktet om openconnect, der kører i baggrunden. Hvis det ikke virker, så kan du fortsætte. Selvom det fungerede, når du for eksempel oprettede forbindelse fra en gæst-Wi-Fi på arbejdet, så kan det være for tidligt at glæde sig; du bør prøve at gentage proceduren hjemmefra.
Certifikat
Der er stor sandsynlighed for, at intet starter, og openconnect-udgangen vil se sådan ud:
POST https://vpn.evilcorp.com/
Connected to 777.777.777.777:443
SSL negotiation with vpn.evilcorp.com
Server certificate verify failed: signer not found
Certificate from VPN server "vpn.evilcorp.com" failed verification.
Reason: signer not found
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progressPå den ene side er dette ubehageligt, fordi der ikke var nogen forbindelse til VPN, men på den anden side er det i princippet klart, hvordan man løser dette problem.
Her sendte serveren os et certifikat, hvorved vi kan fastslå, at forbindelsen oprettes til serveren for vores oprindelige selskab, og ikke til en ond svindler, og dette certifikat er ukendt for systemet. Og derfor kan hun ikke tjekke, om serveren er ægte eller ej. Og så, for en sikkerheds skyld, holder den op med at virke.
For at openconnect kan oprette forbindelse til serveren, skal du udtrykkeligt fortælle den, hvilket certifikat der skal komme fra VPN-serveren ved hjælp af —servercert-nøglen
Og du kan finde ud af hvilket certifikat serveren sendte os direkte fra det openconnect printede. Her er fra dette stykke:
To trust this server in future, perhaps add this to your command line:
--servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
Enter 'yes' to accept, 'no' to abort; anything else to view: fgets (stdin): Operation now in progressMed denne kommando kan du prøve at oprette forbindelse igen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMåske virker det nu, så kan du gå videre til slutningen. Men personligt viste Ubuntu mig en figen i denne 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 vil løse, men du vil ikke være i stand til at gå dertil. Adresser som jira.evilcorp.com er slet ikke løst.
Hvad der skete her er ikke klart for mig. Men eksperimentet viser, at hvis du tilføjer linjen til /etc/resolv.conf
nameserver 192.168.430.534så vil adresserne inde i VPN'et begynde at løse sig på magisk vis, og du kan gå igennem dem, det vil sige, hvad DNS leder efter for at løse adresser, ser specifikt ud i /etc/resolv.conf, og ikke et andet sted.
Du kan bekræfte, at der er en forbindelse til VPN'en, og den virker uden at foretage ændringer i /etc/resolv.conf; for at gøre dette skal du blot indtaste i browseren ikke det symbolske navn på ressourcen fra VPN'en, men dens IP-adresse
Som følge heraf er der to problemer
- Når du opretter forbindelse til en VPN, bliver dens dns ikke opfanget
- al trafik går gennem VPN, som ikke tillader adgang til internettet
Jeg vil fortælle dig, hvad du skal gøre nu, men først lidt automatisering.
Automatisk indtastning af den faste del af adgangskoden
Nu har du højst sandsynligt allerede indtastet din adgangskode mindst fem gange, og denne procedure har allerede træt dig ud. For det første fordi adgangskoden er lang, og for det andet fordi, at du ved indtastning skal passe inden for et fast tidsrum
Den endelige løsning på problemet var ikke med i artiklen, men du kan sikre dig, 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. Hele adgangskoden kan sendes til openconnect via standardinput ved hjælp af argumentet --passwd-on-stdin .
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNu kan du konstant vende tilbage til den sidst indtastede kommando og kun ændre en del af Google Authenticator der.
En virksomheds-VPN tillader dig ikke at surfe på internettet.
Generelt er det ikke særlig ubelejligt, når du skal bruge en separat computer for at gå til Habr. Manglende evne til at copy-paste fra stackoverfow kan generelt lamme arbejdet, så noget skal gøres.
Vi skal på en eller anden måde organisere det, så når du skal have adgang til en ressource fra det interne netværk, går Linux til VPN, og når du skal til Habr, går det til internettet.
openconnect, efter lancering og etablering af en forbindelse med vpn, udfører et specielt script, som er placeret i /usr/share/vpnc-scripts/vpnc-script. Nogle variabler sendes til scriptet som input, og det konfigurerer VPN. Desværre kunne jeg ikke finde ud af, hvordan man deler trafikstrømme mellem en virksomheds-VPN og resten af internettet ved hjælp af et indbygget script.
Tilsyneladende blev vpn-slice-værktøjet udviklet specielt til folk som mig, som giver dig mulighed for at sende trafik gennem to kanaler uden at danse med en tamburin. Nå, det vil sige, du bliver nødt til at danse, men du behøver ikke at være shaman.
Trafikadskillelse ved hjælp af vpn-slice
For det første skal du installere vpn-slice, du skal selv finde ud af dette. Hvis der er spørgsmål i kommentarerne, vil jeg skrive et separat indlæg om dette. Men dette er et almindeligt Python-program, så der burde ikke være nogen vanskeligheder. Jeg installerede ved hjælp af virtualenv.
Og så skal hjælpeprogrammet anvendes ved at bruge -script-switchen, hvilket indikerer at openconnect, at du i stedet for standardscriptet skal bruge vpn-slice
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script sendes en streng med en kommando, der skal kaldes i stedet for scriptet. ./bin/vpn-slice - sti til den eksekverbare vpn-slice fil 192.168.430.0/24 - maske af adresser at gå til i vpn. Her mener vi, at hvis adressen starter med 192.168.430, så skal ressourcen med denne adresse søges inde i VPN'en
Situationen skulle nu være næsten normal. Næsten. Nu kan du gå til Habr, og du kan gå til den interne ressource via ip, men du kan ikke gå til den interne ressource med symbolsk navn. Hvis du angiver et match mellem det symbolske navn og adresse i værter, burde alt fungere. Og arbejd indtil ip'en ændres. Linux kan nu få adgang til internettet eller intranettet, afhængigt af IP. Men ikke-virksomheds-DNS bruges stadig til at bestemme adressen.
Problemet kan også vise sig i denne form - på arbejdet er alt fint, men derhjemme kan du kun få adgang til interne virksomhedsressourcer via IP. Det skyldes, at når du er tilsluttet virksomhedens Wi-Fi, bruges virksomhedens DNS også, og symbolske adresser fra VPN’en løses i den, på trods af at det stadig er umuligt at gå til en sådan adresse uden at bruge en VPN.
Automatisk ændring af værtsfilen
Hvis vpn-slice bliver spurgt høfligt, kan den, efter at have hævet VPN, gå til sin DNS, finde IP-adresserne på de nødvendige ressourcer der ved deres symbolske navne og indtaste dem i værter. Efter at have slået VPN fra, vil disse adresser blive fjernet fra værter. For at gøre dette skal du sende symbolske navne 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 skulle alt fungere både på kontoret og på stranden.
Søg efter adresserne på alle underdomæner i DNS givet af VPN
Hvis der er få adresser inden for netværket, fungerer metoden med automatisk ændring af værtsfilen ganske godt. Men hvis der er mange ressourcer på netværket, så bliver du hele tiden nødt til at tilføje linjer som zoidberg.test.evilcorp.com til scriptet zoidberg er navnet på en af testbænkene.
Men nu hvor vi forstår lidt, hvorfor dette behov kan elimineres.
Hvis du, efter at have hævet VPN, kigger i /etc/hosts, kan du se denne linje
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Og en ny linje blev tilføjet til resolv.conf. Kort sagt, vpn-slice bestemte på en eller anden måde, hvor dns-serveren til vpn'en er placeret.
Nu skal vi sikre os, at for at finde ud af IP-adressen på et domænenavn, der slutter på evilcorp.com, går Linux til virksomhedens DNS, og hvis der er behov for noget andet, så til standarden.
Jeg Googlede i et stykke tid og fandt ud af, at en sådan funktionalitet er tilgængelig i Ubuntu ud af æsken. Dette betyder muligheden for at bruge den lokale DNS-server dnsmasq til at løse navne.
Det vil sige, at du kan sikre dig, at Linux altid går til den lokale DNS-server for IP-adresser, som igen, afhængigt af domænenavnet, vil lede efter IP'en på den tilsvarende eksterne DNS-server.
Til at styre alt relateret til netværk og netværksforbindelser, bruger Ubuntu NetworkManager, og den grafiske grænseflade til at vælge for eksempel Wi-Fi-forbindelser er blot en frontend til det.
Vi bliver nødt til at klatre i dens konfiguration.
- Opret en fil i /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Vær opmærksom på punktet foran evilcorp. Det signalerer dnsmasq, at alle underdomæner af evilcorp.com skal søges i virksomhedens dns.
- Fortæl NetworkManager at bruge dnsmasq til navneopløsning
Network-manager-konfigurationen er placeret i /etc/NetworkManager/NetworkManager.conf Du skal tilføje der:
[main] dns=dnsmasq
- Genstart NetworkManager
service network-manager restartNu, efter at have oprettet forbindelse til en VPN ved hjælp af openconnect og vpn-slice, vil ip'en blive bestemt normalt, selvom du ikke tilføjer symbolske adresser til argumenterne til vpnslice.
Sådan får du adgang til individuelle tjenester via VPN
Efter at det lykkedes mig at oprette forbindelse til VPN'en, var jeg meget glad i to dage, og så viste det sig, at hvis jeg forbinder til VPN'en uden for kontornetværket, så virker mail ikke. Symptomet er velkendt, er det ikke?
Vores mail er placeret på mail.publicevilcorp.com, hvilket betyder at den ikke falder ind under reglen i dnsmasq og mailserveradressen søges gennem offentlig DNS.
Nå, kontoret bruger stadig DNS, som indeholder denne adresse. Det var det, jeg troede. Faktisk, efter at have tilføjet linjen til dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
situationen har ikke ændret sig overhovedet. ip forblev den samme. Jeg skulle på arbejde.
Og først senere, da jeg dykkede dybere ned i situationen og forstod problemet lidt, fortalte en smart person mig, hvordan jeg skulle løse det. Det var nødvendigt at oprette forbindelse til mailserveren ikke bare sådan, men via VPN
Jeg bruger vpn-slice til at gå gennem VPN til adresser, der starter med 192.168.430. Og mailserveren har ikke kun en symbolsk adresse, der ikke er et underdomæne af evilcorp, den har heller ikke en IP-adresse, der starter med 192.168.430. Og selvfølgelig tillader han ikke nogen fra det generelle netværk at komme til ham.
For at Linux kan gå gennem VPN og til mailserveren, skal du også tilføje det til vpn-slice. Lad os sige, at afsenderens 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 hæve VPN med ét argument
Alt dette er selvfølgelig ikke særlig bekvemt. Ja, du kan gemme teksten i en fil og kopiere og indsætte den i konsollen i stedet for at skrive den i hånden, men det er stadig ikke særlig behageligt. For at gøre processen nemmere kan du pakke kommandoen ind i et script, der vil blive placeret i PATH. Og så skal du kun indtaste den kode, du har modtaget fra Google Authenticator
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Hvis du sætter scriptet i connect~evilcorp~ kan du blot skrive i konsollen
connect_evil_corp 567987Men nu skal du stadig holde konsollen, hvor openconnect kører åben af en eller anden grund
Kører openconnect i baggrunden
Heldigvis tog forfatterne af openconnect sig af os og tilføjede en særlig nøgle til programmet -baggrund, som får programmet til at arbejde i baggrunden efter lanceringen. Hvis du kører det på denne måde, kan du lukke konsollen efter lancering
#!/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 ikke klart, hvor logfilerne går hen. Generelt har vi ikke rigtig brug for logfiler, men man ved aldrig. openconnect kan omdirigere dem til syslog, hvor de vil blive opbevaret sikkert. du skal tilføje –syslog-kontakten til kommandoen
#!/bin/sh
echo "fixedPassword$1" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444
--user poxvuibr
--passwd-on-stdin
--background
--syslog
--script "./bin/vpn-slice 192.168.430.0/24 jira.vpn.evilcorp.com git.vpn.evilcorp.com " vpn.evilcorp.com Og så viser det sig, at openconnect fungerer et sted i baggrunden og ikke generer nogen, men det er ikke klart, hvordan man stopper det. Det vil sige, at du selvfølgelig kan filtrere ps-outputtet ved hjælp af grep og lede efter en proces, hvis navn indeholder openconnect, men det er på en eller anden måde kedeligt. Tak til forfatterne, der også tænkte over dette. Openconnect har en nøgle -pid-fil, med hvilken du kan instruere openconnect til at skrive dens 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 du altid dræbe en proces med kommandoen
kill $(cat ~/vpn-pid)Hvis der ikke er nogen proces, vil kill forbande, men vil ikke kaste en fejl. Hvis filen ikke er der, så sker der heller ikke noget dårligt, så du kan trygt dræbe processen i den 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 du tænde for din computer, åbne konsollen og køre kommandoen og give den koden fra Google Authenticator. Konsollen kan derefter sømmes fast.
Uden VPN-slice. I stedet for et efterord
Det viste sig at være meget svært at forstå, hvordan man lever uden VPN-slice. Jeg skulle læse og google meget. Heldigvis, efter at have brugt så meget tid med et problem, læste tekniske manualer og endda man openconnect som spændende romaner.
Som et resultat fandt jeg ud af, at vpn-slice, ligesom det oprindelige script, ændrer routingtabellen til separate netværk.
Routing tabel
For at sige det enkelt er dette en tabel i den første kolonne, som indeholder, hvad den adresse, som Linux ønsker at gå igennem, skal begynde med, og i den anden kolonne, hvilken netværksadapter, der skal gennemgås på denne adresse. Faktisk er der flere højttalere, men det ændrer ikke på essensen.
For at se routingtabellen skal du køre ip-rutekommandoen
default via 192.168.1.1 dev wlp3s0 proto dhcp metric 600
192.168.430.0/24 dev tun0 scope link
192.168.1.0/24 dev wlp3s0 proto kernel scope link src 192.168.1.534 metric 600
192.168.430.534 dev tun0 scope link Her er hver linje ansvarlig for, hvor du skal hen for at sende en besked til en eller anden adresse. Den første er en beskrivelse af, hvor adressen skal begynde. For at forstå, hvordan man bestemmer, at 192.168.0.0/16 betyder, at adressen skal starte med 192.168, skal du google, hvad en IP-adressemaske er. Efter dev er der navnet på den adapter, som beskeden skal sendes til.
Til VPN lavede Linux en virtuel adapter - tun0. Linjen sikrer, at trafikken for alle adresser, der starter med 192.168, går igennem den
192.168.0.0/16 dev tun0 scope link Du kan også se på den aktuelle tilstand af routingtabellen ved hjælp af kommandoen rute -n (IP-adresser er smart anonymiseret) Denne kommando producerer resultater i en anden form og er generelt forældet, men dens output findes ofte i manualer på internettet, og du skal kunne læse den.
Hvor IP-adressen for en rute skal starte, kan forstås ud fra kombinationen af kolonnerne Destination og Genmask. De dele af IP-adressen, der svarer til tallene 255 i Genmask, tages i betragtning, men dem, hvor der er 0, er det ikke. Det vil sige, at kombinationen af Destination 192.168.0.0 og Genmask 255.255.255.0 betyder, at hvis adressen starter med 192.168.0, så vil anmodningen til den gå ad denne rute. Og hvis Destination 192.168.0.0 men Genmask 255.255.0.0, så vil anmodninger til adresser, der starter med 192.168, gå langs denne rute
For at finde ud af, hvad vpn-slice rent faktisk gør, besluttede jeg at se på tabellernes tilstande før og efter
Før du tændte for VPN'en, 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 blev det sådan her
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 som dette
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0
222.222.222.0 0.0.0.0 255.255.255.0 U 600 0 0 wlp3s0
333.333.333.333 222.222.222.1 255.255.255.255 UGH 0 0 0 wlp3s0
192.168.430.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0
192.168.430.534 0.0.0.0 255.255.255.255 UH 0 0 0 tun0Det kan ses, at hvis du ikke bruger vpn-slice, så skriver openconnect eksplicit, at alle adresser, undtagen de specifikt angivne, skal tilgås via vpn.
Lige her:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Der ved siden af er der straks angivet en anden sti, som skal bruges, hvis den adresse, som Linux forsøger at passere igennem, ikke matcher nogen maske fra tabellen.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Det er allerede skrevet her, at du i dette tilfælde skal bruge en standard Wi-Fi-adapter.
Jeg tror, at VPN-stien bruges, fordi den er den første i routingtabellen.
Og teoretisk set, hvis du fjerner denne standardsti fra routing-tabellen, bør i forbindelse med dnsmasq openconnect sikre normal drift.
jeg forsøgte
route del defaultOg alt fungerede.
Routing forespørgsler til en mailserver uden vpn-slice
Men jeg har også en mailserver med adressen 555.555.555.555, som også skal tilgås via VPN. Ruten til den skal også tilføjes manuelt.
ip route add 555.555.555.555 via dev tun0Og nu er alt godt. Så du kan undvære vpn-slice, men du skal vide godt, hvad du laver. Jeg tænker nu på at tilføje til den sidste linje i det oprindelige openconnect-script fjernelse af standardruten og tilføje en rute for maileren efter at have oprettet forbindelse til VPN, bare så der er færre bevægelige dele på min cykel.
Sandsynligvis ville dette efterord være nok til, at nogen forstår, hvordan man opsætter en VPN. Men mens jeg prøvede at forstå, hvad og hvordan man gør, læste jeg en hel del af sådanne guider, der fungerer for forfatteren, men af en eller anden grund ikke virker for mig, og jeg besluttede at tilføje alle de stykker, jeg fandt, her. Sådan noget ville jeg blive meget glad for.
Kilde: www.habr.com