Wolle jo Linux op it wurk brûke, mar jo bedriuws-VPN lit jo net? Dan kin dit artikel helpe, hoewol dit net wis is. Ik wol jo fan tefoaren warskôgje dat ik problemen mei netwurkadministraasje net goed begryp, dus it is mooglik dat ik alles ferkeard dien haw. Oan 'e oare kant is it mooglik dat ik in gids op sa'n manier skriuwe kin dat it foar gewoane minsken begryplik is, dus ik ried jo oan om it te besykjen.
It artikel befettet in protte ûnnedige ynformaasje, mar sûnder dizze kennis soe ik de problemen dy't my ûnferwachts ferskynden mei it opsetten fan in VPN net oplosse kinne. Ik tink dat elkenien dy't besiket in gebrûk dizze gids sil hawwe problemen dy't ik hie net, en ik hoopje dat dizze ekstra ynformaasje sil helpe lossen dizze problemen op harsels.
De measte kommando's dy't yn dizze hantlieding brûkt wurde moatte wurde útfierd fia sudo, dy't foar koarteheid is fuortsmiten. Hâld yn gedachten.
De measte IP-adressen binne slim obfuscated, dus as jo in adres sjogge lykas 435.435.435.435, dan moat d'r wat normaal IP wêze, spesifyk foar jo gefal.
Ik haw Ubuntu 18.04, mar ik tink mei lytse feroarings de gids kin tapast wurde op oare distribúsjes. Lykwols, yn dizze tekst Linux == Ubuntu.
Cisco Connect
Dejingen dy't op Windows of MacOS binne kinne ferbine mei ús bedriuws-VPN fia Cisco Connect, dy't it gateway-adres moat opjaan en, elke kear as jo ferbine, in wachtwurd ynfiere dat bestiet út in fêst diel en in koade generearre troch Google Authenticator.
Yn it gefal fan Linux koe ik Cisco Connect net rinne, mar ik slagge in oanbefelling te googlejen om openconnect te brûken, spesifyk makke om Cisco Connect te ferfangen.
Openconnect
Yn teory hat Ubuntu in spesjale grafyske ynterface foar openconnect, mar it wurke net foar my. Miskien is it foar it better.
Op Ubuntu wurdt openconnect ynstalleare fanút de pakketbehearder.
apt install openconnectFuort nei ynstallaasje kinne jo besykje te ferbinen mei in VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com is it adres fan in fiktive VPN
poxvuibr - fiktive brûkersnamme
openconnect sil jo freegje om in wachtwurd yn te fieren, dat, lit my jo herinnerje, bestiet út in fêst diel en in koade fan Google Authenticator, en dan sil it besykje te ferbinen mei de vpn. As it wurket, lokwinske, kinne jo feilich oerslaan it midden, dat is in soad pine, en gean nei it punt oer iepenferbining rint op 'e eftergrûn. As it net wurket, dan kinne jo trochgean. Hoewol as it wurke by it ferbinen, bygelyks fan in gast Wi-Fi op it wurk, dan kin it te betiid wêze om bliid te wêzen; jo moatte besykje de proseduere fan hûs te werheljen.
Sertifikaat
D'r is in hege kâns dat neat sil begjinne, en de iepenferbining-útfier sil der sa útsjen:
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 progressOan 'e iene kant is dit onaangenaam, om't d'r gjin ferbining wie mei de VPN, mar oan' e oare kant is hoe't jo dit probleem reparearje kinne, yn prinsipe dúdlik.
Hjir stjoerde de tsjinner ús in sertifikaat, wêrmei't wy kinne bepale dat de ferbining makke wurdt mei de tsjinner fan ús lânseigen korporaasje, en net nei in kweade frauder, en dit sertifikaat is ûnbekend foar it systeem. En dêrom kin se net kontrolearje oft de server echt is of net. En sa, foar it gefal, hâldt it op mei wurkjen.
Om iepenferbining te ferbinen mei de tsjinner, moatte jo it eksplisyt fertelle hokker sertifikaat fan 'e VPN-tsjinner komme moat mei de -servercert-kaai
En jo kinne útfine hokker sertifikaat de tsjinner ús direkt stjoerde fan hokker openconnect printe. Hjir is fan dit stik:
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 progressMei dit kommando kinne jo besykje opnij te ferbinen
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comMiskien no wurket it, dan kinne jo nei de ein. Mar persoanlik liet Ubuntu my in fig yn dizze foarm sjen
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 sil oplosse, mar do silst net by steat wêze om te gean dêr. Adressen lykas jira.evilcorp.com wurde hielendal net oplost.
Wat hjir bard is, is my net dúdlik. Mar eksperimint lit sjen dat as jo de rigel tafoegje oan /etc/resolv.conf
nameserver 192.168.430.534dan sille de adressen yn 'e VPN begjinne te magysk oplosse en jo kinne troch har rinne, dat is, wat DNS siket om adressen op te lossen, sjocht spesifyk yn /etc/resolv.conf, en net earne oars.
Jo kinne ferifiearje dat d'r in ferbining is mei de VPN en it wurket sûnder feroaringen te meitsjen oan /etc/resolv.conf; Om dit te dwaan, fier gewoan yn 'e browser net de symboalyske namme fan' e boarne fan 'e VPN, mar it IP-adres
As gefolch binne der twa problemen
- By it ferbinen mei in VPN wurdt syn dns net ophelle
- alle ferkear giet fia VPN, dat jout gjin tagong ta it ynternet
Ik sil jo fertelle wat jo no dwaan moatte, mar earst in bytsje automatisearring.
Automatysk ynfier fan it fêste diel fan it wachtwurd
Tsjintwurdich hawwe jo wierskynlik al jo wachtwurd op syn minst fiif kear ynfierd en dizze proseduere hat jo al wurch makke. As earste, om't it wachtwurd lang is, en twadde, om't jo by it ynfieren moatte passe binnen in fêste tiidperioade
De definitive oplossing foar it probleem wie net opnommen yn it artikel, mar jo kinne derfoar soargje dat it fêste diel fan it wachtwurd net in protte kearen hoecht te wurde ynfierd.
Lit ús oannimme dat it fêste diel fan it wachtwurd is fixedPassword, en it diel fan Google Authenticator is 567 987. It hiele wachtwurd kin trochjûn wurde om te iepenjenferbining fia standert ynfier mei it argumint --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNo kinne jo konstant weromgean nei it lêste ynfierde kommando en dêr mar in diel fan Google Authenticator feroarje.
In bedriuws-VPN lit jo net op it ynternet surfe.
Yn 't algemien is it net heul ûngemaklik as jo in aparte kompjûter moatte brûke om nei Habr te gean. It ûnfermogen om te kopiearjen-plakken fan stackoverfow kin it wurk oer it algemien paralysearje, dus der moat wat dien wurde.
Wy moatte it op ien of oare manier organisearje, sadat as jo tagong moatte ta in boarne fan it ynterne netwurk, Linux nei de VPN giet, en as jo nei Habr moatte gean, giet it nei it ynternet.
openconnect, nei it starten en oprjochtsjen fan in ferbining mei vpn, fiert in spesjaal skript út, dat leit yn /usr/share/vpnc-scripts/vpnc-script. Guon fariabelen wurde trochjûn oan it skript as ynfier, en it konfigurearret de VPN. Spitigernôch koe ik net útfine hoe't ik ferkearsstreamen splitst tusken in bedriuws-VPN en de rest fan it ynternet mei in native skript.
Blykber is it vpn-slice-hulpprogramma spesjaal ûntwikkele foar minsken lykas my, wêrtroch jo ferkear troch twa kanalen kinne stjoere sûnder te dûnsjen mei in tamboeryn. No, dat is, jo sille dûnsje moatte, mar jo moatte gjin sjamaan wêze.
Ferkearskieding mei vpn-slice
As earste moatte jo vpn-slice ynstallearje, jo moatte dit sels útfine. As der fragen binne yn de kommentaren, skriuw ik hjir in aparte post oer. Mar dit is in gewoan Python-programma, dus d'r moatte gjin swierrichheden wêze. Ik ynstallearre mei help fan virtualenv.
En dan moat it hulpprogramma tapast wurde, mei de -script-skeakel, wat oanjout om te iepenjen ferbine dat jo ynstee fan it standertskript vpn-slice moatte brûke
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com --script wurdt trochjûn in tekenrige mei in kommando dat moat wurde neamd ynstee fan it skript. ./bin/vpn-slice - paad nei it útfierbere bestân vpn-slice 192.168.430.0/24 - masker fan adressen om nei te gean yn vpn. Hjir bedoele wy dat as it adres begjint mei 192.168.430, dan moat de boarne mei dit adres socht wurde binnen de VPN
De situaasje soe no hast normaal wêze moatte. Hast. No kinne jo gean nei Habr en jo kinne gean nei de intra-korporaasje boarne troch ip, mar jo kinne net gean nei de intra-corporate boarne troch symboalyske namme. As jo in oerienkomst oantsjutte tusken de symboalyske namme en adres yn hosts, soe alles moatte wurkje. En wurkje oant de ip feroaret. Linux kin no tagong krije ta it ynternet of it yntranet, ôfhinklik fan it IP. Mar non-corporate DNS wurdt noch altyd brûkt om it adres te bepalen.
It probleem kin him ek manifestearje yn dizze foarm - op it wurk is alles goed, mar thús kinne jo allinich tagong krije ta ynterne bedriuwsboarnen fia IP. Dit is om't as jo ferbûn binne mei bedriuwswi-Fi, wurdt de bedriuws-DNS ek brûkt, en symboalyske adressen fan 'e VPN wurde dêryn oplost, nettsjinsteande it feit dat it noch ûnmooglik is om nei sa'n adres te gean sûnder in VPN te brûken.
Automatyske wiziging fan it hostbestân
As vpn-slice beleefd wurdt frege, dan kin it nei it ferheegjen fan de VPN nei syn DNS gean, dêr de IP-adressen fan 'e nedige boarnen fine troch har symboalyske nammen en ynfiere se yn hosts. Nei it útsetten fan de VPN sille dizze adressen fan hosts fuortsmiten wurde. Om dit te dwaan, moatte jo symboalyske nammen trochjaan oan vpn-slice as arguminten. Lykas dit.
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 No moat alles wurkje sawol op it kantoar as op it strân.
Sykje nei de adressen fan alle subdomeinen yn 'e DNS jûn troch de VPN
As d'r in pear adressen binne binnen it netwurk, dan wurket de oanpak fan it automatysk wizigjen fan it hostbestân frij goed. Mar as d'r in protte boarnen op it netwurk binne, dan moatte jo konstant rigels lykas zoidberg.test.evilcorp.com tafoegje oan it skript zoidberg is de namme fan ien fan 'e testbanken.
Mar no't wy in bytsje begripe wêrom't dizze need kin wurde elimineare.
As jo, nei it ferheegjen fan de VPN, sjogge yn /etc/hosts, kinne jo dizze line sjen
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
En in nije rigel waard tafoege oan resolv.conf. Koartsein, vpn-slice hat op ien of oare manier bepaald wêr't de dns-tsjinner foar de vpn leit.
No moatte wy derfoar soargje dat om it IP-adres fan in domeinnamme te finen dy't einiget op evilcorp.com, Linux giet nei de bedriuws-DNS, en as der wat oars nedich is, dan nei de standert.
Ik googlede in skoft en fûn dat sokke funksjonaliteit beskikber is yn Ubuntu út 'e doaze. Dit betsjut de mooglikheid om de lokale DNS-tsjinner dnsmasq te brûken om nammen op te lossen.
Dat is, jo kinne derfoar soargje dat Linux altyd nei de lokale DNS-tsjinner giet foar IP-adressen, dy't op syn beurt, ôfhinklik fan 'e domeinnamme, sil sykje nei it IP op 'e oerienkommende eksterne DNS-tsjinner.
Om alles te behearjen yn ferbân mei netwurken en netwurkferbiningen, brûkt Ubuntu NetworkManager, en de grafyske ynterface foar it selektearjen fan bygelyks Wi-Fi-ferbiningen is gewoan in front-end derfan.
Wy sille moatte klimme yn syn konfiguraasje.
- Meitsje in triem yn /etc/NetworkManager/dnsmasq.d/evilcorp
address=/.evilcorp.com/192.168.430.534
Jou omtinken oan it punt foar evilcorp. It sinjalearret dnsmasq dat alle subdomeinen fan evilcorp.com socht wurde moatte yn 'e bedriuwsdns.
- Fertel NetworkManager om dnsmasq te brûken foar nammeresolúsje
De konfiguraasje fan de netwurkbehearder leit yn /etc/NetworkManager/NetworkManager.conf Jo moatte dêr taheakje:
[haad] dns=dnsmasq
- Restart NetworkManager
service network-manager restartNo, nei ferbining mei in VPN mei openconnect en vpn-slice, sil de ip normaal wurde bepaald, sels as jo gjin symboalyske adressen tafoegje oan de arguminten foar vpnslice.
Hoe kinne jo tagong krije ta yndividuele tsjinsten fia VPN
Nei't ik it slagge om te ferbinen mei de VPN, wie ik twa dagen heul bliid, en doe die bliken dat as ik ferbine mei de VPN fan bûten it kantoarnetwurk, dan wurket post net. It symptoom is bekend, is it net?
Us e-post is te finen yn mail.publicevilcorp.com, wat betsjut dat it net falt ûnder de regel yn dnsmasq en it e-postserveradres wurdt socht fia iepenbiere DNS.
No, it kantoar brûkt noch DNS, dat dit adres befettet. Dat tocht ik. Yn feite, nei it tafoegjen fan de line oan dnsmasq
address=/mail.publicevilcorp.com/192.168.430.534
de situaasje is hielendal net feroare. ip bleau itselde. Ik moast oan it wurk.
En pas letter, doe't ik djipper yn 'e situaasje dûkte en it probleem in bytsje begriep, fertelde ien tûk persoan my hoe't ik it oplosse moast. It wie nedich om te ferbinen mei de e-posttsjinner net allinich sa, mar fia VPN
Ik brûk vpn-slice om troch de VPN te gean nei adressen dy't begjinne mei 192.168.430. En de e-posttsjinner hat net allinich in symboalysk adres dat gjin subdomein fan evilcorp is, it hat ek gjin IP-adres dat begjint mei 192.168.430. En hy lit fansels net ien út it algemiene netwurk by him komme.
Om Linux troch de VPN en nei de e-posttsjinner te gean, moatte jo it ek tafoegje oan vpn-slice. Litte wy sizze dat it adres fan de mailer 555.555.555.555 is
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 foar it ferheegjen fan VPN mei ien argumint
Dit alles is fansels net heul handich. Ja, jo kinne de tekst opslaan yn in bestân en kopiearje en plakke yn 'e konsole ynstee fan it mei de hân te typen, mar it is noch altyd net heul noflik. Om it proses makliker te meitsjen, kinne jo it kommando yn in skript ynpakke dat yn PATH lizze sil. En dan hoege jo allinich de koade yn te fieren ûntfongen fan 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 As jo it skript yn connect~evilcorp~ sette, kinne jo gewoan yn 'e konsole skriuwe
connect_evil_corp 567987Mar no moatte jo de konsole wêryn openconnect rint om ien of oare reden noch iepen hâlde
Running openconnect op 'e eftergrûn
Gelokkich hawwe de auteurs fan openconnect ús fersoarge en in spesjale kaai tafoege oan it programma -eftergrûn, wêrtroch it programma nei it starten op 'e eftergrûn wurket. As jo it sa útfiere, kinne jo de konsole nei lansearring slute
#!/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 No is it gewoan net dúdlik wêr't de logs hinne geane. Yn it algemien hawwe wy net echt logs nedich, mar jo witte noait. openconnect kin se trochferwize nei syslog, wêr't se feilich en feilich sille wurde bewarre. jo moatte de -syslog-skeakel tafoegje oan it kommando
#!/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 En sa docht bliken dat openconnect earne op 'e eftergrûn wurket en gjinien hinderet, mar it is net dúdlik hoe't it kin stopje. Dat is, jo kinne fansels de ps-útfier filterje mei grep en sykje nei in proses wêrfan de namme openconnect befettet, mar dit is op ien of oare manier ferfeelsum. Mei tank oan de skriuwers dy't hjir ek oer neitocht hawwe. Openconnect hat in kaai -pid-bestân, wêrmei jo openconnect ynstruearje kinne om syn prosesidentifikator nei in bestân te skriuwen.
#!/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-pidNo kinne jo altyd in proses deadzje mei it kommando
kill $(cat ~/vpn-pid)As der gjin proses, sil deadzje flokke, mar sil net smyt in flater. As it bestân der net is, sil der ek neat slims barre, dus jo kinne it proses feilich deadzje yn 'e earste rigel fan it skript.
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-pidNo kinne jo jo kompjûter ynskeakelje, de konsole iepenje en it kommando útfiere, it trochjaan fan de koade fan Google Authenticator. De konsole kin dan wurde spikere.
Sûnder VPN-slice. Yn stee fan in neiwurd
It die bliken heul lestich te wêzen om te begripen hoe te libjen sûnder VPN-slice. Ik moast in protte lêze en googleje. Gelokkich, nei't trochbrocht safolle tiid mei in probleem, technyske hânboeken en sels man openconnect lêzen as spannende romans.
As resultaat fûn ik út dat vpn-slice, lykas it native skript, de routingtabel feroaret om netwurken te skieden.
Routing tabel
Om it gewoan te sizzen, dit is in tabel yn 'e earste kolom dy't befettet wêrmei it adres dat Linux wol trochgean moat begjinne mei, en yn' e twadde kolom hokker netwurkadapter op dit adres troch te gean. Eins binne der mear sprekkers, mar dat feroaret net oan de essinsje.
Om de routingtabel te besjen, moatte jo it kommando ip-rûte útfiere
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 Hjir is elke rigel ferantwurdlik foar wêr't jo hinne moatte om in berjocht nei in adres te stjoeren. De earste is in beskriuwing fan wêr't it adres begjinne moat. Om te begripen hoe te bepalen dat 192.168.0.0/16 betsjut dat it adres mei 192.168 begjinne moat, moatte jo googleje wat in IP-adresmasker is. Nei dev is d'r de namme fan 'e adapter wêr't it berjocht nei stjoerd wurde moat.
Foar VPN makke Linux in firtuele adapter - tun0. De line soarget derfoar dat ferkear foar alle adressen begjinnend mei 192.168 der trochhinne giet
192.168.0.0/16 dev tun0 scope link Jo kinne ek sjen nei de aktuele tastân fan de routing tabel mei help fan it kommando rûte -n (IP-adressen binne tûk anonymisearre) Dit kommando produsearret resultaten yn in oare foarm en wurdt oer it generaal ôfkard, mar syn útfier wurdt faak fûn yn hânboeken op it ynternet en jo moatte it lêze kinne.
Wêr't it IP-adres foar in rûte begjinne moat, kin begrepen wurde út 'e kombinaasje fan 'e Destination en Genmask kolommen. Dy dielen fan it IP-adres dy't oerienkomme mei de nûmers 255 yn Genmask wurde rekken holden, mar dy dêr't der 0 binne net. Dat is, de kombinaasje fan bestimming 192.168.0.0 en Genmask 255.255.255.0 betsjut dat as it adres begjint mei 192.168.0, dan sil it fersyk dêrta lâns dizze rûte gean. En as bestimming 192.168.0.0 mar Genmask 255.255.0.0, dan sille fersiken nei adressen dy't begjinne mei 192.168 lâns dizze rûte gean
Om út te finen wat vpn-slice eins docht, besleat ik om te sjen nei de tastân fan 'e tabellen foar en nei
Foardat jo de VPN ynskeakele, wie it sa
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 wlp3s0Nei it oproppen fan openconnect sûnder vpn-slice waard it sa
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 tun0En nei it oproppen fan openconnect yn kombinaasje mei vpn-slice lykas dit
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 tun0It kin sjoen wurde dat as jo gjin vpn-slice brûke, dan skriuwt openconnect eksplisyt dat alle adressen, útsein dy spesifyk oanjûn, moatte wurde tagong fia vpn.
Hjir:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Dêr njonken wurdt daliks in oar paad oanjûn, dat brûkt wurde moat as it adres dat Linux besiket troch te gean, net oerienkomt mei in masker fan 'e tabel.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0It is hjir al skreaun dat jo yn dit gefal in standert Wi-Fi-adapter moatte brûke.
Ik leau dat it VPN-paad wurdt brûkt om't it de earste is yn 'e routingtabel.
En teoretysk, as jo dit standertpaad fan 'e routingtabel fuortsmite, dan moat yn gearhing mei dnsmasq openconnect normale wurking soargje.
ik probearre
route del defaultEn alles wurke.
Rûting fan fersiken nei in e-posttsjinner sûnder vpn-slice
Mar ik haw ek in e-posttsjinner mei it adres 555.555.555.555, dêr't ek fia VPN tagong wurde moat. De rûte dêrhinne moat ek mei de hân tafoege wurde.
ip route add 555.555.555.555 via dev tun0En no is alles goed. Dat jo kinne dwaan sûnder vpn-slice, mar jo moatte goed witte wat jo dogge. Ik tink no oer it tafoegjen oan 'e lêste rigel fan it native openconnect-skript it fuortheljen fan' e standertrûte en it tafoegjen fan in rûte foar de mailer nei it ferbinen mei de vpn, krekt sadat d'r minder bewegende dielen yn myn fyts binne.
Wierskynlik soe dit neiwurd genôch wêze foar ien om te begripen hoe't jo in VPN kinne ynstelle. Mar wylst ik besocht te begripen wat en hoe te dwaan, lies ik in protte fan sokke gidsen dy't wurkje foar de auteur, mar om ien of oare reden net wurkje foar my, en ik besleat om hjir alle stikken ta te foegjen dy't ik fûn. Ik soe tige bliid wêze oer soks.
Boarne: www.habr.com