Hvernig á að tengjast fyrirtækis VPN í Linux með openconnect og vpn-sneið

Viltu nota Linux í vinnunni en VPN fyrirtækis þíns leyfir þér það ekki? Þá gæti þessi grein hjálpað, þó það sé ekki víst. Ég vil vara þig við því fyrirfram að ég skil illa netstjórnunarmál, svo það er mögulegt að ég hafi gert allt vitlaust. Hins vegar er hugsanlegt að ég geti skrifað leiðarvísi þannig að hann verði skiljanlegur fyrir venjulegt fólk, svo ég ráðlegg þér að prófa hann.

Greinin inniheldur mikið af óþarfa upplýsingum, en án þessarar vitneskju hefði ég ekki getað leyst vandamálin sem komu mér óvænt upp við að setja upp VPN. Ég held að allir sem reyna að nota þessa handbók muni eiga í vandræðum sem ég átti ekki við og ég vona að þessar auka upplýsingar hjálpi til við að leysa þessi vandamál á eigin spýtur.

Flestar skipanirnar sem notaðar eru í þessari handbók þarf að keyra í gegnum sudo, sem hefur verið fjarlægt í stuttu máli. Hafa í huga.

Flestar IP tölur hafa verið alvarlega óljósar, þannig að ef þú sérð vistfang eins og 435.435.435.435, þá hlýtur það að vera einhver eðlilegur IP þar, sérstaklega við þitt tilvik.

Ég er með Ubuntu 18.04, en ég held að með smávægilegum breytingum sé hægt að nota leiðbeiningarnar á aðrar dreifingar. Hins vegar, í þessum texta Linux == Ubuntu.

Cisco Connect

Þeir sem eru á Windows eða MacOS geta tengst fyrirtækja VPN okkar í gegnum Cisco Connect, sem þarf að tilgreina gáttar heimilisfangið og, í hvert skipti sem þú tengist, slá inn lykilorð sem samanstendur af föstum hluta og kóða sem myndaður er af Google Authenticator.

Í tilfelli Linux gat ég ekki komið Cisco Connect í gang, en mér tókst að googla tilmæli um að nota openconnect, sérstaklega gerð til að koma í stað Cisco Connect.

Openconnect

Fræðilega séð hefur Ubuntu sérstakt grafískt viðmót fyrir openconnect, en það virkaði ekki fyrir mig. Kannski er það til bóta.

Á Ubuntu er openconnect sett upp frá pakkastjóranum.

apt install openconnect

Strax eftir uppsetningu geturðu prófað að tengjast VPN

openconnect --user poxvuibr vpn.evilcorp.com

vpn.evilcorp.com er heimilisfang skáldaðs VPN
poxvuibr - tilbúið notendanafn

openconnect mun biðja þig um að slá inn lykilorð, sem, að mig minnir, samanstendur af föstum hluta og kóða frá Google Authenticator, og þá mun það reyna að tengjast vpn. Ef það virkar, til hamingju, geturðu örugglega sleppt miðjunni, sem er mikill sársauki, og haldið áfram að benda á openconnect sem keyrir í bakgrunni. Ef það virkar ekki, þá geturðu haldið áfram. Þó að ef það virkaði við tengingu, til dæmis frá Wi-Fi gesta í vinnunni, þá gæti verið of snemmt að gleðjast; þú ættir að reyna að endurtaka ferlið að heiman.

Vottorð

Það eru miklar líkur á því að ekkert fari í gang og openconnect úttakið mun líta einhvern veginn svona út:

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 progress

Annars vegar er þetta óþægilegt, vegna þess að það var engin tenging við VPN, en hins vegar er í grundvallaratriðum ljóst hvernig eigi að laga þetta vandamál.

