Ydych chi eisiau defnyddio Linux yn y gwaith, ond ni fydd eich VPN corfforaethol yn gadael i chi? Yna efallai y bydd yr erthygl hon yn helpu, er nad yw hyn yn sicr. Hoffwn eich rhybuddio ymlaen llaw nad wyf yn deall materion gweinyddu rhwydwaith yn dda, felly mae’n bosibl imi wneud popeth o’i le. Ar y llaw arall, mae'n bosibl y gallaf ysgrifennu canllaw yn y fath fodd fel y bydd yn ddealladwy i bobl gyffredin, felly rwy'n eich cynghori i roi cynnig arno.
Mae'r erthygl yn cynnwys llawer o wybodaeth ddiangen, ond heb y wybodaeth hon ni fyddwn wedi gallu datrys y problemau a ymddangosodd yn annisgwyl i mi wrth sefydlu VPN. Credaf y bydd unrhyw un sy'n ceisio defnyddio'r canllaw hwn yn cael problemau nad oedd gennyf, a gobeithio y bydd y wybodaeth ychwanegol hon yn helpu i ddatrys y problemau hyn ar eu pen eu hunain.
Mae angen rhedeg y rhan fwyaf o'r gorchmynion a ddefnyddir yn y canllaw hwn trwy sudo, sydd wedi'i ddileu er mwyn bod yn gryno. Cadwch mewn cof.
Mae'r rhan fwyaf o gyfeiriadau IP wedi'u cuddio'n ddifrifol, felly os gwelwch gyfeiriad fel 435.435.435.435, rhaid bod rhywfaint o IP arferol yno, sy'n benodol i'ch achos.
Mae gen i Ubuntu 18.04, ond rwy'n meddwl gyda mân newidiadau y gellir cymhwyso'r canllaw i ddosbarthiadau eraill. Fodd bynnag, yn y testun hwn Linux == Ubuntu.
Cisco Cyswllt
Gall y rhai sydd ar Windows neu MacOS gysylltu â'n VPN corfforaethol trwy Cisco Connect, sydd angen nodi'r cyfeiriad porth a, bob tro y byddwch chi'n cysylltu, nodi cyfrinair sy'n cynnwys rhan sefydlog a chod a gynhyrchir gan Google Authenticator.
Yn achos Linux, ni allwn gael Cisco Connect i redeg, ond llwyddais i google argymhelliad i ddefnyddio openconnect, a wnaed yn benodol i ddisodli Cisco Connect.
Openconnect
Mewn theori, mae gan Ubuntu ryngwyneb graffigol arbennig ar gyfer openconnect, ond ni weithiodd i mi. Efallai ei fod er gwell.
Ar Ubuntu, gosodir openconnect o'r rheolwr pecyn.
apt install openconnectYn syth ar ôl ei osod, gallwch geisio cysylltu â VPN
openconnect --user poxvuibr vpn.evilcorp.comvpn.evilcorp.com yw cyfeiriad VPN ffug
poxvuibr - enw defnyddiwr ffug
Bydd openconnect yn gofyn ichi nodi cyfrinair, sydd, gadewch imi eich atgoffa, yn cynnwys rhan sefydlog a chod gan Google Authenticator, ac yna bydd yn ceisio cysylltu â'r vpn. Os yw'n gweithio, llongyfarchiadau, gallwch chi hepgor y canol yn ddiogel, sy'n llawer o boen, a symud ymlaen at y pwynt am redeg openconnect yn y cefndir. Os nad yw'n gweithio, yna gallwch barhau. Er pe bai'n gweithio wrth gysylltu, er enghraifft, o Wi-Fi gwestai yn y gwaith, yna gall fod yn rhy gynnar i lawenhau; dylech geisio ailadrodd y weithdrefn gartref.
Tystysgrif
Mae tebygolrwydd uchel na fydd unrhyw beth yn dechrau, a bydd allbwn openconnect yn edrych fel hyn:
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 progressAr y naill law, mae hyn yn annymunol, oherwydd nid oedd unrhyw gysylltiad â'r VPN, ond ar y llaw arall, mae sut i ddatrys y broblem hon, mewn egwyddor, yn glir.
Yma anfonodd y gweinydd dystysgrif atom, lle gallwn benderfynu bod y cysylltiad yn cael ei wneud â gweinydd ein corfforaeth frodorol, ac nid â thwyllwr drwg, ac nid yw'r dystysgrif hon yn hysbys i'r system. Ac felly ni all hi wirio a yw'r gweinydd yn real ai peidio. Ac felly, rhag ofn, mae'n rhoi'r gorau i weithio.
Er mwyn i openconnect gysylltu â'r gweinydd, mae angen i chi ddweud yn benodol pa dystysgrif ddylai ddod o'r gweinydd VPN gan ddefnyddio'r allwedd —servercert
A gallwch ddarganfod pa dystysgrif a anfonodd y gweinydd atom yn uniongyrchol o'r hyn a argraffwyd gan openconnect. Dyma o'r darn yma:
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 progressGyda'r gorchymyn hwn gallwch geisio cysylltu eto
openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.comEfallai nawr ei fod yn gweithio, yna gallwch chi symud ymlaen i'r diwedd. Ond yn bersonol, dangosodd Ubunta ffigys i mi yn y ffurf hon
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.combydd habr.com yn datrys, ond ni fyddwch yn gallu mynd yno. Nid yw cyfeiriadau fel jira.evilcorp.com yn cael eu datrys o gwbl.
Nid yw'r hyn a ddigwyddodd yma yn glir i mi. Ond mae arbrawf yn dangos os ydych chi'n ychwanegu'r llinell at /etc/resolv.conf
nameserver 192.168.430.534yna bydd y cyfeiriadau y tu mewn i'r VPN yn dechrau datrys yn hudol a gallwch gerdded trwyddynt, hynny yw, mae'r hyn y mae DNS yn edrych amdano i ddatrys cyfeiriadau yn edrych yn benodol yn /etc/resolv.conf, ac nid yn rhywle arall.
Gallwch wirio bod cysylltiad â'r VPN a'i fod yn gweithio heb wneud unrhyw newidiadau i /etc/resolv.conf; i wneud hyn, nodwch yn y porwr nid enw symbolaidd yr adnodd o'r VPN, ond ei gyfeiriad IP
O ganlyniad, mae dwy broblem
- Wrth gysylltu â VPN, nid yw ei dns yn cael ei nodi
- mae'r holl draffig yn mynd trwy VPN, nad yw'n caniatáu mynediad i'r Rhyngrwyd
Fe ddywedaf wrthych beth i'w wneud nawr, ond ychydig o awtomeiddio yn gyntaf.
Mynediad awtomatig o ran sefydlog y cyfrinair
Erbyn hyn, mae'n debyg eich bod eisoes wedi nodi'ch cyfrinair o leiaf bum gwaith ac mae'r weithdrefn hon eisoes wedi eich blino. Yn gyntaf, oherwydd bod y cyfrinair yn hir, ac yn ail, oherwydd wrth fynd i mewn mae angen i chi ffitio o fewn cyfnod amser penodol
Ni chynhwyswyd yr ateb terfynol i'r broblem yn yr erthygl, ond gallwch wneud yn siŵr nad oes angen nodi rhan sefydlog y cyfrinair sawl gwaith.
Gadewch i ni dybio bod rhan sefydlog y cyfrinair yn fixedPassword, a'r rhan o Google Authenticator yw 567. Gellir trosglwyddo'r cyfrinair cyfan i openconnect trwy fewnbwn safonol gan ddefnyddio'r ddadl --passwd-on-stdin.
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdinNawr gallwch chi ddychwelyd yn gyson i'r gorchymyn a gofnodwyd ddiwethaf a newid dim ond rhan o Google Authenticator yno.
Nid yw VPN corfforaethol yn caniatáu ichi syrffio'r Rhyngrwyd.
Yn gyffredinol, nid yw'n anghyfleus iawn pan fydd yn rhaid i chi ddefnyddio cyfrifiadur ar wahân i fynd i Habr. Yn gyffredinol, gall yr anallu i gopïo-bastio o stackoverfow barlysu gwaith, felly mae angen gwneud rhywbeth.
Mae angen i ni ei drefnu rywsut fel bod Linux yn mynd i'r VPN pan fydd angen i chi gael mynediad at adnodd o'r rhwydwaith mewnol, a phan fydd angen i chi fynd i Habr, mae'n mynd i'r Rhyngrwyd.
Mae openconnect, ar ôl lansio a sefydlu cysylltiad â vpn, yn gweithredu sgript arbennig, sydd wedi'i lleoli yn /usr/share/vpnc-scripts/vpnc-script. Mae rhai newidynnau yn cael eu trosglwyddo i'r sgript fel mewnbwn, ac mae'n ffurfweddu'r VPN. Yn anffodus, ni allwn ddarganfod sut i rannu llif traffig rhwng VPN corfforaethol a gweddill y Rhyngrwyd gan ddefnyddio sgript frodorol.
Yn ôl pob tebyg, datblygwyd y cyfleustodau vpn-sleis yn arbennig ar gyfer pobl fel fi, sy'n eich galluogi i anfon traffig trwy ddwy sianel heb ddawnsio gyda thambwrîn. Wel, hynny yw, bydd yn rhaid i chi ddawnsio, ond nid oes rhaid i chi fod yn siaman.
Gwahanu traffig gan ddefnyddio vpn-sleis
Yn gyntaf, bydd yn rhaid i chi osod vpn-sleisen, bydd yn rhaid i chi ddarganfod hyn eich hun. Os oes cwestiynau yn y sylwadau, byddaf yn ysgrifennu post ar wahân am hyn. Ond mae hon yn rhaglen Python reolaidd, felly ni ddylai fod unrhyw anawsterau. Fe wnes i osod gan ddefnyddio virtualenv.
Ac yna mae'n rhaid cymhwyso'r cyfleustodau, gan ddefnyddio'r switsh -script, gan nodi i openconnect bod angen i chi ddefnyddio vpn-slice yn lle'r sgript safonol
echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr --passwd-on-stdin
--script "./bin/vpn-slice 192.168.430.0/24 " vpn.evilcorp.com Mae --script yn cael ei basio llinyn gyda gorchymyn y mae angen ei alw yn lle'r sgript. ./bin/vpn-slice - llwybr i'r ffeil gweithredadwy sleis vpn 192.168.430.0/24 - mwgwd o gyfeiriadau i fynd iddynt yn vpn. Yma, rydym yn golygu, os yw'r cyfeiriad yn dechrau gyda 192.168.430, yna mae angen chwilio'r adnodd gyda'r cyfeiriad hwn y tu mewn i'r VPN
Dylai'r sefyllfa fod bron yn normal erbyn hyn. Bron. Nawr gallwch chi fynd i Habr a gallwch chi fynd i'r adnodd rhyng-gorfforaethol trwy ip, ond ni allwch chi fynd i'r adnodd rhyng-gorfforaethol yn ôl enw symbolaidd. Os byddwch yn nodi cyfatebiaeth rhwng yr enw symbolaidd a'r cyfeiriad yn y gwesteiwyr, dylai popeth weithio. A gweithio nes bod yr ip yn newid. Gall Linux bellach gael mynediad i'r Rhyngrwyd neu'r fewnrwyd, yn dibynnu ar yr IP. Ond mae DNS anghorfforaethol yn dal i gael ei ddefnyddio i bennu'r cyfeiriad.
Gall y broblem hefyd amlygu ei hun yn y ffurflen hon - yn y gwaith mae popeth yn iawn, ond gartref dim ond trwy IP y gallwch chi gael mynediad at adnoddau corfforaethol mewnol. Mae hyn oherwydd pan fyddwch chi'n gysylltiedig â Wi-Fi corfforaethol, mae'r DNS corfforaethol hefyd yn cael ei ddefnyddio, ac mae cyfeiriadau symbolaidd o'r VPN yn cael eu datrys ynddo, er gwaethaf y ffaith ei bod yn dal yn amhosibl mynd i gyfeiriad o'r fath heb ddefnyddio VPN.
Addasiad awtomatig o'r ffeil gwesteiwr
Os gofynnir yn gwrtais i vpn-slice, yna ar ôl codi'r VPN, gall fynd i'w DNS, dod o hyd i gyfeiriadau IP yr adnoddau angenrheidiol wrth eu henwau symbolaidd a'u nodi yn y gwesteiwyr. Ar ôl diffodd y VPN, bydd y cyfeiriadau hyn yn cael eu tynnu oddi ar westeion. I wneud hyn, mae angen i chi drosglwyddo enwau symbolaidd i vpn-slice fel dadleuon. Fel hyn.
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 Nawr dylai popeth weithio yn y swyddfa ac ar y traeth.
Chwiliwch am gyfeiriadau pob is-faes yn y DNS a roddir gan y VPN
Os nad oes llawer o gyfeiriadau o fewn y rhwydwaith, yna mae'r dull o addasu'r ffeil gwesteiwr yn awtomatig yn gweithio'n eithaf da. Ond os oes llawer o adnoddau ar y rhwydwaith, yna bydd angen i chi ychwanegu llinellau fel zoidberg.test.evilcorp.com yn gyson at y sgript Zoidberg yw enw un o'r meinciau prawf.
Ond nawr ein bod yn deall ychydig pam y gellir dileu'r angen hwn.
Os, ar ôl codi'r VPN, rydych chi'n edrych i mewn /etc/hosts, gallwch weld y llinell hon
192.168.430.534 dns0.tun0 # vpn-slice-tun0 AUTOCREATED
Ac ychwanegwyd llinell newydd i resolv.conf. Yn fyr, roedd vpn-slice rywsut yn penderfynu ble mae gweinydd dns ar gyfer y vpn wedi'i leoli.
Nawr mae angen i ni sicrhau, er mwyn darganfod cyfeiriad IP enw parth sy'n gorffen yn evilcorp.com, bod Linux yn mynd i'r DNS corfforaethol, ac os oes angen rhywbeth arall, yna i'r un rhagosodedig.
Fe wnes i Googled ers cryn amser a chanfod bod ymarferoldeb o'r fath ar gael yn Ubuntu allan o'r bocs. Mae hyn yn golygu'r gallu i ddefnyddio'r gweinydd DNS lleol dnsmasq i ddatrys enwau.
Hynny yw, gallwch chi sicrhau bod Linux bob amser yn mynd i'r gweinydd DNS lleol ar gyfer cyfeiriadau IP, a fydd yn ei dro, yn dibynnu ar yr enw parth, yn edrych am yr IP ar y gweinydd DNS allanol cyfatebol.
I reoli popeth sy'n ymwneud â rhwydweithiau a chysylltiadau rhwydwaith, mae Ubuntu yn defnyddio NetworkManager, ac mae'r rhyngwyneb graffigol ar gyfer dewis, er enghraifft, cysylltiadau Wi-Fi yn ben blaen iddo.
Bydd angen inni ddringo yn ei ffurfwedd.
- Creu ffeil yn /etc/NetworkManager/dnsmasq.d/evilcorp
cyfeiriad=/.evilcorp.com/192.168.430.534
Rhowch sylw i'r pwynt o flaen evilcorp. Mae'n arwydd o dnsmasq y dylid chwilio holl is-barthau evilcorp.com yn y dns corfforaethol.
- Dywedwch wrth NetworkManager i ddefnyddio dnsmasq i ddatrys yr enw
Mae'r ffurfweddiad rhwydwaith-rheolwr wedi'i leoli yn /etc/NetworkManager/NetworkManager.conf Mae angen i chi ychwanegu yno:
[prif] dns=dnsmasq
- Ailgychwyn NetworkManager
service network-manager restartNawr, ar ôl cysylltu â VPN gan ddefnyddio openconnect a vpn-slice, bydd yr ip yn cael ei bennu fel arfer, hyd yn oed os na fyddwch yn ychwanegu cyfeiriadau symbolaidd at y dadleuon i vpnslice.
Sut i gael mynediad at wasanaethau unigol trwy VPN
Ar ôl i mi lwyddo i gysylltu â'r VPN, roeddwn i'n hapus iawn am ddau ddiwrnod, ac yna os byddaf yn cysylltu â'r VPN o'r tu allan i rwydwaith y swyddfa, yna nid yw post yn gweithio. Mae'r symptom yn gyfarwydd, ynte?
Mae ein post wedi'i leoli yn mail.publicevilcorp.com, sy'n golygu nad yw'n dod o dan y rheol yn dnsmasq ac mae cyfeiriad y gweinydd post yn cael ei chwilio trwy DNS cyhoeddus.
Wel, mae'r swyddfa'n dal i ddefnyddio DNS, sy'n cynnwys y cyfeiriad hwn. Dyna beth oeddwn i'n ei feddwl. Yn wir, ar ôl ychwanegu'r llinell at dnsmasq
cyfeiriad=/mail.publicevilcorp.com/192.168.430.534
nid yw’r sefyllfa wedi newid o gwbl. ip aros yr un fath. Roedd yn rhaid i mi fynd i'r gwaith.
A dim ond yn ddiweddarach, pan wnes i ymchwilio'n ddyfnach i'r sefyllfa a deall y broblem ychydig, dywedodd un person craff wrthyf sut i'w datrys. Roedd angen cysylltu â'r gweinydd post nid yn unig fel hynny, ond trwy VPN
Rwy'n defnyddio vpn-slice i fynd trwy'r VPN i gyfeiriadau sy'n dechrau gyda 192.168.430. Ac nid yn unig y mae gan y gweinydd post gyfeiriad symbolaidd nad yw'n is-barth o evilcorp, nid oes ganddo hefyd gyfeiriad IP sy'n dechrau gyda 192.168.430. Ac wrth gwrs nid yw'n caniatáu i unrhyw un o'r rhwydwaith cyffredinol ddod ato.
Er mwyn i Linux fynd trwy'r VPN ac at y gweinydd post, mae angen i chi ei ychwanegu at vpn-slice hefyd. Gadewch i ni ddweud mai cyfeiriad y postiwr yw 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 Sgript ar gyfer codi VPN gydag un ddadl
Nid yw hyn i gyd, wrth gwrs, yn gyfleus iawn. Gallwch, gallwch arbed y testun i ffeil a'i gopïo-gludo i'r consol yn lle ei deipio â llaw, ond nid yw'n ddymunol iawn o hyd. I wneud y broses yn haws, gallwch lapio'r gorchymyn mewn sgript a fydd wedi'i lleoli yn PATH. Ac yna dim ond y cod a dderbyniwyd gan Google Authenticator fydd angen i chi ei nodi
#!/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 Os rhowch y sgript yn connect~evilcorp~ gallwch ysgrifennu yn y consol
connect_evil_corp 567987Ond nawr mae'n rhaid i chi gadw'r consol lle mae openconnect yn rhedeg ar agor am ryw reswm
Yn rhedeg openconnect yn y cefndir
Yn ffodus, fe wnaeth awduron openconnect ofalu amdanom ac ychwanegu allwedd arbennig i'r rhaglen -background, sy'n gwneud i'r rhaglen weithio yn y cefndir ar ôl ei lansio. Os ydych chi'n ei redeg fel hyn, gallwch chi gau'r consol ar ôl ei lansio
#!/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 Nawr nid yw'n glir i ble mae'r logiau'n mynd. Yn gyffredinol, nid oes gwir angen logiau arnom, ond ni wyddoch chi byth. gall openconnect eu hailgyfeirio i syslog, lle byddant yn cael eu cadw'n ddiogel. mae angen i chi ychwanegu'r switsh -syslog i'r gorchymyn
#!/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 Ac felly, mae'n ymddangos bod openconnect yn gweithio yn rhywle yn y cefndir ac nad yw'n poeni unrhyw un, ond nid yw'n glir sut i'w atal. Hynny yw, gallwch chi, wrth gwrs, hidlo'r allbwn ps gan ddefnyddio grep a chwilio am broses y mae ei henw yn cynnwys openconnect, ond mae hyn rywsut yn ddiflas. Diolch i'r awduron a feddyliodd am hyn hefyd. Mae gan Openconnect ffeil -pid-allwedd, y gallwch chi gyfarwyddo openconnect i ysgrifennu ei ddynodwr proses i ffeil.
#!/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-pidNawr gallwch chi bob amser ladd proses gyda'r gorchymyn
kill $(cat ~/vpn-pid)Os nad oes proses, bydd lladd yn melltithio, ond ni fydd yn taflu gwall. Os nad yw'r ffeil yno, yna ni fydd unrhyw beth drwg yn digwydd ychwaith, felly gallwch chi ladd y broses yn ddiogel yn llinell gyntaf y sgript.
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-pidNawr gallwch chi droi eich cyfrifiadur ymlaen, agor y consol a rhedeg y gorchymyn, gan basio'r cod gan Google Authenticator iddo. Yna gellir hoelio'r consol i lawr.
Heb VPN-sleisen. Yn lle ôl-air
Trodd allan i fod yn anodd iawn deall sut i fyw heb VPN-sleis. Roedd yn rhaid i mi ddarllen a google llawer. Yn ffodus, ar ôl treulio cymaint o amser gyda phroblem, mae llawlyfrau technegol a hyd yn oed dyn openconnect yn darllen fel nofelau cyffrous.
O ganlyniad, darganfyddais fod vpn-slice, fel y sgript brodorol, yn addasu'r tabl llwybro i rwydweithiau ar wahân.
Bwrdd llwybro
I'w roi yn syml, dyma dabl yn y golofn gyntaf sy'n cynnwys yr hyn y dylai'r cyfeiriad y mae Linux eisiau mynd drwyddo ddechrau, ac yn yr ail golofn pa addasydd rhwydwaith i fynd drwyddo yn y cyfeiriad hwn. Mewn gwirionedd, mae mwy o siaradwyr, ond nid yw hyn yn newid y hanfod.
Er mwyn gweld y tabl llwybro, mae angen i chi redeg y gorchymyn llwybr ip
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 Yma, mae pob llinell yn gyfrifol am ble mae angen i chi fynd er mwyn anfon neges i ryw gyfeiriad. Mae'r cyntaf yn ddisgrifiad o ble y dylai'r cyfeiriad ddechrau. Er mwyn deall sut i benderfynu bod 192.168.0.0/16 yn golygu y dylai'r cyfeiriad ddechrau gyda 192.168, mae angen ichi google beth yw mwgwd cyfeiriad IP. Ar ôl dev mae enw'r addasydd y dylid anfon y neges ato.
Ar gyfer VPN, gwnaeth Linux addasydd rhithwir - tun0. Mae'r llinell yn sicrhau bod traffig ar gyfer pob cyfeiriad sy'n dechrau gyda 192.168 yn mynd drwyddo
192.168.0.0/16 dev tun0 scope link Gallwch hefyd edrych ar gyflwr presennol y tabl llwybro gan ddefnyddio'r gorchymyn llwybr -n (Mae cyfeiriadau IP yn ddienw yn glyfar) Mae'r gorchymyn hwn yn cynhyrchu canlyniadau mewn ffurf wahanol ac yn gyffredinol mae'n anghymeradwy, ond mae ei allbwn i'w gael yn aml mewn llawlyfrau ar y Rhyngrwyd ac mae angen i chi allu ei ddarllen.
Gellir deall ble y dylai cyfeiriad IP llwybr gychwyn o'r cyfuniad o'r colofnau Cyrchfan a Genmask. Mae'r rhannau hynny o'r cyfeiriad IP sy'n cyfateb i'r rhifau 255 yn Genmask yn cael eu hystyried, ond nid yw'r rhai lle mae 0 yn cael eu hystyried. Hynny yw, mae'r cyfuniad o Gyrchfan 192.168.0.0 a Genmask 255.255.255.0 yn golygu, os yw'r cyfeiriad yn dechrau gyda 192.168.0, yna bydd y cais iddo yn mynd ar hyd y llwybr hwn. Ac os yw Cyrchfan 192.168.0.0 ond Genmask 255.255.0.0, yna bydd ceisiadau am gyfeiriadau sy'n dechrau gyda 192.168 yn mynd ar hyd y llwybr hwn
Er mwyn darganfod beth mae vpn-slice yn ei wneud mewn gwirionedd, penderfynais edrych ar gyflwr y tablau cyn ac ar ôl
Cyn troi'r VPN ymlaen roedd fel hyn
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 wlp3s0Ar ôl galw openconnect heb vpn-sleis daeth fel hyn
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 tun0Ac ar ôl galw openconnect mewn cyfuniad â vpn-sleisen fel hyn
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 tun0Gellir gweld, os nad ydych yn defnyddio vpn-slice, yna mae openconnect yn ysgrifennu'n benodol bod yn rhaid cyrchu pob cyfeiriad, ac eithrio'r rhai a nodir yn benodol, trwy vpn.
Reit yma:
0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 0 tun0Yno, wrth ei ymyl, nodir llwybr arall ar unwaith, y mae'n rhaid ei ddefnyddio os nad yw'r cyfeiriad y mae Linux yn ceisio mynd trwyddo yn cyfateb i unrhyw fwgwd o'r bwrdd.
0.0.0.0 222.222.222.1 0.0.0.0 UG 600 0 0 wlp3s0Mae eisoes wedi'i ysgrifennu yma bod angen i chi ddefnyddio addasydd Wi-Fi safonol yn yr achos hwn.
Rwy'n credu bod y llwybr VPN yn cael ei ddefnyddio oherwydd dyma'r un cyntaf yn y tabl llwybro.
Ac yn ddamcaniaethol, os ydych chi'n tynnu'r llwybr rhagosodedig hwn o'r tabl llwybro, yna ar y cyd â dnsmasq openconnect dylai sicrhau gweithrediad arferol.
Ceisiais
route del defaultAc fe weithiodd popeth.
Llwybro ceisiadau i weinydd post heb vpn-slice
Ond mae gen i weinydd post hefyd gyda'r cyfeiriad 555.555.555.555, sydd hefyd angen ei gyrchu trwy VPN. Mae angen ychwanegu'r llwybr ato â llaw hefyd.
ip route add 555.555.555.555 via dev tun0Ac yn awr mae popeth yn iawn. Felly gallwch chi wneud heb vpn-sleis, ond mae angen i chi wybod yn dda beth rydych chi'n ei wneud. Rwyf nawr yn meddwl am ychwanegu at linell olaf y sgript openconnect brodorol dileu'r llwybr rhagosodedig ac ychwanegu llwybr ar gyfer y postiwr ar ôl cysylltu â'r vpn, dim ond fel bod llai o rannau symudol yn fy meic.
Yn ôl pob tebyg, byddai'r ôl-air hwn yn ddigon i rywun ddeall sut i sefydlu VPN. Ond tra roeddwn yn ceisio deall beth a sut i wneud, darllenais gryn dipyn o ganllawiau o'r fath sy'n gweithio i'r awdur, ond am ryw reswm nad ydynt yn gweithio i mi, a phenderfynais ychwanegu yma'r holl ddarnau a ddarganfyddais. Byddwn yn hapus iawn am rywbeth felly.
Ffynhonnell: hab.com