Hér sendi þjónninn okkur vottorð, þar sem við getum komist að því að tengingin sé gerð við miðlara innfædds fyrirtækis okkar, en ekki við vondan svindlara, og þetta vottorð er óþekkt fyrir kerfið. Og þess vegna getur hún ekki athugað hvort þjónninn sé raunverulegur eða ekki. Og svo, bara ef það hættir að virka.

Til þess að openconnect geti tengst netþjóninum þarftu að segja honum sérstaklega hvaða vottorð ætti að koma frá VPN netþjóninum með því að nota —servercert lykilinn

Og þú getur fundið út hvaða vottorð þjónninn sendi okkur beint frá því sem openconnect prentaði. Hér er úr þessu stykki:

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 progress

Með þessari skipun geturðu reynt að tengjast aftur

openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com

Kannski er það núna að virka, þá geturðu haldið áfram til enda. En persónulega sýndi Ubuntu mér fíkju í þessu formi

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.com

habr.com mun leysa, en þú munt ekki geta farið þangað. Heimilisföng eins og jira.evilcorp.com eru alls ekki leyst.

Hvað gerðist hér er mér ekki ljóst. En tilraun sýnir að ef þú bætir línunni við /etc/resolv.conf

nameserver 192.168.430.534

þá munu vistföngin inni í VPN byrja að leysast á töfrandi hátt og þú getur gengið í gegnum þau, það er, það sem DNS er að leita að til að leysa heimilisföng lítur sérstaklega út í /etc/resolv.conf, en ekki einhvers staðar annars staðar.

Þú getur staðfest að það sé tenging við VPN og það virkar án þess að gera breytingar á /etc/resolv.conf; til að gera þetta skaltu bara slá inn í vafrann ekki táknrænt nafn auðlindarinnar frá VPN, heldur IP tölu þess

Þar af leiðandi eru tvö vandamál

  • Þegar þú tengist VPN er dns þess ekki tekið upp
  • öll umferð fer í gegnum VPN, sem leyfir ekki aðgang að internetinu

Ég skal segja þér hvað þú átt að gera núna, en fyrst smá sjálfvirkni.

Sjálfvirk færsla á fasta hluta lykilorðsins

Núna hefur þú líklega þegar slegið inn lykilorðið þitt að minnsta kosti fimm sinnum og þessi aðferð hefur þegar þreytt þig. Í fyrsta lagi vegna þess að lykilorðið er langt og í öðru lagi vegna þess að þegar þú ferð inn þarftu að passa innan ákveðins tíma

Endanleg lausn á vandanum var ekki innifalin í greininni, en þú getur tryggt að fasta hluta lykilorðsins þurfi ekki að slá inn oft.

Segjum að fasti hluti lykilorðsins sé fixedPassword og hluti frá Google Authenticator sé 567 987. Hægt er að senda allt lykilorðið til openconnect með venjulegu inntaki með því að nota röksemdin --passwd-on-stdin .

echo "fixedPassword567987" | openconnect --servercert sha256:4444444444444444444444444444444444444444444444444444444444444444 --user poxvuibr vpn.evilcorp.com --passwd-on-stdin

Nú geturðu stöðugt farið aftur í síðustu innslögðu skipunina og aðeins breytt hluta af Google Authenticator þar.

VPN fyrirtækja leyfir þér ekki að vafra á netinu.

Almennt séð er það ekki mjög óþægilegt þegar þú þarft að nota sérstaka tölvu til að fara í Habr. Vanhæfni til að copy-paste frá stackoverfow getur almennt lamað vinnu, svo eitthvað þarf að gera.

Við þurfum einhvern veginn að skipuleggja það þannig að þegar þú þarft að fá aðgang að auðlind frá innra netinu fer Linux í VPN og þegar þú þarft að fara á Habr fer það á internetið.

openconnect, eftir að hafa ræst og komið á tengingu við vpn, keyrir sérstakt handrit, sem er staðsett í /usr/share/vpnc-scripts/vpnc-script. Sumar breytur eru sendar til handritsins sem inntak og það stillir VPN. Því miður gat ég ekki fundið út hvernig á að skipta umferðarflæði á milli VPN fyrirtækja og restina af internetinu með innfæddu handriti.

Svo virðist sem vpn-slice tólið var þróað sérstaklega fyrir fólk eins og mig, sem gerir þér kleift að senda umferð í gegnum tvær rásir án þess að dansa við tambúrínu. Jæja, það er, þú verður að dansa, en þú þarft ekki að vera shaman.

Aðskilnaður umferðar með vpn-sneið

Í fyrsta lagi verður þú að setja upp vpn-sneið, þú verður að finna út úr þessu sjálfur. Ef það eru spurningar í athugasemdunum mun ég skrifa sérstaka færslu um þetta. En þetta er venjulegt Python forrit, svo það ættu ekki að vera neinir erfiðleikar. Ég setti upp með því að nota virtualenv.

Og þá verður að nota tólið, með því að nota -script rofann, sem gefur til kynna að openconnect sé að í stað venjulegs forskriftar þarftu að nota 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 fær streng með skipun sem þarf að kalla í stað skriftunnar. ./bin/vpn-slice - slóð að vpn-slice keyrsluskránni 192.168.430.0/24 - maska ​​af vistföngum til að fara á í vpn. Hér er átt við að ef heimilisfangið byrjar á 192.168.430, þá þarf að leita að auðlindinni með þetta heimilisfang inni í VPN

Ástandið ætti nú að vera nánast eðlilegt. Næstum. Nú geturðu farið í Habr og þú getur farið í auðlind innan fyrirtækis með ip, en þú getur ekki farið í auðlind innan fyrirtækis með táknrænu nafni. Ef þú tilgreinir samsvörun milli táknræns nafns og heimilisfangs í vélum ætti allt að virka. Og vinna þar til ip breytist. Linux getur nú nálgast internetið eða innra netið, allt eftir IP. En DNS sem ekki er fyrirtæki er enn notað til að ákvarða heimilisfangið.

Vandamálið getur líka komið fram í þessu formi - í vinnunni er allt í lagi, en heima geturðu aðeins fengið aðgang að innri fyrirtækjaauðlindum í gegnum IP. Þetta er vegna þess að þegar þú ert tengdur við fyrirtækis Wi-Fi er fyrirtækis DNS einnig notað og táknræn vistföng frá VPN eru leyst í því, þrátt fyrir að það sé enn ómögulegt að fara á slíkt heimilisfang án þess að nota VPN.

Sjálfvirk breyting á hýsingarskránni

Ef VPN-sneið er beðið kurteislega, þá getur það, eftir að VPN hefur verið hækkað, farið á DNS þess, fundið þar IP tölur nauðsynlegra auðlinda með táknrænum nöfnum þeirra og slegið þær inn í hýsingaraðila. Eftir að slökkt hefur verið á VPN verða þessi vistföng fjarlægð af gestgjöfum. Til að gera þetta þarftu að senda táknræn nöfn til vpn-slice sem rök. Svona.

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 

Nú ætti allt að virka bæði á skrifstofunni og á ströndinni.

Leitaðu að heimilisföngum allra undirléna í DNS sem VPN gefur upp

Ef það eru fá heimilisföng innan netsins, þá virkar aðferðin við að breyta hýsingarskránni sjálfkrafa nokkuð vel. En ef það er mikið af auðlindum á netinu, þá þarftu stöðugt að bæta línum eins og zoidberg.test.evilcorp.com við handritið zoidberg er nafnið á einum af prófbekkjunum.

En núna þegar við skiljum svolítið hvers vegna hægt er að útrýma þessari þörf.

Ef þú lítur í /etc/hosts eftir að þú hefur hækkað VPN, geturðu séð þessa línu

192.168.430.534 dns0.tun0 # vpn-sneið-tun0 SJÁLFSTOFNAÐUR

Og nýrri línu var bætt við resolv.conf. Í stuttu máli, vpn-sneið ákvað einhvern veginn hvar dns netþjónninn fyrir VPN er staðsettur.

Nú þurfum við að ganga úr skugga um að til að finna út IP tölu léns sem endar á evilcorp.com fer Linux í DNS fyrirtækja og ef eitthvað annað er þörf, þá í sjálfgefið.

Ég gúglaði í nokkurn tíma og komst að því að slík virkni er fáanleg í Ubuntu strax. Þetta þýðir að hægt er að nota staðbundna DNS netþjóninn dnsmasq til að leysa nöfn.

Það er, þú getur gengið úr skugga um að Linux fari alltaf á staðbundna DNS-þjóninn fyrir IP-tölur, sem aftur, allt eftir léninu, mun leita að IP-inu á samsvarandi ytri DNS-þjóni.

Til að stjórna öllu sem tengist netkerfum og nettengingum notar Ubuntu NetworkManager og grafíska viðmótið til að velja til dæmis Wi-Fi tengingar er bara framhlið þess.

Við verðum að klifra upp í stillingu þess.

  1. Búðu til skrá í /etc/NetworkManager/dnsmasq.d/evilcorp

address=/.evilcorp.com/192.168.430.534

Gefðu gaum að punktinum fyrir framan evilcorp. Það gefur til kynna dnsmasq að leita ætti í öllum undirlénum evilcorp.com í fyrirtækjadns.

  1. Segðu NetworkManager að nota dnsmasq fyrir nafnaupplausn

Stilling netstjórans er staðsett í /etc/NetworkManager/NetworkManager.conf Þú þarft að bæta við þar:

[aðal] dns=dnsmasq

  1. Endurræstu NetworkManager

service network-manager restart

Nú, eftir að hafa tengst VPN með openconnect og vpn-slice, verður ip-talan ákvörðuð venjulega, jafnvel þótt þú bætir ekki táknrænum heimilisföngum við rökin við vpnslice.

Hvernig á að fá aðgang að einstökum þjónustum í gegnum VPN

Eftir að ég náði að tengjast VPN var ég mjög ánægður í tvo daga og þá kom í ljós að ef ég tengist VPN utan skrifstofunetsins þá virkar pósturinn ekki. Einkennin eru kunnugleg, er það ekki?

Pósturinn okkar er staðsettur á mail.publicevilcorp.com, sem þýðir að hann fellur ekki undir regluna í dnsmasq og netfang póstþjónsins er leitað í gegnum opinbert DNS.

Jæja, skrifstofan notar enn DNS, sem inniheldur þetta heimilisfang. Það er það sem ég hélt. Reyndar, eftir að hafa bætt línunni við dnsmasq

address=/mail.publicevilcorp.com/192.168.430.534

ástandið hefur ekkert breyst. ip var óbreytt. Ég varð að fara að vinna.

Og aðeins seinna, þegar ég kafaði dýpra í stöðuna og skildi vandamálið aðeins, sagði einn klár manneskja mér hvernig ég ætti að leysa það. Það var nauðsynlegt að tengjast póstþjóninum ekki bara þannig heldur í gegnum VPN

Ég nota vpn-sneið til að fara í gegnum VPN á netföng sem byrja á 192.168.430. Og póstþjónninn hefur ekki aðeins táknrænt heimilisfang sem er ekki undirlén evilcorp, hann hefur heldur ekki IP tölu sem byrjar á 192.168.430. Og auðvitað leyfir hann engum frá hinu almenna neti að koma til sín.

Til þess að Linux geti farið í gegnum VPN og á póstþjóninn þarftu að bæta því við vpn-slice líka. Segjum að heimilisfang sendanda sé 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 

Forskrift til að hækka VPN með einum rökum

Allt þetta er auðvitað ekki mjög þægilegt. Já, þú getur vistað textann í skrá og copy-paste hann inn í stjórnborðið í stað þess að slá hann inn í höndunum, en það er samt ekki mjög notalegt. Til að gera ferlið auðveldara geturðu sett skipunina inn í skriftu sem verður staðsett í PATH. Og þá þarftu aðeins að slá inn kóðann sem fékkst frá 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 

Ef þú setur handritið í connect~evilcorp~ geturðu einfaldlega skrifað í vélinni

connect_evil_corp 567987

En nú þarftu samt að hafa stjórnborðið sem openconnect er í gangi opið í af einhverjum ástæðum

Keyrir openconnect í bakgrunni

Sem betur fer sáu höfundar openconnect um okkur og bættu sérstökum lykli við forritið -bakgrunn sem gerir það að verkum að forritið virkar í bakgrunni eftir að það er opnað. Ef þú keyrir það svona geturðu lokað stjórnborðinu eftir ræsingu

#!/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  

Nú er bara ekki ljóst hvert logs fara. Almennt, við þurfum í raun ekki logs, en þú veist aldrei. openconnect getur beint þeim til syslog, þar sem þeim verður haldið öruggum og öruggum. þú þarft að bæta –syslog rofanum við skipunina

#!/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 svo kemur í ljós að openconnect virkar einhvers staðar í bakgrunni og truflar engan, en það er ekki ljóst hvernig á að stöðva það. Það er, þú getur auðvitað síað ps úttakið með grep og leitað að ferli sem inniheldur openconnect, en þetta er einhvern veginn leiðinlegt. Þakkir til höfunda sem hugsuðu um þetta líka. Openconnect er með lykil -pid-skrá, sem þú getur gefið openconnect fyrirmæli um að skrifa ferli auðkenni þess í skrá.

#!/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-pid

Nú geturðu alltaf drepið ferli með skipuninni

kill $(cat ~/vpn-pid)

Ef það er ekkert ferli, drepur mun bölva, en mun ekki kasta villu. Ef skráin er ekki til staðar, þá mun ekkert slæmt gerast heldur, svo þú getur örugglega drepið ferlið í fyrstu línu handritsins.

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-pid

Nú geturðu kveikt á tölvunni þinni, opnað stjórnborðið og keyrt skipunina og sent henni kóðann frá Google Authenticator. Síðan er hægt að negla niður vélina.

Án VPN-sneið. Í stað eftirmála

Það reyndist mjög erfitt að skilja hvernig á að lifa án VPN-sneiðar. Ég þurfti að lesa og googla mikið. Sem betur fer, eftir að hafa eytt svo miklum tíma í vandamál, voru tæknilegar handbækur og jafnvel man openconnect lesnar eins og spennandi skáldsögur.

Fyrir vikið komst ég að því að vpn-sneið, eins og innfædda handritið, breytir leiðartöflunni í aðskilin net.

Leiðartöflu

Í einföldu máli er þetta tafla í fyrsta dálknum sem inniheldur það sem heimilisfangið sem Linux vill fara í gegnum á að byrja á og í öðrum dálki hvaða netkort á að fara í gegnum á þessu heimilisfangi. Reyndar eru ræðumenn fleiri en þetta breytir ekki kjarnanum.

Til þess að skoða leiðartöfluna þarftu að keyra ip leiðarskipunina

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 

Hér er hver lína ábyrg fyrir því hvert þú þarft að fara til að senda skilaboð á eitthvert heimilisfang. Í fyrsta lagi er lýsing á því hvar heimilisfangið ætti að byrja. Til þess að skilja hvernig á að ákvarða að 192.168.0.0/16 þýðir að heimilisfangið ætti að byrja á 192.168 þarftu að gúgla hvað IP tölu maska ​​er. Eftir dev er nafn millistykkisins sem skilaboðin á að senda til.

Fyrir VPN bjó Linux til sýndarmillistykki - tun0. Línan tryggir að umferð fyrir öll heimilisföng sem byrja á 192.168 fari í gegnum hana

192.168.0.0/16 dev tun0 scope link 

Þú getur líka skoðað núverandi stöðu leiðartöflunnar með því að nota skipunina leið -n (IP vistföng eru snjall nafnleynd) Þessi skipun gefur niðurstöður á öðru formi og er almennt úrelt, en úttak hennar er oft að finna í handbókum á netinu og þú þarft að geta lesið hana.

Hvar IP tölu leiðar ætti að byrja má skilja út frá samsetningu Destination og Genmask dálkanna. Þeir hlutar IP tölunnar sem samsvara tölunum 255 í Genmask eru teknir með í reikninginn, en þeir þar sem 0 er ekki. Það er, samsetning áfangastaðar 192.168.0.0 og Genmask 255.255.255.0 þýðir að ef heimilisfangið byrjar á 192.168.0, þá mun beiðnin til þess fara eftir þessari leið. Og ef áfangastaður 192.168.0.0 en Genmask 255.255.0.0, þá munu beiðnir til netföng sem byrja á 192.168 fara eftir þessari leið

Til þess að komast að því hvað vpn-slice gerir í raun og veru ákvað ég að skoða stöðuna í töflunum fyrir og eftir

Áður en kveikt var á VPN var þetta svona

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 wlp3s0

Eftir að hafa hringt í openconnect án vpn-slice varð þetta svona

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 tun0

Og eftir að hafa hringt í openconnect ásamt vpn-sneið eins og þessum

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 tun0

Það má sjá að ef þú notar ekki vpn-slice, þá skrifar openconnect beinlínis að öll heimilisföng, nema þau sem eru sérstaklega tilgreind, verða að vera aðgengileg í gegnum vpn.

Hérna:

0.0.0.0         0.0.0.0         0.0.0.0         U     0      0        0 tun0

Þar við hliðina er strax sýnd önnur leið sem þarf að nota ef heimilisfangið sem Linux er að reyna að fara í gegnum passar ekki við neina grímu úr töflunni.

0.0.0.0         222.222.222.1   0.0.0.0         UG    600    0        0 wlp3s0

Það er þegar skrifað hér að í þessu tilfelli þarftu að nota venjulegan Wi-Fi millistykki.

Ég tel að VPN leiðin sé notuð vegna þess að hún er sú fyrsta í leiðartöflunni.

Og fræðilega séð, ef þú fjarlægir þessa sjálfgefna slóð úr leiðartöflunni, þá ætti í sambandi við dnsmasq openconnect að tryggja eðlilega notkun.

ég reyndi

route del default

Og allt virkaði.

Beina beiðnum til póstþjóns án vpn-sneiðar

En ég er líka með póstþjón með heimilisfanginu 555.555.555.555 sem þarf líka að komast í gegnum VPN. Einnig þarf að bæta við leiðinni að honum handvirkt.

ip route add 555.555.555.555 via dev tun0

Og nú er allt í lagi. Svo þú getur verið án vpn-sneiðar, en þú þarft að vita vel hvað þú ert að gera. Ég er núna að hugsa um að bæta við síðustu línuna í innfæddu openconnect handritinu að fjarlægja sjálfgefna leiðina og bæta við leið fyrir póstinn eftir að hafa tengst vpn, bara svo að það séu færri hreyfanlegir hlutar í hjólinu mínu.

Sennilega myndi þetta eftirmál vera nóg fyrir einhvern til að skilja hvernig á að setja upp VPN. En á meðan ég var að reyna að skilja hvað og hvernig ég ætti að gera, las ég töluvert af slíkum leiðbeiningum sem virka fyrir höfundinn, en af ​​einhverjum ástæðum virka ekki fyrir mig, og ég ákvað að bæta við hér öllum verkunum sem ég fann. Ég væri mjög ánægður með eitthvað svona.

Heimild: www.habr.com

Bæta við athugasemd